Have received some preliminary answers to the above questions... I've read online references to the RPi boot process which describe what I see on a raspbian but raise some questions about the openSUSE boot process. Currently, am assuming there should not be any difference how a raspbian boots and how a RPi TW boots despite the TW lacking a number of files. I assume that although I don't think is documented, it may be that the cmdline.txt file and various entries in the raspbian config.txt are optional and if I want to add these files to my TW, those files will be read because it's unlikely someone would explicitly remove the code that would do that. Also, I wonder if there is a bug in at least the most current RPi 1 JeOS image(see my link in above post), it seems to start to boot silently but terminates at a "boot>" prompt with only the following files on the disk bootcode.bin Config.txt fixup.dat LICENCE.broadcom start.elf u-boot.bin I understand on first boot, the contents of the above files should be extracted and written to the SDcard, but it's not happening on my machine... And I think if the boot process has started I should see a lot more than just the above listed files after first boot. BTW - unless something related isn't working, I would think that there should be a bootlog, maybe saving the last 3 or so boots unless there is a way to restart the boot in a debugging mode which would do so. Thx, Tony On Sat, Sep 24, 2016 at 3:54 PM, Tony Su wrote:

Right now, When I insert the RPi 1 image into my RPi Zero, it just sits there... nothing happening. I'd ordinarily expect the LED light to be blinking furiously as the system boots up, so it's likely the image just isn't bootable.

Have written the image 2 ways... Following the instructions as described on the following link using xzcat to decompress the JEOS .xz file, which is then piped to dd, writing to the sdcard.

https://en.opensuse.org/HCL:Raspberry_Pi

I also extracted the file, then used Win32DiskImager to write results to the sdcard blindly which still wouldn't work...

When both failed, I took a look at what the uncompressed result was, and I see not a raw file system but executable binary files and the main image in ELF format.

Is the flow for how these files are supposed to execute documented somewhere? Or, is the source for all this publicly visible(I've looked around, can't find in OBS, Studio, GitHub)? It's kind of hard to see where the problem might be when the code is in binary format...

Thx, Tony

. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

For now, I assume that openSUSE Rpi 1 images are based on the 3rd party community based Fedora/Pignus project which also uses u-boot.bin. https://pignus.computer/ On Mon, Sep 26, 2016 at 12:14 PM, Tony Su wrote:

Update: I've verified that the raspbian installs a Device Tree overlay which adds device definitions to the Device Tree already in the kernel, and among the 70 added devices are definitions for dwc and dwc2.

So, it appears that even if you enable related kernel modules, if you don't also enable hardware support you're going to be SOL.

I'm flying a bit blind trying to determine how best to try to incorporate support for the raspbian Device Tree overlay into TW because TW has some unique files, in particular u-boot.bin which I'm guessing likely loads the kernel and maybe does other stuff... But without seeing exactly what is the Rpi boot process, I'm experimenting in the dark.

I'd rather not try to reverse engineer what I can't currently see. Is there a public repository for the Rpi ARM project which can be inspected? Although it would be nice to inspect and verify other file contents, my current focus is on u-boot.bin with possible consequences not only for the Device Tree but also whether cmdline.txt is missing because it's not effective in an openSUSE Rpi (and then I'd need to know the alternative which works).

Thx, Tony

On Sun, Sep 25, 2016 at 5:58 PM, Tony Su wrote:

...

Have received some preliminary answers to the above questions... I've read online references to the RPi boot process which describe what I see on a raspbian but raise some questions about the openSUSE boot process.

Currently, am assuming there should not be any difference how a raspbian boots and how a RPi TW boots despite the TW lacking a number of files. I assume that although I don't think is documented, it may be that the cmdline.txt file and various entries in the raspbian config.txt are optional and if I want to add these files to my TW, those files will be read because it's unlikely someone would explicitly remove the code that would do that.

Also, I wonder if there is a bug in at least the most current RPi 1 JeOS image(see my link in above post), it seems to start to boot silently but terminates at a "boot>" prompt with only the following files on the disk

bootcode.bin Config.txt fixup.dat LICENCE.broadcom start.elf u-boot.bin

I understand on first boot, the contents of the above files should be extracted and written to the SDcard, but it's not happening on my machine... And I think if the boot process has started I should see a lot more than just the above listed files after first boot.

BTW - unless something related isn't working, I would think that there should be a bootlog, maybe saving the last 3 or so boots unless there is a way to restart the boot in a debugging mode which would do so.

Thx, Tony

On Sat, Sep 24, 2016 at 3:54 PM, Tony Su wrote:

...

Right now, When I insert the RPi 1 image into my RPi Zero, it just sits there... nothing happening. I'd ordinarily expect the LED light to be blinking furiously as the system boots up, so it's likely the image just isn't bootable.

Have written the image 2 ways... Following the instructions as described on the following link using xzcat to decompress the JEOS .xz file, which is then piped to dd, writing to the sdcard.

https://en.opensuse.org/HCL:Raspberry_Pi

I also extracted the file, then used Win32DiskImager to write results to the sdcard blindly which still wouldn't work...

When both failed, I took a look at what the uncompressed result was, and I see not a raw file system but executable binary files and the main image in ELF format.

Is the flow for how these files are supposed to execute documented somewhere? Or, is the source for all this publicly visible(I've looked around, can't find in OBS, Studio, GitHub)? It's kind of hard to see where the problem might be when the code is in binary format...

Thx, Tony

. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

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 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-raspberryp...

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

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 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....

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 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 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-raspberryp...

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 16.10.2016 um 00:00 schrieb Andreas Färber:

Note that there is no .dts file for the Pi Zero in the v4.7 kernel: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm... 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?

U-Boot> printenv fdtfile fdtfile=bcm2835-rpi-zero.dtb bcm2835-rpi-zero.dtb doesn't exist in dtb-bcm2835 4.7, leading to: libfdt fdt_check_header(): FDT_ERR_BADMAGIC before it enters GRUB with my modified image or runs our boot.scr with the official image. The workaround then is very easy: a) Interrupt U-Boot and manually load an existing .dtb file: load mmc 0:2 $fdt_addr_r dtb/bcm2835-rpi-b-plus.dtb or with my experimental GRUB based image boot/dtb/bcm2835-rpi-b-plus.dtb b) Create a bcm2835-rpi-zero.dtb symlink to that file: cd /boot/dtb ln -s bcm2835-rpi-b-plus.dtb bcm2835-rpi-zero.dtb This step may need to be repeated after zypper up/dup installs new dtb-bcm2835 packages. If you create the symlink on your host, you can skip step a). Eh voilà, you get a booting Tumbleweed system. 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org