[U-Boot-Users] 440EPX is not booting from 1Gb/128MB NAND flash
Hi,
I am trying to boot my board which is based on Sequoia 440EPX. The only difference between my board and the reference board is that I have a 1 Gb NAND flash ( NAND01GW3B2A) instead of 256Mb flash present on reference board.
In U-boot I have changed the board configuration file to reflect correct specs.
* Now the NAND chip has to be defined (no autodetection used!) */ #define CFG_NAND_PAGE_SIZE (2048) /* NAND chip page size */ #define CFG_NAND_BLOCK_SIZE (128 << 10) /* NAND chip block size */ #define CFG_NAND_PAGE_COUNT (64) /* NAND chip page count */ #define CFG_NAND_BAD_BLOCK_POS (5) /* Location of bad block marker */ #define CFG_NAND_4_ADDR_CYCLE /* Fourth addr used (>32MB) */
I have also changed the eeprom configuration word to 0x87788252 0x0947D010 0xA0A82358 0x0D050000
Is there any other place where some NAND configuration is defined?
Thanks Nikhil
On Thursday 07 February 2008, Nikhil Gautam wrote:
I am trying to boot my board which is based on Sequoia 440EPX. The only difference between my board and the reference board is that I have a 1 Gb NAND flash ( NAND01GW3B2A) instead of 256Mb flash present on reference board.
In U-boot I have changed the board configuration file to reflect correct specs.
- Now the NAND chip has to be defined (no autodetection used!)
*/ #define CFG_NAND_PAGE_SIZE (2048) /* NAND chip page size */ #define CFG_NAND_BLOCK_SIZE (128 << 10) /* NAND chip block size */ #define CFG_NAND_PAGE_COUNT (64) /* NAND chip page count */ #define CFG_NAND_BAD_BLOCK_POS (5) /* Location of bad block marker */ #define CFG_NAND_4_ADDR_CYCLE /* Fourth addr used (>32MB) */
I have also changed the eeprom configuration word to 0x87788252 0x0947D010 0xA0A82358 0x0D050000
Is there any other place where some NAND configuration is defined?
Could be that nand_spl/nand_boot.c needs to be changed to support booting from 2k page sized devices too. It was only tested on 512 byte page devices till now.
I can only recommend to debug using an BDI2000. But you have probably already realized, that NAND booting debugging is not that easy.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Thanks Stefan,
I figured couple of more things that needed change
In ndfc.c #ifdef CFG_NAND_4_ADDR_CYCLE /* Set NandFlash Core Configuration Register */ /* 2 col x 2 rows */ out32(base + NDFC_CCR, 0x00002000 | (cs << 24)); #else /* Set NandFlash Core Configuration Register */ /* 1 col x 2 rows */ out32(base + NDFC_CCR, 0x00000000 | (cs << 24)); #endif /* CFG_NAND_4_ADDR_CYCLE */
Also for 1Gb NAND flash, the address fetch is different then 256Mb, here is what I changed
#ifdef CFG_NAND_4_ADDR_CYCLE /* Column address */ this->write_byte(mtd, 0); /* A[7:0] */ this->write_byte(mtd, (uchar)(page_addr & 0x0f)); /* A[11:8] */ this->write_byte(mtd, (uchar)((page_addr >> 4) & 0xff)); /* A[19:12] */ /* One more address cycle for devices > 32MiB */ this->write_byte(mtd, (uchar)((page_addr >> 12) & 0xff)); /* A[27:20] */ #else /* Column address */ this->write_byte(mtd, 0); /* A[7:0] */ this->write_byte(mtd, (uchar)(page_addr & 0xff)); /* A[16:9] */ this->write_byte(mtd, (uchar)((page_addr >> 8) & 0xff)); /* A[24:17] */ #endif
Even with these two changes, the board is not booting??
Nikhil - Show
On Feb 6, 2008 9:24 PM, Stefan Roese sr@denx.de wrote:
On Thursday 07 February 2008, Nikhil Gautam wrote:
I am trying to boot my board which is based on Sequoia 440EPX. The only difference between my board and the reference board is that I have a 1 Gb NAND flash ( NAND01GW3B2A) instead of 256Mb flash present on reference board.
In U-boot I have changed the board configuration file to reflect correct specs.
- Now the NAND chip has to be defined (no autodetection used!)
*/ #define CFG_NAND_PAGE_SIZE (2048) /* NAND chip page size */ #define CFG_NAND_BLOCK_SIZE (128 << 10) /* NAND chip block size */ #define CFG_NAND_PAGE_COUNT (64) /* NAND chip page count */ #define CFG_NAND_BAD_BLOCK_POS (5) /* Location of bad block marker */ #define CFG_NAND_4_ADDR_CYCLE /* Fourth addr used (>32MB) */
I have also changed the eeprom configuration word to 0x87788252 0x0947D010 0xA0A82358 0x0D050000
Is there any other place where some NAND configuration is defined?
Could be that nand_spl/nand_boot.c needs to be changed to support booting from 2k page sized devices too. It was only tested on 512 byte page devices till now.
I can only recommend to debug using an BDI2000. But you have probably already realized, that NAND booting debugging is not that easy.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On Friday 08 February 2008, Nikhil Gautam wrote:
I figured couple of more things that needed change
In ndfc.c #ifdef CFG_NAND_4_ADDR_CYCLE /* Set NandFlash Core Configuration Register */ /* 2 col x 2 rows */ out32(base + NDFC_CCR, 0x00002000 | (cs << 24)); #else /* Set NandFlash Core Configuration Register */ /* 1 col x 2 rows */ out32(base + NDFC_CCR, 0x00000000 | (cs << 24)); #endif /* CFG_NAND_4_ADDR_CYCLE */
I don't think this change is needed. This only affects "auto-read" mode, so the first stage NAND boot loader (IPL), that loads the 4k SPL which we are talking about right now into memory. But you have to configure the corresponding bits in the bootstrap EEPROM correctly of course.
Also for 1Gb NAND flash, the address fetch is different then 256Mb, here is what I changed
#ifdef CFG_NAND_4_ADDR_CYCLE /* Column address */ this->write_byte(mtd, 0); /* A[7:0] */ this->write_byte(mtd, (uchar)(page_addr & 0x0f)); /* A[11:8] */ this->write_byte(mtd, (uchar)((page_addr >> 4) & 0xff)); /* A[19:12] */ /* One more address cycle for devices > 32MiB */ this->write_byte(mtd, (uchar)((page_addr >> 12) & 0xff)); /* A[27:20] */ #else /* Column address */ this->write_byte(mtd, 0); /* A[7:0] */ this->write_byte(mtd, (uchar)(page_addr & 0xff)); /* A[16:9] */ this->write_byte(mtd, (uchar)((page_addr >> 8) & 0xff)); /* A[24:17] */ #endif
This doesn't match the 4 address cycle mode used for bigger 512k page devices. I think we may need another config define for 2k page devices.
Even with these two changes, the board is not booting??
And where does it hang? Did you have a chance to see where execution stops? Is nand_boot() called at all?
I suggest to debug things extensively with an BDI2000.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi Stefan,
After some debugging using BDI, I found out that there are more then one problem here.
IPL loads the SPL correctly. And I can see that nand_boot( ) is called. The first problem I found was that the nand_is_bad_block( ) is returning true after a while. I think its treating empty blocks as bad blocks. I know there are no bad blocks because I booted using the NOR image and then checked the NAND flash.
Secondly, the SPL is copying the u-boot image to ram incorrectly. By this I mean, when I do the memory dump of RAM where U-boot image should be loaded, only the first NAND page (2K) is copied correctly. After that it's random or empty.
The third problem is that in the board config file #define CFG_NAND_U_BOOT_OFFS (16 << 10) is incorrect for current U-boot. If you look at nand_boot.c /* * offs has to be aligned to a block address! */ block = CFG_NAND_U_BOOT_OFFS / CFG_NAND_BLOCK_SIZE;
This is because this file copies sectors completely. For 2k page size and 64 pages per block, The SPL is again copying the complete NAND flash from address "0" to RAM.
Changing this define to #define CFG_NAND_U_BOOT_OFFS (128 << 10) will not help because when u-boot is compiles, it pads the image enough so that the U-Boot ram image is always located at 16K. Do you know how can I change it to that my new U-boot ram image starts from 128K offset.
Thanks
Nikhil Gautam
On Feb 7, 2008 8:50 PM, Stefan Roese sr@denx.de wrote:
On Friday 08 February 2008, Nikhil Gautam wrote:
I figured couple of more things that needed change
In ndfc.c #ifdef CFG_NAND_4_ADDR_CYCLE /* Set NandFlash Core Configuration Register */ /* 2 col x 2 rows */ out32(base + NDFC_CCR, 0x00002000 | (cs << 24)); #else /* Set NandFlash Core Configuration Register */ /* 1 col x 2 rows */ out32(base + NDFC_CCR, 0x00000000 | (cs << 24)); #endif /* CFG_NAND_4_ADDR_CYCLE */
I don't think this change is needed. This only affects "auto-read" mode, so the first stage NAND boot loader (IPL), that loads the 4k SPL which we are talking about right now into memory. But you have to configure the corresponding bits in the bootstrap EEPROM correctly of course.
Also for 1Gb NAND flash, the address fetch is different then 256Mb, here is what I changed
#ifdef CFG_NAND_4_ADDR_CYCLE /* Column address */ this->write_byte(mtd, 0); /* A[7:0] */ this->write_byte(mtd, (uchar)(page_addr & 0x0f)); /* A[11:8] */ this->write_byte(mtd, (uchar)((page_addr >> 4) & 0xff)); /* A[19:12] */ /* One more address cycle for devices > 32MiB */ this->write_byte(mtd, (uchar)((page_addr >> 12) & 0xff)); /* A[27:20] */ #else /* Column address */ this->write_byte(mtd, 0); /* A[7:0] */ this->write_byte(mtd, (uchar)(page_addr & 0xff)); /* A[16:9] */ this->write_byte(mtd, (uchar)((page_addr >> 8) & 0xff)); /* A[24:17] */ #endif
This doesn't match the 4 address cycle mode used for bigger 512k page devices. I think we may need another config define for 2k page devices.
Even with these two changes, the board is not booting??
And where does it hang? Did you have a chance to see where execution stops? Is nand_boot() called at all?
I suggest to debug things extensively with an BDI2000.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi Nikhil,
On Friday 08 February 2008, Nikhil Gautam wrote:
After some debugging using BDI, I found out that there are more then one problem here.
IPL loads the SPL correctly. And I can see that nand_boot( ) is called. The first problem I found was that the nand_is_bad_block( ) is returning true after a while. I think its treating empty blocks as bad blocks. I know there are no bad blocks because I booted using the NOR image and then checked the NAND flash.
How did you define CFG_NAND_BAD_BLOCK_POS in your board config file? For 512 byte page devices this is "5" but for 2k devices it should be "0".
For testing you could change nand_is_bad_block() to return always 0.
Secondly, the SPL is copying the u-boot image to ram incorrectly. By this I mean, when I do the memory dump of RAM where U-boot image should be loaded, only the first NAND page (2K) is copied correctly. After that it's random or empty.
The third problem is that in the board config file #define CFG_NAND_U_BOOT_OFFS (16 << 10) is incorrect for current U-boot. If you look at nand_boot.c /* * offs has to be aligned to a block address! */ block = CFG_NAND_U_BOOT_OFFS / CFG_NAND_BLOCK_SIZE;
This is because this file copies sectors completely. For 2k page size and 64 pages per block, The SPL is again copying the complete NAND flash from address "0" to RAM.
Changing this define to #define CFG_NAND_U_BOOT_OFFS (128 << 10) will not help because when u-boot is compiles, it pads the image enough so that the U-Boot ram image is always located at 16K. Do you know how can I change it to that my new U-boot ram image starts from 128K offset.
Sure. This is defined in the nand_spl config.mk file. For example Sequoia has here in nand_spl/board/amcc/sequoia/config.mk:
# On 440EP(x) platforms the SPL is located at 0xfffff000...0xffffffff, # in the last 4kBytes of memory space in cache. # We will copy this SPL into internal SRAM in start.S. So we set # TEXT_BASE to starting address in internal SRAM here. # TEXT_BASE = 0xE0013000
# PAD_TO used to generate a 16kByte binary needed for the combined image # -> PAD_TO = TEXT_BASE + 0x4000 PAD_TO = 0xE0017000
You need to change this PAD_TO accordingly.
Hope this helps.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi Stefan,
I bypassed the function nand_is_bad_block( ) and also my image is now padded correctly. But still the problem is that SPL doesn't copy the U-boot image correctly onto the RAM. It copies the first page of first block from NAND flash again and again.
This must be because of some configuration of NDFC done by SPL because I can see that IPL copied the first 4K (2 pages) correctly from NAND flash to RAM. But there aren't many NDFC or NAND configuration parameter that I can change.
Have anyone seen this kind of problem before?
Thanks,
Nikhil Gautam
On Feb 8, 2008 2:57 PM, Nikhil Gautam nikhilgautam1@gmail.com wrote:
Hi Stefan,
After some debugging using BDI, I found out that there are more then one problem here.
IPL loads the SPL correctly. And I can see that nand_boot( ) is called. The first problem I found was that the nand_is_bad_block( ) is returning true after a while. I think its treating empty blocks as bad blocks. I know there are no bad blocks because I booted using the NOR image and then checked the NAND flash.
Secondly, the SPL is copying the u-boot image to ram incorrectly. By this I mean, when I do the memory dump of RAM where U-boot image should be loaded, only the first NAND page (2K) is copied correctly. After that it's random or empty.
The third problem is that in the board config file #define CFG_NAND_U_BOOT_OFFS (16 << 10) is incorrect for current U-boot. If you look at nand_boot.c /* * offs has to be aligned to a block address! */ block = CFG_NAND_U_BOOT_OFFS / CFG_NAND_BLOCK_SIZE;
This is because this file copies sectors completely. For 2k page size and 64 pages per block, The SPL is again copying the complete NAND flash from address "0" to RAM.
Changing this define to #define CFG_NAND_U_BOOT_OFFS (128 << 10) will not help because when u-boot is compiles, it pads the image enough so that the U-Boot ram image is always located at 16K. Do you know how can I change it to that my new U-boot ram image starts from 128K offset.
Thanks
Nikhil Gautam
On Feb 7, 2008 8:50 PM, Stefan Roese sr@denx.de wrote:
On Friday 08 February 2008, Nikhil Gautam wrote:
I figured couple of more things that needed change
In ndfc.c #ifdef CFG_NAND_4_ADDR_CYCLE /* Set NandFlash Core Configuration Register */ /* 2 col x 2 rows */ out32(base + NDFC_CCR, 0x00002000 | (cs << 24)); #else /* Set NandFlash Core Configuration Register */ /* 1 col x 2 rows */ out32(base + NDFC_CCR, 0x00000000 | (cs << 24)); #endif /* CFG_NAND_4_ADDR_CYCLE */
I don't think this change is needed. This only affects "auto-read" mode, so the first stage NAND boot loader (IPL), that loads the 4k SPL which we are talking about right now into memory. But you have to configure the corresponding bits in the bootstrap EEPROM correctly of course.
Also for 1Gb NAND flash, the address fetch is different then 256Mb, here is what I changed
#ifdef CFG_NAND_4_ADDR_CYCLE /* Column address */ this->write_byte(mtd, 0); /* A[7:0] */ this->write_byte(mtd, (uchar)(page_addr & 0x0f)); /* A[11:8] */ this->write_byte(mtd, (uchar)((page_addr >> 4) & 0xff)); /* A[19:12] */ /* One more address cycle for devices > 32MiB */ this->write_byte(mtd, (uchar)((page_addr >> 12) & 0xff)); /* A[27:20] */ #else /* Column address */ this->write_byte(mtd, 0); /* A[7:0] */ this->write_byte(mtd, (uchar)(page_addr & 0xff)); /* A[16:9] */ this->write_byte(mtd, (uchar)((page_addr >> 8) & 0xff)); /* A[24:17] */ #endif
This doesn't match the 4 address cycle mode used for bigger 512k page devices. I think we may need another config define for 2k page devices.
Even with these two changes, the board is not booting??
And where does it hang? Did you have a chance to see where execution stops? Is nand_boot() called at all?
I suggest to debug things extensively with an BDI2000.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi Nikhil,
On Monday 11 February 2008, Nikhil Gautam wrote:
I bypassed the function nand_is_bad_block( ) and also my image is now padded correctly. But still the problem is that SPL doesn't copy the U-boot image correctly onto the RAM. It copies the first page of first block from NAND flash again and again.
Now this could be an indication for what is going wrong here.
This must be because of some configuration of NDFC done by SPL because I can see that IPL copied the first 4K (2 pages) correctly from NAND flash to RAM. But there aren't many NDFC or NAND configuration parameter that I can change.
Have anyone seen this kind of problem before?
No.
But as mentioned above, if you see the same 2k page multiple times, it seems that the addressing in nand_command() (nand_boot.c) is not correct for those 2k page devices. And looking at nand_base.c you will notice two different implementations for nand_command:
nand_command() and nand_command_lp() (lp for Large Page)
I suggest you take a look at this and merge the needed changes into nand_boot.c
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi Stefan,
After looking at nand_command_lp( ), I added following piece of code everytime I send address to NAND flash.
#ifdef CFG_NAND_4_ADDR_CYCLE /* Begin command latch cycle */ this->hwcontrol(mtd, NAND_CTL_SETCLE); /* Write out the start read command */ this->write_byte(mtd, NAND_CMD_READSTART); /* End command latch cycle */ this->hwcontrol(mtd, NAND_CTL_CLRCLE); #endif /* CFG_NAND_4_ADDR_CYCLE */
This change along with the change in nand_spl padding and change in board configuration file defines, I got the 440EPx to boot from the 1Gb NAND flash.
Thanks,
Nikhil
On Feb 11, 2008 8:26 AM, Stefan Roese sr@denx.de wrote:
Hi Nikhil,
On Monday 11 February 2008, Nikhil Gautam wrote:
I bypassed the function nand_is_bad_block( ) and also my image is now padded correctly. But still the problem is that SPL doesn't copy the U-boot image correctly onto the RAM. It copies the first page of first block from NAND flash again and again.
Now this could be an indication for what is going wrong here.
This must be because of some configuration of NDFC done by SPL because I can see that IPL copied the first 4K (2 pages) correctly from NAND flash to RAM. But there aren't many NDFC or NAND configuration parameter that I can change.
Have anyone seen this kind of problem before?
No.
But as mentioned above, if you see the same 2k page multiple times, it seems that the addressing in nand_command() (nand_boot.c) is not correct for those 2k page devices. And looking at nand_base.c you will notice two different implementations for nand_command:
nand_command() and nand_command_lp() (lp for Large Page)
I suggest you take a look at this and merge the needed changes into nand_boot.c
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi Nikhil,
On Tuesday 12 February 2008, Nikhil Gautam wrote:
After looking at nand_command_lp( ), I added following piece of code everytime I send address to NAND flash.
#ifdef CFG_NAND_4_ADDR_CYCLE /* Begin command latch cycle */ this->hwcontrol(mtd, NAND_CTL_SETCLE); /* Write out the start read command */ this->write_byte(mtd, NAND_CMD_READSTART); /* End command latch cycle */ this->hwcontrol(mtd, NAND_CTL_CLRCLE); #endif /* CFG_NAND_4_ADDR_CYCLE */
This change along with the change in nand_spl padding and change in board configuration file defines, I got the 440EPx to boot from the 1Gb NAND flash.
Great.
We definitely need another config option than CFG_NAND_4_ADDR_CYCLE to select the 2k page NAND booting option. Thinking about it, we already have this option:
CFG_NAND_PAGE_SIZE
This is set to 512 for small page devices and set to 2k for large page devices. So the code can be "selected" via this #if statement:
#if (CFG_NAND_PAGE_SIZE > 512)
Since the difference between both nand_command() functions is quite big, I suggest to implement a 2nd version of this large page nand_command() function. Like this:
#if (CFG_NAND_PAGE_SIZE > 512) /* * NAND command for large page NAND devices (2k) */ static int nand_command(struct mtd_info *mtd, int block, int page, int offs, u8 cmd) { ... } #else /* * NAND command for small page NAND devices (512) */ static int nand_command(struct mtd_info *mtd, int block, int page, int offs, u8 cmd) { ... } #endif
Another questions: Is the bad page detection now working correctly?
Please provide a proper patch with the 2k NAND booting support. Take a look at this links for guidance:
http://www.denx.de/wiki/Training/ContributingCode http://www.denx.de/wiki/UBoot/Patches http://www.denx.de/wiki/UBoot/CodingStyle
Hope this helps.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
In message 200802120612.46861.sr@denx.de you wrote:
This is set to 512 for small page devices and set to 2k for large page devices. So the code can be "selected" via this #if statement:
#if (CFG_NAND_PAGE_SIZE > 512)
Please use an explicit test instead, i. e. for example
#if (CFG_NAND_PAGE_SIZE == 2048)
unless you are absolutley sure that all future devices (say, with 8k or 8k page sizes) will behave identical. Otherwise it will be a mess to clean up that code later.
Thanks.
Best regards,
Wolfgang Denk
On Tuesday 12 February 2008, Wolfgang Denk wrote:
#if (CFG_NAND_PAGE_SIZE > 512)
Please use an explicit test instead, i. e. for example
#if (CFG_NAND_PAGE_SIZE == 2048)
unless you are absolutley sure that all future devices (say, with 8k or 8k page sizes) will behave identical. Otherwise it will be a mess to clean up that code later.
I got my idea from the current Linux MTD NAND drivers (and U-Boot btw). Here the distinction between small page and large page devices is done this way:
if (mtd->writesize > 512) lp.. else sp..
That's why I still prefer my suggestion.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
In message 200802120711.17212.sr@denx.de you wrote:
I got my idea from the current Linux MTD NAND drivers (and U-Boot btw). Here the distinction between small page and large page devices is done this way:
...
That's why I still prefer my suggestion.
Ok, thanks for checking.
Best regards,
Wolfgang Denk
Hi Stefan
Thanks for all the help in solving the problem. I have some questions about submitting the patch and testing of the patch.
First of all I am working on proprietary board based on AMCC sequoia board. Hence some of the files I changed are module specific like config.mk in nand_spl/board/....and I also modified the following lines in u-boot-nand.lds
cpu/ppc4xx/start.o (.text)
/* Align to next NAND block */ . = ALIGN(0x20000); common/environment.o (.ppcenv) /* Keep some space here for redundant env and potential bad env blocks */ . = ALIGN(0x80000);
Above is to allow some space for u-boot environment and possible bad blocks. This file is also module specific.
Besides these two files I have changed nand_boot.c and ndfc.c. Considering all this, how should I create this patch. Should I create a patch for the sequoia board?
Also how are we going to test this patch? I'll make sure it meets all the requirement in terms of coding style, etc but as far as testing goes, I can only test on my board because sequoia reference board comes only with 256Mb NAND flash.
Thanks
Nikhil
On Feb 12, 2008 2:31 PM, Wolfgang Denk wd@denx.de wrote:
In message 200802120711.17212.sr@denx.de you wrote:
I got my idea from the current Linux MTD NAND drivers (and U-Boot btw). Here the distinction between small page and large page devices is done this way:
...
That's why I still prefer my suggestion.
Ok, thanks for checking.
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@denx.de The people of Gideon have always believed that life is sacred. That the love of life is the greatest gift ... We are incapable of destroying or interfering with the creation of that which we love so deeply -- life in every form from fetus to developed being. -- Hodin of Gideon, "The Mark of Gideon", stardate 5423.4
Hi Nikhil.
On Thursday 14 February 2008, Nikhil Gautam wrote:
Thanks for all the help in solving the problem. I have some questions about submitting the patch and testing of the patch.
First of all I am working on proprietary board based on AMCC sequoia board.
You need to create a new board port for your custom board. This could be done by "cloning" the Sequoia port and modifying it.
Hence some of the files I changed are module specific like config.mk in nand_spl/board/....and I also modified the following lines in u-boot-nand.lds
cpu/ppc4xx/start.o (.text) /* Align to next NAND block */ . = ALIGN(0x20000); common/environment.o (.ppcenv) /* Keep some space here for redundant env and potential bad env blocks*/ . = ALIGN(0x80000);
Above is to allow some space for u-boot environment and possible bad blocks. This file is also module specific.
Right. All this should *not* go into the Sequoia port but into your new board port. The infrastructure is ready for it.
Besides these two files I have changed nand_boot.c and ndfc.c.
Sure. These are probably the only common changes needed.
Considering all this, how should I create this patch. Should I create a patch for the sequoia board?
*NO*. Please don't. Create you own board port.
Also how are we going to test this patch? I'll make sure it meets all the requirement in terms of coding style, etc but as far as testing goes, I can only test on my board because sequoia reference board comes only with 256Mb NAND flash.
You will test this on your board and I (or somebody else) will test it on already supported NAND booting platforms.
Hope this helps.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
participants (3)
-
Nikhil Gautam -
Stefan Roese -
Wolfgang Denk