Orange Pi

Clive – what? STM with a single register?

That’s what I was thinking of, yes. Don’t tell me I’ve forgotten something, or that they have decided to re-use it since I left? Surely not…

Not all that tiny, I suppose, but not exactly enormous. Very tangled to decode – okay if you make it all off limits and then use odd bits of it for odd things that each use small chunks of instruction set space I suppose.

Another fun bit…STM (and LDM) with no registers at all…

Don’t tell me I’ve forgotten something,

…the fact that loads of people still use it for stacking/unstacking single registers?

“LDM or STM of single register is probably slower than LDR or STR” makes 178 appearances in a build of RISC OS, which is pretty bloody good considering there are 156 instances of this when building Twin (which is tiny in comparison).

I’m guilty too. There are times when I STM R14 because… laziness. STM is cuddly and friendly while STR is complicated, what with the #-4 offset and all. ;-)

Very tangled to decode

Down a road that looks like that is the lurking ghost of x86.

Another fun bit…STM (and LDM) with no registers at all…

Well, in theory one could use this to provide a completely new instruction.

8000  EF000010  SWI   OS_GetEnv
8004  E1A0D001  MOV   R13, R1
8008  E92D0000  STMDB R13!, {}
800C  E1A0F00E  MOV   PC, R14

Internal error: undefined instruction at &0000800C.

It’ll throw an exception so it could be trapped. ;-)

I know you’ve said before that you’ve been using C since the 90’s, but judging by the large number of comments throughout the source I get the feeling that you’re not yet fully comfortable with it.

To be fair, it can depend on what you’re doing with it; I’ve been using it for years for Windows app development but had never needed to touch the << operator until I wrote my “Uptime” RISC OS module. A lot of the “low level” stuff is still a mystery to me…

I’ve been using it for years for Windows app development but had never needed to touch the << operator until I wrote my “Uptime” RISC OS module.

To be fair, thiis is one of the thiings that really irritated me about VisualBasic, the lack of a simple binary shift. To multiply and divide by powers of two to an integer is just so horrible given that one can easily imagine the sort of chundering going on inside VB in order to perform the * or / when a shift is, what, a single instruction on pretty much every processor on the planet?

A lot of the “low level” stuff is still a mystery to me…

That’s not a surprise given the sorts of fruity stuff you can do in C, like:

  return *(void *)&this->that.something;

I made that up. It’s probably wrong. But I’ve seen worse. Then there’s the “let’s make functions look like an array so we can call them programmatiically” thing. I’m sure very useful for emulators and the like, but it leads to the sort of code that makes spaghetti GOSUB of the ’80s look tame in comparison.

…but judging by the large number of comments throughout the source I get the feeling that you’re not yet fully comfortable with it.

You aren’t far off. I’ve forgotten a whole lot :( It’s incredibly frustrating.

I’ll be digesting all this info properly when I have a chance. Can’t really do anything useful until next week.

I did something a couple of days ago that had the results I expected unfortunately. Because of USB serial issues with RO, I set up a serial to TCP/IP WiFi bridge using an esp8266. It didn’t work well. I’m amazed it worked at all.
It’s complex, but comes down to a 3 way logic level battle. Or it should. Weird thing was it was dropping data on TX. That is OPiPC → esp8266 → WiFi → terminal. Any bursts only had the beginning transmitted. The rest would dissapear into the ether. So I’d only receive the beginning of a directory listing then nothing, for example.

A fun thing that I did notice though is if I used xterm-colour in Nettle, it could correctly display the extended character attributes like colours from the OPiPC. I had suspected it could, but this proved it. Because it was just a bridge it lacked Telnet extensions.

One of the reasons I tried this was the Serial USB drivers for RO end up with an irritating local echo happening so 2x every character was printed.

In the end it was all pointless anyway. I mean I can load binaries from ext4. It takes a few steps, including copying over the network. I would have preferred to use X/YMODEM protocols, but I just can’t seem to get Hearsay or Connector to behave. I was hoping to check for data corruption after doing a transfer with one of them instead.

e: Jeffrey, you can say my code is horrible if you want. I know it is. It’s a mess. I know. I don’t even like looking at it.

the fact that loads of people still use it for stacking/unstacking single registers?

Now this is where my background shows. I wasn’t aware of that at all.

STM is cuddly and friendly while STR is complicated

Of course a clever assembler could automagically assemble any instance of LDM/STM single register as the corresponding LDR/STR. And since the instructions are the same length (!) automagically replacing them in existing code wouldn’t be that difficult either.

Down a road that looks like that is the lurking ghost of x86.

There’s a fair few examples of that already in ARMv7. Okay, not so extreme – hence my comment about “tangled”. Some day I’ll take a look at v8. Or maybe not. I find I’m not missing any of the apps I wrote with chunks of assembler in them (yet?) – all the ones I’m still using are BASIC only. Don’t know if I’ll ever write Assembler again.

A lot’s happened recently. I’m also sick. When I’m better and get my brain back I’m going to tackle this some more. With the new useful information and time to think, i believe some may have actually penetrated my thick skull.

I’m looking forward to tackling this again soon.
Just posting because something not entirely related but interesting happened:

https://www.cnx-software.com/2017/09/26/allwinner-socs-with-mali-gpu-get-mainline-linux-opengl-es-support/

The problem with AllWinner SBCs has been that some hardware acceleration has only been possible by using linux with a legacy Android kernel which had some nasty bugs and issues. The Mali support for mainline linux kernels comes in the form of a blob still, but at least it’s not a mess that nobody was willing to touch like it has been.

I have absolutely no idea if the blob can be made to work for other OSes, but it’s still interesting.

e: This is for OpenGLES btw, not for the video codecs. Not sure what the status on that is, because tbqh I find the OPiPC better for watching video than the RPi3.

Edit:
Sometimes a break is good. Fresh eyes on forgotten code. Comments are good. Beyond what has been spotted by Jeffrey, I’m finding some really silly mistakes including but not limited to the UART code. I’m borrowing a version of the blink example code for now although it is at odds with what RISC OS wants. Ie instead of failing silently it’s blocking.

I’m thinking I can borrow a few GPIO pins for a simple output for debugging if I can’t catch the issue via UART, assuming it wasn’t actually the UART code. I’m hoping it’s failing where Jeffrey pointed out and not before.

Jeffrey, I know the AddRAM bit I did is garbage by the way. I fully expected the code to crash before there. I did run into the issue of having no idea what areas could be considered allocatable too.

The USBSerial blockdriver has sped things up immeasurably. I don’t have much time to work on this but I’v already found a few failure points.
Jeffrey, it appears that R11 is one of the registers that is saved in C’s stack frame. It then immediately reuses r11. I’m not sure yet if it restores r11 before it needs to be used. I’m just slowly shuffling through the disassembly, matching it to the source to work out how things end up at the point of the register dump I just grabbed.

There are some anomalies. Most notably the PC is in a HAL function stub which never gets called. According to the PC the undefined instruction is a very valid looking MOV. So this is an odd one. My bet is on linker issues again.

e: Yep.
I rearranged a few things, fixed a few things I wasn’t happy with and rebuilt. No matter what, the C code is branching to weird landing points. It seems to be missing it’s target symbol. Weird.

I’m not sure yet if it restores r11 before it needs to be used.

It wont.

There are some anomalies. Most notably the PC is in a HAL function stub which never gets called. According to the PC the undefined instruction is a very valid looking MOV. So this is an odd one. My bet is on linker issues again.

I’d check the PSR as well; it’s possible the instruction is undefined because it’s dropped into Thumb mode.

It looks like GCC does have an equivalent of Norcroft’s __global_reg attribute, so I’d recommend adding the following to a common header which will be included by everything:

register void *RO_Base asm ("v8");

https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html

However that may end up generating an error due to it conflicting with one of the APCS registers (I think v8 is typically the APCS frame pointer?). Possibly you’ll be able to fix this with -fomit-frame-pointer. Failing that, try changing the code so that RO_Base is stored in v6.

Ultimately it doesn’t really matter what register RO_Base is stored in, since the HAL can always locate the OS image directly. But when the MMU is enabled and you need to keep track of the HAL workspace pointer (which will be in v6) it’s going to be important to have a tried-and-tested way of preserving the register (otherwise you’d need stubs for almost every call into C, to allow the workspace pointer to be supplied as a function argument).

(Note also that using v6 for both RO_Base and the HAL workspace pointer should be fine, since one is only used pre-MMU and the other is only used post-MMU)

It didn’t drop to thumb. Only reason I didn’t include the reg dump was I’m typing this on the PC.

I think before any of these issues are tackled, the big, big issue of the landing points of branches missing their target at build time needs to be tackled.

Not sure if I mentioned but I have a second build setup. It’s the same tree as my C one except the HAL is a different directory. It’s kind of my testbed.
After the feeling of crushing defeat with the linker sunk in I swept away the old files in the assembly HAL to a safe place and started a “proper” one again. It already has usable elementts like the H3 Hdr which I cleaned up a little. But I started from the “Top” with a different approach today.
While I was at it I got gcc to spit out gas assembly files for the C I’ve done so I can recycle some bits and pieces. Porting to ObjAsm and back is pretty easy thankfully, as long as macros aren’t involved.

I just want some confirmation on a question I asked at an earlier point.
Does the contents of the HAL affect the contents of the main ROM in any way during build? I hope the answer is “No”.

An idea came to me. I can build a complete ROM. The ROM is large. The HAL which isn’t very capable yet needs RO to make it more than a few instructions in.
Copying the entire ROM over XMODEM every time I wanted to test would be tedious. So what I’m thinking is I build a ROM and zero out the first 96(?)KB of the image then dump that on to the SD card. Then I could just load that then dump the HAL via XMODEM over it at the same base address. I mean I could remove the beginning of the RO ROM and have a different offset but this just seems easier. Does it sound feasible?

While I’m here. For posterity, the machid for the Orange Pi PC is 0×1029.
I haven’t been able to find the machid anywhere. I spotted it this time in the currently installed version of UBoot while it was loading the Linux image. This is a number I don’t want to lose. Last time I checked there was no entry in the machid database.

Does the contents of the HAL affect the contents of the main ROM in any way during build?

No.

So what I’m thinking is I build a ROM and zero out the first 96(?)KB of the image then dump that on to the SD card. Then I could just load that then dump the HAL via XMODEM over it at the same base address.

Yes, that should work fine.

While I’m here. For posterity, the machid for the Orange Pi PC is 0×1029.
I haven’t been able to find the machid anywhere. I spotted it this time in the currently installed version of UBoot while it was loading the Linux image. This is a number I don’t want to lose. Last time I checked there was no entry in the machid database.

Allwinner’s codename for the H3 is sun8i. Meanwhile, http://www.arm.linux.org.uk/developer/machines/ shows that ID 0×1029 (i.e. 4137) is for the sun6i. So it sounds like they’ve just re-used a generic ID of theirs.

As more and more platforms start to make use of device trees, it should become less and less necessary for devices to be given unique(-ish) machine IDs (for device tree-supporting OSes, at least!)

I just wanted to say this isn’t dead. I’m restarting, in a sense. I’ve found more necessary information and learned some more. Also I worked out how to use tftp for loading binary images in U-Boot, which has simplified everything.

A couple of days ago I transferred some of my work to a new OS build tree. Something was fatally damaged in the old one preventing it from building. No loss. The source from that period was pretty finicky.

Although I’ve only just started, what I’ve got builds and executes without issue. This is a very good thing.

Would it be possible for someone knowledgeable in the HAL to do a small update to the RISCOS_InitARM page, please?
The actual purpose of the flags is unclear.

There aren’t any defined flags. SBZ = “Should be zero”

…Oh. I see now. I feel silly. I saw that, but completely misunderstood what I was looking at.

Entry 

flags  Reserved – sbz 

       SVC mode 

       MMU and caches off 

       IRQs and FIQs disabled 

       No RAM or stack used 

b0: Reserved. sbz

b1: SVC mode

b2: MMU and caches off

etc. etc.

Using the OMAP3 source as a guide is a double edged sword. It’s useful, but unpicking what’s going on with all the macros is difficult because of all the variants, and the complexity of the OMAP SoCs.

On the other end of things, the AllWinner SoCs are what I’d call a flat, monolithic design. No layers, no weird memory tricks like the BCMnnnn. It’s very simple.
An example is HAL_UARTPorts in “UART.s”. I haven’t even found all the steps it goes through to do that yet.
AllWinner isn’t big on change. Like I can say straight off that I could find the UART base for the H2+, H3, H5, and A64 at &01C28000. There will be 4 UARTs total with an offset of &400, and a fifth, and the mysterious R_UART at &01F02800. e: It’s for the AR100 coprocessor
This consistency is nearly universal. In the bottom 4MB of memory space or so there’s an organisational difference with some of the SRAM banks, BROMs and debugging I think, but that’s about it.

It’s worth bearing in mind that you don’t need the UART entry points in order to boot the system.

1. Make sure all unimplemented entries point to a function which just does “MOV pc,lr”. (It might be important for it to be that exact instruction – I have vague memories of some code in the kernel/OS which peeks at some of the entry points to see if they’re implemented or not)
2. To get to HAL_Init, the only thing you need to implement is HAL_Init.
3. To get as far as a command prompt (using the kernel’s DebugTerminal, and a minimal set of ROM modules), you’ll need:
   1. HAL_DebugTX & HAL_DebugRX
   2. HAL_KbdScanDependencies (returning -1)
4. To stop bad stuff™ happening, you’ll then want to implement the IRQ, timer & counter APIs
5. You should now have a minimally-usable system – as long as you don’t do something like get enter the desktop, the system should function correctly and you can add arbitrary modules to the ROM
6. Since the system is now operational, it’s your choice what you want to implement next (USB, video, SD, UART, IIC, etc.). Just remember that implementing the UART support before you’re able to transition away from using the serial debug terminal for everything isn’t likely to be very useful :-)

For “minimal set of ROM modules”, I think you’ll want the following:

• HAL
• Kernel
• FileSwitch
• ResourceFS
• Messages
• MessageTrans
• Possibly the Debugger and BASIC too (depending on whether you want to be able to debug things!)

It’s probably easiest to start with a known-good components file (OMAP, Pi, doesn’t really matter), and when disabling the unwanted modules just mark them as “-type EXP” so that they’re still involved in the header/lib export phase. That way you won’t have to deal with build errors due to missing headers.

Bearing in mind that the OMAP3 port is the only port where I’ve been there from day one, it’s possible the above isn’t completely accurate. But I’m pretty confident that you can get quite far (or at least far enough for the OS to start giving you error messages) with just HAL_Init, HAL_DebugTX, HAL_DebugRX and HAL_KbdScanDependencies, and that above list of modules. And if/when you do get things working, report back here so that any documentation can be updated accordingly.

1. Good to know. Already got that for HAL_UART* entries, but nothing else yet. The rest are just NullEntry, which now I look may actually be exactly that anyway.

2. That’s very useful information. As it is I can send my code blindly into OS_Start where there is a perceptible pause before the CPU resets. I haven’t bothered with anything on the far side of OS_Start yet. It’s mostly just there as an end point for the things I’m trying to get working which never gets executed because of an infinite loop I put in beforehand.

3. That doesn’t seem too hard. I’ve already got code that does most of #1, just not within the HAL framework. Do you mean that HAL_KbdScanDependencies can just be a stub which returns -1, or does there need to be more going on?

4. I’m genuinely surprised it can make it as far as the command prompt at all without these.

My current tree is based off OMAP3 from about a week ago. Most of the modules are disabled. I think I can strip a little further but not much.

It seems silly but to make things easier for myself I made a simple Obey file that pops open filer windows for all the necessary component / module / etc directories so I can tweak all that in a hurry if I want to.

Right now my ROMlet isn’t being copied anywhere at boot. I’m leaving it near the bottom of RAM at 0×41000000 (I could probably shift it down near 0×40000000) where it’s safe from being clobbered by anything in U-Boot or when I turn the MMU back off

I was chasing a nasty build bug since last night. Finally got it today. Long story short, I removed my version of the board.* files from my code. It’s just not needed.

I am a little hung up on how to enumerate the UARTs in a neat way. Also, How do I treat SRAM?
There’s a 64k, 32k, and 44k block starting at 0×0000 0000.
I had considered using OS_AddRAM to map it in with a fast speed specified, but that doesn’t feel right. I’m less than certain, but the third block, SRAM C, may possibly be associated with hardware crypto (documented!).

2. That’s very useful information. As it is I can send my code blindly into OS_Start where there is a perceptible pause before the CPU resets. I haven’t bothered with anything on the far side of OS_Start yet. It’s mostly just there as an end point for the things I’m trying to get working which never gets executed because of an infinite loop I put in beforehand.

It’s probably worth concentrating on getting OS_Start working, if it’s currently failing. No point having a UART driver which will never be called!

Do you mean that HAL_KbdScanDependencies can just be a stub which returns -1

Yes

Right now my ROMlet isn’t being copied anywhere at boot. I’m leaving it near the bottom of RAM at 0×41000000 (I could probably shift it down near 0×40000000)

That should be fine, at least for now. Later on you might find you have limited screen memory available, due to the way the kernel sets aside the chunk of RAM that’s used for video memory (unless told otherwise, it takes MIN(32MB,chunk_size/2) from the first chunk of RAM).

Also, How do I treat SRAM?

Ignore it for now. The kernel does try to (half-heartedly) prioritise using fast RAM over slow RAM, but with most systems I don’t think there’s enough SRAM for it to make any significant difference. There are also some limits on how small memory chunks can go until the kernel breaks – and I don’t think anyone knows for certain what those limits are (probably somewhere around 256KB).

It’s probably worth concentrating on getting OS_Start working, if it’s currently failing. No point having a UART driver which will never be called!

Who knows if it’s working or failing at this point. It has nowhere to go, and no way to show what it’s doing.
I’m just trying to smooth out some of the larger bumps before it. I sorted my UART number to address issue by the way. There was something very complex going on that was hard to pin down that was causing a macro to cause build errors.

That should be fine, at least for now. Later on you might find you have limited screen memory available, due to the way the kernel sets aside the chunk of RAM that’s used for video memory (unless told otherwise, it takes MIN from the first chunk of RAM).

Is there something besides OS_AddRAM that defines the location of video memory? I was just going to slap it where U-Boot has it defined for the time being. It’s not like any of it is hard to shift around later.

I guess maybe the stack could be shoved in SRAM. Possibly.

Is there something besides OS_AddRAM that defines the location of video memory?

There are two kinds of video memory – there’s the kernel-managed video memory, and there’s driver-managed video memory.

The location of kernel-managed VRAM will be taken from one of the chunks passed into OS_AddRAM. You can influence the kernel’s logic by specifically flagging a chunk as VRAM (bit 0), or as unsuitable for DMA (bit 7). Theoretically bit 1 does something as well, but I’m not sure if that’s working (nothing uses it). Pages of kernel-managed VRAM which aren’t currently in use by the screen can be reused as regular RAM, which was obviously very useful on early machines (both 32bit and 8bit) where memory was much scarcer.

The location of driver-managed VRAM is indicated via GraphicsV 9 / HAL_VideoFramestoreAddress. Spare pages of driver-managed VRAM can’t be used as regular RAM, since as far as the kernel is concerned it isn’t actually RAM (the kernel treats it as arbitrary IO space, like the hardware registers used by all the CPU’s peripherals).

However the key thing is that the kernel will always reserve a chunk of RAM as kernel-managed VRAM, even if no video drivers make use of it. (This is on my long list of things to fix)

I guess maybe the stack could be shoved in SRAM. Possibly.

Yes, placing the initial stack in SRAM would be a good way of making sure RISC OS doesn’t clobber it.

You could also use it to pass information over the OS_Start call, since there’s no proper way of doing that at the moment. E.g. for OMAP machines without physical NVRAM, the U-Boot script is set up to load the CMOS file into SRAM. Then in HAL_Init the HAL maps in that memory and checks to see if valid-looking CMOS is there so that it can offer it to the OS.

The debug tool *Memory is very cool and useful!

I’ve been stuck for a bit. It goes in to OS_Start and never comes out. No idea what happens when it goes in there. I guess I’ll need to sprinkle some debug characters around in kernel.s to work out where it’s choking.

I wanted to ask about OS_AddRAM. The end address of a block is exclusive. So would that mean as a quick example

block1 start: &10000000

block1 end:   &1FFFFFFC

block2 start: &20000000

blah blah.

I realised my static workspace was actually an ethereal workspace too. Not that it has much use at this point. Does it? At least it’s shackled to an address now.

I fed AddRAM a chunk of sacrificial VRAM just in case. Actually it is the location of the U-boot framebuffer which I don’t imagine would change unless acted upon. Interestingly it’s parked in the top of RAM with a little gap up top where the U-Boot stack lives.