Orange Pi

I guess I’ll need to sprinkle some debug characters around in kernel.s to work out where it’s choking.

Yes, that would be the best way of doing it.

I wanted to ask about OS_AddRAM. The end address of a block is exclusive.

You seem to have misunderstood what exclusive means :-)

block1 start: &10000000
block1 end:   &20000000
block2 start: &20000000
blah blah.

If you were to pass in &1FFFFFFC then the kernel would round it down to the next page boundary (so &1FFFF000), but should otherwise work fine

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.

Technically the HAL should have no workspace, until the kernel gives it an address to use via HAL_Init.

If the HAL needs workspace prior to calling OS_Start, then it’s the HAL’s responsibility to find a safe place to store it (e.g. SRAM).

If we had a way of checking memory access during startup then it would be possible to come up with a concrete specification of how the kernel/HAL should handle memory leading up to HAL_Init, and then run some automated tests to make sure all the different edge cases are dealt with correctly.

I realised my static workspace was actually an ethereal workspace too.

Did you mean ethereal or ephemeral?
In context, I think perhaps the latter.

Steve, I have contemplated this and believe ethereal was a better fit.
I created the table for the static workplace, however it existed in no tangible form. I can only guess that any attempts to write to it would put the values where the table definition exists.

Jeffrey, are you referring to clobbering the stack ingeneral? I’m just checking because I’m resetting the stack before OS_Start anyway because I can’t think of any good reason to preserve anything that may be in there, not that there really should be AFAIK

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.

Do you mean the stack, or SRAM? Both actually seem like interesting ideas.

You seem to have misunderstood what exclusive means :-)

Clearly! My understanding wasn’t wrong. Just incorrect in this context. It’s why I asked.

Michael, I have to get that far first!

I haven’t even been able to look at it. Too busy. Breaks are good though. It gives time to think things over properly.

Jeffrey, are you referring to clobbering the stack ingeneral? I’m just checking because I’m resetting the stack before OS_Start anyway because I can’t think of any good reason to preserve anything that may be in there, not that there really should be AFAIK

Just for the period prior to OS_Start. Although, now that I think about it, the only places where OS_AddRAM writes to memory are (a) the stack and (b) the start of the first memory block (so it can build up a list of all the blocks). So as long as you don’t set the stack pointer to be within, say, the first 1K of the first memory block you should be fine.

Do you mean the stack, or SRAM? Both actually seem like interesting ideas.

SRAM. Passing information over OS_Start via the stack won’t do you any good because the kernel sets up its own stacks (and may wipe or overwrite whatever stack you were originally using, if it was in an area of RAM registered via OS_AddRAM)

I have some fixing to do before continuing.
I can’t trust my results. Story time. A couple of days ago it took me a few minutes to isolate the code in Kernel.s.HAL that’s getting upset. I’m not sure of the practice of posting OS source, so I’ll say it seems to between block 31 and 32 in RISCOS_Start.

Yesterday I had some time to work on my code. After doing some fixing there was a build error in my HAL code that I had to do more and more work to make go away.
After a while the kernel source started to choke on missing libraries. Then fun things started to happen like getting a message that files werent found when I clicked on them. And then a couple of corrupted characters in a window title. Uh-oh.

I swapped out the Pi Zero for the Pi 3. I haven’t been using it because fo heat issues. I’ve found a way to drop the temperature a bit but that’s something for another thread.
So, my tree builds again. However my HAL code just falls flat on a data abort for all intents a few instructions in to Top.s

This brings me to now. I need clarification… again. Sorry Jeffrey.

In the HAL documentation, OS_InitARM is 0, and OS_AddRAM is 1 in the order of RISC OS Entry points by number.

OS_AddRAM states that it must be the first call to RISC OS after a hardware reset.

Which one am I meant to call first?

e: fixed the broken bit stopping the code from getting to where it normally does. Back to staring at the HAL.s source trying to understand why that bit gets stuck.

I’m not sure of the practice of posting OS source

1. Find the file in the CVS viewer
2. View the file with markup so that it will have line numbers shown
3. Find the line you want
4. Copy the URL, and append an anchor of the form #l<lineno>, e.g. https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/HAL?rev=4.8.2.1;content-type=text%2Fx-cvsweb-markup#l424

it seems to between block 31 and 32 in RISCOS_Start.

That would suggest either (a) a bug in the kernel that’s triggered by certain memory configurations passed to OS_AddRAM, or (b) your HAL is corrupting the RAM list (or passing a bad pointer)

Which one am I meant to call first?

OS_InitARM first. I’ve updated the wiki docs for OS_AddRAM to be more accurate.

Thanks again!

I forced the kernel HAL.s to progress past that point. Obviously it broke further along, but I wanted to see where it broke. It definitely points to an issue in the way I’m giving RISCOS_AddRAM its data.

I’m just setting up my code to do a dumb copy of the OS Image so I can apply different RAM organization. Trouble is, it’ll be putting the OS within the U-Boot declared VRAM. I haven’t worked out how to shift it yet. At least it’ll be in a high area which hopefully won’t get touched.

I’m leaving the SRAM alone for now. I’m pretty sure the CPU vector table lives at 0×0 still.

Unrelated, but when I wanted to dig for memory mapping in Linux on the OPi PC, I accidentally put in an SD card for the OPi Zero (H2+). It booted fine, so I just used it for my hunt.

Hopefully shifting the RO image above everything will get around the memory mapping issue as I know you suggested previously. The only reason I haven’t done it yet is it pretty much clobbers everything so I have to tread carefully.
I’m going to shove the RO image in at &80200000, 6MB below the top of physical ram on my OPi PC2. I’m making that distinction because there are things the code could run on which have 256MB, 512MB, 1GB, or 2GB RAM. For now there’s no sense in being clever.

I moved it up to 0×42000000, and just gave it a single block of the memory in 0×40000000 to 0×42000000 below it. I figure it should be enough to give me insight into if it is the position of the image in memory that’s the issue.
Something a little odd happened. It hit OS_Start, and at least a good couple of minutes after that it hit the usual getting stuck point.
I just tried that again and replicated it.

While kind of awful, is there anything inherently wrong with this for a heavily reduced test of adding RAM and going into RISCOS_Start?
These are snippets from a few different places lumped together for the quote.

BLOCK_0_START  *  &40000000

BLOCK_0_END    *  &42000000

BLOCK_0_FLAGS  *  2_001110000000
…

        LDR a1, =BLOCK_0_FLAGS

        LDR a2, =BLOCK_0_START

        LDR a3, =BLOCK_0_END

        LDR a4, =&FFFFFFFF

        MOV v1, #0
CallOSM OS_AddRAM
mov v1, a1
…

       MOV a1,   2_11001

       ADRL    a2, HAL_Base + OSROM_HALSize

       ADR     a3, HALdescriptor

       MOV     a4, v1
CallOSM OS_Start

is there anything inherently wrong with this for a heavily reduced test of adding RAM and going into RISCOS_Start?

Yes. With APCS, only a1-a4 are used to pass arguments to functions. Any extra arguments (i.e. v1) must be pushed onto the stack.

So you need to change from this:

MOV v1, #0
CallOSM OS_AddRAM

To something like this:

MOV temp, #0
PUSH {temp} ; or whatever other stack push macro/instruction you prefer
CallOSM OS_AddRAM
ADD sp,sp,#4 ; it's the caller's responsibility to clear the extra arguments off of the stack after the function call

Note that the OMAP3 HAL cheats a bit and doesn’t bother clearing the argument off the stack – since it knows there’s only a max of 2 RAM blocks and that OS_Start is going to reset the stack anyway.

For now, I’d also avoid setting bit 4 of a1 when calling OS_Start, because the kernel does use that flag to make assumptions about whether some areas of workspace have been zero-initialised or not. (there’s also a bit of a grey area with respect to wiping the stack and the RAM block list, since I don’t think those are explicitly cleared anywhere. So if you’re very unlucky you might encounter an issue due to that)

It didn’t even occur to me that OS_AddRAM was APCS compliant, even though I think you may have told me that ages ago. Sorry!
The RAM blocks are zeroed beforehand in my code anyway. It’s just a simple loop that’s fed the start and end addresses, so it’s slow but it does the job.

After fixing the param passing blunder it goes in RISCOS_Start and out the other end. My HAL_Init pretty much just consists of a debug character.
From what you said on the last page I guess I should be seeing something besides just that?
I’d better go back and check HAL_DebugTX is working properly.

It’s just a simple loop that’s fed the start and end addresses, so it’s slow but it does the job.

If there’s no fast DMA to clear the RAM, it’s better to let the kernel do it, since it can do it pretty quickly (and it’ll be able to do it in parallel to the keyboard scan that’s used to control CMOS reset, etc.)

After fixing the param passing blunder it goes in RISCOS_Start and out the other end.

Hurrah!

From what you said on the last page I guess I should be seeing something besides just that?
I’d better go back and check HAL_DebugTX is working properly.

Yes, the next thing you see after that should be a “HAL initialised” message that’s output by the kernel, via HAL_DebugTX.

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/HAL?rev=4.9#l1018

Sorry. I’ve been super busy. Sadly I was wrong about how far the code was getting. The hazards of copy-pasting code blocks.
What I can say from the alphanumeric soup I get over the UART it gets as far as MMU_activation_zone

The prerequisites for even getting that far seem to be to only have mapped RAM below the RO image. Not sure if the number of blocks makes a difference.

I have a couple of questions.

1: The addresses mentioned in the HAL make file and env(?) file which start in &FCxxxxxx for the ROM location. Given the address I would assume that is a Post-MMU logical address. Is that correct?

2: I can’t seem to easilt do anything about the location of the VRAM &7FE79000 – &7FFF1E00 which is nearly to the top of RAM on my test machine. The little bit above is the U-Boot stack. Do I omit this from the mapping, or add it as VRAM? Trouble being everything seems to collapse in a heap if I declare any RAM above the OS image.

What I can say from the alphanumeric soup I get over the UART it gets as far as MMU_activation_zone

One thing to remember is that once the MMU is turned on, any debug code you’ve added to the kernel which writes to the physical address of the UART won’t work, because it won’t be mapped into the logical address space yet. So if you have debug code located after that point, you’ll either have to remove it, or add some code to make sure the UART gets mapped in.

1: The addresses mentioned in the HAL make file and env(?) file which start in &FCxxxxxx for the ROM location. Given the address I would assume that is a Post-MMU logical address. Is that correct?

Correct.

2: I can’t seem to easilt do anything about the location of the VRAM &7FE79000 – &7FFF1E00 which is nearly to the top of RAM on my test machine. The little bit above is the U-Boot stack. Do I omit this from the mapping, or add it as VRAM? Trouble being everything seems to collapse in a heap if I declare any RAM above the OS image.

Keep things simple and omit it from the mapping.

• Assigning &7FE79000 – &7FFF1E00 for use as VRAM is probably a Linuxism, due to (AFAIK) Linux not supporting unified memory architectures in the same way that RISC OS does. I.e. under Linux the VRAM is for exclusive use by the GPU, whereas under RISC OS it can optionally be used as regular RAM when not in use by the GPU. So unless there’s a hardware limitation for the areas of RAM which can be used by the GPU, there shouldn’t be any need to pay any attention to the area that u-boot is setting aside for VRAM.
• Also, your focus right now should be on trying to get to HAL_Init. Once that’s working it’ll be a lot easier to make future changes, because you’ll know that if something breaks you can always compare against your earlier code to find out what change it was that broke things. If your code has never worked then it’s much harder to spot where the problem is!

As always, useful information.
I recall reading somewhere, possibly in a source comment that linux on the AllWinner SoCs has to be patched because it won’t accept a RAM region as IO.

Moving along slowly but surely. Lots of missing, broken, and hardcoded bits. Also a healthy dose of Cargo Cult programming but I’m slowly working out what things do in the source. I’m using both OMAP3 and BCM2835 code as reference. They both have very different ways of going about the same tasks. This makes it possible to extrapolate what’s actually going on.

I just saw proof that my recent ROM relocation code isn’t quite working right. I didn’t think it would. It’s too simple.
A quick tweak to disable the relocation, and loading the ROM directly to &7F800000 revealed some of my other additions are working :)
Please remember these are stubs.

## Starting application at 0x7F800000 ...
0 1 2 34 567890121234563123456412345651234566123456712345689ADEHAL initialised
IICInit
ClearWkspRAM
HAL_CleanerSpace
InitCMOSCache entry
InitCMOSCache failed
IMB_Full done
InitDynamicAreas
InitVectors
InitIRQ1
IMB_Full
VduInit
ExecuteInit
Machine ID duff,zero substituted
KeyInit
OscliInit
Enabling IRQs
IRQs on
HAL_InitDevices
InitVariables
AMBControl_Init
ModuleInitForKbdScan

e: a little further now

Reset CMOS
ReadDefaults
InitHostedDAs
MouseInit
ModuleInit

Turn on the debug terminal (DebugTerminal option in Kernel.hdr.Options) and you should see something much more exciting :-)

It locks up part way through loading! Haha I don’t think that’s what you mean though. Really I’m surprised it gets as far as it does.
My biggest issues currently seem to be:

• ROM relocation isn’t properly implemented. The way it works currently is very early in execution it compares the PC to the hardcoded copy destination. If higher, it drops through. If lower it copies the ROM and branches to it’s base address. At that point there’s nothing worth saving.

• The workspace. I’m having trouble grasping the whole thing in HAL_Init. I think it’s just dumb luck that the mapped in UARTs don’t get clobbered.
  If I can get past working that out, it should be pretty easy to start adding in functionality.

The good thing about describing things like this is I found a mistake in my relocation code. It doesn’t invalidate caches, check MMU is off etc until after relocation. Whoops!
e: It does do all that before copying, and after. Nevermind.

ROM relocation isn’t properly implemented.

Which is surprising, if you’re basing your work off of the OMAP3 and BCM HALs :-) Providing you can work out the register usage, you should be able to use the existing code as-is (just make sure you use the ARMv7 cache maintenance ops from the OMAP3 HAL, not the ARMv6-ish ones from the BCM HAL)

The workspace. I’m having trouble grasping the whole thing in HAL_Init. I think it’s just dumb luck that the mapped in UARTs don’t get clobbered.

If you had some code like this for transmitting a byte:

LDR a2, =UART_Phys ; physical address of UART registers
STRB a1, [a2, #UART_TX]

Then the simple way of converting that to use logical addresses would be:

; In HAL_Init
MOV     a1, #0
LDR     a2, =UART_Phys
MOV     a3, #UART_Size
CallOS  OS_MapInIO
STR     a1, UART_Log ; where UART_Log is in the HAL static workspace

; In HAL_DebugTX
LDR a2, UART_Log
STRB a1, [a2, #UART_TX]

The complexity in the current HALs is that they try to minimise the number of times OS_MapInIO is called. They know that the hardware registers for all the different peripherals tend to be located near to each other in physical space, so they just make one or two calls to OS_MapInIO in order to map in one or two large blocks, and then manually calculate the offsets for the different peripherals within those blocks. But in practical terms there’s little difference between the two approaches.

Also there’s complexity in the OMAP3 HAL due to the way that it’s designed to work work with many different boards, each with its own UART mapping.

You answered a question that I forgot to ask! About mapping large blocks of IO vs small ones. Given the memory layout it is vastly preferable for me to do a couple of large blocks.
You saw output past HAL_Init. I had no problem mapping in IO. What I’m not as sure of is how to store things effectively in the workspace post HAL_Init.
I’m guessing that the .hdr files with the indices and sizes of entries deal with the offsets which are applied to sb? But then your example didn’t seem to work that way.

Which is surprising, if you’re basing your work off of the OMAP3 and BCM HALs :-) Providing you can work out the register usage, you should be able to use the existing code as-is

Yeah. no. The thing about that is OMAP3 Top.s is dripping with macro-nese. My version has been written from scratch and is very rickety. Pretty much feeling my way and seeing what works. On the positive side I tried to keep the HAL code structure roughly similar to OMAP3 where I could. I’m going to put aside my version of Top.s and try to use a stripped version of the OMAP3 Top.s as a skeleton. All the board config macro things and the simulated Linux header things were getting in the way. And I kind of tended towards the BCM code whenever I came across anything to do with interconnects in the OMAP code.

From what I can tell, the Kernel should be fine, so long as I can work out how to feed it what it wants. I’m not looking forward to dealing with the interrupts. The GIC is well documented, but I don’t think any other RO ports use it.

You saw output past HAL_Init. I had no problem mapping in IO. What I’m not as sure of is how to store things effectively in the workspace post HAL_Init.
I’m guessing that the .hdr files with the indices and sizes of entries deal with the offsets which are applied to sb?

Correct.

But then your example didn’t seem to work that way.

I incorrectly assumed that you already understood that part :-)

ObjAsm is able to automatically translate things like “LDR a2, UART_Log” to “LDR a2, [sb, #offset]”.

https://www.riscosopen.org/wiki/documentation/show/A%20BASIC%20guide%20to%20ObjAsm%20Part%203 (see the “base register” section)

Yeah. no. The thing about that is OMAP3 Top.s is dripping with macro-nese.

Hint: The ROM relocation code starts at the relocate_code label and ends at the “Copy completed OK” comment. Strip out the DMA code and you’ll be left with something that’s practically identical to the relocation code that’s present in the BCM HAL (since I just copied & pasted the code, since there’s no point reinventing the wheel)

The GIC is well documented, but I don’t think any other RO ports use it.

OMAP4, OMAP5, Titanium, iMX6 all use the GIC (although not all the same version, and probably using SoC-specific register names rather than ARM’s official ones)

That link was exactly what I needed. Thanks. I was a little uncertain on how to apply offsets to entries so I could do things like populate the UART base address entries using that method.
All sorted now. I also swapped out my Top.s with a heavily stripped and altered OMAP3 version, with a few minor changes to other files.
It worked first time, and more consistently than my original file. Without DebugTerminal enabled it makes it to ModuleInit, and with it enabled it gets to ModuleInitForKbdScan. So it makes it no further, but it’s way more stable.
Is there anything else that should be enabled / disabled to get the debug terminal working? If I recall you said it should get that far without really having anything implemented. I know it wouldn’t exactly be usable but it’d be a good next milestone to aim for.

The Interrupt controller is a GIC PL400. Putting there for me too. I just had to find it in the datasheet again because I’m not sure where I saved the GIC datasheet. The hazard of working from multiple devices.

The processor vectors should be set up somewhere around the “IMB_Full” debug print, so if the machine was crashing with a data abort or similar I’d expect you to see some debug output from that. Which suggests that it hasn’t crashed, and instead it’s just stuck in a loop somewhere – possibly due to the timers not being implemented (unlikely, AFAIK it should initialise at least one or two modules before reaching anything timer-dependent), or possibly due to an interrupt firing (there’s a good chance one of u-boot’s hardware drivers left an interrupt or two enabled). Without having any interrupt code in the HAL there’s no way for the OS to mask the errant interrupt, so it just gets stuck in an infinite loop constantly being pulled back into the interrupt processor vector.

So I’d try implementing some basic handling of the GIC. Possibly you could lift most of the code from another HAL, but the problem there is that all the current GIC drivers are a bit quirky so you’ll either have a hard time understanding what’s going on, or you’ll just be proliferating those quirks.

The code in the Titanium HAL is probably the cleanest, you just need to strip out the code for handling the PCI interrupts.

Once you’ve got something up and running, it might be worth adding some debug output (e.g. to HAL_IRQSource) just so you can make sure the code is working correctly and the system isn’t stuck in an interrupt loop (in fact, adding some code to your current empty HAL_IRQSource would be a good way of verifying that an errant interrupt is the cause of the current problem)

Stepping in here… I don’t think I have a working interrupt HAL (as in not completely fully functional) and I get to the debug prompt without workarounds.

I’m really not sure what’s happening with it yet. I’m going back through and making some bits less skeletal. Un-commenting or un-short circuiting some debug sections etc. to bring it closer to what it should be. With HAL debug enabled it gets as far as InitDynamicAreas so that’s a step back. Without debug, I have no idea. I fixed debug output so it doesn’t output anything. Didn’t think that through.

I changed MapInIO to just map in a big block, and I started work on extrapolating from that. Previously the only thing I had mapped in was the UARTs.

I did some reading. Apparently U-Boot doesn’t use interrupts. It’s single threading and polling.
Don’t remember if I said but the very first thing my code does is disable the MMU and various other things. Doesn’t touch the GIC though.

I really wish I could easily share my code to get some more eyes on it, but RO doesn’t lend itself easily to that.

Next time I’m at the computer I’ll add some output code to the Interrupt stuff too see if anything there is firing.

Hey, look!
Michael, I went back over everything to try to work out what I missed, and fixed a few things. It’s obviously not perfect, but at least it gets to a (totally worthless) prompt.

=> go 0x42000000
## Starting application at 0x42000000 ...
3567890121234563123456412345651234566123456712345689ADEHAL initialised
IICInit
ClearWkspRAM
HAL_CleanerSpace
InitCMOSCache entry
InitCMOSCache failed
IMB_Full done
InitDynamicAreas
InitVectors
InitIRQ1
IMB_Full
VduInit
ExecuteInit
Machine ID duff,zero substituted
KeyInit
OscliInit
Enabling IRQs
IRQs on
Debug terminal on
HAL_InitDevices
InitVariables
AMBControl_Init
ModuleInitForKbdScan
Reset CMOS
ReadDefaults
InitHostedDAs
MouseInit
ModuleInit
init mod UtilityModule                                                          
init mod FileSwitch   
init mod ResourceFS
init mod Messages  
init mod MessageTrans                                                           
init mod RTSupportError: DataAbort:Abort on data transfer at &FC0662F0 (Error Nu
mber &80000002)                                                                 
*Cat           
    
Directory '@' not found (Error number &D6)                                      
*fx0                                      
    
RISC OS 5.23 (11 Feb 2018) (Error number &F7)                                   
*                                            
             

It was a second attempt boot. First time around it reset somewhere between MMU init and HAL init. I tried another load and run which got it that far.
That’s not a bad thing. It just means that I’ve got some setup in the wrong order or missing. Not surprising.

init mod RTSupportError: DataAbort:Abort on data transfer at &FC0662F0 (Error Nu
mber &80000002)

RTSupport doesn’t work for me, try to leave that out.