From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Fri, 23 Mar 2007 13:49:06 -0400 Subject: [U-Boot-Users] Problems porting U-boot to custom board In-Reply-To: <9B595346504D314DA4936056A3E156EB869481@E03MVX3-UKDY.domain1.systemhost.net> References: <9B595346504D314DA4936056A3E156EB869481@E03MVX3-UKDY.domain1.systemhost.net> Message-ID: <46041312.3050602@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de michael.firth at bt.com wrote: > Apologies for the Newbie question, but I'm not really sure where else to > ask about this. > > We've designed a board based around the Freescale MPC8343 processor, and > are trying to get U-boot running on it. > > We have used an Embedded Planet evaluation board as the starting point > for our design. Unfortunately it seems that, although Embedded Planet > have ported U-Boot to their board, they haven't pushed the files to > support it upstream. Thus the only version of U-Boot I have that will > support this evaluation board is 1.1.4, which I know is ancient. > > The system seems to be freezing very early on in the boot process (line > 171 of the mpc83xx start.S file) while it seems to be doing some flash > remapping operations. What seems to be happening, using GDB and an > Abatron, is that it gets to this line, and then 'teleports' to a > function called 'hung()'. > > The specific line that is giving the problem "lis r4, > (CFG_MONITOR_BASE)@h" looks to just be loading a register with a value, > but I don't really know PowerPC assembler. :-D Methinks that will change. or > 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." > 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. > 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. As a bonus that cannot be overstated, it also gives you source control over your local changes. > 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. ;-)