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