On Wed, 2016-03-16 at 23:21 +0100, Alexander Graf wrote: > > 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
The serial number is available in the One Time Programmable memory. http://elinux.org/RPI_vcgencmd_usage vcgencmd otp_dump |grep 28: |cut -b 4- The MAC address seems to be RPI's prefix b8:27:eb plus the last 3 bytes of the serial. Bill -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
