Hi, Sorry about any inaccurate postings I may be making in my impatience moving trying to move faster than you are able to respond, and I'm not blaming you or anyone else for responsiveness, I'm really appreciative of your answers and am under a strict timeline if I'm to use openSUSE images.
My OBS search was probably "User Error" not selecting the correct OBS category. But, what is in the OBS project you referenced still doesn't provide much info. From what I'm now guessing, it looks like the Kiwi files only describe "SUSE stuff," ie SUSE repos, packages installed, packages deleted, etc. It seems to be entirely silent on u-boot.bin plus the "standard Rpi" files including bootcode.bin, start.elf and Config.txt. So, These questions... I've done hashed comparisons to verify that bootcode.bin and start.elf are almost certainly the exact same files as raspbian which might be considered "mainline Rpi." I assume that these files are updated and are the latest from raspbian? openSUSE somewhat uniquely uses u-boot.bin (das boot). As a relatively newcomer to looking at this and Rpi boot architecture, I've compared what Fedora and Debian are doing to what we are doing. I'm guessing that... u-boot.bin was standard when first generation (Rpi 1) was released. This may be why openSUSE started using das boot which apparently has a very long history (more than a decade) enabling a consistent approach to booting embedded devices across a universe of platforms. But, I'm also guessing that by the time Rpi 2 was released, raspbian determined that u-boot.bin was no longer suitable moving forward for possibly a number of reasons (Device Tree to be mentioned soon). Since u-boot.bin is not replaced by another similar utility, it looks to me like those functions were likely embedded in start.elf (This is purely an educated guess) so today there is likely an overlap in functionality which may or may not be important. So, starting with RPi 2, raspbian implemented its "new, improved" architecture and Fedora likely followed suit. Today, It looks like raspbian installs all 3 generations of Rpi by using a base procedure and additional/appropriate kernels and start.elf sub-files for each type of Rpi. Fedora seems to have adopted the new architecture only as of Rpi2 (and 3), and decided to maintain the original codebase by splitting off the original architecture based on u-boot.bin as a community project (https://pignus.computer/) openSUSE seems to build all its Rpi images to still use the u-boot-bin architecture, modifying kernels and packages as appropriate(I haven't looked closely at all images, this is based solely on what I'm seeing in the OBS kiwi definitions but that seems to be all I have to work with for now). This decision to continue to use the u-boot.bin boot architecture is significant. I don't know how many things are affected, but it seems that extending hardware support to numerous daughterboards (hats) and other hardware including dcw/dcw2 are affected, and it's now questionable whether it's possible to inject kernel load parameters by the User. Re: Kernel load parameters Das boot documentation describes setting environment variables, but I don't see a User friendly way to do this on first boot... I suspect this might be something that might be possible only on subsequent boots. Re: Extending the Device Tree This is and will be a critical capability in embedded devices, particularly those who "stack" their boards. Currently, raspbian provides support for 70 additional types of hardware which openSUSE does not because those additional types are added in through a Device Tree overlay. Das boot does not provide an easy way to augment the Device Tree, it instead seems to implement the Device Tree as a binary blob which was probably an advantage before current standard Kernel re-architecture, and requires that adding to the Device Tree has to be pre-compiled before merging http://www.denx.de/wiki/DULG/UBootCmdFDT Unless someone can provide the answers to the following questions differently than I now believe, I think some serious thought might have to be made to re-architecture moving forward. For now, unless the following has easy answers I've not yet found, I don't think for example OTG is possible on openSUSE which is a significant and important capability. - Is it possible to easily inject kernel load parameters on first boot, particularly to load specified loadable kernel modules? - Is it possible to extend support for hardware not supported by default easily on first boot? Thx for your time, Tony On Tue, Sep 27, 2016 at 3:22 PM, Andreas Färber <afaer...@suse.de> wrote: > Tony, > > Please STOP spreading wild speculations!!! > I never even heard of the project you accused us of using. > > https://en.wikipedia.org/wiki/Das_U-Boot > > All openSUSE images and packages are built on OBS: > https://build.opensuse.org/ > > Each image has a corresponding package on OBS and the .kiwi file in the > package contains a list of packages that are again found on OBS. > > All official Tumbleweed ARM images and packages are in the > openSUSE:Factory:ARM project: > https://build.opensuse.org/project/show/openSUSE:Factory:ARM > > In your case: > https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS-raspberrypi > > Just the other day this was once again mentioned in another thread on > this same mailing list! > > Why U-Boot? openSUSE cannot be installed on FAT partitions, they don't > support symlinks among others. U-Boot on the FAT partition allows us to > boot the kernel from an ext4 partition or since recently also GRUB2 as > UEFI bootloader that in turn loads the kernel. Both allow interactivity. > > Device tree overlays or cmdline.txt are not used by U-Boot. > > Regards, > Andreas > > -- > 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+unsubscr...@opensuse.org > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
