Possibly my last message in this thread for a long while... A likely fairly final update for now...
After looking around quite a bit, I think I've finally found references for how the critical binaries u-boot.bin and start.elf are created and so also likely know the current contents of these files which have to some extent verified some of my earliest guesses about overlapping and actual functionalities. I won't fill this post about details but if anyone wants to discuss these files with me, I can always be PM'd. Bottom line which might be important to openSUSE maintainers is that the "modern" raspbian method for booting uses a binary blob they don't directly manage which includes "semi-proprietary" code, ie code with licensing restrictions although has been clearly authorized for use by raspbian. This probably does not comply with openSUSE licensing policy. My preliminary evaluation is that it's likely possible to use this alternate way to boot (maybe even forking from the Fedora ARM project) but would likely have to be an unofficial project. The alternative to stay with u-boot.bin and easily integrate future hardware support is likely going to be difficult, at least it looks like no one I can find seems to want to do it, and I doubt that Das Boot may want to do the work themselves to create a routine that automatically compiles Device Tree definitions (standard format). The immediate effect is as I described above... Unlikely support for OTG (Pignus is currently not working, their effort is only 2 mths old as of this writing) and any/all HATS (Daughterboards). If someone can actually post how at least a HATS can work, I'd really like to know how they got it to work. Tony On Wed, Sep 28, 2016 at 12:18 PM, Tony Su <ton...@su-networking.com> wrote: > More a FYI for anyone who is interested in trying to implement OTG.... > > I haven't yet been able to get the following to work, but if > successful then it can provide an immediate solution specifically to > implement OTG and nothing else I mentioned in the previous post. > > The following is the heart of what the pignus Zero project is doing, > which is to very specifically define and inject the required kernel > module "gadget" and then set up a systemd service that implements. > https://github.com/pignus-project/pignus-kickstarts/blob/master/pignus-zero.ks > > The approach avoids all the likely incompatibilities and effort > required to augment the Device Tree and manually configures what needs > to be done so avoids any need to dynamicly inject kernel parameters. > > No need for anyone else to look into this unless they want to, I'll > report on its success (or not) and if successful might be able to > propose something. It's still a Band-Aid because IMO lack of support > for everything else will be significant to many people building more > featured devices. > > Tony > > On Wed, Sep 28, 2016 at 8:49 AM, Tony Su <ton...@su-networking.com> wrote: >> 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
