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 <ton...@su-networking.com> 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 <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
