Porting barebox to Novena: misc questions

[Sascha Hauer]

On Tue, Mar 18, 2014 at 11:35:26AM +0800, Sean Cross wrote:
> On 17/3/14 6:53 PM, Sascha Hauer wrote:
> > On Mon, Mar 17, 2014 at 03:44:15PM +0800, Sean Cross wrote:
> >> On 17/3/14 3:18 PM, Sascha Hauer wrote:
> >>> On Mon, Mar 17, 2014 at 12:28:28PM +0800, Sean Cross wrote:
> >>>> Here is the resulting output and BUG from this run:
> >>>>
> >>>> barebox 2014.03.0-00628-g7fed07d-dirty #158 Mon Mar 17 12:25:45 SGT 2014
> >>>>
> >>>>
> >>>> Board: Kosagi i.MX6DL Novena Board
> >>>> detected i.MX6 DualLite revision 1.1
> >>>> Trying to request region ttb (from 0x4fff4000:0x4fff7fff): ok
> >>>> Trying to request region malloc space (from 0x4be00000:0x4fdfffff): ok
> >>>> Trying to request region barebox (from 0x4fe00000:0x4fe4b4a7): ok
> >>>> Trying to request region barebox data (from 0x4fe4b4a8:0x4fe5c8f7): ok
> >>>> Trying to request region bss (from 0x4fe5c8f8:0x4fe6214f): ok
> >>>> Trying to request region stack (from 0x4fff8000:0x4fffffff): ok
> >>>> mmu: find_pte: TTB for address 0x4cd1e000 is not of type table
> >>>> mmu: Memory banks:
> >>>> mmu: #0 0x10000000 - 0xffffffff
> >>>
> >>> So you have one memory bank that starts at 0x10000000 which is the
> >>> standard SDRAM base for i.MX6. Good. But why is the size 0? Have you
> >>> specified this in your devicetree? It should contain the correct size.
> >>> It could also be that we do not parse #ddress-cells / #size-cells
> >>> correctly (in case one of these is not 1 in your devicetree).
> >>
> >> There is no "memory" node in my .dts file, so it's inheriting the
> >> default "memory { device_type = "memory"; reg = <0 0>; };" from
> >> skeleton.dtsi.
> > 
> > Ok, that's fine.
> > 
> >> I add memory in my board.c file:
> >>
> >> static int kosagi_novena_mem_init(void)
> >> {
> >>         /* Pull out RAM capacity, which was stored here in lowlevel.c */
> >>         arm_add_mem_device("ram0", 0x10000000, readl(MX6_SRC_BASE_ADDR +
> >> 0x20));
> > 
> > Are you sure the readl returns the proper memory size? How about
> > replacing this with a hardcoded value for testing?
> 
> That's very good thinking.  I'm guessing there's a fencepost error
> somewhere.  It works if I set it to SZ_1GB, but not when I include the
> full amount.  I've tried printing the value stored in that register, and
> it is correct.
> 
> This works:
> 
>         arm_add_mem_device("ram0", 0x10000000, SZ_2G + SZ_1G + SZ_512M +
> SZ_128M);
> 
> This does not:
> 
>         arm_add_mem_device("ram0", 0x10000000, SZ_2G + SZ_1G + SZ_512M +
> SZ_128M + 1);
> 
> Is there something special about the address 0xf8000000?

The memory start and size should be aligned to 1MiB. Otherwise the MMU
code doesn't work. I didn't bother to catch this because all real memory
fulfills this requirement. There's nothing special with 0xf8000000, I
just tried:

arm_add_mem_device("ram0", 0x10000000, SZ_2G + SZ_1G + SZ_512M + SZ_128M + SZ_1M);

and this works on a board I have here (although that board doesn't even
have that amount of memory)

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |