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/0005-net-smsc95xx-Allow-mac-address-to-be-set-as-a-parame.patch
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: [email protected]
To contact the owner, e-mail: [email protected]
