Move machine specific code to board at s3c64xx
Subsystems (2)
PATCH 1/1 Move machine specific code to board at s3c64xx
Move machine specific code to smdk6400.
Some board use OneNAND instead of NAND.
---
board/samsung/smdk6400/lowlevel_init.S +7 -0
@@ -104,6 +104,13 @@ lowlevel_init: bl nand_asm_init #endif + /* Memory subsystem address 0x7e00f120 */ + ldr r0, =ELFIN_MEM_SYS_CFG + + /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */ + mov r1, #0xd + str r1, [r0] + bl mem_ctrl_asm_init /* Wakeup support. Don't know if it's going to be used, untested. */
cpu/arm1176/s3c64xx/cpu_init.S +0 -7
@@ -28,13 +28,6 @@ .globl mem_ctrl_asm_init mem_ctrl_asm_init: - /* Memory subsystem address 0x7e00f120 */ - ldr r0, =ELFIN_MEM_SYS_CFG - - /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */ - mov r1, #0xd - str r1, [r0] - /* DMC1 base address 0x7e001000 */ ldr r0, =ELFIN_DMC1_BASE
PATCH 1/1 Move machine specific code to board at s3c64xx
board/samsung/smdk6400/lowlevel_init.S
Quoted 6 lines · Kyungmin Park
Move machine specific code to smdk6400.
Some board use OneNAND instead of NAND.Signed-off-by Kyungmin Park <[email protected]>---
board/samsung/smdk6400/lowlevel_init.S +0
-0
Guennadi could you test it?
Best Regards,
J.
PATCH 1/1 Move machine specific code to board at s3c64xx
In reply to Kyungmin ParkQuoted 10 lines · Kyungmin Park
Move machine specific code to smdk6400.
Some board use OneNAND instead of NAND.Signed-off-by Kyungmin Park <[email protected]>---
board/samsung/smdk6400/lowlevel_init.S +0
-0
board/samsung/smdk6400/lowlevel_init.S lowlevel_init: · line 113
Quoted 10 lines
board/samsung/smdk6400/lowlevel_init.S +7
-0@@ -104,6 +104,13 @@ lowlevel_init: bl nand_asm_init #endif + /* Memory subsystem address 0x7e00f120 */ + ldr r0, =ELFIN_MEM_SYS_CFG + + /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */ + mov r1, #0xd + str r1, [r0] +
Hm, no, I don't quite agree. In principle, yes, this configuration can be considered platform-specific and moving it this way of course works. But:
1. The patch comment is not correct. This code doesn't select between NAND and OneNAND. It selects between (one of) NANDs and SROMs.
2. While at it, we could fix the value being written to the MEM_SYS_CFG register too. Currently it writes 0xd =
(1 << 0) - ignored, default 0, so, better set it to 0
| (0 << 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0 | (1 << 2) - ignored, default 0, so, better set it to 0 | (1 << 3) - set Xm0CSn[3] to SROMC CS3
So, we should just write an 8 in it:
+ mov r1, #0x8
+ str r1, [r0]
3. The comment in the code doesn't look right. According to the above it should read
+ /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */
The only thing that confuses me, is why the author, belonging to the manufacturer of the chip, hasn't done this. Maybe the documentation is wrong?
I tested it with the "8" - it works. So, once the issues are fixed, you get my "Tested-by", although, I guess, you can test it just as well:-)
Thanks
Guennadi
Quoted 21 lines
board/samsung/smdk6400/lowlevel_init.S +0
-0bl mem_ctrl_asm_init /* Wakeup support. Don't know if it's going to be used, untested. */cpu/arm1176/s3c64xx/cpu_init.S +0
-7@@ -28,13 +28,6 @@ .globl mem_ctrl_asm_init mem_ctrl_asm_init: - /* Memory subsystem address 0x7e00f120 */ - ldr r0, =ELFIN_MEM_SYS_CFG - - /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */ - mov r1, #0xd - str r1, [r0] - /* DMC1 base address 0x7e001000 */ ldr r0, =ELFIN_DMC1_BASE
Quoted 5 lines
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
---
Guennadi Liakhovetski, Ph.D.
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 at denx.de
PATCH 1/1 Move machine specific code to board at s3c64xx
Quoted 26 lines · Guennadi Liakhovetski
Quoted 10 lines · Kyungmin Park
Move machine specific code to smdk6400.
Some board use OneNAND instead of NAND.Signed-off-by Kyungmin Park <[email protected]>---
board/samsung/smdk6400/lowlevel_init.S +0
-0board/samsung/smdk6400/lowlevel_init.S lowlevel_init: · line 113
Quoted 10 lines
board/samsung/smdk6400/lowlevel_init.S +7
-0@@ -104,6 +104,13 @@ lowlevel_init: bl nand_asm_init #endif + /* Memory subsystem address 0x7e00f120 */ + ldr r0, =ELFIN_MEM_SYS_CFG + + /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */ + mov r1, #0xd + str r1, [r0] +Hm, no, I don't quite agree. In principle, yes, this configuration can be considered platform-specific and moving it this way of course works. But:
Quoted 2 lines
1. The patch comment is not correct. This code doesn't select between NAND and OneNAND. It selects between (one of) NANDs and SROMs.
Yes I just move to platform since it's board specific.
Quoted 14 lines
2. While at it, we could fix the value being written to the
MEM_SYS_CFGregister too. Currently it writes0xd=(1 << 0) - ignored, default 0, so, better set it to 0
| (0 << 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0 | (1 << 2) - ignored, default 0, so, better set it to 0 | (1 << 3) - set Xm0CSn[3] to SROMC CS3So, we should just write an 8 in it:
(quoted diff) +2
-0+ mov r1, #0x8 + str r1, [r0]
Quoted 4 lines
3. The comment in the code doesn't look right. According to the above it should read
+ /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */
Right, and also add OneNAND & NFCON is depends on XNANDSEL.
As you know mem_ctrl_asm_init is common code and other boards can use it without board specific codes.
In OneNAND board, it should be set as 0x1002
Quoted 5 lines
The only thing that confuses me, is why the author, belonging to the manufacturer of the chip, hasn't done this. Maybe the documentation is wrong?
Maybe he missed it. Document is right.
Thank you,
Kyungmin Park
PATCH 1/1 Move machine specific code to board at s3c64xx
Quoted 10 lines · Kyungmin Park
Quoted 10 lines
(1 << 0) - ignored, default 0, so, better set it to 0
| (0 << 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0 | (1 << 2) - ignored, default 0, so, better set it to 0 | (1 << 3) - set Xm0CSn[3] to SROMC CS3So, we should just write an 8 in it:
(quoted diff) +2
-0+ mov r1, #0x8 + str r1, [r0]
Quoted 6 lines
Quoted 4 lines
3. The comment in the code doesn't look right. According to the above it should read
+ /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */
Right, and also add OneNAND & NFCON is depends on XNANDSEL.
In the datasheet this signal is called XSELNAND. And I don't think we have to quote this in the comment. This is a hardware configuration issue, not software, and we are not explaining the complete NAND configuration here, otherwise we would have to mention OM signals too, maybe more.
Quoted 4 lines
As you know
mem_ctrl_asm_initis common code and other boards can use it without board specific codes.In OneNAND board, it should be set as
0x1002
Sorry, do not understand what "it." If you mean the MEM_SYS_CFG then I also don't understand this. As I quoted from the datasheet above, bit 1 set to 0 (0 << 1) is for _both_ - NAND or OneNAND. You suggest to set it to 1, which is SROMC CS2. And (1 << 12) is the data bus width, which also doesn't seem to be directly related to the NAND / OneNAND selection. Or did you mean another register?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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: [email protected]
PATCH 1/1 Move machine specific code to board at s3c64xx
In reply to Guennadi LiakhovetskiDear Guennadi Liakhovetski,
Review
Quoted 13 lines · In message <[email protected]> you wrote:
2. While at it, we could fix the value being written to the
MEM_SYS_CFGregister too. Currently it writes0xd=(1 << 0) - ignored, default 0, so, better set it to 0
| (0 << 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0 | (1 << 2) - ignored, default 0, so, better set it to 0 | (1 << 3) - set Xm0CSn[3] to SROMC CS3So, we should just write an 8 in it:
(quoted diff) +2
-0+ mov r1, #0x8 + str r1, [r0]
No, you should not use magic numbers like 0x08 or 0x0d which nobody can read but use meaningful preprocessor constants here so we actually understand the code without looking up the bits in the documentation.
Best regards,
Wolfgang Denk
Signature · 5 lines
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 at denx.de Death, when unnecessary, is a tragic thing. -- Flint, "Requiem for Methuselah", stardate 5843.7
PATCH 1/1 Move machine specific code to board at s3c64xx
In reply to Guennadi LiakhovetskiQuoted 27 lines · Guennadi Liakhovetski
Quoted 10 lines · Kyungmin Park
Quoted 10 lines
(1 << 0) - ignored, default 0, so, better set it to 0
| (0 << 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0 | (1 << 2) - ignored, default 0, so, better set it to 0 | (1 << 3) - set Xm0CSn[3] to SROMC CS3So, we should just write an 8 in it:
(quoted diff) +2
-0+ mov r1, #0x8 + str r1, [r0]Quoted 6 lines
Quoted 4 lines
3. The comment in the code doesn't look right. According to the above it should read
+ /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */
Right, and also add OneNAND & NFCON is depends on XNANDSEL.
In the datasheet this signal is called XSELNAND. And I don't think we have to quote this in the comment. This is a hardware configuration issue, not software, and we are not explaining the complete NAND configuration here, otherwise we would have to mention OM signals too, maybe more.
Quoted 3 lines
As you know
mem_ctrl_asm_initis common code and other boards can use it without board specific codes.
Quoted 9 lines
Quoted 1 line
In OneNAND board, it should be set as
0x1002Sorry, do not understand what "it." If you mean the
MEM_SYS_CFGthen I also don't understand this. As I quoted from the datasheet above, bit 1 set to 0 (0 << 1) is for _both_ - NAND or OneNAND. You suggest to set it to 1, which is SROMC CS2. And (1 << 12) is the data bus width, which also doesn't seem to be directly related to the NAND / OneNAND selection. Or did you mean another register?
Right, I write wrong value, MEM_SYS_CFG has 0x1000. In OneNAND booting mode, MP0_CS_CFG[1] and MP0_CS_CFG[3] are ignored.
It's not easy to describe since it depends on hardware configuration. However, there are not too much configurations
S3C64XX_MEM_SYS_CFG_NAND 0x0008S3C64XX_MEM_SYS_CFG_ONENAND 0x1000S3C64XX_MEM_SYS_CFG_MOVINAND 0x????
Is there more?
Thank you,
Kyungmin Park
PATCH 1/1 Move machine specific code to board at s3c64xx
Quoted 10 lines · Kyungmin Park
Quoted 9 lines
Quoted 1 line
In OneNAND board, it should be set as
0x1002Sorry, do not understand what "it." If you mean the
MEM_SYS_CFGthen I also don't understand this. As I quoted from the datasheet above, bit 1 set to 0 (0 << 1) is for _both_ - NAND or OneNAND. You suggest to set it to 1, which is SROMC CS2. And (1 << 12) is the data bus width, which also doesn't seem to be directly related to the NAND / OneNAND selection. Or did you mean another register?
Quoted 8 lines
Right, I write wrong value,
MEM_SYS_CFGhas0x1000. In OneNAND booting mode, MP0_CS_CFG[1] and MP0_CS_CFG[3] are ignored.It's not easy to describe since it depends on hardware configuration. However, there are not too much configurations
S3C64XX_MEM_SYS_CFG_NAND0x0008S3C64XX_MEM_SYS_CFG_ONENAND0x1000
????? I asked above what the bus width has to do with OneNAND selection, you didn't reply.
Quoted 1 line
S3C64XX_MEM_SYS_CFG_MOVINAND0x????
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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 at denx.de
PATCH 1/1 Move machine specific code to board at s3c64xx
Quoted 15 lines · Guennadi Liakhovetski
Quoted 13 lines · Kyungmin Park
Quoted 9 lines
Quoted 1 line
In OneNAND board, it should be set as
0x1002Sorry, do not understand what "it." If you mean the
MEM_SYS_CFGthen I also don't understand this. As I quoted from the datasheet above, bit 1 set to 0 (0 << 1) is for _both_ - NAND or OneNAND. You suggest to set it to 1, which is SROMC CS2. And (1 << 12) is the data bus width, which also doesn't seem to be directly related to the NAND / OneNAND selection. Or did you mean another register?Right, I write wrong value,
MEM_SYS_CFGhas0x1000. In OneNAND booting mode, MP0_CS_CFG[1] and MP0_CS_CFG[3] are ignored.
Quoted 8 lines
Quoted 5 lines
It's not easy to describe since it depends on hardware configuration. However, there are not too much configurations
S3C64XX_MEM_SYS_CFG_NAND0x0008S3C64XX_MEM_SYS_CFG_ONENAND0x1000????? I asked above what the bus width has to do with OneNAND selection, you didn't reply.
OneNAND has always 16-bit butwidth. there's no exception.
Quoted 2 lines
Quoted 2 lines
S3C64XX_MEM_SYS_CFG_MOVINAND0x????
I don't tested boot from MMC. So I don't know which value is right
Thank you,
Kyungmin Park
PATCH 1/1 Move machine specific code to board at s3c64xx
In reply to Guennadi LiakhovetskiDear Guennadi Liakhovetski,
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 4 lines
Quoted 2 lines
+ /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */
Right, and also add OneNAND & NFCON is depends on XNANDSEL.
In the datasheet this signal is called XSELNAND. And I don't think we have to quote this in the comment. This is a hardware configuration issue, not software, and we are not explaining the complete NAND configuration here, otherwise we would have to mention OM signals too, maybe more.
Hey, actually I do think that describing which hardware configurations the software performs is a Good Thing (TM).
I do NOT want to have to look up each and every bit in the reference manual when reading the source code.
Meaningful names are a good thing, also - much better than cryptic numbers everywhere.
Quoted 8 lines
Quoted 1 line
In OneNAND board, it should be set as
0x1002Sorry, do not understand what "it." If you mean the
MEM_SYS_CFGthen I also don't understand this. As I quoted from the datasheet above, bit 1 set to 0 (0 << 1) is for _both_ - NAND or OneNAND. You suggest to set it to 1, which is SROMC CS2. And (1 << 12) is the data bus width, which also doesn't seem to be directly related to the NAND / OneNAND selection. Or did you mean another register?
Get rid of these magic numbers. Use readable constants everywhere!
Best regards,
Wolfgang Denk
Signature · 5 lines
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 at denx.de Suffocating together ... would create heroic camaraderie. -- Khan Noonian Singh, "Space Seed", stardate 3142.8
PATCH 1/1 Move machine specific code to board at s3c64xx
In reply to Kyungmin ParkQuoted 7 lines · Kyungmin Park
Quoted 5 lines
Quoted 2 lines
S3C64XX_MEM_SYS_CFG_NAND0x0008S3C64XX_MEM_SYS_CFG_ONENAND0x1000????? I asked above what the bus width has to do with OneNAND selection, you didn't reply.
OneNAND has always 16-bit butwidth. there's no exception.
Ok, thanks, but I wouldn't call the macro ONENAND, but rather 16BIT, but that's just IMHO.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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 at denx.de
PATCH 1/1 Move machine specific code to board at s3c64xx
In reply to Wolfgang DenkQuoted 8 lines · Wolfgang Denk
Dear Guennadi Liakhovetski,
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 4 lines
Quoted 2 lines
+ /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */
Right, and also add OneNAND & NFCON is depends on XNANDSEL.
Quoted 7 lines
Quoted 4 lines
In the datasheet this signal is called XSELNAND. And I don't think we have to quote this in the comment. This is a hardware configuration issue, not software, and we are not explaining the complete NAND configuration here, otherwise we would have to mention OM signals too, maybe more.
Hey, actually I do think that describing which hardware configurations the software performs is a Good Thing (TM).
Exactly, "which hardware configurations the software performs", XSELNAND is not performed in software, this is just a pin you wire high or low on your board. That's why I said we might not need to comment upon it. That's how I interpreted the datasheet anyway.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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 at denx.de
PATCH 1/1 Move machine specific code to board at s3c64xx
Dear Guennadi Liakhovetski,
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 3 lines
Hey, actually I do think that describing which hardware configurations the software performs is a Good Thing (TM).
Exactly, "which hardware configurations the software performs", XSELNAND is not performed in software, this is just a pin you wire high or low on your board. That's why I said we might not need to comment upon it. That's how I interpreted the datasheet anyway.
I don;t think how this would make a difference. Even if the signal is defined by the hardware dsign - the very moment I am referencing this signal in any piece of software I should explain it so the reader of the code understands what I'm doing.
Using meaningful names instead of magic numbers is a minimum to do.
Best regards,
Wolfgang Denk
Signature · 6 lines
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 at denx.de "It ain't so much the things we don't know that get us in trouble. It's the things we know that ain't so." - Artemus Ward aka Charles Farrar Brown
PATCH 1/1 Move machine specific code to board at s3c64xx
Quoted 12 lines · Wolfgang Denk
Dear Guennadi Liakhovetski,
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 3 lines
Hey, actually I do think that describing which hardware configurations the software performs is a Good Thing (TM).
Exactly, "which hardware configurations the software performs", XSELNAND is not performed in software, this is just a pin you wire high or low on your board. That's why I said we might not need to comment upon it. That's how I interpreted the datasheet anyway.
Quoted 4 lines
I don;t think how this would make a difference. Even if the signal is defined by the hardware dsign - the very moment I am referencing this signal in any piece of software I should explain it so the reader of the code understands what I'm doing.
I don't think this pin is referenced in software, at least not in this register, AFAICS. The only reason why Kyungmin mentioned it and why it is mentioned in the datasheet in the description of this register, is that this pin defines the selection between NAND and OneNAND - along with some other pins (OM[4:1] or some such). So, you cannot set this pin in software, you cannot read this pin in software (I think), maybe you have to switch a jumper when selecting another configuration, but that again has little to do with software, IMHO.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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 at denx.de