[U-Boot-Users] How to Handel Non-Continuous Memory Regions
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?
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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 regardsOn 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
-- Ricardo Ribalda http://www.eps.uam.es/~rribalda/
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 regardsOn 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@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
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
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 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
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
Jerry,
Excellent Idea! I will test it right away.
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
participants (4)
-
Jerry Van Baren -
Ricardo -
Stuart Wood -
Wolfgang Denk