[U-Boot] Segmented RAM, big userspace.
Hi, all!
We have a board, based on s3c2416, with 128MB of RAM and 1GB of NAND flash. RAM is organized as 2 memory banks with far placed bases:
TOP
UNUSED 64MB
64MB SDRAM
--- 128MB segment base 1 -----
UNUSED 64MB
64MB SDRAM
-- 128MB segment base 0 ------
BOTTOM
So we could have only 64MB as one piece; Due to u-boot reloaction code we need to have u-boot in first 64MB also. And now we have root filesystem which we need to flash using u-boot, which is a little over this 64MB limit.
Is there some way to use second memory bank from u-boot? Is it possible to tftp file in parts and flash it on NAND in parts? (This requires handling of bad blocks too)
We need to flash using u-boot, that's requirement for speedy production.
It is possible to flash filesystems in parts, but for this to work these are needed to be properly split. This raises a problem of bad blocks - writing previous piece might end not where you expect it to end, but a few blocks later. Hand-handling this case is too error-prone.
Thanks a lot, S.
Dear Sergey Lapin,
In message 20111213160810.GA27440@build.ihdev.net you wrote:
We have a board, based on s3c2416, with 128MB of RAM and 1GB of NAND flash. RAM is organized as 2 memory banks with far placed bases: TOP UNUSED 64MB 64MB SDRAM --- 128MB segment base 1 ----- UNUSED 64MB 64MB SDRAM -- 128MB segment base 0 ------ BOTTOM
So we could have only 64MB as one piece; Due to u-boot reloaction code we need to have u-boot in first 64MB also. ...
Why would that be the case?
I would expect that U-Boot (with all it's heap and stack and everything) sits only at the upper end of the upper bank of memory (in your sgment 1).
... . And now we have root filesystemwhich we need to flash using u-boot, which is a little over this 64MB limit.
Split it?
Is there some way to use second memory bank from u-boot? Is it possible to tftp file in parts and flash it on NAND in parts? (This requires handling of bad blocks too)
We need to flash using u-boot, that's requirement for speedy production.
I somewhat doubt that. Booting Linux is probably a matter of 2 or 3 seconds, or less. You migth save that time again by using Linux' much better performing network stack, together with interleaving network traffic and flash writing.
If I were in this situation, I'd probably run this under Linux.
Best regards,
Wolfgang Denk
On Tue, Dec 13, 2011 at 05:24:22PM +0100, Wolfgang Denk wrote:
Dear Sergey Lapin,
In message 20111213160810.GA27440@build.ihdev.net you wrote:
We have a board, based on s3c2416, with 128MB of RAM and 1GB of NAND flash. RAM is organized as 2 memory banks with far placed bases: TOP UNUSED 64MB 64MB SDRAM --- 128MB segment base 1 ----- UNUSED 64MB 64MB SDRAM -- 128MB segment base 0 ------ BOTTOM
So we could have only 64MB as one piece; Due to u-boot reloaction code we need to have u-boot in first 64MB also. ...
Why would that be the case?
If we specify memory size as 128MB (gd->ram_size) u-boot reloacates itself to unused part of first memory bank instead of the end of second bank, which actually makes it fail badly. If we specify memory size to 64MB, u-boot works, but we lose access to second segment (segment 1). Or at least have not really comfortable placement.
I would expect that U-Boot (with all it's heap and stack and everything) sits only at the upper end of the upper bank of memory (in your sgment 1).
... . And now we have root filesystemwhich we need to flash using u-boot, which is a little over this 64MB limit.
Split it?
There comes issue of NAND bad blocks.
Is there some way to use second memory bank from u-boot? Is it possible to tftp file in parts and flash it on NAND in parts? (This requires handling of bad blocks too)
We need to flash using u-boot, that's requirement for speedy production.
I somewhat doubt that. Booting Linux is probably a matter of 2 or 3 seconds, or less. You migth save that time again by using Linux' much better performing network stack, together with interleaving network traffic and flash writing.
If I were in this situation, I'd probably run this under Linux.
Well, we already running production using u-boot. And on production devices we have no (fast) network access. We boot u-boot from mmc, which flashes images on the same card and then boots device. I can't see how faster we can be with Linux, which will add several more seconds to boot.
tftp is needed for development and images actually can be split, but it is quite hard to flash them properly.
Thanks a lot, S.
Dear Sergey Lapin,
In message 20111213165113.GA27964@build.ihdev.net you wrote:
So we could have only 64MB as one piece; Due to u-boot reloaction code we need to have u-boot in first 64MB also. ...
Why would that be the case?
If we specify memory size as 128MB (gd->ram_size) u-boot reloacates itself to unused part of first memory bank instead of the end of second bank, which actually makes it fail badly.
You are not supposed to "specify" RAM sizes. You should use get_ram_size() to auto-detect the installed size, and do this separately for each bank of memory.
I'm not sure if the relocation code on ARM makes any assumptions that the memory is contiguous, but it should be relatively easy to fix so that it always relocates to the end of the last (highest) bank of memory.
If I were in this situation, I'd probably run this under Linux.
Well, we already running production using u-boot. And on production devices we have no (fast) network access. We boot u-boot from mmc, which flashes images on the same card and then boots device. I can't see how faster we can be with Linux, which will add several more seconds to boot.
Linx MMC drivers and file system code will probably be way faster than what we have in U-Boot, and you can inteleave reading from MMC with writing to NAND - actually you can do it fully in parallel uner Linux (using for example "buffer" or similar tools).
Until you really measure it you should not make assumptions which way is faster.
Best regards,
Wolfgang Denk
On 12/13/2011 10:08 AM, Sergey Lapin wrote:
It is possible to flash filesystems in parts, but for this to work these are needed to be properly split. This raises a problem of bad blocks - writing previous piece might end not where you expect it to end, but a few blocks later. Hand-handling this case is too error-prone.
Use a separate partition for each chunk. Each partition should have extra space for as many bad blocks as you reasonably anticipate in that partition. The start address of each partition is fixed, regardless of the number of bad blocks in previous partitions.
-Scott
participants (3)
-
Scott Wood -
Sergey Lapin -
Wolfgang Denk