[opensuse-arm] Raspberry Pi status update
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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 05.01.2014 16:23, schrieb Andreas Färber:
(Question: Contrib:Factory:RaspberryPi u-boot-rpib looks like openSUSE:Factory:ARM u-boot-rpib but there is no _link - is that intentional?)
Same for kernel-raspberrypi (with kernel-source being a symlink rather than the other way around), but there it's obvious that it has a custom patch in patches.suse.tar.bz2. That seems based on bcm2708 whereas Alex' dtb-bcm2835 seems from/for the upstream bcm2835. kernel-raspberrypi being at 3.11.4-1 and possibly incompatible with 3.12.5's bcm2835-rpi-b.dtb, I tried zImage-3.12.2-2-default from openSUSE:Factory:ARM kernel-default: U-Boot output is similar to that for kernel-raspberrypi, but after a while it reboots. I notice that in config-3.12.2-2-default the following are not set: CONFIG_I2C_BCM2835 CONFIG_BCM2835_WDT CONFIG_USB_HCD_BCMA /* not sure if applicable? */ CONFIG_MMC_SDHCI_BCM2835 Regards, 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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 05.01.2014 18:00, schrieb Andreas Färber:
I notice that in config-3.12.2-2-default the following are not set: CONFIG_I2C_BCM2835 CONFIG_BCM2835_WDT CONFIG_USB_HCD_BCMA /* not sure if applicable? */ CONFIG_MMC_SDHCI_BCM2835
Using openSUSE kernel.git master's `make ARCH=arm menuconfig` based on kernel-source.git config/armv6hl/default I've created the attached diff and manually backported it to Factory's kernel-source package, resulting in the attached config file. Unfortunately my local osc build is still not finished, so I'm sharing this untested. Since we're booting from SD card it seems logical to me to build in MMC drivers rather than having them as modules. I2C and WDT ended up being straightforward additions by contrast. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Le 07/01/2014 01:40, Andreas Färber a écrit :
Am 05.01.2014 18:00, schrieb Andreas Färber:
I notice that in config-3.12.2-2-default the following are not set: CONFIG_I2C_BCM2835 CONFIG_BCM2835_WDT CONFIG_USB_HCD_BCMA /* not sure if applicable? */ CONFIG_MMC_SDHCI_BCM2835 Using openSUSE kernel.git master's `make ARCH=arm menuconfig` based on kernel-source.git config/armv6hl/default I've created the attached diff and manually backported it to Factory's kernel-source package, resulting in the attached config file.
Unfortunately my local osc build is still not finished, so I'm sharing this untested. Since we're booting from SD card it seems logical to me to build in MMC drivers rather than having them as modules. I2C and WDT ended up being straightforward additions by contrast.
Thanks for fixing that. Once your build is finished, you could submit your patch in opensuse-kernel ML to get it in GIT repo. Guillaume
Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 07.01.2014 10:02, schrieb Guillaume Gardet:
Le 07/01/2014 01:40, Andreas Färber a écrit :
Am 05.01.2014 18:00, schrieb Andreas Färber:
I notice that in config-3.12.2-2-default the following are not set: CONFIG_I2C_BCM2835 CONFIG_BCM2835_WDT CONFIG_USB_HCD_BCMA /* not sure if applicable? */ CONFIG_MMC_SDHCI_BCM2835 Using openSUSE kernel.git master's `make ARCH=arm menuconfig` based on kernel-source.git config/armv6hl/default I've created the attached diff and manually backported it to Factory's kernel-source package, resulting in the attached config file.
Unfortunately my local osc build is still not finished, so I'm sharing this untested. Since we're booting from SD card it seems logical to me to build in MMC drivers rather than having them as modules. I2C and WDT ended up being straightforward additions by contrast.
Thanks for fixing that.
Once your build is finished, you could submit your patch in opensuse-kernel ML to get it in GIT repo.
Okay. Build finished over night, no visible change when booting. I also tried the u-boot-rpib from Factory:ARM rather than Factory:Contrib, renaming boot.scr to boot.scr.uimg, no change either. (I am planning to submit the rename fix to Base:System once my pending https://build.opensuse.org/request/show/212959 has been processed.) I notice that CONFIG_ARM_APPENDED_DTB=y is set. Does that *require* or does it *allow* a directly appended dtb? If the latter, then I could try rebuilding with CONFIG_ARM_ATAG_DTB_COMPAT set as last resort, which was required on my AC100 when using Android's fastboot bootloader. Just to be sure I tried appending the dtb to my zImage, but no change either. 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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.01.2014, at 12:44, Andreas Färber
Am 07.01.2014 10:02, schrieb Guillaume Gardet:
Le 07/01/2014 01:40, Andreas Färber a écrit :
Am 05.01.2014 18:00, schrieb Andreas Färber:
I notice that in config-3.12.2-2-default the following are not set: CONFIG_I2C_BCM2835 CONFIG_BCM2835_WDT CONFIG_USB_HCD_BCMA /* not sure if applicable? */ CONFIG_MMC_SDHCI_BCM2835 Using openSUSE kernel.git master's `make ARCH=arm menuconfig` based on kernel-source.git config/armv6hl/default I've created the attached diff and manually backported it to Factory's kernel-source package, resulting in the attached config file.
Unfortunately my local osc build is still not finished, so I'm sharing this untested. Since we're booting from SD card it seems logical to me to build in MMC drivers rather than having them as modules. I2C and WDT ended up being straightforward additions by contrast.
Thanks for fixing that.
Once your build is finished, you could submit your patch in opensuse-kernel ML to get it in GIT repo.
Okay. Build finished over night, no visible change when booting.
I also tried the u-boot-rpib from Factory:ARM rather than Factory:Contrib, renaming boot.scr to boot.scr.uimg, no change either. (I am planning to submit the rename fix to Base:System once my pending https://build.opensuse.org/request/show/212959 has been processed.)
Accepted.
I notice that CONFIG_ARM_APPENDED_DTB=y is set. Does that *require* or does it *allow* a directly appended dtb? If the latter, then I could try
It *allow*s a directly appended dtb.
rebuilding with CONFIG_ARM_ATAG_DTB_COMPAT set as last resort, which was required on my AC100 when using Android's fastboot bootloader. Just to be sure I tried appending the dtb to my zImage, but no change either.
Do you have a reset pin on there somewhere? If so, you could try to reset the system after you booted the kernel and then try to dump __log_buf from the still-alive RAM that the kernel wrote it to (you can find the virtual address with nm on vmlinux, just add the physical RAM offset to that for u-boot's md command). Since you don't seem to have a working USB driver, you could add said md command to your boot.scr so that u-boot always dumps log_buf after reset. That way you might be able to find out what's going wrong. Of course, a serial port would help as well. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Thanks Andreas for your time and effort. All my attempts were based on - berryboot and kernel-raspberry with these two I had the problem that the config.txt setup for berryboot never loaded an initrd and the kernel-raspberry kernel was not compiled with support for initrd. I think you tried with - u-boot and kernel-default + dtb Is that correct ? I'm just asking because I'm not sure which is our preferred way for supporting raspberry boards Thanks Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.01.2014, at 19:14, Marcus Schäfer
Hi,
Thanks Andreas for your time and effort.
All my attempts were based on
- berryboot and kernel-raspberry
with these two I had the problem that the config.txt setup for berryboot never loaded an initrd and the kernel-raspberry kernel was not compiled with support for initrd.
I think you tried with
- u-boot and kernel-default + dtb
Is that correct ?
I'm just asking because I'm not sure which is our preferred way for supporting raspberry boards
The best case scenario would be to do it the same way as on the chromebook, so we fake an "EFI partition" which we shove the raspberry specific stuff and a u-boot binary onto and then bootstrap the whole system from there the same way as every other. However, since that's been our preferred way of doing it for the past year and nobody managed to get it working, anything that gets us rolling is good enough for now. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Marcus, Thanks for your efforts of getting us a building JeOS image at all. :) Am 05.01.2014 19:14, schrieb Marcus Schäfer:
All my attempts were based on
- berryboot and kernel-raspberry
Sorry, I have no idea what berryboot is. That's something we're neither using in the JeOS image nor have packaged in Factory:Contrib, it seems?
I think you tried with
- u-boot and kernel-default + dtb
Is that correct ?
I left the bootcode.bin etc. in place and based upon that I tried booting different binaries via Config.txt: kernel=zImage (JeOS-raspberrypi defaults) => OK, but no way to specify initrd in Config.txt kernel=zImage, device_tree=bcm2835-rpi-b.dtb, device_tree_address=0x100 => no boot (arguments no longer valid?) kernel=u-boot.bin (u-boot-rpib patched to load our boot.scr) boot/linux.vmx + boot/initrd.uboot boot/linux.vmx + boot/initrd.uboot + bcm2835-rpi-b.dtb boot/linux.vmx + bcm2835-rpi-b.dtb boot/linux.vmx zImage-3.12.2-2-default + bcm2835-rpi-b.dtb zImage-3.12.2-2-default + boot/initrd.uboot + bcm2835-rpi-b.dtb => U-Boot on HDMI, but no output after "Starting kernel ..." Alex told me the preferred way to boot were to use U-Boot everywhere, thus my efforts to get a working setup. Regards, 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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (4)
-
Alexander Graf -
Andreas Färber -
Guillaume Gardet -
Marcus Schäfer