Can someone check support for RPi OTG? Req RPi 1 or RPi Zero today

Just to add:

on a fresh dd’ed SD-card with the image there should be two partitions, “BOOT” and “ROOT”, the “EFI” is prepared during first boot process.

What I dont’ get from your description so far is, what is the last output you see on serial console/monitor?

Do you see the initial load?
Do you see the “efi stub” message?

On first boot there is subsequently this error message described above

/lib/modules/4.3.3-5-raspberrypi/kernel/drivers/net/usb/usbnet.ko error=No such file or directory 

…but if you wait long enough the login appears and ssh is read for login (if an IP is provided for the random MAC assigned to the eth0 interface).

Am not sitting in front of the display, but I remember that the last dozen or so blocks of entries (yes, they’re each in their own stanza separated above and below by an empty line)

Load a file successfully
Error networking

Then, the very last entry is as I’ve described it, a command prompt with blinking cursor exactly as I’ve depicted

boot >

But, am thinking now it <might> be my attempt to invoke the dwc kernel module which I’ve 95% verified in my mind is unsupported without the Device Tree Overlay (or relevant definition), which I’ll post about separately to keep each sub-topic clear (following in this thread, since all seems to be relevant to this thread’s subject line).

TSU

Update on the lack of Device Tree overlays in the current RPi TW images…

First, a brief description what a Device Tree overlay is…
Within the past year or two, the Linux kernel has made a major change in defining how hardware devices are defined and supported. Whereas previously everything was stored in a single file with stanzas defining each hardware device, the complaint was that there was no organization (devices were not listed in any specific order), there was no definable hierarchy and the entire file had to be read serially to utilize.

The Device Tree was born so that devices are now defined in separate files in a specified location.
A Device Tree overlay is a separate location where device files can be added (typically during boot) to the mainline Device Tree distributed with the mainline kernel.

There are some additional important benefits, such as no longer loading all devices during boot so they are available.
The Device Tree allows only specified hardware to be loaded during boot (see Config.txt which is described next)

Some a priori basic info before talking about the Device Tree overlay

First, the reader should know that the RPi doesn’t have a BIOS in the conventional sense, but uses a file called Config.txt to set low level parameters the same way you’d ordinarily do it in a BIOS. If a setting isn’t set in this file, there are default values, so you’ll find the contents of this file vary wildly from one distro to another, but the settings are all standard and common settings so are portable between any distro.
https://www.raspberrypi.org/documentation/configuration/config-txt.md

The other important file to know about is the file cmdline.txt which is not currently distributed in openSUSE TW.
This file simply contains kernel boot parameters, similar to what we might specify in our GRUB menu on a full size machine.
The contents of the file are obviously injected “as is” into the kernel load command, so the content and formatting must be very exact, ie no extra spaces, tabs, line returns, etc. Like Config.txt, unless the kernel is highly customized, the content of this file is entirely portable between distros. I’m also assuming(perhaps wrongly) that the unique openSUSE u-boot.bin file isn’t loading the kernel in some unique way that would render cmdline.txt irrelevant.

How an overlay is implemented in RPi
The technical documentation for how is implemented in RPi
https://www.raspberrypi.org/documentation/configuration/device-tree.md

Without access to source (particularly u-boot.bin which is unique to openSUSE compared to other distros), I can only guess what is within the standard files that make up a TW RPi boot, so at this time I’m <assuming> as I experiment moving forward that functionality in these common files have not been removed… But, I also can’t be certain that there might be conflicts when there is functionality that can overlap (whatever u-boot.bin is doing which I can only guess at for now).

Bottom Line in Summary

  • Supporting the raspbian Device Tree overlay or implementing something similar is imperative. Currently there appears to be 70 definition files distributed by raspbian, many of which I recognize as **very **important like hardware support for dwc and i2c.
  • Right now, without access to source I’m blindly guessing at places what is happening so for instance can’t be certain if what I’m trying to do will work. I can make reasonable guesses based on things like file comparisons and maybe hashing the files to further verify that they’re identical, but it still leaves unanswered questions about unique files, particularly binaries.

Reverse-engineering is a lot of effort with uncertain results.
If this is all open source, I’d really, really like to just see and know what is happening…

TSU