Hi everyone, To start the New Year, I've tested the 13.1:Contrib JeOS-raspberrypi image. That one does not boot unless the "BOOT" FAT partition is resized, as Guillaume and Marcus discussed recently.
I went on to test the Factory:Contrib JeOS-raspberrypi image (from osc getbinaries), and that one boots right out of the box. Yay! Still, either are rather useless since the ext4 root partition is too small for a `zypper dup`. Alex has therefore asked me to investigate booting via U-Boot, to be able to load kiwi's initrd. https://build.opensuse.org/request/show/212779 was necessary for JeOS-raspberrypi to load kernel and initrd from the FAT partition - accepted. A first u-boot-rpib fix to execute our boot.scr is waiting for review: https://build.opensuse.org/request/show/212778 (Question: Contrib:Factory:RaspberryPi u-boot-rpib looks like openSUSE:Factory:ARM u-boot-rpib but there is no _link - is that intentional?) Not sure yet if it makes a difference, but the path to cmdline.txt was obviously wrong since it didn't end up in the JeOS-raspberrypi image - waiting for review: https://build.opensuse.org/request/show/212860 If non-empty, this will affect also the default boot without U-Boot. U-Boot showed an error about setenv syntax visible. Inserting a printenv in the boot script I noticed that bootargs was missing. Turns out, U-Boot is configured to accept 8 command arguments only and setenv bootargs was trying to supply more than that. Single quotes fixed this, SR TBD. Whether using fdt or not, initrd or not, with kernel=u-boot.bin this is the furthest I have come: mmc0 is current device reading boot/linux.vmx 2616584 bytes read in 374 ms (6.7 MiB/s) reading boot/initrd.uboot 64897618 bytes read in 8628 ms (7.2 MiB/s) reading boot/dtb/bcm2835-rpi-b.dtb 7216 bytes read in 23 ms (305.7 KiB/s) Kernel image @ 0x1000000 [ 0x000000 - 0x27ed08 ] ## Loading init Ramdisk from Legacy Image at 02100000 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 64897554 Bytes = 61.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02000000 Booting using the fdt blob at 0x2000000 Using Device Tree in place at 02000000, end 0x004c2f Starting kernel ... That's using the identical kernel that boots okay as kernel=zImage. Alex noticed that sometimes the LEDs would show activity on Ethernet after a bit, but I was unable to ssh onto the device, so I consider it rather unlikely that it's proceeding fine on UART but just having some HDMI console issue. The red PWR LED is lit but no activity on the green ACT LED. Comparison of /proc/cmdline with boot.script bootargs revealed that the Raspberry Pi bootloader is passing some additional arguments, including vc_mem.mem_base. Adding them to bootargs did not help. My .dtb file was extracted from a local (x86_64 host) build of home:algraf:branches:Base:System dtb-source's dtb-bcm2835.spec. https://build.opensuse.org/request/show/212777 When using a .dtb file, fdtaddr needs to be set. This either requires a line similar to kerneladdr to `setenv fdtaddr ${fdt_addr_r}` or be specified in our script - not sure which is preferred in this case, duplicating addresses into our script or outputting `printenv` errors to the user? Can someone with a TTL UART adapter please check if there's anything more on serial output that might give us a clue of what's wrong? Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
