Orange Pi

Physical separation and change of language, twice, when pushed through two grey-matter interpreters should suffice.

…

…

Mummy, why is my computer screen bright pink and upside down? Is it broken?

No sweetie,the optical interface in your grey matter system controller has not yet adjusted to the up-down interpretation required for standard viewing¹ and your up-down will so adjust. Your pink is what all standard people define as shades of grey.

¹ Infant vision vs. older child & adult vision differences.

Mummy, why is my computer screen bright pink and upside down? Is it broken?

No sweetie, we bought a Mac and we call that a “feature”.

I’m pretty tired right now and it’s not even evening, so please forgive if what I say is gibberish. I did a little searching on the web just now. I found where in the linux devicetree source the framebuffer drivers are… I think. It might as well have been a shopping list in Mandarin Chinese. At least nobody can accuse me of stealing code. So I kept searching elsewhere.
Something hit me that was mentioned earlier about using U-Boot after reading some changelogs for the one of the drivers. I believe U-Boot configures the graphics hardware and creates a simple framebuffer. Looking at the u-boot github and my remembered experience of discovering the existence of that damned .fex file encoded as a binary to get the HDMI output up and running it seems like a very reasonable assumption.

The question really is about the most idiotic thing of all in my eyes. License compatibility. I don’t think there’s a problem but I’m not sure. After all u-boot is a binary loader, not a part of the operating system.
It seems like a potential starting point at least and possibly a way of avoiding reinventing the wheel.

e: I just discovered that u-boot supports serial upload of programs into RAM for execution. U-boot makes the Orange Pi sort of like my Coldfire demo board!

I’ve hacked around with uboot quite a bit for a company I used to work for (we were creating a custom boot sequence to load a heavily modified version of Ångström running on an Apalis T30 (Nvidia Tegra)).

If you like I can dig around in my memory and old hard drives to see if there is any way I can help out?

Phone posting. Please excuse the terse nature.
A u-boot based version seems like a better idea the more I think about it. It might even make what could be called u-boot generic possible. I may be the only person that’s interested though.
I wouldn’t worry just yet Glen. I do plan on trying basic bare metal access post u-boot when I get a chance.

The question really is about the most idiotic thing of all in my eyes. License compatibility. I don’t think there’s a problem but I’m not sure. After all u-boot is a binary loader, not a part of the operating system.

Yeah, there’s nothing wrong with creating a RISC OS port that relies on u-boot as a bootloader. The OMAP3, 4 & 5 ports all rely on u-boot for doing some of the initial hardware setup.

However if you’re going to rely on u-boot for setting up a fixed framebuffer then you’ll quickly run into the problem that RISC OS doesn’t like to be restricted to only having one screen mode available. You’ll be able to influence the OS to a certain extent via use of GraphicsV 16 and GraphicsV 7 (i.e. have a GraphicsV 7 implementation which only accepts the mode you returned from GraphicsV 16), but the mode change procedure is currently a tangled mess so there are likely to be some situations where the OS falls over or ends up using the wrong settings.

Yes absolutely. I’d expect it to go down in flames treating the framebuffer that way. It just seems like a means of doing a first step. I suspect on a Pi that it’s the GPU but when RISC OS is set up with a rotated display for portrait mode, screen mode changes don’t work properly. Well, they do sort of. The lower resolution modes don’t scale. They just appear in a smaller rectangle. Ugh. You know what I mean. As usual I’m posting tired. Words aren’t coming to me.
What I’m trying to say is even if the graphics modes could be short circuited to an extent, causing lower resolutions to only occupy a part of the buffer it could be a temporary solution. Or a problem. I’m not sure. I can’t think of how it’d handle the non-linearity of the X axis in the framebuffer in relation to the Y. Ie if you are at the end of a row and add 1, the next position is up (or is it down?) one row and at the first column.
If that is done when just using a rectangle on the framebuffer, it’d just keep going right. Sequential writes would fall apart. But that’s just one of many problems.

I’m still not ready to throw this in the too hard basket. It’s still an interesting idea, and it could give a new lease of life to older Android tablets among other things.

I really want to try some code on the Orange Pi PC but as I’ve said it’s my NAS, so I have to work something out. A frustrating thing about linux is that settings are such a pain to shift between devices. Maybe the Pi B from the Raspberry Pie Contest can stand in. Still unrelated but I have noticed the Raspberry Pi Zero is way more stable with RISC OS than Raspbian. It suffers from random lockups in linux which I believe are related to the USB OTG controller hardware. It works fine in RISC OS, so the Zero will stay my development machine.

edit:
The Pi B is now my temporary NAS / uPnP server.
The Orange Pi PC has an FTD232 type USB UART connected to the UART header on the OPi PC. After a couple of false starts getting the pins right the PC can talk to the OPi just fine. I can see U-boot and if I let it progress, see Linux. The u-boot prompt is way closer to my Coldfire demo board’s onboard almost-OS than I expected. I have to say this is really cool. Lots of ways to mess with memory, move things around, load things and even a monitor. Out of time for today but I’m going to upload the “Hello World” program I found on the Orange Pi forum to do a sanity test. I also may have found a program on GitHub with a BSD license that controls the graphics registers.

much later edit:
Too sore and tired after this week for complex thought. I tried to load a simple binary via serial to the Orange Pi. For whatever reasons the load commands are missing from the u-boot on the SD card for the Ubuntu distribution it uses. Looks like I need to set up a dedicated SD card for this, but that’s a bit of a sticking point. MicroSD cards are strangely hard to get here. All I can readily get are low capacity Chinese off brand ones that cost more than the Orange Pi PC did. Pretty sure that’s why that shop has them in stock. I’ll go through and check the ones I have to see if there’s an un-needed one that still works.
From what I read, I think the Sunxi u-boot version is a superset, not a subset of u-boot, and the tutorial I found for serial transfer of binaries on u-boot is using an AllWinner SoC, so all I can do is guess that the version used on the Linux image I’m using is old and / or peculiar.

Wasn’t well for a bit and it messed with my mind a bit, but I did try to make some progress in working out what’s going on. Compiling a U-boot with some interesting options is easy enough. Current versions also seem to have the ability to pass system configuration settings to the OS it is booting.
I built a version which unfortunately lost the ability to boot Ubuntu that was on the SD card. However what I built was apparently intended for the Linux mainline kernel, and aside from the errors resulting from my lack of knowledge, I did get the U-Boot prompt and gained the extra commands for loading images, debugging etc.

From what I’ve seen, the framebuffer may not be a major problem. The issue Linux seems to have with it is that it’s a hulking mass of disparate parts. It appears to be possible to use U-Boot to set up a framebuffer and possibly fiddle the registers after boot to change the resolution. The framebuffer part of the GPU also appears to support scaling.
Setting the resolution seems to require having knowledge of the registers if others beyond the standard HDMI “canned” resolutions are required. The registers are known.
I have found absolutely nothing on the audio yet except that it may be a proper DAC, and also appears to have inputs, but I don’t know if they are broken out. It wouldn’t be hard to work out. It’s just a lack of time on my part.

Please note I’m only just fiddling with the hardware or researching when I can steal a few minutes. I think what needs to be done first is definitely scrape together as much information on the finer details of the registers at possible.

Honestly I just want to get librogpio a bit more complete before I play with this too much.

Perhaps it could be cool to set up a definition of a CLI only RISC OS, that could be used for ports. That would be a first step (and it could be used as compute node or web server or file server). RISC OS CLI (call it RISC OS PICO if you want) should be much easier to port.

David, I like the way you think. Can a stubbed HAL be made with “snap in” modules being added that are loaded at boot? I know Tank’s Pi GPIO and serial work seems to do that, and that RISC OS supports OS SWIs being claimed by programs.
Isn’t there a way of changing console I/O from keyboard / screen to UART, or has that been obsoleted?

Last night I spent a good couple of hours trying to find where I put the u-boot source and binaries. Eventually I realised I compiled it on the Orange Pi PC before I made Linux un-bootable by dumping the version of u-boot with the options I wanted on it. Of course I re-imaged that card already. I tried cross compiling and the make freaked out. Looks like it had something to do with a pop to a disallowed register. Guess I’ll be doing another native compile and swapping SD cards or something.

Haven’t really been around, and my phone failing hasn’t helped, however I have been doing some reading. The main problem is definitely licensing.
Apparently there are magic numbers shoved into registers for the display hardware. I don’t know about now but I do know those numbers originated from OEM source with varying licenses.
Legalese regarding licenses isn’t my strong point I’m afraid.
Ignoring the legal side there seems to be enough information available to get most of the hardware functional.

I bought an Orange Pi Zero which uses the H2 chipset. Just mentioning it because info on the H2 seems to be pretty much non-existent and not worth bothering with.

Legalese is easy. Basically it is a lot of words that boils down to a bit of “cough up or STFU” coupled with a bit of “what’s mine is mine, what’s yours is mine, what’s everybody’s is mine”.

Thing is, ultimately all hardware works by pushing numbers into registers. The tricky bit is what numbers and when. :-)

From what I understand what has been causing developers issues are that Allwinner has source available with no license on it. It’s like a baited trap really.

If the code is there with no license then how could they claim another license applies to it later on if its been used in someone’s own proprietary or open source project?

Or is there an intrinsic/default license that applies as in “All Rights Reserved” or something…?

“All Rights Reserved” is licence! Which I’d interpret as “This is mine”. It is often followed by another statement relaxing that statement.
Unless a licence is stated then copyright still remains. If a work is made available by the author for download with no explicit licence, then I suggest courts would say that anyone can downloads and use the work (An implied licence) but there would be no other rights i.e. the downloader can’t pass it on.

I do wonder what their business model is though…

We are used to companies that are “This is ours and you have to pay to have it and if there are any faults then you wont know the cause and have to pay us to (maybe) fix them.” or “This is free to use and modify but you have to let others use and modify it as well and if there is a problem you can either deal with it yourself or pay for some support, oh and please pay a donation”

Can there be another way? Or is the other way “Use this freely until you create something really profitable and then we’ll send some lawyers around”

If the code is there with no license then […]

While it may depend upon the whims of a judge, technically if there is no licence there is nothing that grants you any right to make use of the code.

Preface remember I’m taling about the Orange Pi PC, which is H3 based.

I’ve been looking at the OMAP4 kernel source and comparing to the Allwinner H3 datasheet. I know, I should be looking at the datasheet too instead of the kernel source, but I was already there.
Clearly not the same but there are similarities. UART and USB are pretty close. Display is totally different but that’s no surprise.

Okay. Where in the kernel source are things like hardware base addresses?
The UART should be compatible-ish but the base address is different I believe.

Now I have DDE I was going to just do a butcher job on the OMAP4 kernel to see if the pre-HAL code does actually work to some degree on the H3.

Okay. Where in the kernel source are things like hardware base addresses?

Nowhere. The entire point of the HAL is to avoid having hardware dependencies within the kernel.

Now I have DDE I was going to just do a butcher job on the OMAP4 kernel to see if the pre-HAL code does actually work to some degree on the H3.

The pre-HAL code would be the system-specific bootloader, which would usually be out of our control :-)

The boot process is roughly:

1. The system-specific bootloader (u-boot, start.elf, boot ROM, ARM reset circuitry, etc.) will enter the HAL (usually at the start of the HAL/ROM image, but the entry point can easily be system-specific)
2. The HAL does basic hardware + CPU initialisation and RAM detection, as appropriate
3. The HAL calls into the kernel (RISCOS_Start entry point). This call never returns, the kernel is in control from here on.
4. The kernel enables the MMU and initialises itself
5. During the kernel initialisation HAL_Init and HAL_InitDevices will be called to allow the HAL to initialise itself and any hardware
6. Once the HAL + kernel are initialised the kernel will initialise the ROM modules
7. Once the ROM modules are initialised the “RISC OS xxxxMB” message will be displayed and the disc-based boot sequence will be executed

The UART addresses for the OMAP4 HAL are defined in hdr.omap4430. L4_UART3 will be the value to change (UART3 is routed to the serial port connector on the pandaboard). You’ll probably also want to enable the debug switch (at line 24 of hdr.omap4430) so that the HAL startup will try and say something (although the HAL does assume that the serial port is already initialised)

See also my “handy” not-quite-ten-step-plan for porting RISC OS.

Hi Jeffrey. I just wanted you to know I really appreciated your post. Before my previous post I had read your writeup on porting many, many times.
You have answered many questions for me. Unfortunately I haven’t had time to act on it. Just spent time looking through the kernel source to understand it a little better now I know what I’m looking for.

Really I didn’t want to reply without having some sort of progress, but it hasn’t happened as yet.

I’ve been messing around with the Orange Pi PC recently. In that thread in Aldershot I said I managed to build binaries using !GCC that I can execute with u-boot. A major bonus is when I search on the Internet about how to do X with an A7 or even just an ARM, the result is pretty much always applicable. The H3 a very straightforward SoC.

I’ve been trying lots of different approaches. Now my main focus is to build freestanding binaries so I can play with the hardware and check I’m getting things right. I’ve also had a crack at defining my own device type in the RISC OS build tree and failed miserably. I’ve also tried playing with the OMAP4 files without renaming and ran into an issue. It’s CortexA9 that is defined for it but the H3 needs CortexA7 which seems to be defined in multiple places for building.

The UART addresses definitely need a little changing. IIRC the H3 has 5 UARTs. 3×4 pin general purpose, the 2 pin debug UART and a 2 pin used for ??? The UART is plain 16550 with 16450 compatibility (is this 1993?). The other interfaces are mostly all pretty straightforward. The framebuffer is a bit of a headache, but shouldn’t be too bad. The Mali400 is only one part of the graphics system and looks to be perfectly fine being left alone.

Not sure if I’m misremembering but u-bot may wake up all four ARM cores and allocate memory to each, which could be interesting. Kind of makes me wonder what a modified kernel could do with that and the spinlocks.

I’ve also had a crack at defining my own device type in the RISC OS build tree and failed miserably.

If you describe the problems here then we can probably help! There is a list of places to change here but it wouldn’t surprise me if it’s wrong or incomplete.

Not sure if I’m misremembering but u-bot may wake up all four ARM cores and allocate memory to each, which could be interesting.

Yeah it wouldn’t surprise me if it wakes up the other cores. For AArch64 I think there’s a standard way in which u-boot prepares the cores so that the OS can easily take over control of them once it starts; it wouldn’t surprise me if modern versions of u-boot implement a similar system for AArch32.

Once I’ve gotten over today I’ll go through the documents/web pages again to see if I overlooked a file to change.
It wasn’t anything particularly bad. Just spent the whole day driving. I think I left my brain behind on the highway somewhere.

The default mainline linux setup for u-boot is pretty much right for RO straight off. One thing I do have to find out is if u-boot is still “active” after a program has been loaded. eg has it put in place an interrupt handler and where. That sort of thing.

I looked at the RK3288 thread. I’m definitely going to keep trying to work out something for the H3. I think the biggest stumbling block is me. Pretty much every interface including USB is an established industry standard.

IMHO the OPi PC2 / H5 should be left alone or just run as a hacked up H3 variant. It’s weird. I think it can be operated as an A8, with almost the same memory map as the H3, but something like SRAM and BROM have been swapped.