RK3288 initial rants

Yuck. Regardless of the order of operator precedence, that line of code is crying out for some clarity adding brackets!

I did that and things started to break! Hence my questions…

My point is that since there was this I2C error, there could be more errors like that.

In which order does ObjAsm calc out the shifting, substraction and addition?

The operator precedence rules are explained in the manual (However you might need to read the full section to make sense of it all – if you skim through this page from an older manual then you’ll find it’s very easy to miss the information. I’m not sure if the latest ROOL manual is any better, I didn’t have enough time to check last night)

In summary, these are all equivalent:

str a4, [v4, #HDMI_MC_CLKDIS<<2 – HDMI_MC_CLKDIS<<2+4 ]
str a4, [v4, #HDMI_MC_CLKDIS :SHL: 2 – HDMI_MC_CLKDIS :SHL: 2+4 ]
str a4, [v4, #(HDMI_MC_CLKDIS<<2) – (HDMI_MC_CLKDIS<<2)+4 ]
str a4, [v4, #4 ]

(When reading the manual I did think that maybe there’s a bug where << is handled with the same precedence as the comparison operators, but that doesn’t seem to be the case)

Ho and hey!

I have been taking a long break from all this but I think I am ready to restart HDMI from scratch.

Currently stuck in:

Not getting lock on phy.

Another note is that tinkerboard comes with a pmic that needs to be configured to power hdmi. Fixed this from u-boot. pmic communicates with i2c and it is trivial to implement later on.

I get the lock now! BUT… As soon as I switch the monitor to hdmi input I loose the connection. The HPD bit goes 0 and no RXSENSE in the same register.

Can this behaviour exist on i.MX6? Any clues what it might be?

EDIT: With a different interupt mask I get the SENSE bits, but still no HPD.

EDIT2: HPD is alive.

No picture.

I think one of the stumbling blocks I ran into when trying to get HDMI working properly on the IMX6 was working out the correct way to program the display timings – they needed to be programmed in both the IPU “DI wave generator” and the HDMI controller, but the correctness of the HDMI settings didn’t seem to matter unless it was a HDMI signal which was being generated. So things worked in DVI output mode but failed in peculiar ways in HDMI mode.

See here for the code in IMXVideo which translates from the VIDCList timings to the DI/HDMI timings.

I think one of the stumbling blocks I ran into when trying to get HDMI working properly on the IMX6 was working out the correct way to program the display timings – they needed to be programmed in both the IPU “DI wave generator” and the HDMI controller, but the correctness of the HDMI settings didn’t seem to matter unless it was a HDMI signal which was being generated. So things worked in DVI output mode but failed in peculiar ways in HDMI mode.

I have reworked mu clock code, putting hard coded values that I calculated with C based on the pixel clock. I have tried both HDMI and DVI mode. I think I got the setup right now so I except power to be the issue. Btw do you know if FC_DBGFORCE works without IPU pixels?

One thing that was a bit interesting: I only have one monitor on my desk and a kvm swith for dvi. The monitor also got HDMI so the RK board is in that HDMI port. The kvm switch is connected to ARMX6 and PC.

If the RK is powered on with RISCOS and the PC goes into display powersaving the monitor switches to HDMI. It could mean that something is coming out from the board.

While not sortig out HDMI (waiting on some input) I ventured into USB. The RK3288 has a standard EHCI controller.

How can I debug the EHCI module? Is printf available .
I get data abort :)

How can I debug the EHCI module? Is printf available .
I get data abort :)

Calling the (non-rentrant?) VDU subsystem when you’re probably in IRQ mode… Um… ;-)

Probably best to see how the HAL serial device works and output via that, or maybe DADebug etc?

Jeffrey – how do you debug the low level stuff?

Jeffrey – how do you debug the low level stuff?

Conveniently, I’ve recently been writing a wiki page about debugging.

https://www.riscosopen.org/wiki/documentation/show/Debugging%20guide

USB debugging is one of the more annoying ones, since you might not have any way of interacting with the system when things start to go wrong. There are some notes on debugging on the USB stack overview page, so I’d recommend that you follow those:

• Make sure you’re building debug versions of the modules
• Configure them to log to DADebug (look for the debug_set_device call in the module init functions)
• Make sure DADebug is in the ROM
• If the machine is stuck in a loop, make use of DADebug’s TickerPrint option
• You’ll probably want DADebug configured to use HAL_DebugTX as well
• Mess around with the *USBDebug, *EHCIDebug, etc. command line options to tune the detail of the USB driver debug output

If TickerPrint isn’t working then possibly the system is stuck somewhere with IRQs disabled (or stuck in an abort loop), which is where HangWatch comes in (but that will require you to be able to support mapping timers to FIQs).

If things are failing with data aborts, then you can also have a play with the Debugger exception dump facility.

Make sure DADebug is in the ROM

Is it sufficient just to add that (and DebugBtn) to the components file when building a ROM? Is it okay at the end, or should it go in sooner?

With DADebug you’ll generally want to make sure it’s located before whatever’s using it, since some modules/code might only look for it on startup and not bother looking again later on.

DebugBtn I haven’t really looked at. Since it’s Wimp based, it probably needs to be located after the Wimp.

If debugging USB modules in ROM DADebug needs to be initialised before the USBDriver in the HAL – I don’t think it matters where it goes in the rom. If you want to use HAL_DebugTX ensure the rom doesn’t load any serial modules as they reconfigure the serial port and stops HAL_DebugTX.

USB outputs lots of useless rubbish by default so the first thing you’ll probably need to do is comment out lots of dprintf statements or as a minimum the output from the bsd_fns.c file for the controllers and port.c for the usbdriver otherwise the bit you are interested in will soon disappear from DADebug’s circular buffer.

There are ways of removing some of the output by reading the debuglib stronghelp manual – in the sources – but not all.

Thank you for your answers!

IT crash on (*usb_ca.ca_attach)(0, softc, bus); from usbmodule. (Division by zero)
Where goes that functionpointer?

GAH. My timers! What is the relation between counterperiod and readcounter?

usb_ca.ca_attach is ATTACH(usb) in dev.usb.c.usb which calls usb_needs_explore_callback in build.c.usbmodule.

GAH. My timers! What is the relation between counterperiod and readcounter?

The period controls how frequently the timer generates interrupts – the interrupt rate will be granularity/period Hz

ReadCounter returns the count of how many ticks (in units of granularity) until the next interrupt is generated.

Ok. My problem now is that ReadCounter doesn’t return ( or I don’t think it does.)

It enters from gettime in usbhal.

EDIT. I don’t know where it halts. It does halt when using the counter hal functions, from that “attach” call. But I can’t find exactly where…
The Timer hal gives its TIMER_LOAD value as Period and the current value → read. Looks good to me, at least it gives good numbers.
’

EDIT2 IS the RTSupport module needed? It just halts with it enabled.

It is obvious now that the Timer hal functions in question doesn’t return. Just like LR is set to something bad….
The odd thing is that CounterDelay woks and returns… BUT that is form within the HAL:..

:/

The c code i want to use is a JUST FOR TEST a piece of code from core boot. I simply need to find out if clocking is my problem .
I don’t know yet if it works because the npll doesn’t lock. If it makes the trick I will go back to my assembler code and try to fix it. I wonder , is there a code for calculating clock divisors? I have a hard time doing it.

I am more worried about that timer Hal functions doesn’t return from swi calls! Any hints?

FIxed the c code , it locks now.. No luck .. :(
So either PHY or power…

I have SYNC and a color display!!

I need to know how the videomodule tells the video processor where the framebuffer is… Is this vdu_init?
For the first test I am willing to skip all features on different modes etc. Just update the framebuffer pointer to (hopefully) finally see some graphics on screen.

I found the issue of HAL not returning. I had debug in it and that screwed up LR. Fixed that and timer hal seems functional.
I went back to EHCI and I got a bit further. Timing is a issue that I probably can sort out. Right now it stops when it tries to construct bus name
(sprintf(name,Module_Title … etc )

Ok So EHCI runs thru without errors! BUT after some point all output to the serial port stops in that thread. There are some debug I have from the kernel printed.
I know it calls irq enable like 15 times before it gives up, but I don’t know from where.

The output stops right after ONE character is printed.
The problems starts after “register bus”, all output stops after that point. The IRQEnable call is from chmg module init. Always the same number (4d, the roothub?).

It is OS_WriteS that stops working. DebugTX in itself continues to work.