Allwinner H3

I got it!
I didn’t even think to touch the interface control registers because they are lumped in with the EHCI and OHCI registers on a per host basis. After having a look at the U-Boot source I realised they are “hands on” registers. Relevent bits got set, and now I can see the USB drive!

Of course there’s still a lot to do even with USB, including re-enabling the OHCI ports and trying to work out what the module wants, and whether it can even be provided. But this is good! Now I can make progress again, including the desperately needed early boot things like RAM size detection.

Since the last post I’ve mostly been working on code cleanup. Things are kind of tattered after all the efforts to get things working.

Most of the useful headers are now hdr2h compliant, with one major exception. StaticWS. is there any way to deal with “OSentries # 4*(HighestOSEntry+1)”?

I’ve enabled a heap of extra modules too. RTSupport actually works now, which is good.

The chunk of (U-Boot set?) VRAM near the top of RAM can now actually be mapped in as VRAM in RISCOS_AddRAM without locking the system solid. So that’s done now instead of being mapped as IO. Not that it does anything yet anyway.
It made me curious so I had another look at the HAL Video API on the RO wiki. Definitely have no idea what’s going on there :)

Michael Grunditz’s threads are a great resource for me. He encountered a lot of the same things I am.

I think the main reason I am looking at the Video part of the HAL right now was I was contemplating what has to be done to allow RISCOSMark to run.
Both FireBench and RISCOSMark can’t even run for the same, rather obvious reason “File ‘WimpSlot’ not found (Error number &D6)”. I think ROMark complains about the SWI not being there, but same thing really.

Most other things fall flat with “File ‘IconSprites’ not found (Error number &D6)”.

It’s a bit of a shame, but no big deal.

Oh! Only semi-related, but when I got the code to the point where it could boot happily with uImage, a piece of key behaviour was changed somewhere.
I’d mentioned it previously that on completion of boot BASICVFP would be running for some reason, which needed to be quitted to get back to the SVC prompt. It’s behaving now.

Just for the sake of it… not all of these function totally because of missing SWIs, but they can load.

*modules 
No. Position Workspace Name 
  1 FC028F34 00000000  UtilityModule 
  2 FC04D810 20000014  PCI 
  3 FC04F7BC 200001D4  FileSwitch 
  4 FC05C5A0 20001694  ResourceFS
  5 FC05D2A0 00000000  Messages 
  6 FC09005C 200016F4  MessageTrans 
  7 FC091448 200032B4  UK 
  8 FC093004 00000000  Desktop 
  9 FC093C6C 00000000  SharedCLibrary 
 10 FC0FF614 20003394  BufferManager 
 11 FC112764 20003474  DeviceFS 
 12 FC118A50 200035B4  USBDriver 
 13 FC1251C0 2000FF74  EHCIDriver%2 
    FC1251C0 2000C454  EHCIDriver%1
    FC1251C0 200085B4  EHCIDriver%Base 
 14 FC16EC04 20015694  InternationalKeyboard 
 15 FC0C82E8 20015994  ScreenModes 
 16 FC0CEE60 00000000  BASIC 
 17 FC0E016C 00000000  BASIC64 
 18 FC0EF640 00000000  BASICVFP 
 19 FC10087C 20015114  Debugger
 20 FC114C70 200150D4  Portable
 21 FC115698 20018374  RTSupport 
 22 FC130F48 20031314  FileCore%SCSI 
    FC130F48 00000000  FileCore%Base
 23 FC144EAC 20014674  Filer 
 24 FC14DF94 20014574  FilerSWIs 
 25 FC14E284 20013954  FontManager 
 26 FC15EF1C 200137F4  FPEmulator 
 27 FC1654DC 2001A714  VFPSupport
 28 FC16D41C 2001A8D4  Free 
 29 FC181BC0 00000000  Obey
 30 FC183808 00000000  Serial 
 31 FC185390 2001B214  SerialDeviceSupport 
 32 FC185A68 2001B234  Squash 
 33 FC1876C4 2001C374  DOSFS 
 34 FC193340 2001D6F4  SCSIDriver 
 35 FC196A48 2001ED14  SCSISoftUSB 
 36 FC19A63C 20031054  SCSIFS 
 37 FC19BE20 200727D4  BootCommands 
 38 FC19E538 00000000  AUNMsgs 
 39 FC19E62C 20020354  MbufManager 
 40 FC1A0D38 200BCF94  Internet 
 41 FC1C1C44 200C10D4  Resolver
 42 FC1C5EFC 200C2AF4  MimeMap 
 43 FC1C7268 200C3DB4  EtherUSB

e:since that post I’ve added nearly the full complement of modules to the build. It’s helped with random issues because of missing stuff.
Back to it I guess.

My RPi3 that I use for development had a bit of a hiccough last night when the DVI cable got knocked. I eventually got RO not just display a blank screen after booting again, and the pinboard icons came back. But it scared me a little. While I’m backing up the project files, the rest of the source tree isn’t. It has bits and pieces grabbed from CVS and transplanted in

So here I am trying to get SVN working again on my “file server”. I’m not fond of Subversion at all. It does however have the interesting advantage of having a RISC OS port which does file / directory tree translation.
It’s currently grinding away doing an initial import. I can assure everyone I’ll end up getting angry with it and abandoning it again when it starts screaming about things not being in the working copy.

Last night I was messing around with my AWH3 build of RO with all the extra modules I’ve thrown at it. I believe it’s Schrodinger’s release. I’d love to know if it is running the WIMP. I can issue it *WimpMode commands, of which there are some it doesn’t complain. Also doing some things with a connected USB keyboard yield some odd results.
It’s all not particularly useful, but it is interesting.
Some of what I need to do, in no particular order, which is pretty much everything really…

• “Finish” USB
• Work out how to support the ethernet adaptor. Common hardware but it’s not USB.
• RAM detect / talk to U-Boot
• Video driver (not to over-trivialise)
• Sound
• DMA
• PIO / GPIO layer (needed for most of the other items on the list)
• IIC
• SPI
• SD Card
• CPU / DRAM speed support
• Thermal reading
• ???

Given that it boots first time, every time now makes all this way easier.

Maybe RTC could be added to that list. Maybe. I’m working on the Orange Pi PC which has a minor design defect where the SoC RTC is connected to one of the voltage rails, so it can’t be battery backed. Other devices probably don’t have this problem, but I have what I have. Personally I’ve just been using a standard RPi IIC RTC on it anyway.

That whole DVI cable issue caused some problems! Some subtle corruption to RO on the Pi that I didn’t notice initially.
I couldn’t change the size of a WimpSlot because it was saying there wasn’t enough free RAM. There was over 800MB free. hdr2h was causing an abort in UtilityModule. Who knows what else was happening.

I haven’t been able to do any real work on the H3 port recently, however I have been trying to work a few things out.

An interesting one is the behaviour when I run something from the SVC prompt which apparently requires the Desktop. For example !SetPaths in AcornC/C++.
What appears to happen is a dump of binary data to the terminal and then locking solid. This isn’t the case. In amongst the terminal enraging data there is a clue. Two bits of text. “Use *Desktop to start Filer”, “Cancel”. Today I realised. Using the USB keyboard plugged into the OPiPC, hitting ‘Enter’ more or less results in the dump being repeated. Hitting ‘Escape’ results in the SVC prompt reappearing.
After this the output of the SVC prompt is kind of slurred and strange, but it’s definitely functional.
Example:

*baic               
ARM BBC BsssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssSIC V 
(C) Acorn 1989

Startig with 529146108 bytes free
>QIT        

What I take away from all this is the WIMP is probably running. The slurring could either be multitasking related, or perhaps I need to revisit the UART init code. It’s been well behaved so far, but this makes me wonder if the bootm boot method is disabling the FIFOs.

Most of the useful headers are now hdr2h compliant, with one major exception. StaticWS. is there any way to deal with “OSentries # 4*(HighestOSEntry+1)”?

Beyond extending hdr2h, the cleanest way of dealing it would be to replace it with a constant and an assert, e.g.

OSentries # 32
  ASSERT ?OSentries = 4*(HighestOSEntry+1)

That way it’ll keep hdr2h happy, while still helping to make sure the list is the right size.

What appears to happen is a dump of binary data to the terminal and then locking solid. This isn’t the case. In amongst the terminal enraging data there is a clue. Two bits of text. “Use *Desktop to start Filer”, “Cancel”. Today I realised. Using the USB keyboard plugged into the OPiPC, hitting ‘Enter’ more or less results in the dump being repeated. Hitting ‘Escape’ results in the SVC prompt reappearing.

That’s probably VDU sequences – the Wimp makes heavy use of them when rendering the desktop. But if the desktop is rendering things, I’m not really sure why Escape should bring you back to the command line. Maybe it fails during initialisation somehow?

Beyond extending hdr2h…

I have literally no knowledge of Perl. I have an O’Reilly book which probably pre-dates the version of Perl in the RO build tree, but doing what you suggested seems way more sane.

I can’t tell what the binary data is because it hits on terminal control characters more than once and makes a mess, but what you say sounds plausible.

I’ve been thinking about the behaviour too, and I have a theory that isn’t based particularly well on facts because I’m unsure of the finer details of system-wide multitasking.

Things we know are that the SVC prompt can only be directly interacted with via the UART. The USB keyboard goes elsewhere and interacts with something else. Issuing things like ‘Escape’, ‘Crtl + Break’, and a few others definitely have an effect on something.
Example. I press ‘Escape’ on the USB keyboard and nothing immediately appears to happen. However, after pressing ‘Enter’ on the terminal, the terminal displays a line saying “Escape” before printing a new line with the ‘*’ prompt.

What I’m thinking about is exactly how system modal a dialog can be. Escape may not exactly be bringing the UART SVC prompt back to the ‘*’, but rather continuing execution so that the code that spat out the data to screen can finish execution and return.
Given that it responds to the USB keyboard and not the UART, to me at least it implies that it is being executed, or at least attempting to be executed as a desktop application.

Also I can issue some *WimpMode changes successfully. Of course with no visible output, but some are accepted and others are rejected as being unsuitable for the desktop.

At this point I’m not even aiming to have a proper interface. It’d be nice, but other HAL stuff needs to be taken care of first. It’s this behaviour which is a source of some confusion for me.

Probably worth noting is I still haven’t rebooted it. Using the UART SVC prompt still results in some of that odd slurry-ness, and random little spatters of binary data. Just not the page or two of garbage that attempting to execute some things results in.

Currently when I try to run Firebench or ROMark, the complaint seems to be that the desktop resolution isnt’t high enough, which is interesting.
This leads me to another question. How can the current screen resolution be read from the command line? I realised I have no idea how to do this. It’d be interesting to see what it has to say for itself.

I toyed with the idea of a USB ethernet adapter and !VNC too. Trouble is my only USB ethernet adapter is an adapter / USB hub with a MicroUSB connector. The only way I can use that is to get the OTG port on the OPiPC working as a normal USB port. Which brings me back around to implementing GPIO again. Ha.
I mean I’d love to use the builtin ethernet but haven’t got a clue how to hook that up to RO.

I’d be inclined to create an sdcard with a fresh harddisc4 image and set it up on another computer – a pi maybe – so that it starts up correctly, runs vnc server at boot and connects using an external usb ethernet adapter – you can get a micro type B female to type A male adapter if you don’t want to buy a new ethernet adapter. Then you can change the boot and rom files for the orange pi version and try it in the orange pi.

The ethernet port on the orange pi will need a new ethernet driver written for it.

Hi Colin. I’m kind of functioning on reduced capacity right now, so I’m not sure if this is silly.
Currently the OPiPC has a USB stick plugged into it with a HardDisk4 image extracted to it using one of the RPis.

I have no idea if it “sees” !Boot or anything else by default. What I do know is that when the OPiPC boots it’s parked at the root directory of the USB drive, so it has enough marbles to know it’s there.
It doesn’t have SD card access yet. I knew that todo list was incomplete :)
Buying another ethernet adapter doesn’t concern me. They only cost a little more than a USB micro adapter. The wait time from China though. Uggghhhhhh. I need to make an order anyway. Getting low on MicroUSB cables. Always, always breakages on the MicroUSB plug internally. I’ve had rants on them before here.

Given that the OPiPC only has USB and not SD support yet, getting an image working via an RPi may be a touch curly. I know it’s a well trodden path using one media for the ROM and a USB drive for the hard disk, but I’ve never done that before.

The ethernet driver doesn’t concern me much. IIRC it’s a common type, but I have no idea how it’s actually connected up to RISC OS. If I knew that, I would have tried to get the SPI ethernet adapter I have working in RO on the Pi Zero. I actually used to use in on my old Pi Zero in Linux. Meant for Microcontrollers, but an adapter is an adapter.

The USB ethernet thing arrived yesterday. Should be interesting to see what happens when I test it.

Been hung up on writing the (G)PIO code. It’s not even hard. I can see it. Just got a mental block. It is clear to me that I need to get it written before proceeding. It controls a lot of internal and external IO functionality.

The ethernet thing was a waste of money. It uses some weird chipset. It has however prompted me to start work on getting the USB host functionality of the OTG port working. It seems to be done, minus supplying power via a PIO register. It appears as a port, so that’s good.

I have read through this thread and found a lot of it confusing which has lead me to the conclusion that I (a) need to read more and (b) I need to re-evaluate my desire to start a porting effort until (a) has been thoroughly completed!

On topic question: How stable/far along is the port to the H3?

Somehwat off topic question: How much of this effort could be re-used/re-directed to a port to the Allwinner A64? (which is my desired target…once I’ve properly read all there is to read…might take a while…)

Hi Glen.
It hasn’t been abandoned or anything. A combination of being sick and also being kept very busy with other things has slowed progress. The GitHub repo also isn’t up do date. I didn’t trust myself enough. As it was I managed to send some files to the great beyond with no backup.

Where I’m at:

What works to some degree.
*Boots consistently with U-Boot via tftp / bootm.
*Pretty much the full complement of modules built. Not all have support yet.
*USB2.0 support including storage, and HID (I can tell stuff happens via magic key combos)
*Timers and counters
*Interrupts
*UART
*???

What doesn’t work / isn’t implemented.
*Any video support.
*CPU throttling
*Temperature sensor
*IIC
*SPI
*Sound
*Ethernet
*SD Card
*GPIO
*DMA
*A million other things I’m sure.
*USB OTG port
*RAM detection
*RTC

What I’m working on currently is the PIO module. It’s a gateway to configuring a lot of the hardware. I really wanted to keep all the code for touching the main PIO ports in one place.

As for stability, I can leave it running for days and come back to it. It’s always just as I left it.
Trying to run some programs makes it grumpy. I believe it may be running the Desktop with no means of output.

Now, as for the A64… That’s a fun question you asked. Some of the things I haven’t coded yet I’ve been avoiding doing because the way I do it would depend on whether a ROM image can be used for both the 32 and 64 bit incarnations. The big “IF”, is if there is a way of making U-Boot for the aarch64 platforms start a uImage in 32 bit mode.
The frustrating thing is the earlier boot steps on them are in 32 bit, but U-Boot is 64 bit.

All that aside, if it could be dropped into aarch32 bit mode then it should be pretty easy. I just had a look at the H3 and A64 memory maps side by side. Some of the SRAM, BROM, and I think the CoreSight Debug are in different locations. Just about everything else are in the same location and are essentially the same.
In my code I have the SRAM mapped as IO, but it’s unused. Technically, IF the CPU could be put into aarch32 mode before executing the uImage code, it may run the same as it does on my H3. If I knew how to do that I would test it on my H5 based SoC. Unfortunately I don’t.
There is a caveat to all this too. I’m executing my code as a legacy image. The main difference is that legacy is started in SVC mode, whereas the new mode is in HYP mode, requiring a mode change, and any possible setup differences that may be needed.

Thanks for the update and I’m encouraged by the prospect/potential of being able to port to the A64 after the H3!

Will keep my beady eye on the forum from time to time…but otherwise good luck and hope you get better soon!

Thanks. I got sick with three different bugs that were going around concurrently. It was pretty unpleasant. Still trying to shake the lingering after effects.

I keep getting myself all tangled up with the PIO code for some reason, so I’m working on a new C "pseudo"code version. It stops me from trying to be clever.

While I’m here… Let’s say I actually tried to use this C code. It only needs one entry from StaticWS. If I were to give the PIO code an init function which takes the PIO logical base address as a static uint32_t or whatever, would it actually persist?

I made this quick list for another forum. These are the documents which I reference for the H3. Putting these names here for myself or anyone else that wants to know.

• ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition
• Cortex -A7 MPCore Technical Reference Manual
• CoreLink GIC-400 Generic Interrupt Controller Technical Reference Manual
• Allwinner DE2.0 Specification
• Enhanced Host Controller Interface Specification for Universal Serial Bus
• i.MX 6Dual/6Quad Applications Processor Reference Manual (for the graphics hardware)

Really off topic, but I temporarily bricked my phone and my tablet while trying to find a way to use the RO linux port so I could actually work on this more often. My netbook can run RPCEmu at a whopping 9MIPS, so I’d rather just not even try that again. It can’t run the Linux port (which would have been slow anyway) because something to do with the port is unable to allocate memory. No idea.

Going back a step here. Both the H3 and H5 are quite good at running the RO Linux port, although the Linux2 branch is a monumental headache to build.

DE 2.0 … good luck!

DE 2.0 … good luck!

Thanks. It’s not something I’ve been looking forward to.

I think I lost a few brain cells when I got sick. I’ve forgotten how to do some really simple stuff. Working back through it though.
I had another stab at getting the USB OTG port functioning. No luck yet. Not sure why. I think the EHCI controller is fine, and I’ve twiddled all the bits that I think I need to regarding enabling power on the port. Probably just a dumb mistake.

I’ve also been attempting to work on some rudimentary RAM detection. I know what I want to do, but again, need to revisit basics.
What I want the code to do is write a value to the top word of the first 256MiB block of memory, and check for the word at 512MiB, 1GiB and 2GiB. Try a different pattern, just in case and repeat. My thinking is it will encounter the mirrored data in the vacant blocks, but not where there is RAM.
I tried a simple write, read and check to detect RAM on my OPiPC, but it kept saying it had 2GiB RAM, which is wrong. I’m guessing that unused address lines are just left hanging.

I’ve been avoiding doing the RAM detection for too long. So now I’m doing it to avoid finishing the PIO code.

Recently I’ve been through hell trying to use every bit of hardware I can dig up as a means of working on this while not at my computer desk. So many failures. So much time wasted.
The tablet I got running Linux was defeated because of the odd way multitouch worked. No middle mouse button. Also no tablet keyboard cases have a trackpad. So even after I managed to get the Linux port chugging along on it’s ancient Android kernel with EOL Linux distro and lots of stuff built from source, it was still a waste.

My Netbook just can’t seem to handle RO Linux. It just gives a mysterious “Unable to allocate memory” error.

I think I mentioned I bricked my old ASUS TF700T trying to get Linux working on it. I got it working again eventually. Never trying that again though.

Dug out the crusty old Toshiba Satellite. Had to do a strip and rebuild to fix a dislodged power jack. Nothing. It’s just dead.

Dug real deep and found the eee701. I don’t think it had been powered up since about 2010. More wasted time.

Dismantled a 386 laptop in desperation to see if I could find a datasheet for the LCD to do a DIY Pi Top of sorts. Datasheet I found was for a similar model but it had the wrong number of pads on the LCD, so no. Even if I could pull off that miracle, I’d still have the no trackpad issue.

In the process I also learned that RO Linux breaks when trying to use it via XRDP. It can be made to run via X tunnelling over ssh but it can’t accept any inputs.

I know this isn’t really on topic, but I’ve been trying multiple ways to be able to work on it more readily. It’s been really getting to me!

No working x86 laptops at your disposal that could run RPCEmu?

I’ve been avoiding doing the RAM detection for too long. So now I’m doing it to avoid finishing the PIO code.

I wonder, why is RAM detection so important and why is PIO? It is much more fun working on a port when you get it to a usable state. Since you have USB I suggest that you start with the display. There is a NetBSD port? In that case look on that implementation, I am pretty sure they have found a sneak way. Otherwise dump out DE registers from linux or from u-boot (if that has display support). Read in those values in riscos, and crosscheck the DE 2.0 manual.

No working x86 laptops at your disposal that could run RPCEmu?

My netbook can “run” RPCEmu. It’s only really any good as a study in patience and observation of the draw order of RISC OS. TBQH my cycle for years has been to try to use the netbook, get frustrated, and put it away again. There’s just something inherently rubbish about it. Using it to do a ROM build is kind of impractical. I can start it off in the evening and it’s still going the next day.

Yes, the Eee is older and technically lower spec’d, but my old Acer has always been ponderous compared to the Eee for reasons I’ve never pinpointed.

I’ve also tried VNC. It works, but it’s of limited use to me. I used it to make some quick revisions to the RAM detection code recently. However it requires me to have uninterrupted access to the local network, and to have a Pi and VNC up and running beforehand.
What would be amazing would be an Android build of RPCEmu or a modified version of the Linux port. I’m not even sure that the latter would be feasible. I mean I’ve used both on Linux devices using Android kernels but I feel there would be a lot more to it than building it against the Android NDK.

I may seem defeatist. However these are the end results of an appalling number of hours spent trying to find a solution to accessing a build environment away from the desktop.

Michael. RAM detection would be nice. I have three Allwinner based devices here, all with different amounts of RAM. There are heaps of devices out there using similar chipsets using between 256MiB and 2GiB RAM. It’d be nice to make it more available.

The PIO is more than just GPIO. I’d consider GPIO to be a subset of the PIO pads which have been broken out to the header connector. The PIO ports are one of the areas responsible for board control. There are a couple of bits of code where I’ve hardcoded in control of some of the registers to get things working, but that was just a means to an end.

I think I said it in the previous post, but the lack of time at the desk is the biggest issue I’m facing. A lot of the coding is exploratory. I go through so many completely different versions of code poking at the hardware trying to find what tickles it in the right way. It’s a rapid cycle of code, build, run, analyse, repeat.

Changing the subject a little. A while back I received the USB A to MicroUSB adaptor so I could test the LAN adaptor / USB hub that I use for the Pi Zero on the OPiPC without modification. The results were promising but not successful.

RO on the OPiPC could see the device and tell me what it is. The USB ports worked. It could identify the LAN adaptor. However I couldn’t work out how to talk to it / test it via CLI.

While I’m here, I want to know if it’s possible to sanitise an RO source tree so it can be uploaded? I would really like to shove a copy of my tree on to GitHub minus non-distributable DDE stuff. Removing the other things is easy. I just don’t know the extent of what happens with bits from the DDE toolchain. My source has an odd mix of modules pulled from different targets trees. Not something I want to reconstruct in a hurry.

What would be amazing would be an Android build of RPCEmu or a modified version of the Linux port. I’m not even sure that the latter would be feasible. I mean I’ve used both on Linux devices using Android kernels but I feel there would be a lot more to it than building it against the Android NDK.

Remember that if you’re planning to run it on ARM devices (or any other non-x86), performance will be pretty poor due to lack of recompiler support.

While I’m here, I want to know if it’s possible to sanitise an RO source tree so it can be uploaded? I would really like to shove a copy of my tree on to GitHub minus non-distributable DDE stuff. Removing the other things is easy. I just don’t know the extent of what happens with bits from the DDE toolchain. My source has an odd mix of modules pulled from different targets trees. Not something I want to reconstruct in a hurry.

I think the process would be:

1. Perform a “Clean” and “Clean all” build to get as many temp/output files as possible removed (I think this may leave a few files behind still – but I don’t think it would be anything major)
2. Reverse the operation of the “Prepare” script – delete the top-level Apps, BuildSys, Env, Export, Library, and Modules folders. This will get rid of the commercial DDE components.
3. Delete the Images and Install folders too (created by !Builder)

I.e. you should just be left with the folders for the different licenses, Prepare, and Products.

If in doubt you could take a known-clean source tree, perform a build using it, clean it up, and then diff against the original archive.

Only tangentially related but I feel others may benefit, or myself the next time I forget.
This is how to do a one-off connection to a moonfish server from linux. -v is for verbosity and can be omitted.

sudo mount -v -o vers=3 remotename_or_ip:remoteshare localdir

Apparently the NES Classic Edition has an a7 based Allwinner SoC at it’s heart.

http://linux-sunxi.org/R16

Since you have USB I suggest that you start with the display

I gave this some thought and this is what I am doing. I’m just working on writing the code to set the PHY up. Nothing exciting. It’s mostly just a magic incantation of setting bits on registers and timed pauses which developers had to pull from the Sunxi BSP code.
I’m going to work on starting up the display hardware as one of the last items, because I really need other things to be initialised first, especially for HAL_CounterDelay functionality.

edit: There is a document for the PHY. I have it now. Only really has what the source has, plus some extra register names, and minus a couple of magical registers.

I’ve been plagued with issues preventing me from working on this. Just been doing it in little bots occasionally.
Today I tried shifting development over from RO running on the Pi3 to RO Linux running in Raspbian on the Pi3. Truthfully I’m not even sure why I did it, but it works.

The loading module count went up from 89 to 119 today. I found some odd build artefacts in the tree that I cleaned out that were preventing a7 objects from being built.

The troublesome FSLock finally got built. For some reason it just needed more RAM allocated to let it build.

Only one negative effect has been observed. For some reason I can no longer build FPEmulator. It broke about the same time I got SystemDevices to build.

Although the OPiPC is booting via network using tftp from U-Boot and communicating with me via serial cable, it now appears to be using the OS I put on a FileCore formatted USB drive and I believe it is using !Boot

Recently I had a failed attempt at video output. I overlooked something which meant a lot of wasted effort and what amounts to a lot of useless code that needs to be pruned out. However I did see some positive results with trying to init the HDMI PHY finally. Although that may never be needed it’s nice to see that I’ve finally worked out how to talk to it. This means I can get to the DWC video controller.

I found even more documents. I’m probably missing something obvious but for the life of me I can’t work out how to point the video hardware to the base address of the framebuffer, or anywhere for that matter. It’s the one thing I can’t seem to find.

E: Found what I was after on another “Island” Wiki page via Google.