You have a load address and entry point of 0x0. You can't load and run Linux at 0x0. Try something more sensible like 0x400000.

The image that comes with the board (and boots fine) has the load and entry addresses both set to zero...

The image I'm trying to use is generated by running 'make pImage' in the kernel tree, and that's how it's generated...

Am I doing something wrong?

Andy

Hi,

Guys, don't confuse the load address of the pImage with the

*download

address*, ie. the one used for tftp. Your setting of 0/0 for the

load

address and entry point is correct.

Thanks for clearing that up, I thought I was building the image correctly.

However, from your initial post I gathered that your MV kernel does not have BSP support for your hardware. It is unlikely that a simple adaption of the boot info structure will be sufficient. Check out

the

relevant files in arch/ppc/{platforms,kernel} as well as the

configure

options in arch/ppc/config.in and look for things specific for your board.

That's correct, there is no standard support for this board in MV.

Can anyone give me some pointers as to where to place breakpoints in the kernel to try to work out where the startup code is going wrong? As you've probably guessed, this is all a bit new to me.

Many thanks.

Andy

In message 001501c3fae5$0545a150$333335bf@cabletime.com you wrote:

The image I'm trying to use is generated by running 'make pImage' in the kernel tree, and that's how it's generated...

Am I doing something wrong?

No - except from using the wrong kernel tree.

Best regards,

Wolfgang Denk

From: wd@denx.de [mailto:wd@denx.de] Sent: Tuesday, February 24, 2004 10:35 AM To: Chuck Meade Cc: Andy Hawkins; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Problems with u-boot, PPChameleonEVB and MontaVista kernel

In message IIEEICKJLNEPBBDJICNGKEBMEMAA.chuckmeade@mindspring.com Chuck Meade wrote:

...

You have a load address and entry point of 0x0.

...which is perfectly fine on PowerPC.

...

You can't load and run Linux at 0x0. Try something more sensible like 0x400000.

Chuck, you are wrong. Load address and Entry point of 0x0000 are OK on PowerPC.

Best regards,

Wolfgang Denk

Yeah sorry about that, I was thinking one thing and typing another. I have seen so many times people downloading to 0x0 and stomping their ppc vector area, that I answered without paying enough attention to what Andy actually wrote.

I agree with Marius that the platform support code from the other board is most likely not going to work unmodified on this board. You (Andy) need to actually port the kernel to your target -- i.e. each target has target-specific support that is required. If you are having trouble bringing up the low level startup code I would also suggest acquiring a BDI2000, it can be a real help in such situations.

Chuck

Is there any special reason to use their kernel? What does it

contain

that you cannot find in DAVE's / our tested and working kernel tree?

Well, we've decided to use the MontaVista distribution / development environment, and that integrates nicely with their kernel build tools. There may well be features that are present in the MontaVista kernel tree that we would like to use too (although I'd have to check the details). I think the general feeling is that having one source for all this is the best way to go (if we can get it to work).

You have to accept the fact that "similar" is not good enough.

You

must use a kernel which has been proted to the _exact_

matching

board, or you will run into problems sooner or later - at least

if

you don't understand EXACTLY what you are doing (which seems not

to

be the case - no offence meant).

You're absolutely right, I don't understand exactly what I'm doing :). No offence taken whatsoever. I've read through most of 'Understanding the Linux Kernel', but unfortunately it only covers the early kernel boot process for the i386 architecture. Is there any other reference that can give more information for the PowerPC?

Of course. You shall break compatibility to the rest of the

world

just to make their kernel work. What a nonsense.

...

I do have access to a BDI2000, that I've used to break into

a running

...

kernel (at start_here), but can't get it to break when I use the MontaVista kernel. From this, I assume that it's failing somewhere very early in the linux boot process.

Can anyone offer any advice?

Your question is a FAQ:

http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKer nel

I've followed the information in that FAQ. However, all it tells me to do is match up the bd_info structures, and check clock information.

What I cannot understand is why you are wasting your time (and

ours) if you

have a working kernel which you can use.

It just seems to make sense to try to keep everything (kernel, apps, development etc.) under 'one roof' (i.e. MontaVista) if at all possible.

I think whichever kernel tree we use, we're going to have to do some porting either way, so I'd appreciate some guidance as to where in the kernel I should be looking to resolve the problems we currently have (as I might need the knowledge gained when we come to adding further customisations later).

We *do* have a BDI 2000, but I think my ability to be able to debug this problem is hindered by my limited knowledge of the kernel startup code.

Any pointers on how to improve that knowledge (URLs, book and the like), with specific reference to the PowerPC processor, would be much appreciated.

Thanks to all who have replied thus far.

Andy

Then you will either have to move all the modifications needed

for

the PPCHameleon board into their kernel tree (thus creating

something

which again is not the original MV kernel), or have MV provide

a

kernel extended in such way.

That's what I'm expecting to have to do, but unfortunately know where to look for the changes I need to make is difficult.

Yes, and this is your most pressing problem. When the

parameters

passed to the Linux kernel are correct you will at least get

some

boot messages, and see where the kernel crashes then (which it

will

do).

Well, I think I *have* matched up the two structures, but we're still not seeing anything. Where can I put breakpoints in the kernel to try to work out why we're not getting any boot messages?

I think you can use another kernel tree (like that from our

CVS

server) without problems. If you feel you must move our patches

into

the MV tree please feel free to do so - all the history and

comments

are available for free on our CVS server. You can extract the

patches

that are relevant for the PPChameleon board and try applying them

to

the MV tree - I don't expect any serious problems there.

At the risk of asking newbie questions, how would I go about doing this?

Thanks again for all the help so far, it's much appreciated.

Andy

I think whichever kernel tree we use, we're going to have to do some porting either way, so I'd appreciate some guidance as to where in the kernel I should be looking to resolve the problems we currently have (as I might need the knowledge gained when we come to adding further customisations later).

We *do* have a BDI 2000, but I think my ability to be able to debug this problem is hindered by my limited knowledge of the kernel startup code.

Hi again Andy, At least this time I read your question more thoroughly :)

We are becoming off-topic for the U-Boot list -- if you want to take this further, switch to the linuxppc list.

I can tell you for a start that you will need to customize your Linux .config file (make menuconfig for example) for your particular target, and you will also want to study the platform-specific code under arch/ppc/platforms. If your target is not currently supported, you will need to create that support. That means *at least* the files under arch/ppc/platforms, and the Makefile and Config.in changes needed in the tree to support selection of the new platform and its features.

I encourage you to do a search of the entire Linux tree (not case sensitive) for a word like "walnut":

find . -type f |xargs grep -i walnut

This will give you a feel for the places that platform-specifics pop up.

Hope that helps, Chuck