It's Groundhog Day all over again... With the serial console enabled I cannot get the IPFire CU159 on an RPi4B (only 1 GB RAM) to boot. These are set correctly for me: • uENV.txt - SERIAL-CONSOLE=ON • config.txt enable_uart=1 --- U-Boot 2021.07 (Aug 09 2021 - 09:19:51 +0000) RPi4 - IPFire. U-Boot 2021.07 (Aug 09 2021 - 09:19:51 +0000) RPi4 - IPFire.org DRAM: 998 MiB RPI 4 Model B (0xa03111) MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller Port not available. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device "Synchronous Abort" handler, esr 0x96000044 elr: 000000000009df64 lr : 000000000009e4c8 (reloc) elr: 000000003e36ef64 lr : 000000003e36f4c8 x0 : 000000003df5e800 x1 : 6f6f625f726f665f x2 : 7665645f6e006900 x3 : 000000003e3d27d8 x4 : 000000003df5e860 x5 : 000000000000005d x6 : 000000003e3d27e8 x7 : 0000000000000010 x8 : fffffffffffffff0 x9 : 0000000000000008 x10: 00000000ffffffd0 x11: 000000000000000a x12: 000000000001869f x13: 000000003df40da8 x14: 000000003df40eb0 x15: 0000000000000002 x16: 000000003e37119c x17: 0cc49240c2e78984 x18: 000000003df4cd90 x19: 0000000000000060 x20: 000000003e3d2218 x21: 0000000000000030 x22: 000000000000000b x23: 000000003e3d2218 x24: 0000000000000001 x25: 0000000000000060 x26: 000000003df56660 x27: 000000003e3c6aab x28: 000000000000003b x29: 000000003df3fef0 Code: b2400021 f9000481 f9400c01 f8410c02 (f9000c41) Resetting CPU ... resetting ... U-Boot 2021.07 (Aug 09 2021 - 09:19:51 +0000) RPi4 - IPFire.org DRAM: 998 MiB RPI 4 Model B (0xa03111) MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller Port not available. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device "Synchronous Abort" handler, esr 0x96000044 elr: 000000000009df64 lr : 000000000009e4c8 (reloc) elr: 000000003e36ef64 lr : 000000003e36f4c8 x0 : 000000003df5e800 x1 : 6f6f625f726f665f x2 : 7665645f6e006900 x3 : 000000003e3d27d8 x4 : 000000003df5e860 x5 : 000000000000005d x6 : 000000003e3d27e8 x7 : 0000000000000010 x8 : fffffffffffffff0 x9 : 0000000000000008 x10: 00000000ffffffd0 x11: 000000000000000a x12: 000000000001869f x13: 000000003df40da8 x14: 000000003df40eb0 x15: 0000000000000002 x16: 000000003e37119c x17: 0cc49240c2e78984 x18: 000000003df4cd90 x19: 0000000000000060 x20: 000000003e3d2218 x21: 0000000000000030 x22: 000000000000000b x23: 000000003e3d2218 x24: 0000000000000001 x25: 0000000000000060 x26: 000000003df56660 x27: 000000003e3c6aab x28: 000000000000003b x29: 000000003df3fef0 Code: b2400021 f9000481 f9400c01 f8410c02 (f9000c41) Resetting CPU ... resetting ... U-Boot 2021.07 (Aug 09 2021 - 09:19:51 +0000) RPi4 - IPFire.org DRAM: 998 MiB
FWIW... I'm using a 4G RPi4B+ and seeing the same failures trying to boot with serial console and no monitor. I have validated that I can get further with a monitor connected based on this https://github.com/lueschem/edi-pi/issues/22 , But, I'm still unable to fully boot. Disabling console gets me even further, but gets hung up looping: invalid bus width error -22 whilst initialising SD Card
(In reply to Jon from comment #0) > It's Groundhog Day all over again... This is referring to the infinite U-Boot loop. Hopefully I didn't offend with my odd sense of humor!
Looks like a known bug with board revision 1.4! Please retry this with core162 which ship updated firmware binaries from the RPi foundation.
None of the RPi4B boards I have is "board revision 1.4". I think they are all 1.1 / 1.2. I'll test CU 162.
Tested on: Hardware : BCM2711 Revision : c03111 Model : Raspberry Pi 4 Model B Rev 1.1 with these settings: • uENV.txt - SERIAL-CONSOLE=ON • config.txt enable_uart=1 The RPi4B does NOT infinite loop in serial console mode. But, the RPi4B gets the the `Starting kernel ...` line and the serial console no longer works. ` U-Boot 2021.07 (Aug 09 2021 - 09:19:51 +0000) RPi4 - IPFire.org DRAM: 3.9 GiB RPI 4 Model B (0xc03111) MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 2451 bytes read in 14 ms (170.9 KiB/s) ## Executing script at 02400000 113 bytes read in 7 ms (15.6 KiB/s) Load uEnv.txt... ... Set console to ttyAMA0,115200n8 27210240 bytes read in 1206 ms (21.5 MiB/s) 26497 bytes read in 25 ms (1 MiB/s) 7683916 bytes read in 357 ms (20.5 MiB/s) Ramdisk loaded... Unknown command 'bootz' - try 'help' Moving Image from 0x80000 to 0x200000, end=1cc0000 ## Loading init Ramdisk from Legacy Image at 02700000 ... Image Name: Image Type: AArch64 Linux RAMDisk Image (lzma compressed) Data Size: 7683852 Bytes = 7.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02600000 Booting using the fdt blob at 0x2600000 Loading Device Tree to 000000003df33000, end 000000003df3c780 ... OK Starting kernel ... ` It does not like the `bootz` command but I am not sure if the matters...
*** Bug 12684 has been marked as a duplicate of this bug. ***
Apologies for having missed this: Upcoming Core Update 172 updates u-boot, as well as the ARM firmware conglomerate. Do these introduce any improvements? Thank you in advance for testing and reporting back. https://blog.ipfire.org/post/ipfire-2-27-core-update-172-is-available-for-testing
As they relate to the Serial Console? Not at this moment. This is what I see - the serial console gets stuck at "Starting kernel ..." Tested with: CU 172 (stable) RPi4B These are the settings for me: • uENV.txt - SERIAL-CONSOLE=ON • config.txt enable_uart=1 --- U-Boot 2022.10 (Dec 27 2022 - 13:59:35 +0000) RPi4 - IPFire.org DRAM: 3.9 GiB RPI 4 Model B (0xc03111) Core: 205 devices, 16 uclasses, devicetree: board MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 2824 bytes read in 10 ms (275.4 KiB/s) ## Executing script at 02400000 114 bytes read in 6 ms (18.6 KiB/s) Load uEnv.txt... ... Set console to ttyAMA0,115200n8 27808256 bytes read in 1178 ms (22.5 MiB/s) 27222 bytes read in 21 ms (1.2 MiB/s) 15815306 bytes read in 676 ms (22.3 MiB/s) Ramdisk loaded... Unknown command 'bootz' - try 'help' Moving Image from 0x80000 to 0x200000, end=1d60000 ## Loading init Ramdisk from Legacy Image at 02700000 ... Image Name: Image Type: AArch64 Linux RAMDisk Image (lzma compressed) Data Size: 15815242 Bytes = 15.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02600000 Booting using the fdt blob at 0x2600000 Loading Device Tree to 000000003df2c000, end 000000003df35a55 ... OK Starting kernel ...
Also, the RPi4B does boot A-OK and I can access IPFire WebGUI. Very brief testing looks OK so far.
(In reply to Jon from comment #9) > Also, the RPi4B does boot A-OK and I can access IPFire WebGUI. Very brief > testing looks OK so far. Based on the above and that there has been no further input into this bug in the last 2.5 years it looks like the bug was fixed.