[opensuse-arm] Raspberry Pi 1&2 (probably 3, too) borken due to u-boot / grub setup.
Hi, after years of just ignoring openSUSE for rpi, and using yocto/openembedded, I thought I'd try it again. After all, I could even get support for it on raspi3 (which I do not yet have) ;-) It is still broken the same as when I last tried. The reason when booted normally, as almost everyone does, start.elf reads config.txt, configures the hardware according to it *and passes some customized boot parameters to the kernel*. Example (on a working yocto/OE-build, but raspbian does the same): root@raspi02:~# cat /proc/cmdline dma.dmachans=0x7f35 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708.boardrev=0xe bcm2708.serial=0x6xxxxxxx smsc95xx.macaddr=B8:27:EB:A9:00:DE bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait console=tty0 now some of these are static, namely root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep root= console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait but others are dynamic, and filled in by start.elf root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep ^dma\\. dma.dmachans=0x%x bcm2708_fb.fbwidth=%d bcm2708_fb.fbheight=%d bcm2708.boardrev=0x%x bcm2708.serial=0x%x root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep vc_mem\\. vc_mem.mem_base=0x%x vc_mem.mem_size=0x%x The worst part of this is, that the serial number and the mac address are not set. The NIC comes up with a random mac address and the raspi gets a new IP address on every boot. Not nice. So what's needed to fix this? Due to the convoluted way openSUSE does boot, the command line needs to be passed from start.elf to u-boot (easy, see below), then from u-boot to grub2-efi (here I gave up) and then in grub.cfg to the kernel. I have a patched, working u-boot-rpi2 in https://build.opensuse.org/package/show/home:seife:branches:Base:System/u-bo... (this is a proof of concept patch, it exports the command line as "bootargs_orig" variable to the u-boot shell) I'm back to openembedded on the raspis for now, will check if SLES12-SP2 is really sold with this bug too, once I get my hands on an raspberrypi3 :-) have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hey Stefan, On 13/11/2016 18:52, Stefan Seyfried wrote:
Hi,
after years of just ignoring openSUSE for rpi, and using yocto/openembedded, I thought I'd try it again. After all, I could even get support for it on raspi3 (which I do not yet have) ;-)
Welcome in openSUSE ARM land :)
It is still broken the same as when I last tried.
The reason when booted normally, as almost everyone does, start.elf reads config.txt, configures the hardware according to it *and passes some customized boot parameters to the kernel*.
Yes, unfortunately all of that magic only works with the downstream kernel. While we do have downstream kernel based ports available for various systems, the goal is always to design the systems in the most upstream compatible and workflow following ways possible.
Example (on a working yocto/OE-build, but raspbian does the same):
root@raspi02:~# cat /proc/cmdline dma.dmachans=0x7f35 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708.boardrev=0xe bcm2708.serial=0x6xxxxxxx smsc95xx.macaddr=B8:27:EB:A9:00:DE bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait console=tty0
now some of these are static, namely root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep root= console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
but others are dynamic, and filled in by start.elf root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep ^dma\\. dma.dmachans=0x%x bcm2708_fb.fbwidth=%d bcm2708_fb.fbheight=%d bcm2708.boardrev=0x%x bcm2708.serial=0x%x root@raspi02:~# strings /media/mmcblk0p1/start.elf|grep vc_mem\\. vc_mem.mem_base=0x%x vc_mem.mem_size=0x%x
The worst part of this is, that the serial number and the mac address are not set. The NIC comes up with a random mac address and the raspi gets a new IP address on every boot. Not nice.
There were numerous threads about that issue - on the upstream Linux ARM ML as well as on the openSUSE ARM ML. They basically always boiled down to patches like this: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-armv7-rc/00... with upstream Linux rejecting them. I'm not going to judge whether that's smart or not, but we don't want to maintain a bunch of downstream patches in the openSUSE kernel that upstream actively disagreed with.
So what's needed to fix this?
Aha! :) So after years of bikeshedding, upstream finally accepted one approach: https://patchwork.kernel.org/patch/8977811/ This allows us to define the mac address for USB devices inside device tree. U-boot even already knows how to handle that case. It searches for an ethernet alias in device tree and patches the mac address property according to the one it knows. Since U-Boot already has code to calculate the MAC address from the serial number of the RPi, it gets you the full flow.
Due to the convoluted way openSUSE does boot, the command line needs to be passed from start.elf to u-boot (easy, see below), then from u-boot to grub2-efi (here I gave up) and then in grub.cfg to the kernel.
Well, you really shouldn't need to do anything. U-Boot already determines the mac address and if the device tree has an ethernet node, it should automatically get patches with Linux using it. I'm not sure which kernel you're using though. Since the downstream kernel is (obviously) quite behind on anything non-rpi specific, there's a good chance that change didn't make it there yet. But with the current upstream image it should "just work".
I'm back to openembedded on the raspis for now, will check if SLES12-SP2 is really sold with this bug too, once I get my hands on an raspberrypi3 :-)
The SLES12-SP2 build as well as Tumbleweed on RPi3 and Leap on RPi3 follow the model I described above. They're lucky in a sense that there is no 64bit support in the downstream kernel, so people don't even start having funny ideas on how things should work :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Alex, Am 13.11.2016 um 19:52 schrieb Alexander Graf:
Hey Stefan,
On 13/11/2016 18:52, Stefan Seyfried wrote:
Hi,
after years of just ignoring openSUSE for rpi, and using yocto/openembedded, I thought I'd try it again. After all, I could even get support for it on raspi3 (which I do not yet have) ;-)
Welcome in openSUSE ARM land :)
Not yet fully :-) (the excellent built-to-fit crosscompilers from the openembedded SDK are still a major selling point) But for plain "run as-is, no development" boxes, a usable openSUSE would surely be nice.
It is still broken the same as when I last tried.
The reason when booted normally, as almost everyone does, start.elf reads config.txt, configures the hardware according to it *and passes some customized boot parameters to the kernel*.
Yes, unfortunately all of that magic only works with the downstream kernel. While we do have downstream kernel based ports available for various systems, the goal is always to design the systems in the most upstream compatible and workflow following ways possible.
Ah, ok. I didn't realize that the smscXXX.macaddress= parameter was a downstream patch. Well, if we could somehow get the address into an accessible environment, a udev rule that sets the MAC with ifconfig would still be possible.
Due to the convoluted way openSUSE does boot, the command line needs to be passed from start.elf to u-boot (easy, see below), then from u-boot to grub2-efi (here I gave up) and then in grub.cfg to the kernel.
Well, you really shouldn't need to do anything. U-Boot already determines the mac address and if the device tree has an ethernet node, it should automatically get patches with Linux using it.
Yeah, I found this out after connecting a serial console; before the interesting things were scrolled off the screen with "printenv"... So this patch is really obsolete as serial# and ethaddr are already available.
I'm not sure which kernel you're using though. Since the downstream kernel is (obviously) quite behind on anything non-rpi specific, there's a good chance that change didn't make it there yet. But with the current upstream image it should "just work".
I'll try. I installed kenrnel-default, kernel-lpae and kenrel-vanilla, in addition to kernel-rpi2, but they all did not boot at all. I'm now booting openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2016.11.11-Build5.1.raw, but it seems stuck at boot (after clearing the screen from the GRUB messages). Wait! right now it requested an IP address from the DHCP server... ...with the correct MAC address. Nice. It has no graphics output, though, but with a newer kernel-rpi2 this should finally all fit together.
I'm back to openembedded on the raspis for now, will check if SLES12-SP2 is really sold with this bug too, once I get my hands on an raspberrypi3 :-)
The SLES12-SP2 build as well as Tumbleweed on RPi3 and Leap on RPi3 follow the model I described above. They're lucky in a sense that there is no 64bit support in the downstream kernel, so people don't even start having funny ideas on how things should work :).
Ok, so there it might actually work. If not -- I at least have a support contract to have that fixed :-P Thanks, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (2)
-
Alexander Graf -
Stefan Seyfried