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