It turns out that I have to pass parameters to the linux kernel. I
have to do the jump as following:
entryPoint = (void *) 0x8036a000;
entryPoint(2, args, NULL);
If I am using entryPoint(), there will be exception in the early stage
of linux kernel. I still don't understand why this works. When I use
BDM to jump to 0x8036a000, there is no parameter passed in.
On Mon, Dec 1, 2008 at 1:53 PM, Phil Staub <firstname.lastname@example.org> wrote:
> On Fri, Nov 28, 2008 at 08:42:33PM -0800, mike zheng wrote:
>> I am doing development on a MIPS32 processor. However it failed to
>> boot when I try to use a boot loader to start the kernel in the
>> memory. The boot loader uses following command to jump to kernel entry
>> point in the memory:
>> entryPoint = (void *) 0x8036a000;
>> I confirm the kernel image is able to boot up. Using JTAG debugger. I
>> set PC to the entry point of memory 0x8036a000, the kernel boots up. I
>> also disable the Cache before the jump.
>> Any idea on this issue?
> I ran into something like this several years ago on a Malta board that
> behaved differently when the OS was started from JTAG compared to
> In that case there were control registers that allowed relocating the
> base addresses of many of the control registers. The board registers had
> reset/power up values that the kernel startup code assumed was in
> effect, which worked fine with the JTAG debugger, especially if it
> (the debugger) doesn't touch the control registers before jumping into
> the code.
> But the YAMON boot loader re-programmed the base address of several of
> the peripherals and I beleive even the DRAM controller, so the kernel
> startup code was trying to initialize the registers at the reset
> addresses, but those registers were no longer there.
> If this is the case, you'll have to determine a) which registers have
> been modified by the bootloader, and b) what they have been changed
> to. Then, (hopefully) you can use the JTAG debugger to program in
> those register settings each time it resets the chip. In short, you
> need the initial execution environment to be equivalent whether you are
> starting it from the debugger or from the bootloader.
> Phil Staub, Senior Member of Technical Staff, Wind River
> Direct: 702.395.WIND (9463) Fax: 702.365.WIND (9463)