| Message ID | 20200127011444.8114-1-andre.przywara@arm.com |
|---|---|
| Headers | show |
| Series | Ethernet support for Raspberry Pi 4 | expand |
On Mon, Jan 27, 2020 at 01:14:41AM +0000, 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 <clabbe at baylibre.com> Thanks
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 ?
Thanks
-Amit
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
On Mon, 27 Jan 2020 12:50:16 +0100 LABBE Corentin <clabbe at baylibre.com> 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=<filename>" 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
On Mon, Jan 27, 2020 at 12:06:16PM +0000, Andre Przywara wrote: > On Mon, 27 Jan 2020 12:50:16 +0100 > LABBE Corentin <clabbe at baylibre.com> 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=<filename>" 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
On 1/27/20 9:06 PM, Andre Przywara wrote: > On Mon, 27 Jan 2020 12:50:16 +0100 > LABBE Corentin <clabbe at baylibre.com> 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. Best Regards, Jaehoon Chung > >> I need to set a ramdisk and bootefi dont support that. > > Try "initrd=<filename>" 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 > >
On 28/01/2020 23:21, Jaehoon Chung wrote: > On 1/27/20 9:06 PM, Andre Przywara wrote: >> On Mon, 27 Jan 2020 12:50:16 +0100 >> LABBE Corentin <clabbe at baylibre.com> 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. > Can you share some more details? Might it make sense to change the memory addresses in include/configs/rpi.h so that it work out-of-the-box for all cases? Regards, Matthias