On Thu, 2009-04-02 at 11:12 -0500, Scott Wood wrote: > On Wed, Apr 01, 2009 at 08:23:42PM -0700, Sauce.Cheng wrote: > > > I don't see where you set up a BAT that covers 0xf0000000. > > > > if i have to set up a BAT that cover 0xF0000000. i had a debug with LEDs > > like that in u-boot code. everything is //normal. 0xF00000000 is the value > > of CFG_IMMR(CONFIG_SYS_IMMR) that memory map register, it is the phy address > > and //base //address of all internal regishters, isnt? you mean that if i > > set BATs, i should not get the phy address like in the //front ? > > I don't quite follow the above, but what I meant is that you need to > put a mapping in place that covers your LED I/O once you have the MMU on. > > Any mappings that U-boot made will be gone at that point.
Also, f0000000 isn't a very good idea for a hard wired mapping, it will overlap some kernel stuffs. You should dynamically allocate the virtual address, or pick something above 0xfff00000 which should be unused iirc. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
