[U-Boot] [PATCH] [ARM] Move machine specific code to board at s3c64xx
Move machine specific code to smdk6400. Some board use OneNAND instead of NAND.
Signed-off-by: Kyungmin Park kyungmin.park@samsung.com --- diff --git a/board/samsung/smdk6400/lowlevel_init.S b/board/samsung/smdk6400/lowlevel_init.S index e0119a7..53d9125 100644 --- a/board/samsung/smdk6400/lowlevel_init.S +++ b/board/samsung/smdk6400/lowlevel_init.S @@ -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. */ diff --git a/cpu/arm1176/s3c64xx/cpu_init.S b/cpu/arm1176/s3c64xx/cpu_init.S index 08bda99..32bb467 100644 --- a/cpu/arm1176/s3c64xx/cpu_init.S +++ b/cpu/arm1176/s3c64xx/cpu_init.S @@ -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
On 14:16 Wed 22 Oct , Kyungmin Park wrote:
Move machine specific code to smdk6400. Some board use OneNAND instead of NAND.
Signed-off-by: Kyungmin Park kyungmin.park@samsung.com
diff --git a/board/samsung/smdk6400/lowlevel_init.S b/board/samsung/smdk6400/lowlevel_init.S
Guennadi could you test it?
Best Regards, J.
On Wed, 22 Oct 2008, Kyungmin Park wrote:
Move machine specific code to smdk6400. Some board use OneNAND instead of NAND.
Signed-off-by: Kyungmin Park kyungmin.park@samsung.com
diff --git a/board/samsung/smdk6400/lowlevel_init.S b/board/samsung/smdk6400/lowlevel_init.S index e0119a7..53d9125 100644 --- a/board/samsung/smdk6400/lowlevel_init.S +++ b/board/samsung/smdk6400/lowlevel_init.S @@ -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
bl mem_ctrl_asm_init
/* Wakeup support. Don't know if it's going to be used, untested. */ diff --git a/cpu/arm1176/s3c64xx/cpu_init.S b/cpu/arm1176/s3c64xx/cpu_init.S index 08bda99..32bb467 100644 --- a/cpu/arm1176/s3c64xx/cpu_init.S +++ b/cpu/arm1176/s3c64xx/cpu_init.S @@ -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
U-Boot mailing list U-Boot@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@denx.de
On Thu, Oct 23, 2008 at 4:39 PM, Guennadi Liakhovetski lg@denx.de wrote:
On Wed, 22 Oct 2008, Kyungmin Park wrote:
Move machine specific code to smdk6400. Some board use OneNAND instead of NAND.
Signed-off-by: Kyungmin Park kyungmin.park@samsung.com
diff --git a/board/samsung/smdk6400/lowlevel_init.S b/board/samsung/smdk6400/lowlevel_init.S index e0119a7..53d9125 100644 --- a/board/samsung/smdk6400/lowlevel_init.S +++ b/board/samsung/smdk6400/lowlevel_init.S @@ -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, #0xdstr 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:
- 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.
- 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, #0x8str r1, [r0]
- 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
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
On Thu, 23 Oct 2008, Kyungmin Park wrote:
(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, #0x8str r1, [r0]
- 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.
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
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: office@denx.de
On Thu, Oct 23, 2008 at 5:00 PM, Guennadi Liakhovetski lg@denx.de wrote:
On Thu, 23 Oct 2008, Kyungmin Park wrote:
(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, #0x8str r1, [r0]
- 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.
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
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?
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 0x0008 S3C64XX_MEM_SYS_CFG_ONENAND 0x1000 S3C64XX_MEM_SYS_CFG_MOVINAND 0x????
Is there more?
Thank you, Kyungmin Park
On Thu, 23 Oct 2008, Kyungmin Park wrote:
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?
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 0x0008 S3C64XX_MEM_SYS_CFG_ONENAND 0x1000
????? I asked above what the bus width has to do with OneNAND selection, you didn't reply.
S3C64XX_MEM_SYS_CFG_MOVINAND 0x????
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@denx.de
On Thu, Oct 23, 2008 at 5:42 PM, Guennadi Liakhovetski lg@denx.de wrote:
On Thu, 23 Oct 2008, Kyungmin Park wrote:
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?
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 0x0008 S3C64XX_MEM_SYS_CFG_ONENAND 0x1000
????? 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.
S3C64XX_MEM_SYS_CFG_MOVINAND 0x????
I don't tested boot from MMC. So I don't know which value is right
Thank you, Kyungmin Park
On Thu, 23 Oct 2008, Kyungmin Park wrote:
S3C64XX_MEM_SYS_CFG_NAND 0x0008 S3C64XX_MEM_SYS_CFG_ONENAND 0x1000
????? 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@denx.de
Dear Guennadi Liakhovetski,
In message Pine.LNX.4.64.0810230954380.4977@axis700.grange you wrote:
/* 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.
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?
Get rid of these magic numbers. Use readable constants everywhere!
Best regards,
Wolfgang Denk
On Thu, 23 Oct 2008, Wolfgang Denk wrote:
Dear Guennadi Liakhovetski,
In message Pine.LNX.4.64.0810230954380.4977@axis700.grange you wrote:
/* 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).
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@denx.de
Dear Guennadi Liakhovetski,
In message Pine.LNX.4.64.0810231057420.4977@axis700.grange you wrote:
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
On Thu, 23 Oct 2008, Wolfgang Denk wrote:
Dear Guennadi Liakhovetski,
In message Pine.LNX.4.64.0810231057420.4977@axis700.grange you wrote:
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.
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@denx.de
Dear Guennadi Liakhovetski,
In message Pine.LNX.4.64.0810230927050.4977@axis700.grange you wrote:
- 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]
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
participants (4)
-
Guennadi Liakhovetski -
Jean-Christophe PLAGNIOL-VILLARD -
Kyungmin Park -
Wolfgang Denk