Re: Porting barebox to Novena: misc questions

[Sean Cross <xobs@kosagi.com>]

On 18/3/14 4:36 PM, Sascha Hauer wrote:
> 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)

Oh, I didn't realize there was a requirement to align to the nearest
megabyte.

In that case, you're right.  I tried this, and it works:

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

However, this fails:

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


Sean

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox