Re: [U-Boot-Users] U-Boot and Nand Flash
David,
Thank you for your response.
On Wed, 8 Sep 2004 15:29:59 -0700 (PDT), David Farrell davidjf2001@yahoo.com wrote:
Look at the SMDK2410 board. I have if working on a similiar board using the Samsung S3C2410 cpu. I only made a few minor changes to the cvs
The board that I am using actually boots from the Nand flash itself, but only makes the first block available to be read like RAM, all other blocks have to be read using the Read Command which only allows you to read at most 32-bits at a time.
The first block is 16K which is larger than the U-Boot binary.
So in order to copy the rest of the Bootloader from Nand flash to RAM or the kernel from Nand flash to RAM wouldn't I have to write special "read" functions for Nand Flash? There are no flash_read commands in include/flash.h.
I see the changes you made to get writing to Nand Flash working, but fail to see how it handles reading from the Nand flash. Wouldn't that also be in board/smdk4210/flash.c?
Please let me know what I am missing.
Regards,
Dear Bradley,
in message 963b33870409081618661df6b7@mail.gmail.com you wrote:
The first block is 16K which is larger than the U-Boot binary.
Argh... You seem to need new glasses. You not only have problems to read the sources, but also to check sizes.
The U-Boot binary is probably ten times as big as your single 16k block.
U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made to boot directly from such a block. You will need to implement a different loader.
Best regards,
Wolfgang Denk
On Thu, 09 Sep 2004 02:20:47 +0200, Wolfgang Denk wd@denx.de wrote:
in message 963b33870409081618661df6b7@mail.gmail.com you wrote:
The first block is 16K which is larger than the U-Boot binary.
Sorry about the confusion. It was meant to say that the first block is smaller than the U-Boot Binary.
U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made to boot directly from such a block. You will need to implement a different loader.
So I guess that my best option would be to use a small primary bootloader to boot U-Boot from RAM.
If I am reading everything correctly, I should have to change the reset and start locations (.resetvec and .bootpg) along with the setup of the MMU (as all TLB Entries are cleared currently.)
I'm probably missing other steps that are required, I'll be looking at the startup code in more detail.
Do you see any reasons why what I am suggesting may not be feasible at all? I would really like to use U-Boot as our bootloader (or secondary bootloader) if it is at all possible.
Regards,
In message 963b3387040909105576176dee@mail.gmail.com you wrote:
U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made to boot directly from such a block. You will need to implement a different loader.
So I guess that my best option would be to use a small primary bootloader to boot U-Boot from RAM.
Indeed.
If I am reading everything correctly, I should have to change the reset and start locations (.resetvec and .bootpg) along with the setup of the MMU (as all TLB Entries are cleared currently.)
Remember that U-Boot does not use virtual memory.
I'm probably missing other steps that are required, I'll be looking at the startup code in more detail.
Indeed. You will ahve to re-invent all CPU and memory controller init stuff in your primary bootstrap loader, and disable them in U-Boot. It's serious surgery...
Best regards,
Wolfgang Denk
Hi,
U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made to boot directly from such a block. You will need to implement a different loader.
Sorry to disagree. Of course U-Boot at whole will not fit into a NAND block. But you can place all the assembler initialization stuff including NAND relocation into the first block. The relocation code then reads the remaining NAND sectors and appends it to the one already read by the CPU. For the S3C2410 I did post a patch half a year ago.
Bye,
In message 200409230855.06826.maillist@fsforth.de you wrote:
U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made to boot directly from such a block. You will need to implement a different loader.
Sorry to disagree. Of course U-Boot at whole will not fit into a NAND block. But you can place all the assembler initialization stuff including NAND relocation into the first block. The relocation code then reads the remaining NAND sectors and appends it to the one already read by the CPU. For the S3C2410 I did post a patch half a year ago.
What you describe is exactly such a different bootstap loader.
Best regards,
Wolfgang Denk
Hi Wolfgang,
sorry to answer that late.
Sorry to disagree. Of course U-Boot at whole will not fit into a NAND block. But you can place all the assembler initialization stuff including NAND relocation into the first block. The relocation code then reads the remaining NAND sectors and appends it to the one already read by the CPU. For the S3C2410 I did post a patch half a year ago.
What you describe is exactly such a different bootstap loader.
Not exactly It is part of U-Boot as just the relocation code of U-Boot is modified as it now needs to copy from NAND but not from NOR. And care must be taken that this code is in a specific memory range (first NAND block) while normally there are no limits on its position. Technically it is same to some other boot loaders like (lilo, grub) that have different steps when booting of hard disk.
Best regards,
In message 200410290944.07675.maillist@fsforth.de you wrote:
What you describe is exactly such a different bootstap loader.
Not exactly It is part of U-Boot as just the relocation code of U-Boot is modified as it now needs to copy from NAND but not from NOR. And care must be
This is not correct. Before U-Boot relocates the code, it does a lot of other things, including provide console oputput. So you need some system initialization, drivers, libraries (for printf() etc.) etc.
You will find that the the part of U-Boot that is needed is bigger than what it's in your small sector.
Best regards,
Wolfgang Denk
participants (3)
-
Bradley Remedios -
Markus Pietrek -
Wolfgang Denk