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. Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
