[U-Boot-Users] Port U-Boot to SBC-2410X
hi, all.
SBC-2410X is a board based on SAMSUNG S3C2410 made by friendly-arm, which is similiar to smdk2410. Now, I succeed to port U-Boot to SBC-2410X.
In addition to write the new hardware-specific configurations for SBC-2410X according to steps from U-Boot's README, I make U-Boot's nand subsystem work on SBC-2410X and add to hush cmdline-editing (but AUTO_COMPLETE cannot work to go with it yet).
About bugs of NAND subsystem ============================= The original nand subsystem lacks flash_chip-specific functions like NF_Conf and the related enum variable NFCE_STATE for each board, right? Though some boards put them in one sole head file in their board directory, it seems broken because the compilation always shows errors.
Take VCMA9 board for example. Though VCMA9 defines NFCE_STATE, NF_Cmd etc in "board/mpl/vcma9/vcma9.h", but when compiling arm-linux-gcc will complains: In file included from /root/u-boot-1.1.3/include/config.h:2, from /root/u-boot-1.1.3/include/common.h:35, from cmd_nand.c:11: /root/u-boot-1.1.3/include/configs/VCMA9.h:280:1: warning: this is the location of the previous definition cmd_nand.c: In function `NanD_WaitReady': cmd_nand.c:557: warning: implicit declaration of function `NF_WaitRB' cmd_nand.c: In function `NanD_Command': cmd_nand.c:572: warning: implicit declaration of function `NF_Cmd' cmd_nand.c:566: warning: unused variable `nandptr' cmd_nand.c: In function `NanD_Address': cmd_nand.c:614: warning: implicit declaration of function `NF_Addr' cmd_nand.c: In function `NanD_IdentChip': cmd_nand.c:645: warning: implicit declaration of function `NF_SetCE' cmd_nand.c:645: error: `NFCE_LOW' undeclared (first use in this function) cmd_nand.c:645: error: (Each undeclared identifier is reported only once cmd_nand.c:645: error: for each function it appears in.) cmd_nand.c:652: error: `NFCE_HIGH' undeclared (first use in this function) cmd_nand.c:671: warning: implicit declaration of function `NF_Read' cmd_nand.c: In function `NanD_ReadBuf': cmd_nand.c:812: warning: unused variable `nandptr' cmd_nand.c: In function `nand_read_ecc': cmd_nand.c:915: error: `NFCE_LOW' undeclared (first use in this function) cmd_nand.c:1029: error: `NFCE_HIGH' undeclared (first use in this function) cmd_nand.c: In function `nand_write_page': cmd_nand.c:1136: warning: implicit declaration of function `NF_Write' cmd_nand.c:1047: warning: unused variable `nandptr' cmd_nand.c: In function `nand_write_ecc': cmd_nand.c:1278: error: `NFCE_LOW' undeclared (first use in this function) cmd_nand.c:1324: error: `NFCE_HIGH' undeclared (first use in this function) cmd_nand.c: In function `nand_read_oob': cmd_nand.c:1356: error: `NFCE_LOW' undeclared (first use in this function) cmd_nand.c:1385: error: `NFCE_HIGH' undeclared (first use in this function) cmd_nand.c: In function `nand_write_oob': cmd_nand.c:1407: error: `NFCE_LOW' undeclared (first use in this function) cmd_nand.c:1461: error: `NFCE_HIGH' undeclared (first use in this function) cmd_nand.c:1399: warning: unused variable `nandptr' cmd_nand.c: In function `nand_erase': cmd_nand.c:1530: error: `NFCE_LOW' undeclared (first use in this function) cmd_nand.c:1609: error: `NFCE_HIGH' undeclared (first use in this function) make[1]: *** [cmd_nand.o] Error 1 make[1]: Leaving directory `/root/u-boot-1.1.3/common' make: *** [common/libcommon.a] Error 2
I finally put them in "include/linux/mtd/nand.h", and it works.
cmdline editing ================== Though U-Boot brings in hush, it lacks cmdline-editing. That is inconvenient. I pick codes heavily borrowed from vivi bootloader and integrate them into U-Boot. Now, the hush can locate the history command and acts like xterm.
I would like to pack the new board codes and nand subsystem fixes as one patch, while the cmdline-editing codes (in "common/main.c") is the other. Is this ok?
gdlc mail Open WebMail Project (http://openwebmail.org)
In message 20050831135322.M7728@gd-linux.com you wrote:
SBC-2410X is a board based on SAMSUNG S3C2410 made by friendly-arm, which is similiar to smdk2410. Now, I succeed to port U-Boot to SBC-2410X.
Congrats.
In addition to write the new hardware-specific configurations for SBC-2410X according to steps from U-Boot's README, I make U-Boot's nand subsystem work
Please note that a complete rewrite of the NAND code has been discussed several times before. There is some work in progress (performed by Ladislav Michl ladis@linux-mips.org) whic is available in the "testing-NAND" branch of the git repository at source.denx.net.
It makes IMHO littel sense to add patches to the old code. Please help improving / fixing the rewqrite instead.
on SBC-2410X and add to hush cmdline-editing (but AUTO_COMPLETE cannot work to go with it yet).
Ummm.. why only to the hush shell and not as a more general implementation for the simple command interpreter, too?
I pick codes heavily borrowed from vivi bootloader and integrate them into U-Boot. Now, the hush can locate the history command and acts like xterm.
Acts like xterm? This makes zero sense to me. An xterm does not provide any command line interface at all. It is just a terminal emulator in which you can run certain applications...
I would like to pack the new board codes and nand subsystem fixes as one patch, while the cmdline-editing codes (in "common/main.c") is the other. Is this ok?
Make this 3 parts as required by the README: split unrelated changes into separate commits: one for your new baord support, one for the command line extension, and one (eventually) for the NAND (if you still want to submit it, but chances that it will get accepted with the old code are epsilon).
Best regards,
Wolfgang Denk
On Wed, Aug 31, 2005 at 05:19:11PM +0200, Wolfgang Denk wrote:
Please note that a complete rewrite of the NAND code has been discussed several times before. There is some work in progress (performed by Ladislav Michl ladis@linux-mips.org) whic is available in the "testing-NAND" branch of the git repository at source.denx.net.
Wolfgang,
I promised you to send update over a weekend, but didn't tell you which one ;-). Although normaly I do not have problems explaining my boss why I'm working on something we do not necessarily need (nice clean code :)), he has not so good understanding when I'm doing it when I should hunt more important bugs elsewhere. My apologies to everyone...
It makes IMHO littel sense to add patches to the old code. Please help improving / fixing the rewqrite instead.
Patch against "testing-NAND" branch can be found here: ftp://ftp.linux-mips.org/pub/linux/mips/people/ladis/u-boot/u-boot-nand.diff It also contains support for new board NetStar (it is not meant to be included - I want to maintain it outside U-Boot, but I'd agree to put it into "testing-NAND" branch for reference), which shows sample implementation. Note that you have to define CONFIG_NEW_NAND_CODE to actually compile and use new code. Original <linux/mtd/nand.h> was moved to <linux/mtd/nand_old.h> and so has to be fixed all unconverted boards includes (I do not have energy to do it now and test if they still compiles). Ideally old and new code should be able to coexist. Please let me know if you experience any problems or if you want me to split patch into smaller chunks.
File list: drivers/nand/* - Linux MTD include/linux/mtd/* - MTD headers include/nand.h - compat stuff common/cmd_nand_new.c - user command interface to Linux MTD (*) fs/jffs2/jffs2_nand_1pass.c fs/jffs2/jffs2_nand_private.h - somewhat faster jffs2 file loader (*)
(*) - needs discussion and improvements, it's not finished.
Best regards, ladis
Dear Ladislav,
in message 20050831212122.GA32559@orphique you wrote:
I promised you to send update over a weekend, but didn't tell you which one ;-). Although normaly I do not have problems explaining my boss why
I know how this goes. Been there before. Can't remember when for the first time :-(
Patch against "testing-NAND" branch can be found here: ftp://ftp.linux-mips.org/pub/linux/mips/people/ladis/u-boot/u-boot-nand.diff
Can you please either send this by e-mail, or put it on a server that actually works?
It also contains support for new board NetStar (it is not meant to be included - I want to maintain it outside U-Boot, but I'd agree to put it into "testing-NAND" branch for reference), which shows sample
If I add it to "testing-NAND" (and it makes a lot of sense if this is a working example) then it will go more or less automagically into the main tree as soon as I merge branches. Is this acceptable to you?
implementation. Note that you have to define CONFIG_NEW_NAND_CODE to actually compile and use new code. Original <linux/mtd/nand.h> was moved to <linux/mtd/nand_old.h> and so has to be fixed all unconverted boards includes (I do not have energy to do it now and test if they still compiles).
We will have to go through this when switching the code base.
Ideally old and new code should be able to coexist. Please let me know if you
But only one version shall be in the main branch at a time, i. e. one day the new code will replace the old one, and then all boards will need to be converted.
experience any problems or if you want me to split patch into smaller chunks.
Will do when I can lay my hands on the patch; keep getting timeouts only :-(
(*) - needs discussion and improvements, it's not finished.
Thanks for providing a sound base for this discussion.
Best regards,
Wolfgang Denk
On Thu, Sep 01, 2005 at 01:05:54AM +0200, Wolfgang Denk wrote:
Patch against "testing-NAND" branch can be found here: ftp://ftp.linux-mips.org/pub/linux/mips/people/ladis/u-boot/u-boot-nand.diff
Can you please either send this by e-mail, or put it on a server that actually works?
Hmm, something strange had happened, that server is very stable, backuped with diesel generator... Well, it works now. You might be interested in other patches in u-boot directory, all of them should be in your queue anyway.
It also contains support for new board NetStar (it is not meant to be included - I want to maintain it outside U-Boot, but I'd agree to put it into "testing-NAND" branch for reference), which shows sample
If I add it to "testing-NAND" (and it makes a lot of sense if this is a working example) then it will go more or less automagically into the main tree as soon as I merge branches. Is this acceptable to you?
Yes it is, but for sure I'll explain why I didn't want it to be accepted into mainline. Code in board/netstar runs only on one of many CPUs found in NetStar PBX. It is hardly possible to write code which will make that piece of hw act like PBX without hardware documentation and for other applications it is damn expensive toy. That's why I think there is no use of it for others, more boards means more worries when maintaining code and (nothing personal) patch acceptance speed makes it uninteresting for me. Moreover I basicaly made U-Boot act as second stage loader to allow safe upgrades, because one day I'd like to use yaffs2 filesystem and U-Boot currently doesn't support that. Thus I do not see any single advantage of integrating netstar code into mainline. Of course patch will be still avaible to conform with GPL.
We will have to go through this when switching the code base.
Ideally old and new code should be able to coexist. Please let me know if you
But only one version shall be in the main branch at a time, i. e. one day the new code will replace the old one, and then all boards will need to be converted.
Sure. My point was to allow incremental conversion, without breaking support for yet unconverted boards.
Best regards, ladis
Thank for your reply.
I am sorry that I make some confusion between "xterm" and "shell" (By the way, my english is so poor). In fact, hush in U-Boot calls function "readline" (like that bash may use GNU readline library) to handle I/O and implement terminal-extension, right? While terminal (usually serial driver in U-Boot) is a minimal subset to drive I/O devices, readline can do more like command history expansion and cmdline editing. My patch just modifys "readline" function to use vivi's extension codes, which also means that it just consider one line not a complete hush sentence (like "if...then...fi") as one history item. However, I think, it is useful enough.
About the nand subsystem, I am glad to hear that there exists one fresh driver branch. It makes sense to every user, I think. Because nor flash always works as BOOT rom, while nand flash always works as DATA rom. In my embedded project, I cannot do anything without a usable nand driver because the nor flash chip is 1MB while the nand flash chip is 64MB on my board. Where to place my kernel and the huge root filesystem? :-)
I will submit the three patches soon.
Best regards,
luo.jinhua
participants (3)
-
Ladislav Michl -
luo.jinhua -
Wolfgang Denk