booting linux on arm problem

My boot code is located at addr 0x0 and kernel at 0x8000. The boot code initialize uart and print out OK on a terminal correctly, but when it jumps to 0x8000 to start the kernel, the PC was set to

0xEA00009A, which is nowhere in my memory map and caused read abort. The boot code and kernel is supposed to run in the first 64MB DRAM space. I checked the kernel code and found that the kernel died at the vprintk subroutine, but I couldn't pin down the actual problem, I suppose the kernel code should be all right, the only problems should remain with my boot code. The only printout in terminal after OK was
Reply to
Wei Wang
Loading thread data ...

What is your memory map? Means to what address ranges are your flash and RAM mapped?

Juergen

Reply to
Juergen Beisert

Flash mapped from address 0x0 when booting to 0x4000_0000 after booting (16MB). SRAM at 0x4800_0000(32MB). SDRAM mapped from 0x7000_0000 when booting to 0x0000_0000 after booting (64MB), and both the boot code and kernel reside here at address 0x0000_0000.

Reply to
Wei Wang

What does your boot code do in summary ? Is it passing any arguments to the kernel ? Is the number of arguments you specify match with whats on the stack ? Is your flash on chip or on the local/IO bus ?

Reply to
Janaka

This does mean your bootcode is only 32kiB in size? No overlapping between bootcode and kernel in the SDRAM space?

What type of linux image do you try to start? uImage? zImage? What type of bootloader do you are using?

Juergen

Reply to
Juergen Beisert

RAM

The boot code does pretty much the same thing as described here

formatting link
It's legacy code from somebody else, what I don't quite understand is the tagged list in the boot code. which looks like this

ALIGN 256 ; gets us to 0x100 - where Linux expects tags ; to find its boot tags ; 0x100 DCD 0x00000005 ; Size = 5 words, what does this mean? DCD 0x54410001 ; ATAG_CORE, how to determine the value here? I'm not quite sure. DCD 0x00000000 ; Flags DCD 0x00000000 ; PageSize DCD 0x00000000 ; RootDev

DCB 0x00

ALIGN 256 ASSERT . - tags == 256 ; 0x200 DCD 0x00000000 ; Size = 0 words DCD 0x00000000 ; ATAG_NONE - end of list ; 0x208 ALIGN 4 ; 0x208

Just wondering whether there are any resources that I can refer to, in order to understand the boot code better.

Is the number of arguments you specify match with

I'm not entirely sure, how can I find this out?

Is your flash on chip or on the local/IO bus ? I suppose the latter - on the local IO bus, it's connected through static memory controller.

And, what I am still wondering what could have caused the PC change to

0XEA00_009A? there isn't such an address in the entire kernel code.
Reply to
Wei Wang

I think so, the boot loader is only a few hundred bytes.

The image is from sb else, vmlinux.axf (1.4MB), and I will try to find this out whether it is uImage or zImage. The bootloader is just a hundred lines, handcoded

formatting link
booting.php).

Many thanks! -Wei

Reply to
Wei Wang

Found the source code for causing the above problem:

  1. in code start_kernel/printk/vprintk/_spin_unlock_irqrestore, there is a "MSR CPSR_c, r4" instruction which changes the CPSR mode from SVC (supervisor) mode to reserved mode (which is not defined in ARM).
  2. sp and lr values are changed to their values in the reserved mode, which both of them are 0.
  3. the next instruction after the MSR instruction is a pop stack instruction, which pops stack sp at address 0x0, therefore, the
0xea00009a was popped to PC. Still not clear 1) should the processor always be in SVC mode when starting the kernel?
Reply to
Wei Wang

RAM

quoted text -

Do not mistake me. If you clearly understand the problem. Then, that itself will give you a 98% percent answer to your problem.

Karthik Balaguru

Reply to
karthikbalaguru

the

and RAM

quoted text -

Indeed, although I do not want to believe there can even be problems with the processor, but thought it looked very like a processor problem, as a function call saved a certain reg values but popped out different values afterwards, albeit the reg values on stack remained unchanged.

Reply to
Wei Wang

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.