[U-Boot-Users] Problems porting U-boot to custom board

[michael.firth at bt.com]

> -----Original Message-----
> From: Jerry Van Baren [mailto:gerald.vanbaren at smiths-aerospace.com] 
> Sent: 23 March 2007 17:49
> To: Firth,MJC,Michael,XGH35 R
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Problems porting U-boot to custom board
> 
> 
> 
> :-D  Methinks that will change. 
> <http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=R
> EADME;h=15428643edef7ea77710113f8908002b50328577;hb=HEAD#l3583>
> or 
> <http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=R
> EADME;h=15428643edef7ea77710113f8908002b50328577;hb=HEAD#l3639>
> 

I was slightly concerned that the README file doesn't seem to be
completely up to date - for example, under the 'directory hierarchy'
section there is no reference to the 'mpc834x' family. 

I have read most of it as a general guide now, but, at 52 pages of plain
text, it can be slow going. Are there any plans to split the Readme in
to sections?

Also, what is the difference between the two links you posted?

> > I guess this leads me to four initial questions:
> > 1) Is there any obvious gotcha that I'm likely to have fallen in to 
> > that would cause this behaviour?
> 
> Are you running out of RAM rather than booting from flash or 
> does your 
> BDI2000 config file do RAM set up and memory map set up?   If 
> so, that 
> is most likely your problem.  The prior instruction:
>   174         bl map_flash_by_law1
> is mapping flash everywhere, so if you are running out of RAM 
> or if your 
> memory map isn't reset-virginal, you just mapped bogus flash 
> instead of 
> your program.  My mentor from way back had a term for this: "you just 
> sh*t the nest."

I was running out of Flash, but, you were right, the BDI2000 config file
was doing some processor configuration. I didn't expect that to cause
too many problems, as I would have thought that U-Boot would undo what
it had done, but I have moved to a simpler BDI2000 config file which
doesn't do any pre-configuration, and the problem has now changed.

What I'm now seeing is that as soon as U-Boot enables the Machine Check
Exception (function 'cpu_init_f' in cpu_init.c) the processor reboots. I
guess my challenge now is to understand what conditions can cause the
machine check, and work out which one it is, and why.

> 
> > 2) Given that this is an old version of U-boot, I'd like to 
> move to a 
> > more recent version. How difficult is it likely to be to port the 
> > board support from u-boot-1.1.4 to the latest recommended version?
> 
> Shouldn't be difficult, but level of difficult and level of 
> expertise in 
> the porting process are inversely proportional.
> 

I'll probably give that a go, once I get to the end of the pain of
getting our board running and migrating that to the latest U-Boot,
migrating the Embedded Planet board over should be fairly easy by
comparison.

> > 3) What is the latest recommended version? - I've seen 
> references on 
> > here to V1.2.0, but the latest available from the FTP area is 1.1.6.
> 
> Buy yourself a copy of git (that is a joke) and use it to get 
> the head 
> of the development tree.
>    <http://www.denx.de/cgi-bin/gitweb.cgi>
> As a bonus that cannot be overstated, it also gives you 
> source control 
> over your local changes. <http://www.kernel.org/pub/software/scm/git/>
> <http://git.or.cz/> 
> <http://www.kernel.org/pub/software/scm/git/docs/everyday.html>
> <http://www.kernel.org/pub/software/scm/git/docs/tutorial.html>
> 

I guess a question that follows on from that is, if I use the head of
the development tree, how do I keep it current, so that I don't wind up
running some unsupportable interim version between V1.2.0 and V1.2.1 -
is that a job that getting to grips with GIT will help with?

> > 4) If I do manage to port the Embedded Planet support in to 
> the latest 
> > U-Boot, would I be able to push that upstream, and, if I 
> did so, would 
> > I have to support that code?
> 
> Yes and no, but it would be appreciated.  ;-)
> 
> > Thanks in advance
> > 
> > Michael Firth
> 
> Good luck,
> gvb
> 
> P.S. I'm loving gitweb, can paste mysterious urls for the 
> poor reader to 
> click into. :-D  Slow news day here at work. ;-)
> 
Indeed! I'm happy to have mysterious URLs when they contain useful
information.

Thanks for your help so far

Michael