Allwinner H3

I got a modem/router from this decade yesterday. Finally got it working just now. It should help my efforts I hope. Failures during file transfers were the rule rather than the exception.

Right now there’s a slight problem with the port that I’m not sure how to deal with. When it boots it goes and starts loading stuff. The last thing I can actually see is the blahblah.Choices stuff before the serial terminal is spammed with “rubbish” characters until it stops working. Not sure if it’s RO on the H3, !Connector or the SerialUSB driver that fails. I’ve observed the terminal “go dead” in the past when it’s overloaded.

It’s a bit of a nuisance because I have A CPU port (like GPIO) program that I want to test. The math looks good using dummy IO space and read / write functions, but I need to see results before extension and integration.
Something that bothers me about it is that it would go well as a form of the GPIO module, however features are also needed by the HAL so I believe it’d have to use an altered duplicate of the code. Moving port fiddling to a single location is something that I’ve been wanting to do for a while.

Although I’m certain this has been one of the biggest wastes of time in my life, I’m persevering although I’m not sure why.

I now have an actual functioning local subversion server up and running and am using it extensively. It took me 20-odd commits to patch up the source after sending it in and bringing it back out the other end, but that was worth it. There were so many “Zombie” modules which I hadn’t found. Plus there were some odd issues with directories disappearing and other odds and ends.

I’m using Geany in Linux to do some of the editing. It seems pretty happy to find symbols and do some syntax highlighting in the .s files which is nice.

I want to revisit the StaticWS OSentries issue with hdr2h.

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

For some reason it just tells me that the assertion failed. Ideas?

I want to revisit the StaticWS OSentries issue with hdr2h.

Well it’s not likely to be hdr2h which complains, since it skips ASSERTs.

The assert is checking that OSentries is large enough to hold the full table of OS entry points (using the ? operator to get the size of the OSentries label / field). The size looks correct to me, so chances are it’s failing because the HighestOSEntry hasn’t been defined – i.e. you need to include hdr:OSEntries inside/before StaticWS.

That opened Pandora’s box. My includes are in the source files. GETting Hdr:OSEntries made it go into meltdown. So many multiply or incompatibly defined symbols.
Perhaps all the includes should just live in StaticWS instead.

edit: Hmm…

ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]
Error: Assertion failed at line 32 in file hdr.StaticWS
 included by GET/INCLUDE directive at line 15 in file "s.hdmi"
   32 00000000   ASSERT ?OSentries = 4*(HighestOSEntry+1)
Assembly terminated: 
1 Error, 0 Warnings
AMU: *** exit (1) ***

Finally got a proper tree up on GitHub

Using svn-git was a sorry mistake. It’s not really possible for me to take the same repository back the other way.

Something else learned. If Pi-Hole and Apache Subversion are running on the same server, shift the lookup port of one of them. lighttpd and apache2 interfere.

I’ve mostly reconstructed my source into something sort of working from various sources and have resumed work, but I’m a little stuck.

I thought it’d be nice to write some of the code in C. I wrote code for controlling the PIO ports, tested that the logic as good and began transplanting it into my HAL.
Got an odd linker error and began removing possible sources to no avail.

The files in question.
https://gitlab.com/risc_os_strays/ro_awh3_rebase/blob/master/RISC_OS_Dev/mixed/RiscOS/Sources/HAL/AWH3/c/PortIO
https://gitlab.com/risc_os_strays/ro_awh3_rebase/blob/master/RISC_OS_Dev/mixed/RiscOS/Sources/HAL/AWH3/h/PortIO

The error:

ARM Linker: (Warning) Attribute conflict between AREA CLib(C$$code) and image code.
ARM Linker: (attribute difference = {NO_SW_STACK_CHECK}).
ARM Linker: (Error) Undefined symbol(s).
ARM Linker:     _Mod$Reloc$Off, referred to from o.PortIO.
ARM Linker: Errors in link, no output generated.
ARM Linker: finished,  3 informational, 1 warning and 1 error messages.
AMU: *** exit (1) ***

AMU: * ‘_debug’ not re-made because of errors *

The _Mod$Reloc$Off part is the showstopper.

Before anyone says it, I know it doesn’t have the code for getting the base pointer from StaticWS yet. Nothing’s calling the functions yet anyway. I just wanted to see how badly it broke when put into the HAL first.

If anyone has any suggestions on how to make the linker error go away, please say so?

If need be I’ll rewrite in assembly but I’d rather not if it can be avoided.

What are you actually trying to build? The _Mod$Reloc$Off is used in module code, isn’t it? But you can’t use module code if you need to have code that does not have stack checking (as indicated by the attribute error).

Here’s about -zM and /noswst: https://www.riscosopen.org/forum/forums/4/topics/2299#posts-28675

And this might help: https://www.riscosopen.org/forum/forums/3/topics/445?page=6#posts-5425

Just trying to build the HAL I made with a new source file written in C. I’m not sure why it’a causing that error. CLib.c and dummy.c (there to test C things) build without issue. AFAIK I’m not specifying anything different for PortIO.

I need to have a good read of those threads you linked. That second one especially seems like it could hold the answer. Hopefully I’ll have some good news to report.

I only just started last night but I was writing a struct version of StaticWS already. Quite simply because it makes sense. I also know other OSes do things that way for hardware access.

When putting my code back together I had to dig deep to find an old version that was new enough but pre boot-breaking. Writing something for the Processor IO ports was where I had been hung up for ages. So many things need those ports twiddled it made sense to do it all in one place. Plus it gives an easy basis for a native and RPi function compatible GPIO module. IIRC I’m already using hardcoded access to the ports in a few places already.

It’s been bugging me for so long that I have a port which runs but is missing some core functionality. Most notably display output. If it had that, a lot of things could be written and tested onboard.

So the solution is to extend StaticWS and use that extra space to house a C workspace?
I guess that the C workspace would be populated by some assembly before use. Unless I’m misunderstanding the contents could be totally different, which is nice.
When I was looking at my StaticWS I did notice a gotcha. My code has a 2k+4byte space allocated for virtual CMOS. From what I read this could be problematic.

It sounds like you’re trying to compile a ROM based Module written in C, that isn’t staticly linked to CLib.

Isn’t there a parameter needed to tell the linker that it’s ROM based C code? Have a look at an existing C Module’s ROM make file.

What I can’t work out is why CLib builds fine, as does my simple dummy c file, yet the PIO source file I wrote doesn’t.

At worst it’s no big deal because I’m writing an assembly version too.
I don’t know DDE well enough. Does it need CLib? I know in the case of gcc I can use that completely bare with a little extra effort.

My eyes have surrendered for the night unfortunately. I’ll have another look through things another day.

Only semi related but I noticed the Orange Pi 3 was released. 2GB RAM, 4x USB3 ports, gbit ethernet, wifi, bt, MiniPCIe(?) port, 8GB eMMC, the usual IR receiver, and oddly a small GPIO header like a Pi 1 B. Allwinner H6 quad core at 1.8GHz. This is from memory so YMMV. I’m sorely tmpted to buy yet another ARM device I don_t need.

Just trying to build the HAL I made with a new source file written in C. I’m not sure why it’a causing that error.

It’ll be related to p_PIO & p_PIO_L, although I won’t be able to tell the precise reason without digging deeper and trying to compile the code myself.

But regardless of the cause, the solution is simple: Do the thing that you’ve told us not to mention.

Reading through https://www.riscosopen.org/wiki/documentation/show/Using%20C%20in%20assembler%20components#TOC2 may also provide you some help (I’m just not sure about the status of -zM – several of the HALs use the CModule makefile, so I’d assume they’re being compiled with -zM. So if that’s true then it isn’t mandatory to avoid -zM)

I just want to say from the beginning I’m not happy with having separate reads / writes for port L.

Really the only way I can finish those functions is to implement the separate C workspace or pass a pointer to the relevant ports every time, right?

I tried looking at the OMAP3 HAL but it looks like the C code was phased out years ago.

What happens with local variables in C? They seem to work fine. Does “static” still function as intended?

However, you do need to make sure that if a piece of code (whether that’s C or assembler) uses HAL workspace, that it’s never called from C code which had the __global_reg definition compiled in. Otherwise SB the intermediate function may have modified SB from its original value.

Soo… it needs to have the pointer passed in on a per function basis or something instead?

I think I added the CModule fragment to my Makefile. Was this a mistake? Speaking of, I’m aware I made a bit of an error in the makefile where it uses hdr2h.
In the meantime I’m going to keep working on the assembly port of it. It’s good revision.

e
…or I could not be a spaz and have some externs for reading and writing written in asm which would have access to the workspace.

Regarding the Port L issue. It maps the same as Port A but in a completely different part of the memory map. I was thinking maybe I could so something like signal get / set32 with a set high bit in “offset” or something like that to let it know that it needs to use the PORT L base address?

The code probably has a million errors but I put it up. Maybe later I’ll jump through the hoops to build it. My choices are either reboot the Pinebook into Armbian mainline to run RO Linux to build, or to copy the source via sneakernet to something RO which are all unpleasant to use right now, do the file rename dance, and then build. I will be so glad if / when the Vonets adapter arrives.

I got it to build. Haven’t copied / pushed the changes to the repo yet.

Really the only way I can finish those functions is to implement the separate C workspace or pass a pointer to the relevant ports every time, right?

Correct.

What happens with local variables in C? They seem to work fine. Does “static” still function as intended?

Locals are stored on the stack, so they work fine. Statics are just “hidden globals” – they’re still stored in global workspace, so won’t work from the HAL.

However, you do need to make sure that if a piece of code (whether that’s C or assembler) uses HAL workspace, that it’s never called from C code which had the __global_reg definition compiled in. Otherwise SB the intermediate function may have modified SB from its original value.

Soo… it needs to have the pointer passed in on a per function basis or something instead?

Sorry – looks like that bit is complete nonsense. I’ve corrected it now.

I think I added the CModule fragment to my Makefile. Was this a mistake?

Most HALs seem to include CModule, so it seems to be OK. However last night I forget to check whether that resulted in -zM being passed through or not.

The change in the information page makes much more sense now!

I do have to ask, is there an inherent problem in doing what I just did last night? Ie having some assembly functions to deal with workspace related things such as reading and writing to PIO registers which are called by C functions.
It seems to build fine that way at least.

I just solved the apparent boot failure issue my code had since the rebase. I forgot to change the kernel options for serial debugging.
I had to disable the FPEmulator in build because of errors. It has happened to me so many times. Normally I just grab a fresh copy from a build tree archive. IIRC it says something like “Don’t know how to build ^.RISCOS” when it messes up.

Hm. Are there any gotchas for using extern asm functions for doing WS related interactions? Nothing seems to break when I call my C functions from boot.s but they return 0 when they shouldn’t.

e: I did it again. Messed up when using the workspace. I’m very rusty. Will have to work out how to do it again. See!

PIO_set32

    Push "a3"

    LDR     a3, PIO_BaseAddr
    STR     a2, [a3, a1]

    Pull "a3"

    MOV     pc, lr

I do have to ask, is there an inherent problem in doing what I just did last night? Ie having some assembly functions to deal with workspace related things such as reading and writing to PIO registers which are called by C functions.

That approach is fine. The only downside is that the code will likely be sub-optimal since the function calls will prevent the compiler from making good use of all the registers.

Hm. Are there any gotchas for using extern asm functions for doing WS related interactions?

Looking at what you’ve currently got in gitlab, the code in PIO_asm.s and the workspace definition looks fine. But PortIO.c doesn’t have the __global_reg definition enabled – so when you’re calling the PIO functions from Boot.s, the C code is probably pushing sb to the stack, putting some random temporary value into the register, and then calling through to the assembler PIO functions with that temporary still in place.

I uncommented the __global_reg definition. Also did some cleaning up and fixing some silly mistakes. I still need to move out other abandoned versions of the PIO files though.

May I ask, was the version of PIO_asm.s that you saw the version with functions as posted above, or the version with the ADRLs to initially load from the workspace?

I’m using the version with the former and not getting anywhere. Ie writing to the registers associated with the onboard LED show nothing visible, and still read back 0.

That approach is fine. The only downside is that the code will likely be sub-optimal since the function calls will prevent the compiler from making good use of all the registers.

That’s fine. I just want an easy, centralised means of fiddling with the processor IO ports. Besides GPIO, much of the SBC’s functionality is controlled by them.

e: Many typos, including on the forum are in part due to the weird keyboard on the Pinebook. Some commonly used characters need a Fn or Shift+Fn combination to type. I tend to mess it up and not notice.

May I ask, was the version of PIO_asm.s that you saw the version with functions as posted above, or the version with the ADRLs to initially load from the workspace?

The version you posted above, with LDRs.

It doesn’t look like you ever committed a version with the ADRLs enabled, but just to make sure, this is the way you’d need to use them:

PIO_set32

    Push "a3"

    ADRL    a3, PIO_BaseAddr ; Get address of PIO_BaseAddr variable
    LDR     a3, [a3] ; Get value of variable
    STR     a2, [a3, a1]

    Pull "a3"

    MOV     pc, lr

I’m using the version with the former and not getting anywhere. Ie writing to the registers associated with the onboard LED show nothing visible, and still read back 0.

Strange – I can’t see anything obviously wrong with the code.

Thanks for the workspace value accessing snippet. Always appreciated.

So the simple version like I posted was correct? That’s unfortunate. I was hoping for a glaring mistake.

So far:

• The PIO physical addresses appear to be correct.

• The translation to logical address and adding to StaticWS uses the same logic as everything else so it should be correct.

• The bit twiddling logic in the C file was tested with arrays and special read / write functions as a stand alone program and produced the correct results.

• The assembly get and set routines are apparently correct.

• sb is now sacred.

I’m going to try to dig out my little 3 colour LED module and try fiddling some GPIO pins. Also going to add a whole lot of console readout to see exactly what data is being moved around.

Having everything shoved in near the bottom of boot.s isn’t a problem, is it? Once it’s working I need to remove the test code anyway, and do a fair bit of renaming of defines and functions.
After it’s all sorted I can continue support for some other hardware. TWI appears to be low hanging fruit, except for that one port in a different area of memory. TBQH UART is like that too. I kind of just ignored that port. Left it for ’Ron

Booting broke again at an earlier point than anything I touched. Really strange. Did a build using my Pi Zero. Took about an hour. I’m doubting the integrity of that USB drive. Going to fiddle with what I have over the next couple of days. Can’t do a whole lot else right now.

Through the Linux Port, we discovered a lot of unnecessary cache flushes that were slowing the build process down, I’m not sure if they got fixed.

USB/SD on the Pi are also slow, which are probably the bulk of the slowness. I switched my JASPP package build to a RAM drive and it spread up 10,000% !!!