Allwinner H3

I had to persevere with multiple reboots of it getting “stuck”, but I got a clean boot with SCSI* modules. Look! Look!!!!!

RISC OS 1017MB

The USB drive was formatted with HForm and had a recent HD4 dev image dumped onto it. It sees it!

All of the booting difficulties now seem to be coming from the kernel. I’m not saying that the kernel is buggy. More that there is something that the H3 trips up on in there for some reason at random. On the occasions that it gets far enough for RO to produce error messages, the address is always within the kernel. I just need to work out the places it’s failing, and why.

Look! Look!!!!!

Gratulations!

Oh yay. It signed me out and I lost the post :(

Thanks Michael! I’m happy about it.

Just an abridged version of my lost post. RO boot fell over with an undefined instruction. I looked up the address in the Kernel GPA. It’s in HAL_InvalidateCache_ARMvF which happens to have a whole bunch of coprocessor instructions. It always seems to fall over when a coprocessor is involved. Randomly too. I’m not entirely sure how to address this.

edit: been scattergunning with coprocessor commands in the desperate hope that something helps. Tried being systematic starting from scratch. What I have actually did help!

init mod UKError: UndefinedInstruction:Undefined instruction at &FC08CECC (Error Number &80000000)                                                            
*                 

Brexit error?

Still working on it. Just nothing worth showing unless you like .hdr files.

I tried making the iMx6 video code build. Haven’t managed to do that yet. It did however serve it’s purpose as a way of working out dependencides. So now I’m working on filling out bits of functionality around the place, which unfortunately means making lots of headers with lots of content.

Speaking of which, the H3 documentation reads like different people worked on different sections which isn’t surprising. Currently I’m working on typing in the GPIO register entries. The section was written by someone who likes the developer to do arithmetic. FOr example. Pn_PUL0. n*0x24+01C. Or perhaps PA_INT_CFG3 0x200+0*0x20+0x0C. We have a page of various sums like this. In many cases the standard order of operations yields an incorrect result. It’s things like this that make me a bit cranky.

Besides the extreme difficulty getting RO to load, every build has been pretty stable. I haven’t realy had any time to do any coding, so I just leave the OPiPC running with the most recent ROM build. Days at a time. Every time I come back to it it’s still functional.
Yesterday I successfully added VFP and FPEmulation. Previously I’ve had some problems with VFP locking the machine at startup.

It was at this time I noticed something missing. BASICVFP. It wasn’t in the OMAP3 source that I based the port off originally.
As of a couple of days ago I’m working with a BCM2835 tree with USB code and a few other bits poached from OMAP5. The interrupt code I’m using successfully already came from OMAP5.
BASICVFP got added to the build while I was at it. After doing the usual fiddling to get it to boot, it did… to BASICVFP for some reason.
It seemed to work properly. Exiting it dropped me back to the SVC CLI which also worked properly.

I’ve been dilligently taking my math exam for GPIO. I’ve started to grow irritated at the author of this section.

This is for b11:0 of PA_DRV1_REG

[2i+1:2i]
(i=0~5)

…aaaand something broke.

Starting phase rom ...

HAL_AWH3 (castle.RiscOS.Sources.HAL.AWH3)...
amu -E  -k rom COMPONENT=HAL_AWH3 TARGET=AWH3 
AWH3 HAL: rom module built

Kernel (castle.RiscOS.Sources.Kernel)...
amu -E  -k rom COMPONENT=Kernel TARGET=Kernel ASFLAGS="-PD \"CMOS_Override SETS \\\"= FileLangCMOS,fsnumber_SCSIFS,CDROMFSCMOS,&C0\\\"\""
do mkdir -p o.CortexA7
do mkdir -p rm.CortexA7
create o._dirs
AMU: *** Not found ***


PCI (castle.RiscOS.Sources.HWSupport.PCI)...
amu -E  -k rom COMPONENT=PCI TARGET=PCI 
do mkdir -p o.CortexA7
do mkdir -p rm.CortexA7
create o._dirs
AMU: *** Not found ***

etc. etc.

This is why I make backups. Just going to throw down a fresh tree and dump the git copy of my work over it.

It rained last night. It stirred up something that had me sneezing so I got up for a bit and managed to get a build to complete finally somehow.

Even tired and snuffly, some things just kind of jump out. I saw this scroll by while building.

Warning: Unpredictable instruction (invalid processor mode) at line 1855 in file kernel.s.k_body
 1855 00001118         MSREQ   CPSR_c, #PSR32IBit+PSRSVCMode

Is it invalid for a Cortex-a7?

I tried the build a few times just now. When it did get past it’s usual sticking points it’d stop on InitModules, or whatever it is. I just realised I’m using fresh source on a different drive so the kernel wouldn’t have the debug terminal enabled. Whoops!

Now that the flurry of activity before the stable release has subsided, I’m hoping I can stick with the current source for a while.

Is it invalid for a Cortex-a7?

Not sure if it will cause a malfunction, but it’s definitely an invalid mode. However that instruction shouldn’t get executed (there are 32bit & 26bit code paths present).

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Lib/RISC_OSLib/kernel/s/k_body?rev=4.36#l1843

I see what you mean.

It may seem silly, but I’m working on a port of libROGPIO for the H3. It doesn’t really matter if it doesn’t get completed. I’m more using the source as a tool for getting the GPIO for the H3 worked out in an orderly way. Besides some things I did in the original library which I’m not happy with, generally speaking the way things are ordered is logical. I’ve already started to apply the H3 PIO_CPU (I think that’s what it’s called) in the context of the BCM GPIO. It’s been helpful in untangling a horrible section of the datasheet.

I don’t know if it’s preferable in the case of the HAL, but I prefer to have single points of access for certain functionality. So I figure that sorting the GPIO should be done before IIC, finishing getting the USB OTG port working as a master and various other bits and pieces.

This is proving to be an interesting mental exercise. It raised some real questions for me on how to organise GPIO. The H3 PIO is way bigger than the BCMxxxx GPIO. It’s laid out in multiple registers, vaguely like the Broadcom chips, but arrangement wise it’s more like the usual Port A, B etc layout. That leaves me contemplating how to do a numeric representation, especially as not all ports are completely populated. Port B just plain doesn’t exist!

I also chanced across a forum thread on the Orange Pi forum where someone did the work on matching the PIO registers to the Orange Pi’s “Raspberry Pi Compatible” 40 pin GPIO header. These of course are all jumbled up to allow for similar functionality.
So the question is whether H3 HAL GPIO should be set up to control all the PIO registers (Dangerous depending on what’s accessed. They control everything)? If not, the other choices are to set it up in a logical order, or in RPi compatible order.
Perhaps a layer controlling all of it, then another more restricted generic layer that just deals with the broken out GPIO pins?

Thoughts?

or in RPi compatible order.

Would it not make sense, that if it is supposed to be Pi compatible, people might think they can use Pi add-ons?

I just had a quick-ish look over the H3 datasheet, the table I found on the OPi forum and a RPI Pinout diagram. Here is what I found to be set up to be compatible-ish.
*I2C0
*I2C1
*SPI0
*UART

I didn’t dig into the other alt functions of the RPi. I suspect there are more because of the strange ordering of H3 GPIO pins in places, but I don’t know.

One kind of neat thing is the software controlled power LED alt function is connected to the IO port that has PWM0. Ie fading / throbbing LED.

e: Incompatible items I think include connections for a mysterious SIM device not mentioned anywhere, which may or may not be related to the smart card functionality of the H3. There also seems to be I2S, OWA, another UART and other miscellaneous things as alt functions of the GPIO pins.

Perhaps a layer controlling all of it, then another more restricted generic layer that just deals with the broken out GPIO pins?

That sounds sensible to me. For the API used by the GPIO module, the HAL can specify which pins are safe for use – e.g. the table in the Pi HAL sources. So you could have basic pin manipulation functions in the HAL which interact with the pins using a “native” mapping, then use the table exported to the GPIO module to restrict which pins users can actually control.

For any more complex mapping (e.g. remapping to be Pi-compatible), I’d say it’s best to implement that within RISC OS itself. E.g. extend the GPIO module so that it can provide multiple different pin mappings, with each client of the module able to specify which mapping it wants to use. So software designed for the Pi could ask the GPIO module if there’s a Pi-compatible expansion header present (or if there are certain features available on that header), and the GPIO module could check the list of available mappings for the machine and respond appropriately.

I was hoping to stick to something vaguely resembling the GPIO template, not that I could find an example beyond the source from different ports. I really do like the idea of being easily able to swap in and out functional pin groups. Thaat ties in well with an alternate function I forgot about. UART3 (I think) uses the same pins as the SPI boot flash chip if installed (model specific).

Over the last couple of days I got around to rewriting the corrupted SD card for my OPiPC2. Recent experiences with power issues led me to the conclusion that it was having issues because of the power cables. It uses the same type of connector but draws more power than my OPi PC. After plopping my “Development HAT” onto it, it booted fine first go. I’m using it for a long term doomed project to get GCCSDK to actually compile on something. I haven’t been able to do it on any platform for the best part of a year. Although aarch64 fails many, many times during build because it doesn’t get config.guess and config.sub from where automake looks for it for some inscrutable reason and I have to manually (via a script) find and replace every copy of those files in the build tree repeatedly.
After all that the finished product chokes on CRT.o for some reason even though the actual object file is fine.

Okay. That was a massive divergence.

I haven’t worked on the source in any real way since I got sick because I make a lot of mistakes when I’m sick. But I have been reading, and thinking.
With the IO, if we ignore that it’s not 100% populated, and that port L is in a completely different area of memory there is the potentially useful fact that there are 256 IO pads. Including internally used ones. It’s a nice, neat 8 bits and divided neatly too. Could be useful.

Diverging a little again, a spambot dredged up an old thread on the PINE64. I went and had a look at their site. They have so much stuff now! Given a lot of it is based off the H5, including the Pinebook, I’m tempted to have another go at trying to get something 32 bit to boot on the OPiPC2. It shouldn’t be hard. I even found the config option in U-Boot to build it for 32 bit on the H5. Besides the power supply issue, the only reason I haven’t tried it is I can no longer build U-Boot for some reason. I’m hoping it will build on the OPiPC2.
It’s not something I want to waste time on. Just a set and forget sort of thing.

I don’t recall if I touched on uImages. Something was causing lockups early on consistently. I found and fixed a few bugs as a result, but beyond that something was killing it that wasn’t by running it as a binary. I tested this by loading the uImage offset a little so the start address was at 0×42000000 and running it that way, which worked, as well as it does anyway. I was wasting a lot of time on it and decided to move forward again for a while. I’d really prefer to be able to boot it as a uImage, but that’s going to take some experimentation.

edit:
https://lists.denx.de/pipermail/u-boot/2016-June/258143.html

Putting that U boot patch page here so I don’t lose it. It refers to the initial addition of support of aarch32 OSes from an aarch64 U Boot. It appears that using the FIT format for the image is required for autodetection.
It seems like a bit of a double shuffle going from 32 to 64 then back to 32, but I guess it is what it is.

Is there a picture of the ‘PineBook’/ plus details – what about group funding of a machine – for testing on?

I wouldn’t even think of seeking external funding for what is a hobby, and equipment that would be also for personal use. Anyway, my Orange Pi PC2 is close enough for most testing.
Before any of that I have to defeat the weird boot issues on the H3.

I’m certainly no PineBook expert. There seems to be a lot of information available on it though, even on the Pine website. I believe it’s an open design too.

A day or two ago I found some info on it, but I can’t remember where. I want to say it was a document in the U-Boot source tree, but I’m not certain. It pertained to boot methods and order.

Last night I had an idea that I invested a massive few minutes in which may be of use to me. It just involved grabbing a copy of my HAL and throwing it out on it’s own. The goal is just to create a standalone U-Boot loadable program with UART support. I could do that simply without the framework, but the extra bits and pieces, plus the automagic Makefile make things a little nicer.
The goal is to have something small and simple that I can use basic UART text output with, and can experiment with wrapping it with different image containers, and trying to work out what randomly breaks.
While a lot of it occurs during / after MMU reactivation with the OS build, not all of it does.

Things that have given me pause include:

*my tattletale function telling me the MMU is on a couple of times.
*No UART text, but register contents still printed.
*Seemingly random aborts of various types.

Now, I know the DRAM is configured pre U-Boot. I forget the name of that loader right now. It also seems fine later on, so I doubt it’s that.
The MMU is on when the image is loaded. After doing some digging, I believe the U-Boot people opted to enable it and add a 1:1 physical – logical mapping.
I also know that the H3 SoC supports security extensions, PAE, and virtualization. PAE may be in use. The rest don’t seem to be.

U-Boot de-obfuscates the HDMI hardware, enables read access, sets it up, then re-obfuscates it. As yet I haven’t managed to read sane data from it. I think I’m doing it wrong.

Also in the last couple of days I succeeded in building a current U-Boot for the OPiPC2 on the PC. A few things had changed and it took me a little while to set things up right. Not super useful on it’s own, but at least building for it works again.

I’ve been trying to work out how to use the new style FIT U-Boot images to no avail. I can’t find any useful documentation. They boast it’s more flexible etc. but the problem is it seems to require an FDT (flattened device tree) as part of the image format. What is a non-Linux OS supposed to do? Part of the build sequence for FIT images is mkimage calling the device tree compiler. What am I supposed to tell it?
The only reason I’m bothering is it appears that the aarch64 U-Boot can only do the 64-32 bit detection and switching with a FIT image.

Has anyone here used a PineBook?

The Linux RISC OS version might perhaps – be made to work.

Colin, I can conditionally answer that one for you. Before I had issues with build tools going all wobbly etc. I was running RO Linux on my OPi PC2. I just had a quick look and although it’s an old build I still have the binary I built from the source. Hmm. Looks like I was using it to do a build of RO.
The A53 and H5 are pretty close. Just glancing through the A53 datasheet, and referencing my somewhat questionable memories of the H5 datasheet
(not on this PC) there’s two main differences that I can see. H5 has a Mali450, and the A64 a Mali400. I also believe that the A64 only has one USB host + an OTG host/ device, whereas the H5 has 4(?) USB hosts + an OTG host / device.

Super quick update on that. Cloned and built the current Linux port on my Orange Pi PC2. Did the build via SSH. Tested it via RDP. Tried it via SSH tunneled X, but for some reason locks up. Probably just my setup. It used to work with the old installs on my PC and OPiPC2.

Just for fun followed up by building the Linux ROM again but using !Builder from within the RO Linux desktop. No issues.
This is super off topic but thought you’d be interested. The builds were pretty quick too. No idea how to benchmark anything though. Even if I did, there’s a lot of other variables with the Linux host.

I found the page which actually references the differences in behaviour between methods of loading programs with U-Boot.

https://www.denx.de/wiki/DULG/UBootStandalone

I believe it was Jeffrey that suggested this difference in behaviour? I guess it’s time to start tinkering with booting again. As an added bonus I finally found some breadcrumbs regarding how to access U-Boot functions from a program. If it can pull some system info that way it’d be a huge bonus.

I recently used the U-Boot API to access puts, putc and getc functions for some experiments with the Efika MX Smartbook. The standalone subdrectory seems to have been replaced by the api subdrectory over time – see also the include/api_public.h header file.

I extended my local U-Boot to expose the address of the framebuffer so that I could get further with what I was booting but now need to spend more time looking at setting up timers on the i.MX51 SOC before doing anything else.

If you need any hints about any of this, please let me know, though be aware that I’m still learning about this too!

Oh nice. I kind of cheated and wrote down the framebuffer address from the UART output of U-Boot.

I may have to take you up on that later.

I was told that there are issues with getting hold of a Pinebook. I added my name to the list anyway but it doesn’t look good.

In my quest to work out some way of actually being able to work on my stuff without needing to be at the computer desk I’m taking a bit of an odd path. I woke an old tablet back up and found a linux port ca. 2012 on the internet for it and got it up and running. Now I’m doing battle trying to get it to a version of ubuntu that’s supported, while keeping the old android kernel and keeping the hardware working. I figure if I can get it to a version new enough it can run the Linux port of RO, however with the penalty that old kernels incur.
Fingers crossed that this abomination actually works.

I’ve been on a long, circuitous journey of discovery. Mostly messing with toolchains and trying to make the Linux port run on things. However I learned some relevant things.

Essentially I can make RO boot reliably on the H3 now via the legacy Armbian’s version of U-Boot. It gets stuck waiting for a filesystem, but I’m hopeful that was from my recent accidental leaving the USB drive in when booting into Linux. Because I didn’t actively destroy the entire contents of the drive, Linux still sees valid information. It may have run fsck on boot.

When I find the SD card with mainline U-Boot I have previously been working with (I didn’t label it) there is something else to try. There is a possibility that RO may boot with it if I include a boot option to force SVC mode. It appears that it may be booting in HYP according to some docs I saw.

Back in business! I just spent a while going through my main cache of SD cards, labelling and cataloguing the unlabelled ones, and checking whether they are the one I’m using to boot RO images. It was the very last one I had left to check, of course.

forst thing I did was setenv bootm_boot_mode sec
saveenv

Then went thought the motions loading my generated uImage. Booted first go with (what I believe is) the mainline U-Boot.

It is still getting stuck again wanting a filesystem. Not sure why.
The current source has most of the cache, MMU etc. fiddling disabled. It doesn’t seem to need it. Even though it’s banging into the waiting for fs thing, it still boots consistently up to that point!

e: Forgot to say, pressing esc on a USB keyboard either directly connected or through a hub does nothing.