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

Reply via email to