[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Stuart Wood]

I've got an interesting problem. If loading a large image to memory
and then copying it to flash it gets corrupted.
It appears to happen when the image size becomes larger then a bank of
SDRAM. I've got a 32 MByte SDRAM
that appears as 4 banks of 8 MBytes.

The system is using u-boot 1.1.3 and we will move to 1.3.3 soon.
The memory regions are broken up like this.

0xE0000000 - 0xE07FFFFF
0xE1000000 - 0xE17FFFFF
0xE4000000 - 0xE47FFFFF
0xE5000000 - 0xE57FFFFF

The processor is a Cirrus Logic EP9302 ARM920T.

What would the most appropriate way of handling files larger than 8MBytes?

-- 
Stuart Wood

Lab X Technologies, LLC
176 Anderson Ave.
Suite 302
Rochester, NY 14607
Phone: (585) 271-7790 x207
Fax: (585) 473.4707

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Ricardo]

Hi Stuart

I don't know waht architechture that you are using, but if you have an
mmu maybe you can set it to have a virtual memory space contigous.

     Best regards

On Thu, Jul 24, 2008 at 4:56 PM, Stuart Wood
<stuart.wood@labxtechnologies.com> wrote:
> I've got an interesting problem. If loading a large image to memory
> and then copying it to flash it gets corrupted.
> It appears to happen when the image size becomes larger then a bank of
> SDRAM. I've got a 32 MByte SDRAM
> that appears as 4 banks of 8 MBytes.
>
> The system is using u-boot 1.1.3 and we will move to 1.3.3 soon.
> The memory regions are broken up like this.
>
> 0xE0000000 - 0xE07FFFFF
> 0xE1000000 - 0xE17FFFFF
> 0xE4000000 - 0xE47FFFFF
> 0xE5000000 - 0xE57FFFFF
>
> The processor is a Cirrus Logic EP9302 ARM920T.
>
> What would the most appropriate way of handling files larger than 8MBytes?
>
> --
> Stuart Wood
>
> Lab X Technologies, LLC
> 176 Anderson Ave.
> Suite 302
> Rochester, NY 14607
> Phone: (585) 271-7790 x207
> Fax: (585) 473.4707
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>



-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Stuart Wood]

I'm using an ARM90T processor core. It does have a MMU. My
understanding is that u-Boot has discouraged the use of a MMU for
virtual memory space. Are there any examples of processors
architectures that can enable the MMU for address translations?

Stuart

On Thu, Jul 24, 2008 at 11:50 AM, Ricardo <ricardo.ribalda@gmail.com> wrote:
> Hi Stuart
>
> I don't know waht architechture that you are using, but if you have an
> mmu maybe you can set it to have a virtual memory space contigous.
>
>     Best regards
>
> On Thu, Jul 24, 2008 at 4:56 PM, Stuart Wood
> <stuart.wood@labxtechnologies.com> wrote:
>> I've got an interesting problem. If loading a large image to memory
>> and then copying it to flash it gets corrupted.
>> It appears to happen when the image size becomes larger then a bank of
>> SDRAM. I've got a 32 MByte SDRAM
>> that appears as 4 banks of 8 MBytes.
>>
>> The system is using u-boot 1.1.3 and we will move to 1.3.3 soon.
>> The memory regions are broken up like this.
>>
>> 0xE0000000 - 0xE07FFFFF
>> 0xE1000000 - 0xE17FFFFF
>> 0xE4000000 - 0xE47FFFFF
>> 0xE5000000 - 0xE57FFFFF
>>
>> The processor is a Cirrus Logic EP9302 ARM920T.
>>
>> What would the most appropriate way of handling files larger than 8MBytes?
>>
>> --
>> Stuart Wood
>>
>> Lab X Technologies, LLC
>> 176 Anderson Ave.
>> Suite 302
>> Rochester, NY 14607
>> Phone: (585) 271-7790 x207
>> Fax: (585) 473.4707
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> U-Boot-Users mailing list
>> U-Boot-Users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>
>
>
>
> --
> Ricardo Ribalda
> http://www.eps.uam.es/~rribalda/
>



-- 
Stuart Wood

Lab X Technologies, LLC
176 Anderson Ave.
Suite 302
Rochester, NY 14607
Phone: (585) 271-7790 x207
Fax: (585) 473.4707

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Ricardo]

Hello again

AFAIK the ppc440 runs ALLWAYS in virtual mode, and supports allocate
anything in the real space to anywhere in the virtual space.

     Best regards

On Thu, Jul 24, 2008 at 10:30 PM, Stuart Wood
<stuart.wood@labxtechnologies.com> wrote:
> I'm using an ARM90T processor core. It does have a MMU. My
> understanding is that u-Boot has discouraged the use of a MMU for
> virtual memory space. Are there any examples of processors
> architectures that can enable the MMU for address translations?
>
> Stuart
>
> On Thu, Jul 24, 2008 at 11:50 AM, Ricardo <ricardo.ribalda@gmail.com> wrote:
>> Hi Stuart
>>
>> I don't know waht architechture that you are using, but if you have an
>> mmu maybe you can set it to have a virtual memory space contigous.
>>
>>     Best regards
>>
>> On Thu, Jul 24, 2008 at 4:56 PM, Stuart Wood
>> <stuart.wood@labxtechnologies.com> wrote:
>>> I've got an interesting problem. If loading a large image to memory
>>> and then copying it to flash it gets corrupted.
>>> It appears to happen when the image size becomes larger then a bank of
>>> SDRAM. I've got a 32 MByte SDRAM
>>> that appears as 4 banks of 8 MBytes.
>>>
>>> The system is using u-boot 1.1.3 and we will move to 1.3.3 soon.
>>> The memory regions are broken up like this.
>>>
>>> 0xE0000000 - 0xE07FFFFF
>>> 0xE1000000 - 0xE17FFFFF
>>> 0xE4000000 - 0xE47FFFFF
>>> 0xE5000000 - 0xE57FFFFF
>>>
>>> The processor is a Cirrus Logic EP9302 ARM920T.
>>>
>>> What would the most appropriate way of handling files larger than 8MBytes?
>>>
>>> --
>>> Stuart Wood
>>>
>>> Lab X Technologies, LLC
>>> 176 Anderson Ave.
>>> Suite 302
>>> Rochester, NY 14607
>>> Phone: (585) 271-7790 x207
>>> Fax: (585) 473.4707
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> U-Boot-Users mailing list
>>> U-Boot-Users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>>
>>
>>
>>
>> --
>> Ricardo Ribalda
>> http://www.eps.uam.es/~rribalda/
>>
>
>
>
> --
> Stuart Wood
>
> Lab X Technologies, LLC
> 176 Anderson Ave.
> Suite 302
> Rochester, NY 14607
> Phone: (585) 271-7790 x207
> Fax: (585) 473.4707
>



-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Wolfgang Denk]

In message <c13b1cfc0807240756j243b6019xc95a07638c4ad2b2@mail.gmail.com> you wrote:
> I've got an interesting problem. If loading a large image to memory
> and then copying it to flash it gets corrupted.

I think copying to flash is completely unrelated to your problem.

> It appears to happen when the image size becomes larger then a bank of
> SDRAM. I've got a 32 MByte SDRAM
> that appears as 4 banks of 8 MBytes.

You fail to mention an essential fact here.

> The system is using u-boot 1.1.3 and we will move to 1.3.3 soon.
> The memory regions are broken up like this.
> 
> 0xE0000000 - 0xE07FFFFF
> 0xE1000000 - 0xE17FFFFF
> 0xE4000000 - 0xE47FFFFF
> 0xE5000000 - 0xE57FFFFF

It seemd your 4 banks are mapped so that they do NOT form a contiguous
region - what do you think how this is supposed to work?

> What would the most appropriate way of handling files larger than 8MBytes?

Make sure to map your memory such that it forms a single contiguous
region as it should.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Einstein argued that there must be simplified explanations of nature,
because God is not capricious or arbitrary. No  such  faith  comforts
the software engineer.                             - Fred Brooks, Jr.

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Wolfgang Denk]

In message <c13b1cfc0807241330geea8d63ta1cd8db9f9ba02ed@mail.gmail.com> you wrote:
> I'm using an ARM90T processor core. It does have a MMU. My
> understanding is that u-Boot has discouraged the use of a MMU for
> virtual memory space. Are there any examples of processors
> architectures that can enable the MMU for address translations?

PLEASE DO NOT TOP POST / FULL QUOTE.
PLEASE DO NOT TOP POST / FULL QUOTE.
PLEASE DO NOT TOP POST / FULL QUOTE.

What has the MMU to do with it?

Just program your memory controller such that the 4 banks form a
contiguous region.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Never give in.  Never give in.  Never. Never. Never."
- Winston Churchill

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Stuart Wood]

Wolfgamg


> What has the MMU to do with it?
>
> Just program your memory controller such that the 4 banks form a
> contiguous region.

The memory controller unfortunatly can  not map the SDRAM banks as
contiguous region. That IS the main problem. For the SDRAM I'm using
It ends up giving me region sizes of 8MBytes.

U-Boot runs in the first region, and we down load into the second region.
If the down load is larger than the region size it gets corrupted.

So the thought is to enable the MMU to do the address translation.
Or is there another way to handle this?

-- 
Stuart Wood

Lab X Technologies, LLC
176 Anderson Ave.
Suite 302
Rochester, NY 14607
Phone: (585) 271-7790 x207
Fax: (585) 473.4707

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Jerry Van Baren]

Stuart Wood wrote:
> Wolfgamg
> 
> 
>> What has the MMU to do with it?
>>
>> Just program your memory controller such that the 4 banks form a
>> contiguous region.
> 
> The memory controller unfortunatly can  not map the SDRAM banks as
> contiguous region. That IS the main problem. For the SDRAM I'm using
> It ends up giving me region sizes of 8MBytes.
> 
> U-Boot runs in the first region, and we down load into the second region.
> If the down load is larger than the region size it gets corrupted.

IOW, your hardware sucks.  Not the first time *that* has happened.

> So the thought is to enable the MMU to do the address translation.
> Or is there another way to handle this?

No.

Wait, there is half a way.  If your SDRAM banks are not fully decoded 
(and they most likely are *not*), if you use the address last "copy" of 
the first bank and the first "copy" of the second bank, you will have 
two bank's worth of contiguous memory.

> It appears to happen when the image size becomes larger then a bank of
>> SDRAM. I've got a 32 MByte SDRAM
>> that appears as 4 banks of 8 MBytes.
>> 
>> The system is using u-boot 1.1.3 and we will move to 1.3.3 soon.
>> The memory regions are broken up like this.
>> 
>> 0xE0000000 - 0xE07FFFFF
>> 0xE1000000 - 0xE17FFFFF
>> 0xE4000000 - 0xE47FFFFF
>> 0xE5000000 - 0xE57FFFFF

So you should be able to use
   0xE0800000..0xE0FFFFFF - 2nd "copy" of the first bank
   0xE1000000..0xE17FFFFF - 1st "copy" of the second bank
you will double your available consecutive memory.  You can do the same 
thing with the third and fourth banks of memory, but you will still have 
a gap between the first pair and second pair.  This will reduce your 
four fragments / three holes to two fragments / one hole.  Solved half 
your problem anyway.
   0xE4800000..0xE4FFFFFF - 2nd "copy" of the first bank
   0xE5000000..0xE57FFFFF - 1st "copy" of the second bank

HTH,
gvb

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Jerry Van Baren]

Jerry Van Baren wrote:
> So you should be able to use
>    0xE0800000..0xE0FFFFFF - 2nd "copy" of the first bank
>    0xE1000000..0xE17FFFFF - 1st "copy" of the second bank
> you will double your available consecutive memory.  You can do the same 
> thing with the third and fourth banks of memory, but you will still have 
> a gap between the first pair and second pair.  This will reduce your 
> four fragments / three holes to two fragments / one hole.  Solved half 
> your problem anyway.
>    0xE4800000..0xE4FFFFFF - 2nd "copy" of the first bank
>    0xE5000000..0xE57FFFFF - 1st "copy" of the second bank
doh!                                            ^^^^^^

s/first/third/
s/second/fourth/

Sorry for the cut&paste error.
gvb

[U-Boot-Users] How to Handel Non-Continuous Memory Regions

[Stuart Wood]

Jerry,

Excellent Idea! I will test it right away.

-- 
Stuart Wood

Lab X Technologies, LLC
176 Anderson Ave.
Suite 302
Rochester, NY 14607
Phone: (585) 271-7790 x207
Fax: (585) 473.4707