Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
On 1/2/20 1:30 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 30.12.19 13:14, Mauro Condarelli wrote:
>>
>>
>> On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
>>>
>>> Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
I am having problems with this patch.
Problem is "reset"command fails (for my board) with:
> => reset
> resetting ...
> ### ERROR ### Please RESET the board ###
I traced down problem to "drivers/sysreset/sysreset-uclass.c"
requesting
"uclass_first_device(UCLASS_SYSRESET, )", while
"drivers/reset/reset-mips.c"
defines:
> static const struct udevice_id mtmips_reset_ids[] = {
> { .compatible = "mediatek,mtmips-reset" },
> { }
> };
>
> U_BOOT_DRIVER(mtmips_reset) = {
> .name = "mtmips-reset",
> .id = UCLASS_RESET,
... so UCLASS_SYSRESET list is empty.
What am I doing wrong?
TiA!
Mauro
>>> do you have the according node with compatible string
>>> "mediatek,mtmips-reset" in your device-tree?
>> Yes, I do, but problem is elsewhere:
>> "reset" command looks for a UCLASS_SYSRESET while
>> drivers/reset/reset-mips.c
>> (implementing "mediatek,mtmips-reset") provides a UCLASS_RESET.
>>
>> I know too little about u-boot internals to understand which one I
>> should "fix" (if any).
>
> I just tested current mainline U-Boot (top-of-tree) on the GARDENA
> board and the reset works just fine:
>
> => reset
> resetting ...
>
>
> U-Boot 2020.01-rc5-00042-g6cb87cbb14 (Jan 02 2020 - 13:27:15 +0100)
>
> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: GARDENA smart Gateway (MT7688)
> DRAM: 128 MiB
> WDT: Started with servicing (60s timeout)
> Loading Environment from SPI Flash... SF: Detected XM25QH64A with page
> size 256 Bytes, erase size 4 KiB, total 8 MiB
> OK
> F-Data:factory-data version 1 detected
> Net: eth0: eth@1011
> Hit any key to stop autoboot: 0
>
> I didn't check the details of this mail thread, so I can't really
> comment on this. Your board is so similar to the GARDENA one (LinkIt)
> that it should work there as well. Do you gave some differences in
> your defconfig?
My defconfig looks very different, mainly due to not having (currently)
any network in u-boot, but I have USB strorage.
I attach the whole vocore2_defconfig.
To me it seems the only difference that *might* be relevant is I don't
have CONFIG_SYSRESET_SYSCON=y.
... enable... compile... load... test...
SUCCESS!!
That was it.
I was thinking reset should have been handled by "reset-mtmips.c" but
apparently "mfd syscon reboot driver" is needed.
THANKS.
I'll send another iteration of my patches soon after a bit of testing.
> Thanks,
> Stefan
>
Regards
Mauro
CONFIG_MIPS=y
CONFIG_SYS_TEXT_BASE=0x8001
CONFIG_ENV_SIZE=0x1000
CONFIG_ENV_OFFSET=0x00FFE000
CONFIG_ENV_SECT_SIZE=0x1000
CONFIG_ARCH_MTMIPS=y
CONFIG_BOARD_VOCORE2=y
CONFIG_MIPS_BOOT_FDT=y
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_SYS_BOOT_GET_CMDLINE=y
CONFIG_SYS_BOOT_GET_KBD=y
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_USE_BOOTARGS=y
CONFIG_LOGLEVEL=8
CONFIG_VERSION_VARIABLE=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_AUTOBOOT is not set
# CONFIG_BOOTM_NETBSD is not set
# CONFIG_BOOTM_PLAN9 is not set
# CONFIG_BOOTM_RTEMS is not set
# CONFIG_BOOTM_VXWORKS is not set
# CONFIG_CMD_XIMG is not set
CONFIG_RANDOM_UUID=y
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_MTD=y
CONFIG_CMD_PART=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)"
# CONFIG_ISO_PARTITION is not set
CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_ADDR=0x00FFE000
# CONFIG_NET is not set
# CONFIG_DM_DEVICE_REMOVE is not set
# CONFIG_INPUT is not set
CONFIG_LED=y
CONFIG_LED_BLINK=y
CONFIG_LED_GPIO=y
CONFIG_MMC=y
CONFIG_DM_MMC=y
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MMC_MTK=y
CONFIG_MTD=y
CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_MTD=y
# CONFIG_DM_ETH is not set
# CONFIG_RAM_ROCKCHIP_DEBUG is not set
CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_CONS_INDEX=3
CONFIG_SPI=y
CONFIG_MT7621_SPI=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_STORAGE=y
CONFIG_LZMA=y
CONFIG_LZO=y
Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
Hi Mauro,
On 30.12.19 13:14, Mauro Condarelli wrote:
On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
I am having problems with this patch.
Problem is "reset"command fails (for my board) with:
=> reset
resetting ...
### ERROR ### Please RESET the board ###
I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
"uclass_first_device(UCLASS_SYSRESET, )", while
"drivers/reset/reset-mips.c"
defines:
static const struct udevice_id mtmips_reset_ids[] = {
{ .compatible = "mediatek,mtmips-reset" },
{ }
};
U_BOOT_DRIVER(mtmips_reset) = {
.name = "mtmips-reset",
.id = UCLASS_RESET,
... so UCLASS_SYSRESET list is empty.
What am I doing wrong?
TiA!
Mauro
do you have the according node with compatible string
"mediatek,mtmips-reset" in your device-tree?
Yes, I do, but problem is elsewhere:
"reset" command looks for a UCLASS_SYSRESET while
drivers/reset/reset-mips.c
(implementing "mediatek,mtmips-reset") provides a UCLASS_RESET.
I know too little about u-boot internals to understand which one I
should "fix" (if any).
I just tested current mainline U-Boot (top-of-tree) on the GARDENA
board and the reset works just fine:
=> reset
resetting ...
U-Boot 2020.01-rc5-00042-g6cb87cbb14 (Jan 02 2020 - 13:27:15 +0100)
CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
Model: GARDENA smart Gateway (MT7688)
DRAM: 128 MiB
WDT: Started with servicing (60s timeout)
Loading Environment from SPI Flash... SF: Detected XM25QH64A with page size 256
Bytes, erase size 4 KiB, total 8 MiB
OK
F-Data:factory-data version 1 detected
Net: eth0: eth@1011
Hit any key to stop autoboot: 0
I didn't check the details of this mail thread, so I can't really
comment on this. Your board is so similar to the GARDENA one (LinkIt)
that it should work there as well. Do you gave some differences in
your defconfig?
Thanks,
Stefan
Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
>
> Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
>> I am having problems with this patch.
>>
>> Problem is "reset"command fails (for my board) with:
>>> => reset
>>> resetting ...
>>> ### ERROR ### Please RESET the board ###
>> I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
>> "uclass_first_device(UCLASS_SYSRESET, )", while
>> "drivers/reset/reset-mips.c"
>> defines:
>>> static const struct udevice_id mtmips_reset_ids[] = {
>>> { .compatible = "mediatek,mtmips-reset" },
>>> { }
>>> };
>>>
>>> U_BOOT_DRIVER(mtmips_reset) = {
>>> .name = "mtmips-reset",
>>> .id = UCLASS_RESET,
>> ... so UCLASS_SYSRESET list is empty.
>>
>> What am I doing wrong?
>> TiA!
>> Mauro
>>
> do you have the according node with compatible string
> "mediatek,mtmips-reset" in your device-tree?
Yes, I do, but problem is elsewhere:
"reset" command looks for a UCLASS_SYSRESET while
drivers/reset/reset-mips.c
(implementing "mediatek,mtmips-reset") provides a UCLASS_RESET.
I know too little about u-boot internals to understand which one I
should "fix" (if any).
Thanks
Mauro
Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
>
> Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
>> I am having problems with this patch.
>>
>> Problem is "reset"command fails (for my board) with:
>>> => reset
>>> resetting ...
>>> ### ERROR ### Please RESET the board ###
>> I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
>> "uclass_first_device(UCLASS_SYSRESET, )", while
>> "drivers/reset/reset-mips.c"
>> defines:
>>> static const struct udevice_id mtmips_reset_ids[] = {
>>> { .compatible = "mediatek,mtmips-reset" },
>>> { }
>>> };
>>>
>>> U_BOOT_DRIVER(mtmips_reset) = {
>>> .name = "mtmips-reset",
>>> .id = UCLASS_RESET,
>> ... so UCLASS_SYSRESET list is empty.
>>
>> What am I doing wrong?
>> TiA!
>> Mauro
>>
> do you have the according node with compatible string
> "mediatek,mtmips-reset" in your device-tree?
I have the standard mt7628a.dtsi contents:
...
palmbus@1000 {
compatible = "palmbus", "simple-bus";
reg = <0x1000 0x20>;
ranges = <0x0 0x1000 0x1F>;
...
rstctrl: rstctrl@0x34 {
reg = <0x34 0x4>;
compatible = "mediatek,mtmips-reset";
#reset-cells = <1>;
};
...
I tried adding the "old-style":
...
resetc: reset-controller {
compatible = "ralink,rt2880-reset";
#reset-cells = <1>;
};
...
but, apparently, it makes no difference.
Shouldn't that be enough?
TiA
MAuro
Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
> I am having problems with this patch.
>
> Problem is "reset"command fails (for my board) with:
>> => reset
>> resetting ...
>> ### ERROR ### Please RESET the board ###
> I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
> "uclass_first_device(UCLASS_SYSRESET, )", while
> "drivers/reset/reset-mips.c"
> defines:
>> static const struct udevice_id mtmips_reset_ids[] = {
>> { .compatible = "mediatek,mtmips-reset" },
>> { }
>> };
>>
>> U_BOOT_DRIVER(mtmips_reset) = {
>> .name = "mtmips-reset",
>> .id = UCLASS_RESET,
> ... so UCLASS_SYSRESET list is empty.
>
> What am I doing wrong?
> TiA!
> Mauro
>
do you have the according node with compatible string
"mediatek,mtmips-reset" in your device-tree?
--
- Daniel
[U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
I am having problems with this patch.
Problem is "reset"command fails (for my board) with:
> => reset
> resetting ...
> ### ERROR ### Please RESET the board ###
I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
"uclass_first_device(UCLASS_SYSRESET, )", while
"drivers/reset/reset-mips.c"
defines:
> static const struct udevice_id mtmips_reset_ids[] = {
> { .compatible = "mediatek,mtmips-reset" },
> { }
> };
>
> U_BOOT_DRIVER(mtmips_reset) = {
> .name = "mtmips-reset",
> .id = UCLASS_RESET,
... so UCLASS_SYSRESET list is empty.
What am I doing wrong?
TiA!
Mauro
Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
On Wed, 2019-08-28 at 15:18 +0200, Stefan Roese wrote:
> On 28.08.19 08:37, Weijie Gao wrote:
> > This patch updates reset controller node for mt7628
> >
> > Signed-off-by: Weijie Gao
> > ---
> > arch/mips/dts/mt7628a.dtsi | 36
> > 1 file changed, 24 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
> > index f07de1b611..0e2b6598ea 100644
> > --- a/arch/mips/dts/mt7628a.dtsi
> > +++ b/arch/mips/dts/mt7628a.dtsi
> > @@ -1,4 +1,5 @@
> > // SPDX-License-Identifier: GPL-2.0
> > +#include
> >
> > / {
> > #address-cells = <1>;
> > @@ -16,11 +17,6 @@
> > };
> > };
> >
> > - resetc: reset-controller {
> > - compatible = "ralink,rt2880-reset";
> > - #reset-cells = <1>;
> > - };
> > -
> > cpuintc: interrupt-controller {
> > #address-cells = <0>;
> > #interrupt-cells = <1>;
> > @@ -48,6 +44,12 @@
> > mask = <0x1>;
> > };
> >
> > + rstctrl: rstctrl@0x34 {
> > + reg = <0x34 0x4>;
> > + compatible = "mediatek,mtmips-reset";
> > + #reset-cells = <1>;
> > + };
> > +
> > pinctrl: pinctrl@60 {
> > compatible = "mediatek,mt7628-pinctrl";
> > reg = <0x3c 0x2c>, <0x1300 0x100>;
> > @@ -202,7 +204,7 @@
> > compatible = "ralink,mt7628a-wdt",
> > "mediatek,mt7621-wdt";
> > reg = <0x100 0x30>;
> >
> > - resets = < 8>;
> > + resets = < MT7628_TIMER_RST>;
>
> I like this patch. But we should always keep in mind to stay in sync (or sync
> in the future) with the Linux DT sources. And in Linux currently, its the
> "old"
> syntax that you are removing with this patch.
>
> Do you plan to update the Linux DT as well, so that the bindings match again?
>
> Thanks,
> Stefan
I agree with that. At lease a reset controller won't make things
complex.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
On 28.08.19 08:37, Weijie Gao wrote:
This patch updates reset controller node for mt7628
Signed-off-by: Weijie Gao
---
arch/mips/dts/mt7628a.dtsi | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index f07de1b611..0e2b6598ea 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -1,4 +1,5 @@
// SPDX-License-Identifier: GPL-2.0
+#include
/ {
#address-cells = <1>;
@@ -16,11 +17,6 @@
};
};
- resetc: reset-controller {
- compatible = "ralink,rt2880-reset";
- #reset-cells = <1>;
- };
-
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
@@ -48,6 +44,12 @@
mask = <0x1>;
};
+ rstctrl: rstctrl@0x34 {
+ reg = <0x34 0x4>;
+ compatible = "mediatek,mtmips-reset";
+ #reset-cells = <1>;
+ };
+
pinctrl: pinctrl@60 {
compatible = "mediatek,mt7628-pinctrl";
reg = <0x3c 0x2c>, <0x1300 0x100>;
@@ -202,7 +204,7 @@
compatible = "ralink,mt7628a-wdt",
"mediatek,mt7621-wdt";
reg = <0x100 0x30>;
- resets = < 8>;
+ resets = < MT7628_TIMER_RST>;
I like this patch. But we should always keep in mind to stay in sync (or sync
in the future) with the Linux DT sources. And in Linux currently, its the "old"
syntax that you are removing with this patch.
Do you plan to update the Linux DT as well, so that the bindings match again?
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628
This patch updates reset controller node for mt7628
Signed-off-by: Weijie Gao
---
arch/mips/dts/mt7628a.dtsi | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index f07de1b611..0e2b6598ea 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -1,4 +1,5 @@
// SPDX-License-Identifier: GPL-2.0
+#include
/ {
#address-cells = <1>;
@@ -16,11 +17,6 @@
};
};
- resetc: reset-controller {
- compatible = "ralink,rt2880-reset";
- #reset-cells = <1>;
- };
-
cpuintc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
@@ -48,6 +44,12 @@
mask = <0x1>;
};
+ rstctrl: rstctrl@0x34 {
+ reg = <0x34 0x4>;
+ compatible = "mediatek,mtmips-reset";
+ #reset-cells = <1>;
+ };
+
pinctrl: pinctrl@60 {
compatible = "mediatek,mt7628-pinctrl";
reg = <0x3c 0x2c>, <0x1300 0x100>;
@@ -202,7 +204,7 @@
compatible = "ralink,mt7628a-wdt",
"mediatek,mt7621-wdt";
reg = <0x100 0x30>;
- resets = < 8>;
+ resets = < MT7628_TIMER_RST>;
reset-names = "wdt";
interrupt-parent = <>;
@@ -216,7 +218,7 @@
interrupt-controller;
#interrupt-cells = <1>;
- resets = < 9>;
+ resets = < MT7628_INT_RST>;
reset-names = "intc";
interrupt-parent = <>;
@@ -239,6 +241,9 @@
compatible = "mtk,mt7628-gpio", "mtk,mt7621-gpio";
reg = <0x600 0x100>;
+ resets = < MT7628_PIO_RST>;
+ reset-names = "pio";
+
interrupt-parent = <>;
interrupts = <6>;
@@ -267,6 +272,10 @@
spi0: spi@b00 {
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x40>;
+
+ resets = < MT7628_SPI_RST>;
+ reset-names = "spi";
+
#address-cells = <1>;
#size-cells = <0>;
@@ -282,7 +291,7 @@
clock-frequency = <4000>;
- resets = < 12>;
+ resets = < MT7628_UART0_RST>;
reset-names = "uart0";
interrupt-parent = <>;
@@ -300,7 +309,7 @@
clock-frequency = <4000>;
- resets = < 19>;
+ resets = < MT7628_UART1_RST>;
reset-names = "uart1";
interrupt-parent = <>;
@@ -318,7 +327,7 @@
clock-frequency = <4000>;
- resets = < 20>;
+ resets = < MT7628_UART2_RST>;
reset-names = "uart2";
interrupt-parent = <>;
@@ -333,6 +342,9 @@
reg = <0x1010 0x1
0x1011 0x8000>;
+ resets = < MT7628_EPHY_RST>;
+ reset-names = "ephy";
+
syscon = <>;
};
@@ -343,8 +355,8 @@
#phy-cells = <0>;
ralink,sysctl = <>;
- resets = < 22 25>;
- reset-names = "host", "device";
+ resets = < MT7628_UPHY_RST>;
+ reset-names = "phy";
};
ehci@101c {
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
