It's somewhat disappointing that despite my plea you still speculated
about what may have been the history and origins of something when I
already pointed you to where things actually are:
I told you the image packages have .kiwi files that, among others,
contain a list of packages:
I told you that those packages can be found in the same project as the
JeOS-raspberrypi.kiwi lists u-boot-rpi and raspberrypi-firmware that a
simple file search for "pi" or "u-boot" respectively could have
Those packages again document the origin of the files they install and
how they are built. So really no need to guess where things might come
from - our build process is all open, you just need to read.
Note the "Url:" and "Source:" lines in the .spec files.
Similarly the Wikipedia page that I pointed you to has a link to the
U-Boot Wiki that you could've just clicked on to find the sources,
instead of wasting time comparing hashes of u-boot.bin binaries.
And no, as already explained, U-Boot is the _new_ approach that goes
beyond what the Raspberry Pi Foundation did initially with their
proprietary, FAT-only bootcode.bin bootloader. Not the other way around.
And by my reading, unlike openSUSE, Fedora never did armv6hl builds,
which then is the explanation for that Pignus project that you came
across - nothing to do with U-Boot.
So no, we don't take packages or binaries from Raspbian but in this case
from GitHub, where Raspbian and others take them from, too. Same
principle as with U-Boot and other Open Source packages.
My patch for dwc2 OTG dual-role support was already merged:
It will be available in the Tumbleweed images once
None of that is in the way of OTG host mode though, which as I said was
working fine on the Model B rev. 2.
U-Boot does provide an "fdt" command to manipulate and extend the device
tree. Additionally, both U-Boot and GRUB can be used to point to a
custom .dtb file. Just device tree overlays are not supported at this time.
But you should really take one step after another: Get the board to boot
Linux to a prompt first. Then you can play with more advanced features
like gadget drivers or device tree modifications. Getting serial output
from the GPIO header would be a first good step, then you can easily
capture and better analyze the output from U-Boot.
Note that there is no .dts file for the Pi Zero in the v4.7 kernel:
Only v4.9 will have it. Not sure how our U-Boot version handles that.
Can you press a key to get a U-Boot prompt, then enter "printenv
fdtfile" and share the output? (A new u-boot package is on its way to
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org