On 17.03.16 16:02, Guillaume Gardet wrote: > > > Le 17/03/2016 15:59, Alexander Graf a écrit : >> >> On 17.03.16 15:56, Guillaume Gardet wrote: >>> Le 17/03/2016 15:48, Guillaume Gardet a écrit : >>>> Le 17/03/2016 15:40, Alexander Graf a écrit : >>>>> On 17.03.16 15:25, Bill Merriam wrote: >>>>>> 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. >>>>> This big problem is not how to fetch the 3 bytes. It's how to pass >>>>> them >>>>> all the way from u-boot via fdt to the kernel and have the kernel >>>>> properly use it as the mac address for the usb ethernet adapter. >>>> You may ask on u-boot mailing list. I think u-boot is able to do it >>>> more or less automatically. >>> Have a look at fdt_fixup_ethernet(...) function. >> That only works for devices listed in device tree though, right? The eth >> adapter is attached to USB which doesn't list its devices in dt. > > Yes, I think so. > Ask on u-boot ML, maybe people would have some idea.
This really is a kernel problem, not a U-Boot one ;). So I asked on the #armlinux channel. Apparently someone else felt the same pain on other boards and so we have all the infrastructure in place soon to deal with this via device tree: http://www.spinics.net/lists/linux-usb/msg136469.html https://lkml.org/lkml/2016/2/3/621 With these (switching to upstream for RPi will only become realistic within the 4.6 time frame anyway) and the existing logic in U-Boot to write the mac address property for ethernet devices, all we need is a small device tree patch to explicitly list the usb ethernet adapter! Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
