On 17.03.16 20:26, Bill Merriam wrote:
On Thu, 2016-03-17 at 16:02 +0100, 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:/Rasp... >>>> >>>> >>>> >>>> (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:/Rasp... >>> >>> >>> 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.
Guillaume
Alex
In the version of boot.script (and boot.scr) that I have there is this long statement to set boot args to pass to the kernel. The MAC address for the ethernet adapter is set via "smsc95xx.macaddr"
setenv bootargs "root=/dev/disk/by-id/mmc-SE32G_0xa82b1160-part3 loader=uboot disk=/dev/disk/by-id/mmc-SE32G_0xa82b1160 resume=/dev/disk/by-id/mmc-SE32G_0xa82b1160-part4 quiet splash=silen t plymouth.enable=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200n8 kgdboc=ttyAMA0,115200 rootflags=commit=120,data=writeback smsc95xx.macaddr=${usbethaddr} ${append}"
I then set "usbethaddr" as an environment variable and it works nicely. I just used the last random address but I can set the right one that way.
As Guillaume mentioned this is a special hack for the downstream kernel that *should* already work. I'm surprised it doesn't. If you have some time on your hands, please try to debug down why usbethaddr doesn't get set automatically - the code for it is in U-Boot. Going forward, we will move to a more standard EFI based booting mechanism though, which means we can't access U-Boot variables in the kernel command line anymore. So we need a different mechanism to pass the mac address into the kernel. The "usual" way to get things from firmware into the kernel is device tree. The patches I pointed at in the other mail enable support for exactly what we need, so we're getting close to a clean solution. This should also help us on other boards that have ethernet attached via USB, such as the Arndale ones. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org