Support for csb535fs / i.MX21 LiteKit.
PATCH 1/1 Support for csb535fs / i.MX21 LiteKit.
Hi all,
This patch, for the 1.2.0 version, adds support for the csb535fs board embedded in a csb935fs breakout board. The set is known as i.MX21 Litekit.
The main features of the board are:
csb535fs.
- MC9328MX21 processor with an ARM926EJS core.
- 8 Mbytes of NOR FLASH.
- 64 MBytes of SDRAM.
csb935fs
- CS8900 10 MBit Ethernet controller.
- RS232.
- USB.
- SD/MMC.
- Compact Flash.
- 3,5'' 240*320 QVGA TFT LCD.
This patch only adds support for:
- MC9328MX21 processor with an ARM926EJS core.
- 8 Mbytes of NOR FLASH.
- 64 MBytes of SDRAM.
- CS8900 10 MBit Ethernet controller.
- RS232.
CHANGELOG
* Add support for the csb535fs board:
Patch by Jose Maria Lopez, 27 February 2007
-------------- next part --------------
A non-text attachment was scrubbed...
Name: csb535fs.patch.tgz
Type: application/x-compressed-tar
Size: 13652 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070227/0cb3d930/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070227/0cb3d930/attachment.vcf
PATCH 1/1 Support for csb535fs / i.MX21 LiteKit.
Quoted 3 lines · Txema Lopez
Hi all,
This patch, for the 1.2.0 version, adds support for the csb535fs board embedded in a csb935fs breakout board. The set is known as i.MX21 Litekit.
With a quick perusal, the patch looks mostly okay. Unfortunately, it's inconvenient to review because it was sent as a gzipped attachment instead of inline (I can't just hit 'reply' and start typing comments).
Here are some general comments:
- You should add your copyright to all new files that you've added. At the moment, your copyright only appears on a few of the new files.
- Where did include/asm-arm/arch-imx21/imx21-regs.h come from? There is no copyright notice on it at all.
- There's a fair bit of inconsistent whitespace (intermixed space and tab characters).
- I do wonder at the amount of boilerplate required for each new board port (but that's a longer ranged questions directed at the whole of u-boot).
Cheers,
g.
Signature · 4 lines
Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
PATCH 1/1 Support for csb535fs / i.MX21 LiteKit.
Quoted 8 lines · Grant Likely
Quoted 4 lines · Txema Lopez
Hi all,
This patch, for the 1.2.0 version, adds support for the csb535fs board embedded in a csb935fs breakout board. The set is known as i.MX21 Litekit.
Quoted 5 lines
With a quick perusal, the patch looks mostly okay. Unfortunately, it's inconvenient to review because it was sent as a gzipped attachment instead of inline (I can't just hit 'reply' and start typing comments).
I'm sorry, the patch size is more than the 40k U-Boot's limit, so ...
Quoted 3 lines
Here are some general comments:
- You should add your copyright to all new files that you've added. At the moment, your copyright only appears on a few of the new files.
The cpu/arm926ejs/imx21 files have been copied from the cpu/arm920t/imx with a few modifications, so in the files with minor changes I've left the old copyright.
Quoted 2 lines
- Where did
include/asm-arm/arch-imx21/imx21-regs.hcome from? There is no copyright notice on it at all.
It is a modification of include/asm-arm/arch-imx/imx-regs.h
Quoted 2 lines
- There's a fair bit of inconsistent whitespace (intermixed space and tab characters).
Please, could you be more explicit and tell me where these mistakes are .
Quoted 4 lines
- I do wonder at the amount of boilerplate required for each new board port (but that's a longer ranged questions directed at the whole of u-boot).
Me too.
Best regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070228/d5bedb08/attachment.vcf
PATCH 1/1 Support for csb535fs / i.MX21 LiteKit.
Quoted 10 lines · Txema Lopez
Quoted 8 lines · Grant Likely
Quoted 4 lines · Txema Lopez
Hi all,
This patch, for the 1.2.0 version, adds support for the csb535fs board embedded in a csb935fs breakout board. The set is known as i.MX21 Litekit.
Quoted 6 lines
Quoted 5 lines
With a quick perusal, the patch looks mostly okay. Unfortunately, it's inconvenient to review because it was sent as a gzipped attachment instead of inline (I can't just hit 'reply' and start typing comments).
I'm sorry, the patch size is more than the 40k U-Boot's limit, so ...
... it then makes sense to break it up into a couple of patches. :-) shorter patches are easier to review anyway. Plus with smaller patches, changes that get 'acked' aren't necessarily held up by changes that need some more work.
Quoted 8 lines
Quoted 4 lines
Here are some general comments:
- You should add your copyright to all new files that you've added. At the moment, your copyright only appears on a few of the new files.The cpu/arm926ejs/imx21 files have been copied from the cpu/arm920t/imx with a few modifications, so in the files with minor changes I've left the old copyright.
Hmmm, indeed. There are large sections of identical, or near identical code between the two. If I replace all the IMX21_* macros with IMX_* in imx-regs.h, it results in a file that is somewhere around 75% identical.
I know that slightly modified duplicate code is common in u-boot, so this is not an critique on your work, but I'd really like to move away from this mode of operation. Duplicating the original file and modifying it is certainly the easiest way to add support for a new board/cpu, but I think it just leads to maintenance problems down the roads. For example, if one file has been duplicated with minor mods 10 times and a bug is found in it at a later date; the bug fix needs to be applied to 10 files, not one.
Unfortunately, this situation is messy because the imx is in cpu/arm920t and imx32 is in cpu/arm926ejs. It probably requires the creation of a new directory for the common imx soc bits, but where? Perhaps under lib_arm/imx?
Quoted 5 lines
Quoted 3 lines
- Where did
include/asm-arm/arch-imx21/imx21-regs.hcome from? There is no copyright notice on it at all.It is a modification of
include/asm-arm/arch-imx/imx-regs.h
ok
Quoted 5 lines
Quoted 3 lines
- There's a fair bit of inconsistent whitespace (intermixed space and tab characters).
Please, could you be more explicit and tell me where these mistakes are .
Configure your editor to make tab characters and trailing whitespace visually distinct and you'll see them.
- lowlevel_init.S has a dozen or so lines indented with 4 spaces instead of a tab character. The coding standard is for indentation with tab characters, and tab stops are at 8 character columns.
- imx21-regs.h: inconsistent throughout; but you probably inherited this whitespace
- serial.c has a few lines where spaces precede tabs; pretty minor stuff.
Quoted 6 lines
Quoted 5 lines
- I do wonder at the amount of boilerplate required for each new board port (but that's a longer ranged questions directed at the whole of u-boot).
Me too.
:-)
Signature · 4 lines
Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
PATCH 1/1 Support for csb535fs / i.MX21 LiteKit.
Quoted 6 lines · Grant Likely
I know that slightly modified duplicate code is common in u-boot, so this is not an critique on your work, but I'd really like to move away from this mode of operation. Duplicating the original file and modifying it is certainly the easiest way to add support for a new
And It makes the code more readable. It's the pro.
Quoted 2 lines
10 times and a bug is found in it at a later date; the bug fix needs to be applied to 10 files, not one.
Yes, It's the con. But, how many times does it happen?.
Quoted 6 lines
Unfortunately, this situation is messy because the imx is in cpu/arm920t and imx32 is in cpu/arm926ejs. It probably requires the creation of a new directory for the common imx soc bits, but where? Perhaps under lib_arm/imx?
Ummm, lib_arm/imx?. I think this mixes up concepts.
Why not to decouple the arm cores and the SoC code?. For example:
cpu/arm/cores/arm926ejs
cpu/arm/soc/imxPerhaps, there was a discussion about this in U-Boot and I'm talking nonsense.
Anyway, you are the mainteiner so you have the last say. ;-)
Best regards,
Txema.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070301/4c8fb6c2/attachment.vcf
PATCH 1/1 Support for csb535fs / i.MX21 LiteKit.
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 4 lines
I know that slightly modified duplicate code is common in u-boot, so this is not an critique on your work, but I'd really like to move away from this mode of operation. Duplicating the original file and modifying it is certainly the easiest way to add support for a new
And It makes the code more readable. It's the pro.
No, it doesn't make anything more redable. Distributing the code over too many polaces just pollutes the source tree.
Quoted 4 lines
Quoted 2 lines
10 times and a bug is found in it at a later date; the bug fix needs to be applied to 10 files, not one.
Yes, It's the con. But, how many times does it happen?.
All too many times.
Quoted 4 lines
Ummm, lib_arm/imx?. I think this mixes up concepts.
Why not to decouple the arm cores and the SoC code?. For example:cpu/arm/cores/arm926ejs cpu/arm/soc/imx
No, but eventually cpu/arm/imx_common plus cpu/arm926ejs
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de I used to be indecisive, now I'm not sure.
PATCH 1/1 Support for csb535fs / i.MX21 LiteKit.
In reply to Txema LopezHi Wolfgang,
Please, let me know if i'm wrong. Is this your proposal?
ifdef SOC
ifeq ($(SOC),imx)
LIBS += cpu/$(SOC)_common/lib$(SOC).a
else
LIBS += cpu/$(CPU)/$(SOC)/lib$(SOC).a
endif
endif
Hi Grant,
If you are agree, I'll start up with the changes.
Best Regards,
Txema.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070301/409373d8/attachment.vcf
PATCH 1/1 Support for csb535fs / i.MX21 LiteKit.
In reply to Txema LopezQuoted 7 lines · Txema Lopez
Quoted 4 lines · Grant Likely
I know that slightly modified duplicate code is common in u-boot, so this is not an critique on your work, but I'd really like to move away from this mode of operation. Duplicating the original file and modifying it is certainly the easiest way to add support for a new
And It makes the code more readable. It's the pro.
I disagree; adding more code volume makes it harder to find stuff.
Quoted 4 lines
Quoted 2 lines
10 times and a bug is found in it at a later date; the bug fix needs to be applied to 10 files, not one.
Yes, It's the con. But, how many times does it happen?.
Very frequently
Quoted 9 lines
Quoted 5 lines
Unfortunately, this situation is messy because the imx is in cpu/arm920t and imx32 is in cpu/arm926ejs. It probably requires the creation of a new directory for the common imx soc bits, but where? Perhaps under lib_arm/imx?
Ummm, lib_arm/imx?. I think this mixes up concepts.
Why not to decouple the arm cores and the SoC code?. For example:cpu/arm/cores/arm926ejs cpu/arm/soc/imx
That's an idea too. I don't really know where it should go and I'm throwing out ideas.
To put it in cpu/arm/soc/* I think will require changes to the config system. If I understand correctly, the Makefiles assume the CPU support code is one level below the 'cpu' directory. I don't know what the impact is of moving it deeper.
Quoted 2 lines
Perhaps, there was a discussion about this in U-Boot and I'm talking nonsense.
Not that I know of; this is a new discussion.
Quoted 1 line
Anyway, you are the mainteiner so you have the last say. ;-)
Nope, I'm just a reviewer. :-)
g.
Signature · 4 lines
Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195