RK3288 initial rants

Michael can you confirm that the text output you are reporting is via the serial port output?
I can easily imaging some people reading this thread assuming the HDMI display is working!

Michael can you confirm that the text output you are reporting is via the serial port output?
I can easily imaging some people reading this thread assuming the HDMI display is working!

It is serial port output, it’s hard to paste from HDMI. But I am not far from HDMI now, it will come in some days.

USB will take some more time probable , but I have a plan.

I have a question. When I map in memory ,,, Right now I store the logicals in pointers stored in StaticWS. That seems to work for a couple of things, but not for my HDMI controler. I have a test at the end of my Video_Init where I write to a safe place in the controller. If I boot up and use tehe *memory p tool I cannot see anthing in that address..
Also if I try to use DebugReg to print logical addresses the system hangs.

Are you sure that the HDMI controller has its power + clocks enabled?

Yes I think so. The register in question doesn’t need anything before write. I just tried it in s.TOP before MMU and wrote to the physical address and that worked. I can see the value with *Memory. So the only thing I can think of is that the mapping to logical is wrong.

I have also tried to hardcode the logical to 0×0. It gives the same result. I guess it would have crashed the system, right?

Double-check that your parameters to OS_MapInIO are correct (e.g. you usually want a1 to be zero), and that you’re applying the correct offset to the logical address that’s returned.

Because IO memory is mapped in 1MB chunks, the low 20 bits of the logical address should match the low 20 bits of the physical address. So if you print out the logical address of the register it should be easy to spot if you’ve got a wrong address offset somewhere.

E.g. if you ask OS_MapInIO to map in physical address &12345678, it will return with something like &F8D45678 – only the top 12 bits of the address will change. So if you’re not careful you might be applying some of the offsets twice.

I have also tried to hardcode the logical to 0×0. It gives the same result. I guess it would have crashed the system, right?

Yeah. Development ROMs use high processor vectors by default, so the low 16K of the logical address space is unmapped. Perfect for catching bugs when working on new hardware ports :-)

GAH! I think I have found the root cause of all evil, and I can’t solve this riddle..
If I address a hw register like this:
LDR r0,=ADDRESS
MOV r1,#VALUE
STR r1,[r0,#offset]

I get value in address + offset ..

However if I do like this.. (really needed in the driver)

LDR r0,=BASE_ADDRESS
ADD r0,r0,#BASE_OFFSET
MOV r1,#VALUE
STR r1,[r0,#REAL_OFFSET-BASE_OFFSET]

I don’t get VALUE :( This has to be something simple and I am beginning to feel really stupid :)

don’t get VALUE :( This has to be something simple and I am beginning to feel really stupid :)

Solved , hrmf needed to write with STR to 8-bit registers :/

Since I need to use STR to access 8 bit register I wonder,, How does STR truncate values?

Since I need to use STR to access 8 bit register I wonder,, How does STR truncate values?

I think that depends upon the memory system. I think one (IOC? RiscPC?) used to duplicate it as 16 bit values (so a word would have ?2 = ?0)…

Question I have – can you not use STRB with only word aligned addresses?

Question I have – can you not use STRB with only word aligned addresses?

No. Dunno why but everything is connected to a 32 bit bus , thats the only explanation I got.
My main issue with the HDMI controller is that I need to split a 16bit to two 8 bits and write them with STR. That fails somehow and I am thinking if my shifting is wrong based on what I need for STR,

My main issue with the HDMI controller is that I need to split a 16bit to two 8 bits and write them with STR.

Aha, a low byte and a high byte.

And you’ll have registers like 0, 1, 2, 3, etc?

I remember from hacking the parallel port a long time ago, that I used the registers as numbers offset from the base address, but as with your video code, it was an eight bit value on a per-word basis.
So the calculation was base_address + (register << 2), so if we say the base is &8000 (for sake of argument), counting up from register 0 to register 4 would yield the addresses &8000, &8004, &8008, &800C, and finally &8010.

Memory tends to be arranged in this annoying way because often (in the older days, at least), some registers were read sensitive – reading the interrupt status register may clear the interrupt state, so it was better to read only that which was wanted, and not have stray reads. Likewise, for writing, do you want to write a byte to a register, or fart around making sure you don’t corrupt other registers as collateral damage (plus, there may be write-sensitive registers). All in all, it was just logical to have “one register is one integral memory access”.

So when you have the address calculated correctly, try writing with STR and the desired byte in the low byte.

That said – can you read the registers or are they write only? If you can read them, then looking to see what you read can provide help in knowing if your calculations are good. Plus it’s probably less bother to read wrongly than to write wrongly.

There was a datasheet I was reading a long time ago that numbered its registers from one. I spent a lot of time wondering why a broken thing was very broken until reading back the registers indicated that a one register was behaving like another and… yup… code counted from zero, datasheet counted from one. Some Tipp-Ex and a magic marker allowed me to quickly debug the datasheet. ;-)

I think Rick is correct. On the iMx6, the HDMI TX registers are all 8 bits wide, and they’re at 1 byte intervals. The RK3288 manual suggests that they’re still 8 bits wide, but they’re placed at 4 byte intervals, with the relevant 8 bits probably being in the low part of the word (and hopefully the high 24 bits are ignored).

When writing 16-bit or wider values, the iMx6 HAL breaks them down into 8-bit writes. The same code written for the RK3288 would look something like this:

ldr     a2, HDMI_Log
add     a2, a2, #0x1000*4 ; i.e. base of frame composer registers (HDMI_FC_INVIDCONF)
str     a1, [a2, #(0x1001-0x1000)*4] ; HDMI_FC_INHACTV0 offset from HDMI_FC_INVIDCONF
mov     a1, a1, lsr #8
bic     a1, a1, #3<<5
str     a1, [a2, #(0x1002-0x1000)*4] ; HDMI_FC_INHACTV1 offset from HDMI_FC_INVIDCONF

If you want to use the iMx6 register definitions as a base then it’s probably best to edit the definitions so that they’re all multiplied by four, then you can just use the symbolic names as normal and only have to worry about swapping LDRB/STRB for LDR/STR. Easy enough to do with a text editor that allows you to edit multiple lines at once, or maybe with some search and replace.

Jeffrey, I have done all this, except that I shift the addresses in order to make them x4.
The problem is the i2c write to the phy. They all fail. The error bit is set in the IH_I2CMPHY_STAT0 and dunno why in the DDC i2c register.

So my question was about that i2c write. If you look in the i.MX6 code you can see that it splits into two 8 bit STR.
I have tried to use DebugReg but it just freezes ( not in front of the computer right now, but I might by mistake calling the physical address in that function :) )

Anyway I can see that DATA0/1 contains the last written values with *memory when the system starts up.

Anyway I can see that DATA0/1 contains the last written values with *memory when the system starts up.

Well if you can see the right values in the registers then it’s safe to assume that you’re writing them correctly. So the problem must be elsewhere.

• Is it possible the power to the PHY isn’t enabled?
• If you’ve copied the iMx6 code, does your HAL_CounterDelay function corrupt register a3? APCS functions are allowed to corrupt a1-a4 and ip, but the iMx6 code is written under the assumption that the HAL_CounterDelay call won’t corrupt a3.

Is it possible the power to the PHY isn’t enabled?
If you’ve copied the iMx6 code, does your HAL_CounterDelay function corrupt register a3? APCS functions are allowed to corrupt a1-a3 and ip, but the iMx6 code is written under the assumption that the HAL_CounterDelay call won’t corrupt a3.

It should be powered, but of course hard to tell. A3 in this context is used as a delay timer index. However my problem comes instantly. The error bit is 1. I will go to a big computer party over the weekend , so my stuff is packed up (weekend starts tomorrow).. I will spend my time with risc os on the party! Now why don’t I have a RISC OS t-shirt????!! :)

I will start with fixing DebugReg so that I can start printing registers. After this I should be able to track down things better ( see if its powered perhaps..) I have been talking a lot with a Rockchip guy who has been extremely helpful. Mostly regarding the relation between the VOP and the HDMI TX. HDMI is clocked from the VOP, and VOP is way easier to setup than IPU’s on i.MX6.

No success so far. I fixed the debugreg function and the fact that I forgot to use STR (and not strb) in bitwrite. I still get the error bit set from i2cwrite.

Odd.. Both i2c done and error are set..? and for the power. The poweron signal (bit 3) is set in PHY_CONF0. But bit 7 is not set and it is active low.
I wonder if this means that the poweron signal is stuck somehow.,,,

If I use STRB in i2cwrite I get zeros in the registers and nothing in the status register
IN u-boot the hdmi driver uses WRITEL ( address = (u32) value) , and with gcc that translates to STR
But in the i.mx6 driver (u-boot/hdmi) it goes to WRITEB → STRB

Offsets are the same , except that RK always writes with offset * 4.

I just got serial line between the developmen machine and the RK up. Much easier to debug when I don’t need to switch machines in order to use the debug console.

GAH, this give me no excuse for not rewrite HDMI :/

Btw is there a way to paste in Connector?

i2c errors solved, but still no video. Jeffrey, In the i.MX6 code, when does the monitor get sync? Does it from Video_init or is it when the IPU starts to put pixels on it?

The HAL hardcodes a startup mode. Is that actually made to sync or .. ?

Jeffrey, In the i.MX6 code, when does the monitor get sync? Does it from Video_init or is it when the IPU starts to put pixels on it?

I think it’s the call to ips_hdmi_stream (from Video_init → InitVideoMode → ReInitVideoMode) that causes everything to start working. I’d assume the video signal starts immediately, but maybe there’s a bit of a delay, I’m not sure.

The HAL hardcodes a startup mode. Is that actually made to sync or .. ?

The mode that’s programmed by Video_init? I don’t know if that has any practical purpose – it’s probably just leftovers from early prototype code.

HAL_VideoStartupMode? I believe that’s used because John’s monitor didn’t like the default mode that the RISC OS kernel was trying to use.

I think it’s the call to ips_hdmi_stream (from Video_init → InitVideoMode → ReInitVideoMode) that causes everything to start working. I’d assume the video signal starts immediately, but maybe there’s a bit of a delay, I’m not sure.

OK. Thats how I do it now, enabling HDMI out from VOP. I was thinking if the phyconfig part actually kicked life into the monitor.

HAL_VideoStartupMode? I believe that’s used because John’s monitor didn’t like the default mode that the RISC OS kernel was trying to use.

hehe

str a4, [v4, #HDMI_MC_CLKDIS<<2 – HDMI_MC_CLKDIS<<2+4 ]

I have the above line and every other reference to HDMI registers looks the same. In which order does ObjAsm calc out the shifting, substraction and addition? I have done a simple test:

10<<2-4 – 2<<2

That works.

I assumed for a while that the HDMI part of the code worked. So I wrote the very boring code that clocks the VOP based on the current pixelclock. But since it did not help (although needed) I am now back on the HDMI part. I tried with adding paranthesis to every register access, but then I got the i2c error again. This is why I need to know about if the above STR really would work. It was the CLKDIS handling that sorted out I2C errros in the first place. (adding paranthesis around the addition)

str a4, [v4, #HDMI_MC_CLKDIS<<2 – HDMI_MC_CLKDIS<<2+4 ]

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