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 <ton...@su-networking.com> 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 <ton...@su-networking.com> 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
