----- Bill Merriam <[email protected]> a écrit :
> 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:/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.
> > 
> > 
> > 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.

That works only on rpi downstream kernel. Since the smsc driver is modified to 
get this working.


Guillaume



> 
> Bill
> 

--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to