RK3288 initial rants

Assigning the right irq number helps I guess :)

But it doesn’t activate or something… IRQEnable always returns 0.

The EHCImodule goes into loop when adding devices. IN new_instance it starts itself again. It loops about 17 times, and then crash.
It thinks it founds 17 root hubs!

OK then here is the complete EHCI status.

• Interrupt number was wrong , fixed now.
• The Interrupt HAL is probably functional, I based it on the OMAP5 one and double-checked it against u-boot
• The EHCI controller responds like it should on read/writes

So problems..

• EHCImodule stucks at registering the root hub. It enters a loop and tries to register it again and again…
• The IRQ Handler is never entered
• more probably

I have problems with building in debugmode.. But I added a few debug statements.

So What is the next step?

Clocks is on by default * check.

Have you checked that the timer/counter APIs are working correctly?

If you’ve got BASIC working, you should be able to use PRINT TIME to check that the centisecond timer is working correctly.

The USB drivers also expect HAL_CounterDelay to be working, so you could check that from BASIC as well (e.g. use the OS_Hardware SWI to call it and ask it to wait for 1 second)

If timers are working, I’d suggest trying to fix whatever problems you’re having with building the debug versions of the USB drivers (sometimes the debug build does get broken, but I think it should be OK at the moment). Then you can configure the drivers to log to DADebug and (if necessary) use DADebug’s TickerPrint option to get the output.

It thinks it founds 17 root hubs!

Is HAL_USBControllerInfo implemented correctly? EHCIDriver uses it to enumerate the available controllers, so HAL_USBControllerInfo must return 0 once the ‘bus’ number goes out of range, otherwise the OS will think you have an infinite number of USB controllers.

Have you checked that the timer/counter APIs are working correctly?
If you’ve got BASIC working, you should be able to use PRINT TIME to check that the centisecond timer is working correctly.

prints “0” , so it is not working. It is OS_ReadMonotomic right? Where is it taking its time from?
About the Timers HAL. RK3288 uses 64bit timers. IS there a maximum number RISC OS needs? I can limit it to 32bit by using the lower register, setting the other to 0×0.

What is the correct number to return 0 from in USB? I have one EHCI controller (OTG is another story).

Some output from EHCI, Now it checks for controller twise

init mod EHCIDriver0xf9c00000
magic at 20013054read 1111 from f9c00004
read a026 from f9c00008
read 0 from f9c00010
read 80b00 from f9c00010
read 80b00 from f9c00010
read 80b00 from f9c00010
read c000 from f9c00014

mread c000 from f9c00014
read 1111 from f9c00004
read 1111 from f9c00004
read 0 from f9c00054
Registering with USB driver-done
Trying to start EHCIDriver%1 H0
0xf9c00000
magic at 20016e54read 1111 from f9c00004
read a026 from f9c00008
read 0 from f9c00010
read 80b00 from f9c00010
read 80b00 from f9c00010
read 80b00 from f9c00010
read c004 from f9c00014
read c004 from f9c00014
read 1111 from f9c00004
read 1111 from f9c00004
read 0 from f9c00054
Registering with USB driver-done
Trying to start EHCIDriver%2 H1
Failed to start EHCIDriver%2 H1: No EHCI devices found

Status of TIMER HAL. Everything seems in order, but it is clocked at 24Mhz and I don’t know how to slow it down… HAL_CounterDelay isn’t very useful.

Ehh never mind , I am blind. There is a multiplier in the delay function , I’l better use that!

Yes. TImer is ok now..

But the RISC OS clock doesn’t work..?

I upgraded the tree last night, and now the EHCImodule doesn’t get anything at all from controllerinfo.

SO two questions up now:

• How does the RISC OS clock work? What do i need more than Timers HAL? It can be a problem in interrupt on the timer. It would be nice to know how it is used.
• The first EHCI controller seems to be #0. So I should return 0 for anything else?

If the OTG controller is EHCI then HAL_USBControllerInfo returns 0 when hal_device is >=2. If the OTG Controller is not EHCI then HAL_USBControllerInfo returns 0 when hal_device is >=1.

If you look at your EHCI output the line

Trying to start EHCIDriver%1 H0

Is the initialisation of a new instance of the module the number after the H – 0 in this case – is the last successful hal device number.

I don’t have I2c in my HAL, is that a problem ?

Here goes the Interrupt status:

• The GIC isn’t receiving any interrupt from hw. if I can trust IRQStatus. I tried put it en a endless loop over the VOP interrupt (configured for line interrupt). The TIMER0 interrupt is the same.
• The TIMER0 interrupt is triggered if I look on the TIMER0 interrupt status register.
• IRQSOurce always returns -1 (but that might be normal, it is the same on i.mx6)
• IF I do IRQEnable on a enabled device it returns a non zero value.
• I have checked if the cpu actually is in irq mode.

So there are many factors..

• The cpu interface of the GIC might not be correctly configured. I added bit 1 to the ctrl register (u-boot does that), but no effect..
• The IRQ number translation from SOC → GIC might be wrong, but I have checked it many times and it looks correct.

Oh gosh!

I don’t have I2c in my HAL, is that a problem ?

That shouldn’t be a problem

IRQSOurce always returns -1 (but that might be normal, it is the same on i.mx6)

Yes, that’s normal if there’s no active interrupt.

In fact, because of the way the GIC works, when an interrupt fires, the first call to HAL_IRQSource will return the device number, and subsequent calls will return -1 (because it thinks that whatever code made that first call is handling the interrupt). So if HAL_IRQSource is called too often, it may cause the kernel to “miss” an interrupt. And unless there’s a corresponding HAL_IRQClear for each (valid) HAL_IRQSource, the GIC won’t deliver that interrupt (or any lower-priority ones?) to the CPU again.

There are some docs here where I’ve attempted to describe the OS’s/HAL’s approach to IRQ handling in more detail than the current HAL docs. It’s mostly written from the perspective of how the IRQ handling is being extended to support SMP, but it also describes how things currently work for single-core OS’s/machines.

There are some docs here where I’ve attempted to describe the OS’s/HAL’s approach to IRQ handling in more detail than the current HAL docs. It’s mostly written from the perspective of how the IRQ handling is being extended to support SMP, but it also describes how things currently work for single-core OS’s/machines.

Very good text!

If I loop IRQStatus over a enabled interrupt (TIMER0) it reads from the distributor interface. Since it never return anything but zero the device irq never gets to the distributor interface. Very strange!

Anyway If the CPU is in Secure mode I have problems..

I need to know if RISCOS needs to run in non secure mode, and how it handles it!

Traditionally, the OS has only run in non-secure mode, and there’s no code in the kernel for switching to or from secure mode.

I know the IMX6 starts in secure mode (it sets up an SMC handler to allow the L2 cache to be enabled/disabled), and I think it stays there (i.e. SCR.NS remains 0) (I can’t see anything obvious which switches out of secure mode). But I haven’t checked on a running system.

I know the IMX6 starts in secure mode (it sets up an SMC handler to allow the L2 cache to be enabled/disabled), and I think it stays there (i.e. SCR.NS remains 0) (I can’t see anything obvious which switches out of secure mode). But I haven’t checked on a running system.

I know that. RK3288 starts secure. It affects how the GIC works. The i.mx6 port does something for allowing all peripherals in non-secure mode.
I am working on if I can hack u-boot to disable secure mode.

No luck with u-boot..

Now I am trying with the i.mx6 secure handler and do the switch there. The cpu just halts or hangs on the write to p15.
But that was a wrong assumption!

It needs to be called after MMU ON . But now the MMU ON fails.. :/ The only difference is that the monitor is installed.

Now it runs thru and I should be in non-secure mode. No luck with GIC.

No it didn’t. If I set the NS bit R14 goes void. IF I push LR , do the write, pull it back the monitor returns, but NS bit stays unset.

The ARM ARM says that the preferred/correct way of switching to non-secure state is via performing an exception return from Monitor mode with SCR.NS=1

I.e. the following should work (untested):

  MRS CPSR_c,#MON32_mode+I32_bit+F32_bit ; switch to monitor mode (editing SCR.NS outside if MON is discouraged)
  MOV R0,#1+16+32 ; SCR.NS, .FW, .AW set
  MCR p15, 0, R0, c1, c1, 0
  ADR R0,continue
  MOV R1,#A32_bit+I32_bit+F32_bit+SVC32_mode
  STMFD R13!,{R0-R1}
  RFEFD R13!

continue
  ; now in non-secure state

Accessing the SCR in non-secure state will abort, so you could use that as a way of testing whether it worked or not.

You’ll also have to double-check which CP15 registers are banked between secure & non-secure state, as there’s probably some configuration that will need re-applying.

Spent the entire night with this. There are problems with hw access in insecure mode. MapInIo doesn’t work. It might be that the ram is added in secure mode. I am going to research a bit more tonight.

There are probably security settings on the bus/interconnect controller, or maybe on each device, to restrict peripherals from being accessed in non-secure mode.

Perhaps yes. The trm doesn’t cover running in non-secure mode.

Happy day! I skipped the switch…

The problem was silly simple. The Interrupt HAL added 32 to all my IRQ numbers!

*time
Thu,01 Jan 1970.12:30:35
*basic
ARM BBC BASIC V © Acorn 1989

Starting
with
536834300
bytes
free

>PRINT TIME
4218

Well done! #applause :)