help Top(HAL) doesn't start

I am stuck , and I don’t remember how I did it last time. I have built the image with the standard tools , and fired it up with u-boot. It doesn’t reach Top in HAL at all. Is there some special requirements on where the image should be in memory? Hints are most welcome.

What machine do you have? How you did what last time? Which version of u-boot? Hints are all you will get!

Start with the recommended SD card image that is known to work. Alter one thing at a time. Monitor what is happening on a serial terminal. Post the results in enough detail so that someone can help with an explicit comment about exactly where the problem lies.

This is on target IMX53 ,so I guess there are no more details.. I have checked the Top and Debug with GDB and they work (except from calling kernel ofc). So the question is still , is there any particular step that needs to be done when running it. I do fatload image address;go address. Is there some magic offset that it should start from. I have probed the target with openocd ,and it does nothing , just stops. I don’t know if there been any changes to this. Last time I had this work was two years ago , and I can’t remember if I did anything special.

Someone clever will be along shortly to tell you how it really works, but I believe if you’re using the OMAP3 HAL (as I think you suggested in an earlier post), there’s a jump table at the start of the image to determine the board type. If you fatload at ‘address’, you might have to jump in at ‘address + 8’ to make the HAL do various things correctly for your machine type. I also have a feeling there’s a special offset you can jump in at to say the board type is being passed over as a U-boot environment variable, but I’m not sure. As far as I remember, it’s pretty understandable by looking at the source.

Anyway, like I said, someone clever will be along shortly! ;)

If you fatload at ‘address’, you might have to jump in at ‘address + 8’ to make the HAL do various things correctly for your machine type. I also have a feeling there’s a special offset you can jump in at to say the board type is being passed over as a U-boot environment variable, but I’m not sure. As far as I remember, it’s pretty understandable by looking at the source.

OK The odd thing is that it used to just work :) I have tried to put a fake Top that does nothing then printing to the serialport. It doesn’t start so it has to be somehow in a offset that is different from start address. Anyway setting up Beagle now for development replacing VRPC if it works :)

There’s not much that could be going wrong with a simple ‘fatload’ & ‘go’. Have you double checked with a disassembler that your serial port test looks OK? (e.g. no extra headers have appeared at the start of the file and are causing the machine to crash straight away)

In fact, one thing which could be causing problems is the way that romlinker pokes the ROM size into a location near the start of the ROM image. This can be disabled by adding a ‘%noimagesize’ line near the start of your components file (see the OMAP3 components file for an example).

Phew:

MX53-LOCO U-Boot > go 0×70800000

1. Starting application at 0×70800000 …
   *IMX53 HAL init*

:D \o/

BTW: I have tried to build on beagle now ,but the buildtool gives me postmortem errors..

Sigh back to GDB , but at least it points out the exact place where the code crashes :) Very useful. Crash in the early copy routine. I don’t know how to perform DMA copy ( or at least not for this) so I based my copy code on the rpi hal. It fails right after the first “copy”. According to the disasably it should branch back to the right address , but PC ends up in 0×0 == crash. The real fun begins now :)

Quick status:

Addram fails or so I believe because the ram test at the beginning of OS_Start fails..

I am now past the the status I had when my harddisk fails , I am somewhere in the middle of OS_Start :)

Stops in this, no clue why :( :

Examine HAL and RISC OS locations
LDMFD sp, {v4,v5,v6} ; v4 = flags, v5 = RO desc, v6 = HAL desc
LDR lr, [v6, #HALDesc_Size]
LDR v7, [v6, #HALDesc_Start]
ADD v6, v6, v7 ; (v6,v8)=(start,end) of HAL
ADD v8, v6, lr
LDR v7, [v5, #OSHdr_ImageSize]
ADD v7, v5, v7 ; (v5,v7)=(start,end) of RISC

Exactly here :
ADD v8, v6, lr <— this adds up to the end of hal , right?

That’s a bit of an odd place for it to stop. Are you sure it’s not your debugging lying to you? I’d expect it to stop on one of the LDR’s, due to either v5 or v6 being garbage. Double-check that the parameters to OS_Start are correct. Remember that the wiki has plenty of documentation on the HAL if you get stuck. Also you might want to try disabling the copy/relocation code to keep things simple for now – the OS will usually run no matter where the ROM image is located, and OS_AddRAM should be capable of subtracting the ROM image from the RAM list if you haven’t done it yourself.

Thanks. I missed a entry in HALdescriptor. Now it stops a little bit down .. The documentation talks about a riscos header as a argument to OS_Start. I have followed the other hal’s and passes HAL_Base+ OSROM_Halsize to a2. The crash is now in the mmu activation code ..

I am still stuck.. :( I have now tried to use the whole boot process of OMAP3 , except from skipping relocation and changing the ram addresses , uart etc.. . Hangs on mmu or so I believe..

Now raFS crashed on me :(( , back to square one. I really hope to be able to build on beagle soon.

Hangs on mmu or so I believe..

Do you have the complete data sheets for the device in question? It seems to me that while the genetic ARM MMU is fairly standard (but evolves/changes with ARM family), there can be vast differences between what the processor is connected to. Double-check that the MMU code is actually doing what you think it is doing.

Oh well , without my custom code that went away with raFS , I don’t even reach mmu code. I have almost managed to build on beagle , just waiting for cmos widget to make timestamps work :)

Phew ,It builds on beagle now … :) and I am backing up everything to my NAS with !Sunfish. I hope to be able to build it over NFS .. crossing fingers

I am losing faith!! Before the raFS crash I had OS_Addram working OS_Start , semi working. Now when I have restored some files from lost+found , not even addram returns. Let me see if I got it right..
Gahh getting mad ! ;D

Parameters for Addram:

A2 , pointer to ramstart A3 ram end A4 flags ,SP moved

Back on track a little , addram returns and I get into OS_Start.

Fails right here:

ARM_write_control v5

What does this macro do?

What does this macro do?

;set control register
        MACRO
        ARM_write_control $reg,$cond
        MCR$cond ARM_config_cp,0,$reg,ARM_control_reg,C0,0
        MEND

Found it here.

Breaking this down: MCR CP15, 0, R8, C1, C0, 0.

From the original ARM ARM, what’s in R8 would be:

• bit 0 = MMU (0-off, 1-on)
• bit 1 = Alignment fault (0-disabled, 1-enabled)
• bit 2 = Instruction/data cache (0-disabled, …)
• bit 3 = Write buffer (0-disabled, …)
• bit 4 = 0 for 26 bit exception handlers, 1 for 32 bit
• bit 5 = 0 for 26 bit address checking, 1 for 32 bit
• bit 6 = IMPLEMENTATION DEFINED (L)
• bit 7 = 0 for Little Endian, 1 for Big
• bit 8 = MMU protection (system)
• bit 9 = MMU protection (ROM)
• bit 10= IMPLEMENTATION DEFINED (F)
• bit 11= IMPLEMENTATION DEFINED (Z)
• bit 12= Instruction cache (0-disabled, …)
• bits 13+ should be written as zero.

My later ARM ARM is in the other room, however it might pay to look for the exact settings of CP15 for the device you are using, and then look for the value set in R8.

Are you using JTAG? It may not be the instruction failing. You might be doing something like asking for the MMU to be switched on while the MMU tables are incorrect (result = bang!). Some side effect action like that.

The datasheet I found wasn’t too helpful; however it claims to be a Cortex-A8 so ought to be compatible with OMAP3 code…

Gah , can’t find it anywhere. Question sent to Freescale. As far as I can see it should follow the standard.

OK time for a update:

I have made a small elf out of the assembler that kicks life in the mmu (from u-boot). I have only to test it with jtag.

I have a new shiny ARMini and the XM in it is a lot better than my original beagle. Excelent casing , and a nice collection of software. This gives me no excuses ( apart from demanding job projects) to strugle on with the i.MX port.

Excelent casing…

Please, I like to develop;-)