Hi Stefan, Thanks for the quick reply.
> On Thursday 23 July 2009 20:39:44 Wouter Eckhardt wrote: > > I'm working on trying to get VxWorks to boot on a PPC440GX processor > > using U-Boot, using an ALPR board. In order to boot VxWorks properly (it > > expects caching on the SDRAM to be disabled), I created a new board > > directory and such (based on the ALPR board), and then changed the TLB > > settings in init.S. > > Are you sure that the cache needs to be disabled? Perhaps it just needs to > get > properly flushed before booting VxWorks? Just checking. > Yes, I've checked the VxWorks kernel code. The comments mention that if caching is enabled, the cache should be flushed before the call to MMU TLB initialization is done. However, the calling code never actually flushes the cache. So they're not even following their own advice. In the calling code, they just assume that caching is disabled. > > My problem is that when my new U-Boot has booted, the TLBs are not > > configured as I have programmed them. I verified this using a BDI > > debugger. The TLB settings are still the same as the settings the > > original ALPR U-Boot used. I'm really at a loss here. It seems that no > > matter what I try (I tried quite a few variantions of the TLB settings), > > the TLB settings won't change. > > > > So now I several, related, questions: > > - What could be the cause of this? Have I done something wrong? > > This could have multiple reasons. Are you sure that you are running the > freshly compiled image on the board? Did you check the build time? > The build date and time of the U-Boot image I'm running is correct. I've also verified this because #undef-ing the 4XX_DCACHE config causes U-Boot to not function properly (Ethernet problem). So I'm confident that I really am running my own build. I've also verified that I'm compiling the right source, by forcing syntax errors. > > - Is U-Boot reconfiguring the TLBs after init.S has executed? > > Yes. But only one (IIRC). The first TLB for bootrom access. Caching will > be > disabled before relocating to SDRAM. > Hmmm. This should be a problem since I changed the TLB settings to have SDRAM at the first TLB. However, the SDRAM gets remapped in a different TLB as well. Where in the code can I find this? I tried looking for something like that, but couldn't find it. Perhaps that piece of code is actually replacing all TLBs, not just the bootrom access one. > > - If so, how can I control those TLBs? > > All other TLB's should be the same. > > Not sure what's going wrong here. > > Best regards, > Stefan > > ===================================================================== > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de > ===================================================================== Kind regards, Wouter Eckhardt. Disclaimer: The information contained in this email, including any attachments is confidential and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot