On 16.03.16 20:00, Bill Merriam wrote: > On Thu, 2016-03-03 at 20:18 +0100, Dirk Müller wrote: >> Hi, >> >> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi2:/Staging/images/ >> >> >> (yeah, I know its the Pi2 path, I was lazy) contains an untested >> raspberrypi3 image. I already know that serial is broken, that seems >> to be an upstream issue (due to the changed clock frequencies). >> >> I haven't tested it further yet, need to buy some HDMI capable screen >> first. Let me know your findings. >> >> Greetings, >> Dirk > > I have successfully installed this image: > > http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi2/images/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.armv7l-2016.03.09-Build5.2.raw.xz > > It has several issues with booting. Uboot issues messages for a while > and eventually comes to a prompt. If I type "boot", it boots up. At
This is my fault again - as soon as the image got rebuilt with the fixed U-Boot package (that was stuck in Factory review for a week) this error should be gone. > some point I noticed in dmesg a complaint that the first partition was > "dirty" and needed an fsck. It is a FAT filesystem and fsck.fat isn't That's weird. Sounds like a flushing bug during build? > installed. I installed "dosfstools" and checked the file system. > > One of the uboot messages complained that "usbethaddr" was not set. I don't think we support the usb mac stuff quite yet. If you have great ideas how to make it work with upstream U-Boot, we're more than happy to see patches :). > Every time it boots it chooses a new MAC address which causes the dhcp > server to give it a new address every time. I set that variable and did > a saveenv. I suppose that is supposed to happen somehow during the > first boot. The way it works without U-Boot is that the RPi bootloader generates the mac address from the pi serial number. We should probably do the same in U-Boot. IIRC it then gets passed to the kernel using the kernel command line. That's a horrible interface, as it breaks any integration with boot loaders (like grub2). So if we want to move this to an efi based boot mechanism, we need to instead inject the mac address into the device tree. I'm not quite sure where though - usb is not described in dt. > There are also messages about variables "bootfile" and "pxeuuid" being > missing. Variable "scan_dev_for_efi" is a script that tries to set > variable "boot_prefixes" but doesn't get it right. That's the bug that was fixed in u-boot and stuck in review. Basically the bootfile definition got included in the scan_dev_for_efi variable while it should've been its own variable. I simply forgot the null terminator. > I will read u-boot documentation and try to figure it out but if > somebody fixes it I can move on to something else. That leaves the mac address thing to fix :). Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
