net: designware: frequent network problem like CPU not owner of tx frame

[LABBE Corentin]

Hello

We have an HSDK board in kernelCI, and it fail often to do networking tasks. 
(getting image via tftp)
Example:
tftp 0x8200 2156673/tftp-deploy-l8y_ehqa/kernel/uImage
Speed: 100, full duplex
Using ethernet@f0008000 device
TFTP from server 10.201.1.3; our IP address is 10.201.4.179
Filename '2156673/tftp-deploy-l8y_ehqa/kernel/uImage'.
Load address: 0x8200
Loading: *␈CPU not owner of tx frame
CPU not owner of tx frame
CPU not owner of tx frame
CPU not owner of tx frame
ARP Retry count exceeded; starting again
Memory error exception @ 0xfffe
ECR:0x0001
RET:0xfffe
BLINK:  0xbffb04e2
STAT32: 0x00080400
GP: 0x1003e000   r25: 0xbfd92ee0
BTA: 0xbffc5744  SP: 0xbfd92d60  FP: 0x
LPS: 0x11f2 LPE: 0x11fa LPC: 0x
r00: 0x r01: 0x r02: 0x 
r03: 0x r04: 0x r05: 0xbfd92d54 
r06: 0xbffdc700 r07: 0x r08: 0xf0020028 
r09: 0x1003e2b0 r10: 0x8000 r11: 0x000e 
r12: 0x0010 r13: 0xbfda6218 r14: 0xbfd933b8 
r15: 0x0003 r16: 0x r17: 0x0003 
r18: 0xbffeff90 r19: 0x r20: 0xbfd949c8 
r21: 0x r22: 0x r23: 0x 
r24: 0x 
Resetting CPU ...
### ERROR ### Please RESET the board ###

tftp 0x8200 2156279/tftp-deploy-o6vloihf/kernel/uImage
Speed: 100, full duplex
Using ethernet@f0008000 device
TFTP from server 10.201.1.3; our IP address is 10.201.3.203
Filename '2156279/tftp-deploy-o6vloihf/kernel/uImage'.
Load address: 0x8200
Loading: *␈
ARP Retry count exceeded; starting again

tftp 0x8200 2155981/tftp-deploy-wm6qiwhy/kernel/uImage
Speed: 100, full duplex
Using ethernet@f0008000 device
TFTP from server 10.201.1.3; our IP address is 10.201.4.197
Filename '2155981/tftp-deploy-wm6qiwhy/kernel/uImage'.
Load address: 0x8200
Loading: *␈CPU not owner of tx frame
CPU not owner of tx frame
[...] (lot of CPU not owner of tx frame)
CPU not owner of tx frame
ARP Retry count exceeded; starting again

I tried to update uboot until 2022.04, without any change.

Regards

Re: Boot regression on am335x-hs-evm

[LABBE Corentin]

Le Fri, Jun 10, 2022 at 11:48:34AM -0400, Tom Rini a écrit :
> On Fri, Jun 10, 2022 at 05:45:04PM +0200, LABBE Corentin wrote:
> > Le Fri, Jun 10, 2022 at 11:01:47AM -0400, Tom Rini a écrit :
> > > On Fri, Jun 10, 2022 at 04:51:12PM +0200, LABBE Corentin wrote:
> > > > Le Fri, Jun 10, 2022 at 08:16:10AM -0400, Tom Rini a écrit :
> > > > > On Fri, Jun 10, 2022 at 11:59:23AM +0200, LABBE Corentin wrote:
> > > > > > Hello
> > > > > > 
> > > > > > I hit a boot regression on am335x-hs-evm.
> > > > > > On current uboot, the board does not boot at all.
> > > > > > This board uses both MLO and u-boot.img and only MLO was the 
> > > > > > problem.
> > > > > > 
> > > > > > After a bisect, I found that e41651fffda7 ("dm: Support parent 
> > > > > > devices with of-platdata") was the problem.
> > > > > > Reverting this patch lead to a success boot.
> > > > > > 
> > > > > > I cutdown the revert to a minimal fix:
> > > > > > --- a/drivers/core/lists.c
> > > > > > +++ b/drivers/core/lists.c
> > > > > > @@ -120,6 +120,7 @@ int lists_bind_drivers(struct udevice *parent, 
> > > > > > bool pre_reloc_only)
> > > > > > int ret;
> > > > > >  
> > > > > > ret = bind_drivers_pass(parent, pre_reloc_only);
> > > > > > +   return ret;
> > > > > > if (!ret)
> > > > > > break;
> > > > > > if (ret != -EAGAIN && !result)
> > > > > > 
> > > > > > I cannot debug further since printf() is not working at this stage.
> > > > > > 
> > > > > > Since I wanted to know which error was badly handled, I tried to do 
> > > > > > this:
> > > > > > --- a/arch/arm/mach-omap2/sec-common.c
> > > > > > +++ b/arch/arm/mach-omap2/sec-common.c
> > > > > > @@ -111,6 +111,8 @@ static u32 find_sig_start(char *image, size_t 
> > > > > > size)
> > > > > > return 0;
> > > > > >  }
> > > > > >  
> > > > > > +extern int errorcount;
> > > > > > +
> > > > > >  int secure_boot_verify_image(void **image, size_t *size)
> > > > > >  {
> > > > > > int result = 1;
> > > > > > @@ -178,6 +180,7 @@ auth_exit:
> > > > > >  * via YMODEM. This is done to avoid disturbing the YMODEM 
> > > > > > serial
> > > > > >  * protocol transactions.
> > > > > >  */
> > > > > > +   printf("ERRORCOUNT %d\n", errorcount);
> > > > > > if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
> > > > > >   IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
> > > > > >   spl_boot_device() == BOOT_DEVICE_UART))
> > > > > > --- a/drivers/core/lists.c
> > > > > > +++ b/drivers/core/lists.c
> > > > > > @@ -20,6 +20,10 @@
> > > > > >  #include 
> > > > > >  #include 
> > > > > >  
> > > > > > +static int _errorcount;
> > > > > > +int errorlist[1024];
> > > > > > +int errorcount;
> > > > > > +
> > > > > >  struct driver *lists_driver_lookup_name(const char *name)
> > > > > >  {
> > > > > > struct driver *drv =
> > > > > > @@ -120,8 +124,9 @@ int lists_bind_drivers(struct udevice *parent, 
> > > > > > bool pre_reloc_only)
> > > > > > int ret;
> > > > > >  
> > > > > > ret = bind_drivers_pass(parent, pre_reloc_only);
> > > > > > -   if (!ret)
> > > > > > -   break;
> > > > > > +   errorlist[_errorcount] = ret;
> > > > > > +   _errorcount++;
> > > > > > +   errorcount = _errorcount;
> > > > > > if (ret != -EAGAIN && !result)
> > > > > > result = ret;
> > > > > > }
> > > &g

Re: Boot regression on am335x-hs-evm

[LABBE Corentin]

Le Fri, Jun 10, 2022 at 11:01:47AM -0400, Tom Rini a écrit :
> On Fri, Jun 10, 2022 at 04:51:12PM +0200, LABBE Corentin wrote:
> > Le Fri, Jun 10, 2022 at 08:16:10AM -0400, Tom Rini a écrit :
> > > On Fri, Jun 10, 2022 at 11:59:23AM +0200, LABBE Corentin wrote:
> > > > Hello
> > > > 
> > > > I hit a boot regression on am335x-hs-evm.
> > > > On current uboot, the board does not boot at all.
> > > > This board uses both MLO and u-boot.img and only MLO was the problem.
> > > > 
> > > > After a bisect, I found that e41651fffda7 ("dm: Support parent devices 
> > > > with of-platdata") was the problem.
> > > > Reverting this patch lead to a success boot.
> > > > 
> > > > I cutdown the revert to a minimal fix:
> > > > --- a/drivers/core/lists.c
> > > > +++ b/drivers/core/lists.c
> > > > @@ -120,6 +120,7 @@ int lists_bind_drivers(struct udevice *parent, bool 
> > > > pre_reloc_only)
> > > > int ret;
> > > >  
> > > > ret = bind_drivers_pass(parent, pre_reloc_only);
> > > > +   return ret;
> > > > if (!ret)
> > > > break;
> > > > if (ret != -EAGAIN && !result)
> > > > 
> > > > I cannot debug further since printf() is not working at this stage.
> > > > 
> > > > Since I wanted to know which error was badly handled, I tried to do 
> > > > this:
> > > > --- a/arch/arm/mach-omap2/sec-common.c
> > > > +++ b/arch/arm/mach-omap2/sec-common.c
> > > > @@ -111,6 +111,8 @@ static u32 find_sig_start(char *image, size_t size)
> > > > return 0;
> > > >  }
> > > >  
> > > > +extern int errorcount;
> > > > +
> > > >  int secure_boot_verify_image(void **image, size_t *size)
> > > >  {
> > > > int result = 1;
> > > > @@ -178,6 +180,7 @@ auth_exit:
> > > >  * via YMODEM. This is done to avoid disturbing the YMODEM 
> > > > serial
> > > >  * protocol transactions.
> > > >  */
> > > > +   printf("ERRORCOUNT %d\n", errorcount);
> > > > if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
> > > >   IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
> > > >   spl_boot_device() == BOOT_DEVICE_UART))
> > > > --- a/drivers/core/lists.c
> > > > +++ b/drivers/core/lists.c
> > > > @@ -20,6 +20,10 @@
> > > >  #include 
> > > >  #include 
> > > >  
> > > > +static int _errorcount;
> > > > +int errorlist[1024];
> > > > +int errorcount;
> > > > +
> > > >  struct driver *lists_driver_lookup_name(const char *name)
> > > >  {
> > > > struct driver *drv =
> > > > @@ -120,8 +124,9 @@ int lists_bind_drivers(struct udevice *parent, bool 
> > > > pre_reloc_only)
> > > > int ret;
> > > >  
> > > > ret = bind_drivers_pass(parent, pre_reloc_only);
> > > > -   if (!ret)
> > > > -   break;
> > > > +   errorlist[_errorcount] = ret;
> > > > +   _errorcount++;
> > > > +   errorcount = _errorcount;
> > > > if (ret != -EAGAIN && !result)
> > > > result = ret;
> > > > }
> > > > 
> > > > But errorcount is always 0 which is puzzling me since according to my 
> > > > think, lists_bind_drivers() is ran before secure_boot_verify_image().
> > > > 
> > > > Any idea on how to debug further ?
> > > 
> > > You should be able to enable DEBUG_UART and get output that way.  But
> > > it's likely something related to the space constraints of the HS chip
> > > rather than GP.
> > > 
> > 
> > Hello
> > 
> > Thanks for your suggestion, I successfully got futher with:
> > diff --git a/drivers/core/lists.c b/drivers/core/lists.c
> > index b23ee3030e..415ba814f1 100644
> > --- a/drivers/core/lists.c
> > +++ b/drivers/core/lists.c
> > @@ -111,6 +111,8 @@ int lists_bind_drivers(struct udevice *parent, bool 
> > pre_reloc_only)
> > int result = 0;
> > int pass;
> 

Re: Boot regression on am335x-hs-evm

[LABBE Corentin]

Le Fri, Jun 10, 2022 at 08:16:10AM -0400, Tom Rini a écrit :
> On Fri, Jun 10, 2022 at 11:59:23AM +0200, LABBE Corentin wrote:
> > Hello
> > 
> > I hit a boot regression on am335x-hs-evm.
> > On current uboot, the board does not boot at all.
> > This board uses both MLO and u-boot.img and only MLO was the problem.
> > 
> > After a bisect, I found that e41651fffda7 ("dm: Support parent devices with 
> > of-platdata") was the problem.
> > Reverting this patch lead to a success boot.
> > 
> > I cutdown the revert to a minimal fix:
> > --- a/drivers/core/lists.c
> > +++ b/drivers/core/lists.c
> > @@ -120,6 +120,7 @@ int lists_bind_drivers(struct udevice *parent, bool 
> > pre_reloc_only)
> > int ret;
> >  
> > ret = bind_drivers_pass(parent, pre_reloc_only);
> > +   return ret;
> > if (!ret)
> > break;
> > if (ret != -EAGAIN && !result)
> > 
> > I cannot debug further since printf() is not working at this stage.
> > 
> > Since I wanted to know which error was badly handled, I tried to do this:
> > --- a/arch/arm/mach-omap2/sec-common.c
> > +++ b/arch/arm/mach-omap2/sec-common.c
> > @@ -111,6 +111,8 @@ static u32 find_sig_start(char *image, size_t size)
> > return 0;
> >  }
> >  
> > +extern int errorcount;
> > +
> >  int secure_boot_verify_image(void **image, size_t *size)
> >  {
> > int result = 1;
> > @@ -178,6 +180,7 @@ auth_exit:
> >  * via YMODEM. This is done to avoid disturbing the YMODEM serial
> >  * protocol transactions.
> >  */
> > +   printf("ERRORCOUNT %d\n", errorcount);
> > if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
> >   IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
> >   spl_boot_device() == BOOT_DEVICE_UART))
> > --- a/drivers/core/lists.c
> > +++ b/drivers/core/lists.c
> > @@ -20,6 +20,10 @@
> >  #include 
> >  #include 
> >  
> > +static int _errorcount;
> > +int errorlist[1024];
> > +int errorcount;
> > +
> >  struct driver *lists_driver_lookup_name(const char *name)
> >  {
> > struct driver *drv =
> > @@ -120,8 +124,9 @@ int lists_bind_drivers(struct udevice *parent, bool 
> > pre_reloc_only)
> > int ret;
> >  
> > ret = bind_drivers_pass(parent, pre_reloc_only);
> > -   if (!ret)
> > -   break;
> > +   errorlist[_errorcount] = ret;
> > +   _errorcount++;
> > +   errorcount = _errorcount;
> > if (ret != -EAGAIN && !result)
> > result = ret;
> > }
> > 
> > But errorcount is always 0 which is puzzling me since according to my 
> > think, lists_bind_drivers() is ran before secure_boot_verify_image().
> > 
> > Any idea on how to debug further ?
> 
> You should be able to enable DEBUG_UART and get output that way.  But
> it's likely something related to the space constraints of the HS chip
> rather than GP.
> 

Hello

Thanks for your suggestion, I successfully got futher with:
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index b23ee3030e..415ba814f1 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -111,6 +111,8 @@ int lists_bind_drivers(struct udevice *parent, bool 
pre_reloc_only)
int result = 0;
int pass;
 
+   debug_uart_init();
+
/*
 * 10 passes is 10 levels deep in the devicetree, which is plenty. If
 * OF_PLATDATA_PARENT is not enabled, then bind_drivers_pass() will
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index b4805a2e4e..7ab059b4ea 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -158,6 +158,7 @@ config TPL_DM_SERIAL
 
 config DEBUG_UART
bool "Enable an early debug UART for debugging"
+   default y
help
  The debug UART is intended for use very early in U-Boot to debug
  problems when an ICE or other debug mechanism is not available.
@@ -185,7 +186,7 @@ config DEBUG_UART
 choice
prompt "Select which UART will provide the debug UART"
depends on DEBUG_UART
-   default DEBUG_UART_NS16550
+   default DEBUG_UART_OMAP
 
 config DEBUG_UART_ALTERA_JTAGUART
bool "Altera JTAG UART"
@@ -406,7 +407,7 @@ endchoice
 config DEBUG_UART_BASE
hex "Base address of UART"
depends on DEBUG_UART
-   default 0 if DEBUG_UART_SANDBOX
+   

Boot regression on am335x-hs-evm

[LABBE Corentin]

Hello

I hit a boot regression on am335x-hs-evm.
On current uboot, the board does not boot at all.
This board uses both MLO and u-boot.img and only MLO was the problem.

After a bisect, I found that e41651fffda7 ("dm: Support parent devices with 
of-platdata") was the problem.
Reverting this patch lead to a success boot.

I cutdown the revert to a minimal fix:
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -120,6 +120,7 @@ int lists_bind_drivers(struct udevice *parent, bool 
pre_reloc_only)
int ret;
 
ret = bind_drivers_pass(parent, pre_reloc_only);
+   return ret;
if (!ret)
break;
if (ret != -EAGAIN && !result)

I cannot debug further since printf() is not working at this stage.

Since I wanted to know which error was badly handled, I tried to do this:
--- a/arch/arm/mach-omap2/sec-common.c
+++ b/arch/arm/mach-omap2/sec-common.c
@@ -111,6 +111,8 @@ static u32 find_sig_start(char *image, size_t size)
return 0;
 }
 
+extern int errorcount;
+
 int secure_boot_verify_image(void **image, size_t *size)
 {
int result = 1;
@@ -178,6 +180,7 @@ auth_exit:
 * via YMODEM. This is done to avoid disturbing the YMODEM serial
 * protocol transactions.
 */
+   printf("ERRORCOUNT %d\n", errorcount);
if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
  IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
  spl_boot_device() == BOOT_DEVICE_UART))
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -20,6 +20,10 @@
 #include 
 #include 
 
+static int _errorcount;
+int errorlist[1024];
+int errorcount;
+
 struct driver *lists_driver_lookup_name(const char *name)
 {
struct driver *drv =
@@ -120,8 +124,9 @@ int lists_bind_drivers(struct udevice *parent, bool 
pre_reloc_only)
int ret;
 
ret = bind_drivers_pass(parent, pre_reloc_only);
-   if (!ret)
-   break;
+   errorlist[_errorcount] = ret;
+   _errorcount++;
+   errorcount = _errorcount;
if (ret != -EAGAIN && !result)
result = ret;
}

But errorcount is always 0 which is puzzling me since according to my think, 
lists_bind_drivers() is ran before secure_boot_verify_image().

Any idea on how to debug further ?

Thanks
Regards

Re: [PATCH v2] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY

[LABBE Corentin]

On Wed, May 13, 2020 at 12:38:58PM +0200, Matthias Brugger wrote:
> 
> 
> On 13/05/2020 10:07, Corentin Labbe wrote:
> > As discussed at 
> > https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/
> > the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY.
> > Without it, booting with an initrd fail.
> > 
> > Signed-off-by: Corentin Labbe 
> > ---
> > Changes since v1:
> > - added fix for rpi_4_32b_defconfig
> > 
> >  configs/rpi_4_32b_defconfig | 2 +-
> >  configs/rpi_4_defconfig | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> 
> Any reason why you don't added rpi_arm64_defconfig?
> 

I didnt see rpi4 in its name so out of context of my changes.
I believe it is a common defconfig for all rpis, in that case touching it need 
more testing.
So I propose to apply the change for rpi4 which are tested now.
And later I could try to test rpi_arm64_defconfig on rpi4 AND other rpis..

> 
> > diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
> > index 8d262d89b4..f2a975891c 100644
> > --- a/configs/rpi_4_32b_defconfig
> > +++ b/configs/rpi_4_32b_defconfig
> > @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000
> >  CONFIG_NR_DRAM_BANKS=2
> >  CONFIG_DISTRO_DEFAULTS=y
> >  CONFIG_OF_BOARD_SETUP=y
> > -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
> > +CONFIG_ARCH_FIXUP_FDT_MEMORY=y
> >  CONFIG_MISC_INIT_R=y
> >  # CONFIG_DISPLAY_CPUINFO is not set
> >  # CONFIG_DISPLAY_BOARDINFO is not set
> > diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
> > index 2a0cea4222..f1c8f5ef7d 100644
> > --- a/configs/rpi_4_defconfig
> > +++ b/configs/rpi_4_defconfig
> > @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000
> >  CONFIG_NR_DRAM_BANKS=2
> >  CONFIG_DISTRO_DEFAULTS=y
> >  CONFIG_OF_BOARD_SETUP=y
> > -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
> > +CONFIG_ARCH_FIXUP_FDT_MEMORY=y
> >  CONFIG_MISC_INIT_R=y
> >  # CONFIG_DISPLAY_CPUINFO is not set
> >  # CONFIG_DISPLAY_BOARDINFO is not set
> > 

Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY

[LABBE Corentin]

On Tue, May 12, 2020 at 12:17:25PM +0200, Matthias Brugger wrote:
> Hi Corentin,
> 
> On 09/05/2020 01:25, Matthias Brugger wrote:
> > On 09/05/2020 01:18, Matthias Brugger wrote:
> >> Hi Corentin,
> >>
> >> On 24/04/2020 14:51, LABBE Corentin wrote:
> >>> On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote:
> >>>> As discussed at 
> >>>> https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/
> >>>> the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY.
> >>>> Without it, booting with an initrd fail.
> >>>>
> >>>> Signed-off-by: Corentin Labbe 
> >>>> ---
> >>>>  configs/rpi_4_defconfig | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
> >>>> index 6d148dab07..8540b3c927 100644
> >>>> --- a/configs/rpi_4_defconfig
> >>>> +++ b/configs/rpi_4_defconfig
> >>>> @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000
> >>>>  CONFIG_NR_DRAM_BANKS=2
> >>>>  CONFIG_DISTRO_DEFAULTS=y
> >>>>  CONFIG_OF_BOARD_SETUP=y
> >>>> -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
> >>>> +CONFIG_ARCH_FIXUP_FDT_MEMORY=y
> >>>>  CONFIG_MISC_INIT_R=y
> >>>>  # CONFIG_DISPLAY_CPUINFO is not set
> >>>>  # CONFIG_DISPLAY_BOARDINFO is not set
> >>>> -- 
> >>>
> >>
> >> Patch looks good, but is there any reason why you don't enable it for
> >> rpi_4_32b_defconfig and rpi_arm64_defconfig?
> >>
> > 
> > And please add me to the recipients list, otherwise this patches most 
> > probably
> > get lost.
> > 
> 
> Are you planning to send a new version of the patch which enables the option 
> for
> all configs?
> 

Yes, I will.
But note that I didnt tested rpi_4_32b_defconfig.
And I am currently unable to test it.
If you want it to be tested, could you apply this patch as is, and I will 
submit the rpi_4_32b_defconfig later.

Regards

Re: [PATCH] rpi_4_defconfig: add missing CONFIG_ARCH_FIXUP_FDT_MEMORY

[LABBE Corentin]

On Tue, Mar 31, 2020 at 12:26:35PM +, Corentin Labbe wrote:
> As discussed at 
> https://lore.kernel.org/linux-arm-kernel/b726290c-1038-3771-5187-6ac370bc9...@arm.com/T/
> the defconfig for rpi4 miss CONFIG_ARCH_FIXUP_FDT_MEMORY.
> Without it, booting with an initrd fail.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  configs/rpi_4_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
> index 6d148dab07..8540b3c927 100644
> --- a/configs/rpi_4_defconfig
> +++ b/configs/rpi_4_defconfig
> @@ -7,7 +7,7 @@ CONFIG_ENV_SIZE=0x4000
>  CONFIG_NR_DRAM_BANKS=2
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_OF_BOARD_SETUP=y
> -# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
> +CONFIG_ARCH_FIXUP_FDT_MEMORY=y
>  CONFIG_MISC_INIT_R=y
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
> -- 

Hello

gentle ping

Regards

Re: RPI4: fail too boot with an initrd

[LABBE Corentin]

On Mon, Feb 17, 2020 at 02:07:09PM +0100, Matthias Brugger wrote:
> 
> 
> On 17/02/2020 13:53, LABBE Corentin wrote:
> > On Mon, Feb 17, 2020 at 11:50:04AM +0100, Matthias Brugger wrote:
> >>
> >>
> >> On 17/02/2020 11:37, LABBE Corentin wrote:
> >>> On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
> >>>> Hi Corentin,
> >>>>
> >>>> On 14/02/2020 13:27, LABBE Corentin wrote:
> >>>>> Since the inclusion of the "enable network support in RPi4 config" 
> >>>>> serie on uboot, I
> >>>>> have started to work on adding the rpi4 in kernelCI.
> >>>>> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
> >>>>>
> >>>>> Using booti I hit:
> >>>>> [0.00] Linux version 5.6.0-rc1-next-20200212 
> >>>>> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 
> >>>>> [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] 
> >>>>> (LinaroGCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 
> >>>>> 2020
> >>>>> [0.00] Machine model: Raspberry Pi 4 Model B
> >>>>> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
> >>>>> [0.00] printk: bootconsole [uart0] enabled
> >>>>> [0.00] efi: Getting EFI parameters from FDT:
> >>>>> [0.00] efi: UEFI not found.
> >>>>
> >>>> So no EFI,
> >>>>
> >>>>> [0.00] OF: reserved mem: failed to allocate memory for node 
> >>>>> 'linux,cma'
> >>>>
> >>>> Out of memory.
> >>>>
> >>>>> [0.00] cma: Failed to reserve 32 MiB
> >>>>> [0.00] Kernel panic - not syncing: Failed to allocate page 
> >>>>> table page
> >>>>
> >>>> Out of memory...
> >>>>
> >>>>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> >>>>> 5.6.0-rc1-next-20200212 #66
> >>>>> [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
> >>>>> [0.00] Call trace:
> >>>>> [0.00]  dump_backtrace+0x0/0x1a0
> >>>>> [0.00]  show_stack+0x14/0x20
> >>>>> [0.00]  dump_stack+0xbc/0x104
> >>>>> [0.00]  panic+0x16c/0x37c
> >>>>> [0.00]  early_pgtable_alloc+0x30/0xa0
> >>>>
> >>>> ... really early!
> >>>>
> >>>>> [0.00]  __create_pgd_mapping+0x36c/0x588
> >>>>> [0.00]  map_kernel_segment+0x70/0xa4
> >>>>> [0.00]  paging_init+0xf4/0x528
> >>>>> [0.00]  setup_arch+0x250/0x5d8
> >>>>> [0.00]  start_kernel+0x90/0x6d8
> >>>>>
> >>>>>  
> >>>>> Since the same kernel boot with bootefi and that bootefi lack ramdisk 
> >>>>> address,
> >>>>
> >>>> Booting with EFI will cause linux to use the EFI memory map.
> >>>>
> >>>> Does your DT have a memory node? (or does it expect EFI to provide the 
> >>>> information)
> >>>>
> >>>>
> >>>>> I tried to add the address in the dtb via:
> >>>>> fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start 
> >>>>> 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi 
> >>>>> 0x0008 0x0240
> >>>>> But with that, I get:
> >>>>> initrd not fully accessible via the linear mapping -- please check your 
> >>>>> bootloader ...
> >>>>
> >>>> So this one is an EFI boot, but you can't find where to put the 
> >>>> initramfs such that the
> >>>> kernel agrees its in memory.
> >>>>
> >>>> If you boot with 'efi=debug', linux will print the EFI memory map. Could 
> >>>> you compare that
> >>>> to where U-Boot thinks memory is?
> >>>>
> >>>> (it sounds like your DT memory node is missing, and your EFI memory map 
> >>>> is surprisingly small)
> >>>
> >>> Hello
> >>>
> >>> Thanks for your advices.
> >>>
> >>> In the dtb of mainline linux

Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

On Tue, Feb 18, 2020 at 11:13:03AM +0900, Jaehoon Chung wrote:
> Hi LABBE,
> 
> On 2/17/20 8:37 PM, Jaehoon Chung wrote:
> > On 2/3/20 6:48 PM, LABBE Corentin wrote:
> >> On Wed, Jan 29, 2020 at 07:21:09AM +0900, Jaehoon Chung wrote:
> >>> On 1/27/20 9:06 PM, Andre Przywara wrote:
> >>>> On Mon, 27 Jan 2020 12:50:16 +0100
> >>>> LABBE Corentin  wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>> On Mon, Jan 27, 2020 at 04:27:03PM +0530, Amit Tomer wrote:
> >>>>>> Hi,
> >>>>>>   
> >>>>>>> The kernel panic just after with "OF: reserved mem: failed to 
> >>>>>>> allocate memory for node 'linux,cma'" but that's another story.  
> >>>>>>
> >>>>>> But this comes even without having Ethernet patches and when one use
> >>>>>> booti instead of bootefi, right ?
> >>>>>>   
> >>>>>
> >>>>> So booti is unsupported on rpi 4 ?
> >>>>
> >>>> It should be supported, but apparently there is some bug. I guess it's 
> >>>> about not properly reserving memory used by the armstub/ATF. Do you use 
> >>>> the embedded RPi foundation armstub or ATF (do you have an "armstub=..." 
> >>>> line in config.txt)?
> >>>>
> >>>> I will try take a look at this later.
> >>>
> >>> I'm not sure, i had similar issue about failed to allocate memory cma.
> >>> I had enabled CONFIG_ARCH_FIXUP_OF_MEMORY. And i changed the loading 
> >>> address (kernel/ramdisk/device-tree) in boot script for our environment.
> >>> Because sometime some address range is overwritten.
> >>>
> >>
> >> Hello
> >>
> >> I have searched both in uboot and linux sources and didnt found any 
> >> CONFIG_ARCH_FIXUP_OF_MEMORY.
> > 
> > Sorry. It's CONFIG_ARCH_FIXUP_FDT_MEMORY.
> 
> In my case, disable CONFIG_ARCH_FIXUP_FDT_MEMORY. (RAM size is returned to 0.)
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.19.81-arm-rpi4-v7l (abuild@obspw03) (gcc 
> version 9.2.0 (Tizen GCC 9.2.0 20190812 3.5)) #1 SMP Thu Feb 13 12:18:13 UTC 
> 2020
> [0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
> [0.00] CPU: div instructions available: patching division code
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> [0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B
> [0.00] earlycon: uart8250 at MMIO32 0xfe215040 (options '')
> [0.00] bootconsole [uart8250] enabled
> [0.00] INITRD: 0x0270+0x0080 is not a memory region - 
> disabling initrd
> [0.00] cma: Size (0x1000) of region at 0x 
> exceeds limit (0x)
> [0.00] cma: Failed to reserve 256 MiB
> 
> After enabled CONFIG_ARCH_FIXUP_FDT_MEMORY.
> 
> tarting kernel ...
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.19.81-arm-rpi4-v7l (abuild@obspw03) (gcc 
> version 9.2.0 (Tizen GCC 9.2.0 20190812 3.5)) #1 SMP Thu Feb 13 12:18:13 UTC 
> 2020
> [0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
> [0.00] CPU: div instructions available: patching division code
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> [0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B
> [0.00] earlycon: uart8250 at MMIO32 0xfe215040 (options '')
> [0.00] bootconsole [uart8250] enabled
> [0.00] Memory policy: Data cache writealloc
> [0.00] cma: Reserved 256 MiB at 0x1ec0
> [0.00] random: get_random_bytes called from start_kernel+0xc0/0x4f0 
> with crng_init=0
> [0.00] percpu: Embedded 16 pages/cpu s36812 r8192 d20532 u65536
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 1011008
> 
> Kernel is based on RPI vendor kernel. (32bit) And I have changed 
> ramdisk/kernel/fdt loading address.(I think that it's not important.)
> 
> I have checked 1G/2G/4G RPI4 target. Each board is displayed correct ram-size 
> on Kernel side.
> 

Thanks after enabling CONFIG_ARCH_FIXUP_FDT_MEMORY, I successully booted a 
linux-next via booti.

Thanks again.

Regards

Re: RPI4: fail too boot with an initrd

[LABBE Corentin]

On Mon, Feb 17, 2020 at 11:50:04AM +0100, Matthias Brugger wrote:
> 
> 
> On 17/02/2020 11:37, LABBE Corentin wrote:
> > On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
> >> Hi Corentin,
> >>
> >> On 14/02/2020 13:27, LABBE Corentin wrote:
> >>> Since the inclusion of the "enable network support in RPi4 config" serie 
> >>> on uboot, I
> >>> have started to work on adding the rpi4 in kernelCI.
> >>> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
> >>>
> >>> Using booti I hit:
> >>> [0.00] Linux version 5.6.0-rc1-next-20200212 
> >>> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 
> >>> [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] 
> >>> (LinaroGCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
> >>> [0.00] Machine model: Raspberry Pi 4 Model B
> >>> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
> >>> [0.00] printk: bootconsole [uart0] enabled
> >>> [0.00] efi: Getting EFI parameters from FDT:
> >>> [0.00] efi: UEFI not found.
> >>
> >> So no EFI,
> >>
> >>> [0.00] OF: reserved mem: failed to allocate memory for node 
> >>> 'linux,cma'
> >>
> >> Out of memory.
> >>
> >>> [0.00] cma: Failed to reserve 32 MiB
> >>> [0.00] Kernel panic - not syncing: Failed to allocate page table 
> >>> page
> >>
> >> Out of memory...
> >>
> >>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> >>> 5.6.0-rc1-next-20200212 #66
> >>> [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
> >>> [0.00] Call trace:
> >>> [0.00]  dump_backtrace+0x0/0x1a0
> >>> [0.00]  show_stack+0x14/0x20
> >>> [0.00]  dump_stack+0xbc/0x104
> >>> [0.00]  panic+0x16c/0x37c
> >>> [0.00]  early_pgtable_alloc+0x30/0xa0
> >>
> >> ... really early!
> >>
> >>> [0.00]  __create_pgd_mapping+0x36c/0x588
> >>> [0.00]  map_kernel_segment+0x70/0xa4
> >>> [0.00]  paging_init+0xf4/0x528
> >>> [0.00]  setup_arch+0x250/0x5d8
> >>> [0.00]  start_kernel+0x90/0x6d8
> >>>
> >>>  
> >>> Since the same kernel boot with bootefi and that bootefi lack ramdisk 
> >>> address,
> >>
> >> Booting with EFI will cause linux to use the EFI memory map.
> >>
> >> Does your DT have a memory node? (or does it expect EFI to provide the 
> >> information)
> >>
> >>
> >>> I tried to add the address in the dtb via:
> >>> fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start 
> >>> 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi 
> >>> 0x0008 0x0240
> >>> But with that, I get:
> >>> initrd not fully accessible via the linear mapping -- please check your 
> >>> bootloader ...
> >>
> >> So this one is an EFI boot, but you can't find where to put the initramfs 
> >> such that the
> >> kernel agrees its in memory.
> >>
> >> If you boot with 'efi=debug', linux will print the EFI memory map. Could 
> >> you compare that
> >> to where U-Boot thinks memory is?
> >>
> >> (it sounds like your DT memory node is missing, and your EFI memory map is 
> >> surprisingly small)
> > 
> > Hello
> > 
> > Thanks for your advices.
> > 
> > In the dtb of mainline linux:
> > /* Will be filled by the bootloader */
> > memory@0 {
> > device_type = "memory";
> > reg = <0 0 0>;
> > };
> > 
> > In uboot I have:
> > static struct mm_region bcm2711_mem_map[] = {
> > {
> > .virt = 0xUL,
> > .phys = 0xUL,
> > .size = 0xfe00UL,
> > .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> >  PTE_BLOCK_INNER_SHARE
> > }, {
> > .virt = 0xfc00UL,
> > .phys = 0xfc00UL,
> > .size = 0x0380UL,
> > .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> >  PTE_BLOCK_NON_SHARE |
> >  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > }, {
> > /* List terminator */
> > 0,
> > }
> > };
> > But I dont know if uboot use that for filling the memory node.
> 
> No it doesn't. U-Boot uses the DT from the firmware and passes this to the
> kernel. But it seems you pass instead your own device-tree to the kernel, so 
> you
> will need to update the memory node to show the available memory on you board.
> 

I dont understand, in the Linux commit "ARM: dts: Add minimal Raspberry Pi 4 
support" I read:
The RPi 4 is available in 3 different variants (1, 2 and 4 GB RAM), so leave 
the memory size to zero and let the bootloader take care of it.
But if uboot dont fill that...
So the DTB in mainline is wrong, right ?

Regards

Re: RPI4: fail too boot with an initrd

[LABBE Corentin]

On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
> Hi Corentin,
> 
> On 14/02/2020 13:27, LABBE Corentin wrote:
> > Since the inclusion of the "enable network support in RPi4 config" serie on 
> > uboot, I
> > have started to work on adding the rpi4 in kernelCI.
> > But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
> > 
> > Using booti I hit:
> > [0.00] Linux version 5.6.0-rc1-next-20200212 
> > (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 
> > revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (LinaroGCC 
> > 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
> > [0.00] Machine model: Raspberry Pi 4 Model B
> > [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
> > [0.00] printk: bootconsole [uart0] enabled
> > [0.00] efi: Getting EFI parameters from FDT:
> > [0.00] efi: UEFI not found.
> 
> So no EFI,
> 
> > [0.00] OF: reserved mem: failed to allocate memory for node 
> > 'linux,cma'
> 
> Out of memory.
> 
> > [0.00] cma: Failed to reserve 32 MiB
> > [0.00] Kernel panic - not syncing: Failed to allocate page table 
> > page
> 
> Out of memory...
> 
> > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> > 5.6.0-rc1-next-20200212 #66
> > [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
> > [0.00] Call trace:
> > [0.00]  dump_backtrace+0x0/0x1a0
> > [0.00]  show_stack+0x14/0x20
> > [0.00]  dump_stack+0xbc/0x104
> > [0.00]  panic+0x16c/0x37c
> > [0.00]  early_pgtable_alloc+0x30/0xa0
> 
> ... really early!
> 
> > [0.00]  __create_pgd_mapping+0x36c/0x588
> > [0.00]  map_kernel_segment+0x70/0xa4
> > [0.00]  paging_init+0xf4/0x528
> > [0.00]  setup_arch+0x250/0x5d8
> > [0.00]  start_kernel+0x90/0x6d8
> > 
> >  
> > Since the same kernel boot with bootefi and that bootefi lack ramdisk 
> > address,
> 
> Booting with EFI will cause linux to use the EFI memory map.
> 
> Does your DT have a memory node? (or does it expect EFI to provide the 
> information)
> 
> 
> > I tried to add the address in the dtb via:
> > fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start 
> > 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi 0x0008 
> > 0x0240
> > But with that, I get:
> > initrd not fully accessible via the linear mapping -- please check your 
> > bootloader ...
> 
> So this one is an EFI boot, but you can't find where to put the initramfs 
> such that the
> kernel agrees its in memory.
> 
> If you boot with 'efi=debug', linux will print the EFI memory map. Could you 
> compare that
> to where U-Boot thinks memory is?
> 
> (it sounds like your DT memory node is missing, and your EFI memory map is 
> surprisingly small)

Hello

Thanks for your advices.

In the dtb of mainline linux:
/* Will be filled by the bootloader */
memory@0 {
device_type = "memory";
reg = <0 0 0>;
};

In uboot I have:
static struct mm_region bcm2711_mem_map[] = {
{
.virt = 0xUL,
.phys = 0xUL,
.size = 0xfe00UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
.virt = 0xfc00UL,
.phys = 0xfc00UL,
.size = 0x0380UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
/* List terminator */
0,
}
};
But I dont know if uboot use that for filling the memory node.


Booting the rpi4 with efi=debug give:
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.6.0-rc1-next-20200214 
(clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 
revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) 
#70 SMP PREEMPT Fri Feb 14 10:54:54 UTC 2020
[0.00] Machine model: Raspberry Pi 4 Model B
[0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
[0.00] printk: bootconsole [uart0] enabled
[0.00] efi: Getting EFI parameters from 

RPI4: fail too boot with an initrd

[LABBE Corentin]

Hello

Since the inclusion of the "enable network support in RPi4 config" serie on 
uboot, I have started to work on adding the rpi4 in kernelCI.
But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.

Using booti I hit:
[0.00] Linux version 5.6.0-rc1-next-20200212 
(clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 
revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (LinaroGCC 7.4-2019.02)) 
#66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
[0.00] Machine model: Raspberry Pi 4 Model B
[0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
[0.00] printk: bootconsole [uart0] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] OF: reserved mem: failed to allocate memory for node 'linux,cma'
[0.00] cma: Failed to reserve 32 MiB
[0.00] Kernel panic - not syncing: Failed to allocate page table page
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-rc1-next-20200212 
#66
[0.00] Hardware name: Raspberry Pi 4 Model B (DT)
[0.00] Call trace:
[0.00]  dump_backtrace+0x0/0x1a0
[0.00]  show_stack+0x14/0x20
[0.00]  dump_stack+0xbc/0x104
[0.00]  panic+0x16c/0x37c
[0.00]  early_pgtable_alloc+0x30/0xa0
[0.00]  __create_pgd_mapping+0x36c/0x588
[0.00]  map_kernel_segment+0x70/0xa4
[0.00]  paging_init+0xf4/0x528
[0.00]  setup_arch+0x250/0x5d8
[0.00]  start_kernel+0x90/0x6d8

 
Since the same kernel boot with bootefi and that bootefi lack ramdisk address, 
I tried to add the address in the dtb via:
fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start 0x0270; 
fdt set /chosen linux,initrd-end 0x1000; bootefi 0x0008 0x0240
But with that, I get:
initrd not fully accessible via the linear mapping -- please check your 
bootloader ...

I have tried many different start/end address without any change.


My last resort was to embed the rootfs in the kernel.
But with the correct console=, the boot stop at:
[1.373557] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 16, base_baud 
= 0) is a PL011 rev2
[1.382565] printk: console [ttyAMA0] enabled
[1.391318] printk: bootconsole [uart0] disabled

With the wrong console (ttyS0), the boot go up to start init which panic due to 
lack of console.

Regards

Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

On Mon, Jan 27, 2020 at 12:06:16PM +, Andre Przywara wrote:
> On Mon, 27 Jan 2020 12:50:16 +0100
> LABBE Corentin  wrote:
> 
> Hi,
> 
> > On Mon, Jan 27, 2020 at 04:27:03PM +0530, Amit Tomer wrote:
> > > Hi,
> > >   
> > > > The kernel panic just after with "OF: reserved mem: failed to allocate 
> > > > memory for node 'linux,cma'" but that's another story.  
> > > 
> > > But this comes even without having Ethernet patches and when one use
> > > booti instead of bootefi, right ?
> > >   
> > 
> > So booti is unsupported on rpi 4 ?
> 
> It should be supported, but apparently there is some bug. I guess it's about 
> not properly reserving memory used by the armstub/ATF. Do you use the 
> embedded RPi foundation armstub or ATF (do you have an "armstub=..." line in 
> config.txt)?
> 
> I will try take a look at this later.
> 
> > I need to set a ramdisk and bootefi dont support that.
> 
> Try "initrd=" on the kernel command line.
> This is actually an EFI stub feature, the EFI command line is parsed by this 
> pre-kernel code, which filters for initrd= and loads the initrd using the 
> UEFI API (implemented by U-Boot).
> So the initrd has to live on the EFI system partition, which means you can't 
> load it easily via TFTP :-(
> More details here: 
> https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html#the-initrd-option
> 
> Cheers,
> Andre

Just for more information, the official kernel from rpi also panic when booted 
with booti.
[0.00] Linux version 4.19.80 (oe-user@oe-host) (gcc version 8.2.0 
(GCC)) #1 SMP PREEMPT Mon Jan 13 16:34:20 UTC 2020
[0.00] Machine model: Raspberry Pi 4 Model B
[0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
[0.00] bootconsole [uart0] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Failed to reserve 8 MiB
[0.00] Kernel panic - not syncing: ERROR: Failed to allocate 
0x1000 bytes below 0x.

Regards

Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

On Wed, Jan 29, 2020 at 07:21:09AM +0900, Jaehoon Chung wrote:
> On 1/27/20 9:06 PM, Andre Przywara wrote:
> > On Mon, 27 Jan 2020 12:50:16 +0100
> > LABBE Corentin  wrote:
> > 
> > Hi,
> > 
> >> On Mon, Jan 27, 2020 at 04:27:03PM +0530, Amit Tomer wrote:
> >>> Hi,
> >>>   
> >>>> The kernel panic just after with "OF: reserved mem: failed to allocate 
> >>>> memory for node 'linux,cma'" but that's another story.  
> >>>
> >>> But this comes even without having Ethernet patches and when one use
> >>> booti instead of bootefi, right ?
> >>>   
> >>
> >> So booti is unsupported on rpi 4 ?
> > 
> > It should be supported, but apparently there is some bug. I guess it's 
> > about not properly reserving memory used by the armstub/ATF. Do you use the 
> > embedded RPi foundation armstub or ATF (do you have an "armstub=..." line 
> > in config.txt)?
> > 
> > I will try take a look at this later.
> 
> I'm not sure, i had similar issue about failed to allocate memory cma.
> I had enabled CONFIG_ARCH_FIXUP_OF_MEMORY. And i changed the loading address 
> (kernel/ramdisk/device-tree) in boot script for our environment.
> Because sometime some address range is overwritten.
> 

Hello

I have searched both in uboot and linux sources and didnt found any 
CONFIG_ARCH_FIXUP_OF_MEMORY.
Could you give what you did exactly ?

Regards

Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

On Mon, Jan 27, 2020 at 12:06:16PM +, Andre Przywara wrote:
> On Mon, 27 Jan 2020 12:50:16 +0100
> LABBE Corentin  wrote:
> 
> Hi,
> 
> > On Mon, Jan 27, 2020 at 04:27:03PM +0530, Amit Tomer wrote:
> > > Hi,
> > >   
> > > > The kernel panic just after with "OF: reserved mem: failed to allocate 
> > > > memory for node 'linux,cma'" but that's another story.  
> > > 
> > > But this comes even without having Ethernet patches and when one use
> > > booti instead of bootefi, right ?
> > >   
> > 
> > So booti is unsupported on rpi 4 ?
> 
> It should be supported, but apparently there is some bug. I guess it's about 
> not properly reserving memory used by the armstub/ATF. Do you use the 
> embedded RPi foundation armstub or ATF (do you have an "armstub=..." line in 
> config.txt)?

I didnt use armstub=, but even with it, no change.

> 
> I will try take a look at this later.
> 
> > I need to set a ramdisk and bootefi dont support that.
> 
> Try "initrd=" on the kernel command line.
> This is actually an EFI stub feature, the EFI command line is parsed by this 
> pre-kernel code, which filters for initrd= and loads the initrd using the 
> UEFI API (implemented by U-Boot).
> So the initrd has to live on the EFI system partition, which means you can't 
> load it easily via TFTP :-(
> More details here: 
> https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html#the-initrd-option

I need to load it via TFTP.

Thanks for your help
Regards

Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

On Mon, Jan 27, 2020 at 04:27:03PM +0530, Amit Tomer wrote:
> Hi,
> 
> > The kernel panic just after with "OF: reserved mem: failed to allocate 
> > memory for node 'linux,cma'" but that's another story.
> 
> But this comes even without having Ethernet patches and when one use
> booti instead of bootefi, right ?
> 

So booti is unsupported on rpi 4 ?
I need to set a ramdisk and bootefi dont support that.

Regards

Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

On Mon, Jan 27, 2020 at 01:14:41AM +, Andre Przywara wrote:
> This series adds Ethernet support for the Raspberry Pi 4. The SoC
> includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
> device (no USB anymore!). Patch 1 provides a driver for that. There does
> not seem to be publicly available documentation, so this is based on the
> Linux driver, but stripped down to just provide what U-Boot needs.
> Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
> MAC lives in, while patch 3 enables it in the respective defconfigs.
> 
> This version fixes the nasty SError issue that showed when booting Linux.
> To see the changes as patches, refer to [1].
> 
> Please have a look and test it, I hope this helps to simplify
> development, as you spare the SD card and its slot from heavy swapping.
> 
> Cheers,
> Andre.
> 
> [1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v3
> 
> Changelog v2 ... v3:
> - properly reset MAC in eth_probe() to avoid SError in Linux
> - disable RX DMA upon stopping the device
> 
> Changelog v1 ... v2:
> - use native endianess functions when accessing MMIO registers
> - use dev_* DM wrappers for accessing devicetree data
> - round base and length for flush_dcache_range, plus a comment
> - check and round length for invalidate_cache_range
> - support RGMII_RXID PHY mode, to support mainline .dtb
> 
> Amit Singh Tomar (3):
>   net: Add support for Broadcom GENETv5 Ethernet controller
>   rpi4: Update memory map to accommodate scb devices
>   rpi4: Enable GENET Ethernet controller
> 
>  arch/arm/mach-bcm283x/init.c |   6 +-
>  configs/rpi_4_32b_defconfig  |   2 +
>  configs/rpi_4_defconfig  |   2 +
>  configs/rpi_arm64_defconfig  |   1 +
>  drivers/net/Kconfig  |   7 +
>  drivers/net/Makefile |   1 +
>  drivers/net/bcmgenet.c   | 729 
> +++
>  7 files changed, 745 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/bcmgenet.c
> 
> -- 

Hello

I have successfully started a kernel 
(5.5.0-rc7-next-20200124-00075-gd1ea5e663326) with this serie.
Thanks for your help by IRC, updating firmware seems to did the trick.
The kernel panic just after with "OF: reserved mem: failed to allocate memory 
for node 'linux,cma'" but that's another story.

Tested-by: Corentin Labbe 
Thanks

Re: [PATCH v2 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

On Fri, Jan 17, 2020 at 01:20:44AM +, Andre Przywara wrote:
> This series adds Ethernet support for the Raspberry Pi 4. The SoC
> includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform
> device (no USB anymore!). Patch 1 provides a driver for that. There does
> not seem to be publicly available documentation, so this is based on the
> Linux driver, but stripped down to just provide what U-Boot needs.
> Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the
> MAC lives in, while patch 3 enables it in the respective defconfigs.
> 
> This version addresses the comments by the diligent reviewers and testers,
> for a changelog see below.
> To see the individual changes as patches, refer to [1].
> 
> Please have a look and test it, I hope this helps to simplify
> development, as you spare the SD card and its slot from heavy swapping.
> 
> I dropped the Tested-by's, as there were changes in the code. Happy
> to reapply them when people confirm that it still works for them.
> 
> Cheers,
> Andre.
> 
> [1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v2
> 
> Changelog v1 ... v2:
> - use native endianess functions when accessing MMIO registers
> - use dev_* DM wrappers for accessing devicetree data
> - round base and length for flush_dcache_range, plus a comment
> - check and round length for invalidate_cache_range
> - support RGMII_RXID PHY mode, to support mainline .dtb
> 
> Amit Singh Tomar (3):
>   net: Add support for Broadcom GENETv5 Ethernet controller
>   rpi4: Update memory map to accommodate scb devices
>   rpi4: Enable GENET Ethernet controller
> 
>  arch/arm/mach-bcm283x/init.c |   6 +-
>  configs/rpi_4_32b_defconfig  |   2 +
>  configs/rpi_4_defconfig  |   2 +
>  configs/rpi_arm64_defconfig  |   1 +
>  drivers/net/Kconfig  |   7 +
>  drivers/net/Makefile |   1 +
>  drivers/net/bcmgenet.c   | 722 
> +++
>  7 files changed, 738 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/bcmgenet.c
> 
> -- 
> 2.14.5
> 

Hello

I have tested it again and grabbing DHCP and doing TFTP works.
But I still fail to boot any kernel.

U-Boot 2020.01-00660-gec13baddca (Jan 21 2020 - 11:38:05 +0100)
DRAM:  3.9 GiB
RPI 4 Model B (0xc03111)
MMC:   emmc2@7e34: 0, mmcnr@7e30: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment
In:serial
Out:   serial
Err:   serial
Net:   eth0: genet@7d58

dhcp

genet@7d58 Waiting for PHY auto negotiation to complete... done
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 192.168.66.27 (1255 ms)

I use 0x8 for kernel, 0x0270 for RAMfs, 0x0240 for DTB and booti 
0x0008 0x0270 0x0240 for starting kernel.
Both mainline kernel and rpi kernel wont boot.

But this is unrelated to your serie.
Tested-by: Corentin Labbe 

Thanks
Regards

Re: [PATCH 0/3] Ethernet support for Raspberry Pi 4

[LABBE Corentin]

Hello

I have successfully used your patch to obtain an IP via DHCP and download 
kernel/dtb/ramdisk via tftp.
Tested-by: Corentin Labbe 

But I still fail to boot any kernel (mainline/rpi-5.4/rpi-4.19).
But this is irrelevant with your serie, since the same kernel is not bootable 
also via "load mmc 0:1 " but it is via the RPI bootloader.
So it is probably uboot's fault.

Thanks
Regards

Re: [U-Boot] [U-BOOT] [PATCH] net: Add EMAC driver for H3/A83T/A64

[LABBE Corentin]

On Sun, May 22, 2016 at 10:59:33AM +0530, Amit Tomer wrote:
> Hello,
> 
> Thanks for your comments, Sorry for the delayed response.
> 
> > 1 is too high
> 
> Ok, I will fix it but as per data sheet its 64k region(0x1).
> 

Sorry I believed it to be smaller.

> > Space after dot. Try also to keep a minimum of alphabetical order of config.
> 
> Ok, I will fix it.
> 
> > Sort also headers
> 
> Sorry, didn't get your point here.
> 

Sort them by alphabetical order, like  before 

> > I do not know the memory pressure on uboot but the number of descriptors 
> > could be less since uboot seems to not have any scattergather for network 
> > (so 64 or perhaps 32 could be enought)
> 
> Ok, I will keep it to 64 and test.
> 
> > You do not check for any reception error.
> 
> Yes, I missed it, would take care of it in next version.
> 
> > You disable interrupt but I do not see any enabling of it.
> 
> Yes, I knew going to get this comment but don't you think after packet
> transmission
> H/W may enable the interrupt, so it is to take care of that particular case.
> 

I didnt see hardware enabling interrupt by itself.

Regards

LABBE Corentin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-BOOT] [RFC PATCH] EMAC driver for H3/A64

[LABBE Corentin]

On Mon, Apr 25, 2016 at 12:34:06AM +0530, Amit Singh Tomar wrote:
> Hello
> 
> I wanted to contribute and in the process trying to add support for the 
> driver for EMAC controller found on H3/A64 based SoC.
> 
> Sorry, I don't want to post it at this moment but I am kind of stuck from 
> last few days.
> 
> What is working:
> - Able to establish the link between host and Organepi pc(H3).
> - Tx on host side getting incremented.
> - When ping from Orangepi PC to host machine , I see ONE
>   packet is trasnmitted over wire but its bad packet with 
> following output
>   after running tcpdump on host
> 
> 20:41:49.148111 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui 
> Ethernet) Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
>   0x:           
>   0x0010:           
>   0x0020:           
>   0x0030:       
> 
> What needs to be done:
> - Why bad packet is transmitted over the wire from Orangepi 
> pc to Host ?
>   - Make it compatible with external PHY.
> 
> This Patch is based on LABBE Corentin's and Chen-Yu Tsai's work done for 
> Linux Kernel(Thanks to both of them).
> 
> Signed-off-by: Amit Singh Tomar 
> ---
>  arch/arm/dts/sun8i-h3-orangepi-pc.dts |   10 +
>  arch/arm/dts/sun8i-h3.dtsi|7 +
>  configs/orangepi_pc_defconfig |2 +
>  drivers/net/Makefile  |1 +
>  drivers/net/sun8i_emac.c  |  619 
> +
>  5 files changed, 639 insertions(+)
>  create mode 100644 drivers/net/sun8i_emac.c
> 

Hello

I have some comments below

> +
> +#define CONFIG_TX_DESCR_NUM 128
> +#define CONFIG_RX_DESCR_NUM 64
> +#define CONFIG_ETH_BUFSIZE  2048
I do not think you will doing Jumbo frame, so 2048 is too much
Anyway, I have got strange reaction from hw with this value (Even BSP use 2047)

> +#define TX_TOTAL_BUFSIZE(CONFIG_ETH_BUFSIZE * CONFIG_TX_DESCR_NUM)
> +#define RX_TOTAL_BUFSIZE(CONFIG_ETH_BUFSIZE * CONFIG_RX_DESCR_NUM)
> +
> +#define REG_DEFAULT_VALUE0x58000
> +#define REG_DEFAULT_MASK GENMASK(31, 15)
> +
> +#define REG_PHY_ADDR_SHIFT   20
> +#define REG_PHY_ADDR_MASKGENMASK(4, 0)
> +#define REG_LED_POL  BIT(17) /* 1: active low, 0: active high */
> +#define REG_SHUTDOWN BIT(16) /* 1: shutdown, 0: power up */
> +#define REG_PHY_SELECT   BIT(15) /* 1: internal PHY, 0: external 
> PHY */
> +
> +
> +#define RX_BUF_SZ (2048*64)
Unused, and if used, use the proper define 
(CONFIG_RX_DESCR_NUM/CONFIG_ETH_BUFSIZE)

> +
> +#define CONFIG_MDIO_TIMEOUT (3 * CONFIG_SYS_HZ)
> +
> +#define  AHB_GATE_OFFSET_GMAC 17
> +#define  AHB_GATE_OFFSET_EPHY 0
> +
> +#define SUN8I_GPD8_GMAC 4
> +
> +/* H3/A64 EMAC Register Base*/
> +#define SUN8I_EMAC_BASE 0x01c3
> +
> +/* H3/A64 EMAC Register's offset */
> +#define  CTL00x00
> +#define CTL1 0x04
> +#define INT_STA  0x08
> +#define INT_EN   0x0c
> +#define TX_CTL0  0x10
> +#define TX_CTL1  0x14
> +#define  TX_FLOW_CTL 0x1c
> +#define  TX_DMA_DESC 0x20
> +#define RX_CTL0  0x24
> +#define RX_CTL1  0x28
> +#define RX_DMA_DESC  0x34
> +#define  MII_CMD 0x48
> +#define  MII_DATA0x4c
> +#define  ADDR0_HIGH  0x50
> +#define  ADDR0_LOW   0x54
> +#define TX_DMA_STA   0xb0
> +#define  TX_CUR_DESC 0xb4
> +#define TX_CUR_BUF  0xb8
> +#define RX_DMA_STA   0xc0
> +#define RX_CUR_DESC  0xc4
> +#define TX_CUR_BUF   0xc8
> +
> +/* CCM Register base */
> +#define SUN8I_CCM_BASE 0x01c2
> +
> +/* CCM Regsiter's offset */
typo
your patch have some typos, run aspell on it

> +#define  CLK_GATING_REG0 0x60
> +#define CLK_GATING_REG1  0x64
> +#define CLK_GATING_REG2  0x68
> +#define CLK_GATING_REG3  0x6c
> +#define CLK_GATING_REG4  0x70
> +
> +/* System Control Register base */
> +#define SUN8I_SCTL_BASE 0x01c0
> +
> +/* System Control Register's offset */
> +#define VER_REG 0x24
> +#define EMAC_CLK_REG 0x30
> +
> +struct emac_dma_desc {
> + u32 status;
> + u32 st;
> + void *buf_addr;
> + struct emac_dma_desc *next;
> +} __aligned(4);
> +
> +struct emac_eth_dev {
> + struct emac_dma_desc rx_chain[CONFIG_TX_DESCR_NUM];
> + struct emac_dma_desc tx_chain[CONFIG_RX_DESCR_NUM];
> + char rxbuffer[RX_TOTAL_BUFSIZE] __aligned(ARCH_DMA_MINALIGN);
> + char txbuffer[TX_TOTAL_BUFSIZE] __aligned(ARCH_DMA_MINALIGN);
> +
> + u32 interface;
> + u32 link;
> + u32 speed;
> + u32 duplex;
> + u32 phy_configured;
> +