RK3288 initial rants

Nicely done!

I am now in “InitDynamicAreas” , however in that I only get one printout and it looks like printing a bad pointer :)

Oh well…

Really hard crash, all leds on the boards is on. Dunno what that means.

FreePool PMPSize 0003d39b
end sysheap
ExecuteInit
After CallHAL
KeyInit
MouseInit
OscliInit
Enabling IRQs
IRQs on
Debug terminal on
HAL_InitDevices
Error: DataAbort:Abort on data transfer at &FC003240 (Error Number &80000002)
*dd
Error: DataAbort:Abort on data transfer at &%0 (Error Number &80000002)
*basic
Error: DataAbort:Abort on data transfer at &%0 (Error Number &80000002)
*

*help
==> Help on keyword Help

NoSuchSWI1:SWI
&%0
not
known
*modules
No. Position Workspace Name
1 FC0293F4 00000000 UtilityModule
2 FC04CF00 20000014 PCI
*

Error: DataAbort:Abort on data transfer at &FC003240 (Error Number &80000002)

That address will almost certainly be within your HAL. Open up the ROM in StrongED/Zap to see the disassembly, and look at the instruction at offset &3238 (the address RISC OS prints for data aborts is always 8 bytes ahead of the actual instruction, since it doesn’t take into account the 8 byte offset that the CPU applies when it stores the address in R14 and takes the abort vector). Then try and work out where that is in the source code (probably in HAL_InitDevices)

Yes I know what happens..

I can start BASIC now, but I can’t use it.
I need to fill out the HAL now, it is a empty shell. :)

Btw. Is there any other of the supported platforms that use “GIC” as interrupt thing?

Also , The RK3288 has the same USB controller as Pie. So the “only” thing needed is to find out how to glue it with clocks etc. The TRM gives the PHY and a bit of PLL info.

Btw. Is there any other of the supported platforms that use “GIC” as interrupt thing?

OMAP4, OMAP5, iMx6, Titanium (AM5728).

Also , The RK3288 has the same USB controller as Pie. So the “only” thing needed is to find out how to glue it with clocks etc. The TRM gives the PHY and a bit of PLL info.

Good luck with that! There are a many different configurations for the DWC USB controller, and the DWCDriver module does contain modifications that are Pi-specific. So you might have to do some digging to work out what exact configuration is used and whether it will work with our driver version.

Good luck with that! There are a many different configurations for the DWC USB controller, and the DWCDriver module does contain modifications that are Pi-specific. So you might have to do some digging to work out what exact configuration is used and whether it will work with our driver version.

The only way of really find out is to read GPL source code. There is a FreeBSD port, but it is only a embryo , I can only hope it contains something about DWC. Quite ineteresting (and extremely frustrating) that rockchip refuses to give out docs for USB.

BASIC:

*modules
No. Position Workspace Name
1 FC0293F4 00000000 UtilityModule
2 FC04CF00 20000014 PCI
3 FC04EE88 00000000 BASIC
4 FC05FEB4 00000000 BASIC64
*basic64
Error: UndefinedInstruction:Undefined instruction at &%0 (Error Number &80000000
)
*basic
ARM BBC BASIC V © Acorn 1989

*

Which modules do I need in order to use BASIC?

Probably very similar to the ones used in the PiCo ROM, as that is designed to be a cut-down system to run BASIC.

You may also need to ask which modules are going to be used by the BASIC program ? eg any file access will need a filing system; Fonts will need FontManager; etc.

Beware there are different ‘flavours’ of the BASIC module. The ones in ROMs can differ depending on the machine build and load messages externally. The one for softloading will work standalone on all machines and includes messages within it.

For BASIC to work fully you need:

FileSwitch
ResourceFS
TerritoryManager
Messages
MessageTrans
UK
BASIC

For BASIC64 you also need FPEmulator and BASIC64.

You may also need to ask which modules are going to be used by the BASIC program ? eg any file access will need a filing system; Fonts will need FontManager; etc.

I don’t have a filing system to start with. I just want to have BASIC as the first real thing I can run since it can be used with the debug console.

FileSwitch
ResourceFS
TerritoryManager
Messages
MessageTrans
UK
BASIC

Well , FileSwitch crash at the moment as for the others I don’t know yet.

I get this now: It crashes most often in the changedyn code before startup, and now when it completed module init without error it stoped here..
area ffffffff , is this correct?

RISC OS 992MB

Cortex-A17 Processor

Growing area ffffffff
by 1e943000
dest size 00108000
dest max size 20000000
FreePool PMPSize 0003d386

Something is strange here. I get random crashes and everything points to changedyn. What could affect that? Bad RAM timings ?

area ffffffff , is this correct?

Yes, area -1 is application space.

Something is strange here. I get random crashes and everything points to changedyn. What could affect that? Bad RAM timings ?

If u-boot is setting up the RAM for you then I’d assume that it’s correct. A more likely problem would be silicon errata in the CPU; do you know what revision of A17 the RK3288 uses? Both the r1 and r0 errata documents look like they contain some scary entries. Apparently the RK3288 is the first SoC to use the A17, which makes me worried that it might be using r0 silicon, but hopefully they’ve updated it to a newer revision by now.

The other possibility is a bug in RISC OS; pretty much every new CPU we add support for reveals some kind of memory management bug. I have made a lot of fixes in that area over the past few months, but it’s always possible there’s something I’ve missed.

I didn’t have TerritoryManager on last “successful” boot. Will that hang after printing memory cpu?

It will take a number of boots before I know.(added the module now).

No it wasn’t is there any configuration issue that might cause the symptom , or is it the last change dynamic that hangs?

Btw the Cortex is really a A12 with revision r0p1.

But I am beginning to get the feeling that changedyn writes or moves IO mem in the wrong way. I made the region to MapInIO a higher top address than IO ram (for testing) and it stops with
random characters printed at the same place as it usually stops. I map in the entire IO space in one go, since io mem is organized in one chunk.

I also figured out that i boots more frequently if I just mapin a couple of addresses and not the complete range. In this case the crashes follows a pattern. First boot it crash in initdynmem. Then after while with power disconnected it crash in module init, and last after another powerless time it starts up to RISC OS blabla.

Jeffrey , any hints on why it does trash the IO mappings? Every HAL does the same thing, Map in RAM , Map in IO. I do that as well. The only difference is that I don’t relocate the ROM. I supply the kernel with RAM above the ROM in physical space, is there a problem with this? RAM starts at 0×0 on RK3288 and goes up 2GB on the tinker board. Above that comes IO mem. It is linear but there are reserved areas mixed in with it. I don’t think that is a problem, since it fails even if I specifically just map in the couple of addresses I need right now.

Nothing should be touching the IO mappings once they’ve been created. The OS will read the page tables to work out if a mapping already exists, and it will append new mappings to the list, but that’s it. So if it’s overwriting them then it’s either placing them in the wrong part of the memory map or something else is going out of its bounds.

What logical addresses does the OS give you for the IO regions? They should be between &BA000000 and &FA000000 (the main areas of the memory map are defined here)

RAM above ROM should be fine; IOMD-based machines have their ROM located at 0 in physical space.

The only other thing I can think of is that you might be passing the “RAM is cleared” flag to OS_Start when in fact the RAM hasn’t been cleared. IIRC there are various bits of the kernel init which will break if memory isn’t cleared correctly. (If you don’t pass the “RAM is cleared” flag then the kernel will make sure it clears the areas itself)

The only other thing I can think of is that you might be passing the “RAM is cleared” flag to OS_Start when in fact the RAM hasn’t been cleared. IIRC there are various bits of the kernel init which will break if memory isn’t cleared correctly. (If you don’t pass the “RAM is cleared” flag then the kernel will make sure it clears the areas itself)

Thanks for this information! That did the trick. The only question that remains is why it stops at the after printing RISC OS RAM CPU? Does it wait for disk? How can I make it just drop out to * ?

Yeah, it’s probably trying to boot from disc. IIRC you can bypass it by making Hortoculture_Kicking branch directly to DoStartSuper.

RISC OS 2011MB

Cortex-A17 Processor

Acorn SCSIFS

Error: Internal error: abort on data transfer at &FC0203E8 (Error number &800000
02)
*basic
ARM BBC BASIC V © Acorn 1989

Starting
with
536834300
bytes
free

>PRINT “Hello from RISC OS on RK3288!”
Hello from RISC OS on RK3288!
>

Now that’s a real milestone.