[U-Boot] [PATCH] sh: Fix compile error in lowlevel_init file
lowlevel_init of SH was corrected to use the write/readXX macro. However, there was a problem that was not able to be compiled partially. This patch corrected this. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- board/ms7722se/lowlevel_init.S|3 ++- board/ms7750se/lowlevel_init.S|5 +++-- board/renesas/MigoR/lowlevel_init.S |3 ++- board/renesas/r2dplus/lowlevel_init.S | 10 ++ 4 files changed, 13 insertions(+), 8 deletions(-) diff --git a/board/ms7722se/lowlevel_init.S b/board/ms7722se/lowlevel_init.S index 9144e10..1cb57e7 100644 --- a/board/ms7722se/lowlevel_init.S +++ b/board/ms7722se/lowlevel_init.S @@ -131,7 +131,7 @@ bsc_init: write32 RTCSR_A, RTCSR_D - write8 SDMR3_A, #0x00 + write8 SDMR3_A, SDMR3_D ! BL bit off (init = ON) (?!?) @@ -225,6 +225,7 @@ RTCOR_D:.long 0xA55A0034 RTCSR_A: .long SBSC_RTCSR RTCSR_D: .long 0xA55A0010 SDMR3_A: .long 0xFE500180 +SDMR3_D: .long 0x0 .align 1 diff --git a/board/ms7750se/lowlevel_init.S b/board/ms7750se/lowlevel_init.S index 7108019..5e09a39 100644 --- a/board/ms7750se/lowlevel_init.S +++ b/board/ms7750se/lowlevel_init.S @@ -84,7 +84,7 @@ init_bsc: write32 MCR_A, MCR_D1 /* Set SDRAM mode */ - write8 SDMR3_A, #0 + write8 SDMR3_A, SDMR3_D ! Do you need PCMCIA setting? ! If so, please add the lines here... @@ -108,7 +108,7 @@ init_bsc: write32 MCR_A, MCR_D2 /* Set SDRAM mode */ - write8 SDMR3_A, #0 + write8 SDMR3_A, SDMR3_D rts nop @@ -146,6 +146,7 @@ RTCNT_D:.long 0xA500 /* RTCNT Write Code A5h Data 00h */ RTCOR_A: .long RTCOR RTCOR_D: .long RTCOR_D_VALUE /* Set refresh time (about 15us) */ SDMR3_A: .long SDMR3_ADDRESS +SDMR3_D: .long 0x00 MCR_A: .long MCR MCR_D1:.long MCR_D1_VALUE MCR_D2:.long MCR_D2_VALUE diff --git a/board/renesas/MigoR/lowlevel_init.S b/board/renesas/MigoR/lowlevel_init.S index 1da603a..e32a7af 100644 --- a/board/renesas/MigoR/lowlevel_init.S +++ b/board/renesas/MigoR/lowlevel_init.S @@ -117,7 +117,7 @@ bsc_init: write32 RFCR_A, RFCR_D - write8 SDMR3_A, #0x00 + write8 SDMR3_A, SDMR3_D ! BL bit off (init = ON) (?!?) @@ -195,6 +195,7 @@ RFCR_A: .long SBSC_RFCR RFCR_D:.long 0xA55A0221 RTCSR_D: .long 0xA55A009a SDMR3_A: .long 0xFE581180 +SDMR3_D: .long 0x0 SR_MASK_D: .long 0xEF0F diff --git a/board/renesas/r2dplus/lowlevel_init.S b/board/renesas/r2dplus/lowlevel_init.S index 2f6a9b7..76d3cfc 100644 --- a/board/renesas/r2dplus/lowlevel_init.S +++ b/board/renesas/r2dplus/lowlevel_init.S @@ -36,7 +36,7 @@ lowlevel_init: write16 PCR_A, PCR_D - write16 LED_A, #0xff + write16 LED_A, LED_D write32 MCR_A, MCR_D1 @@ -48,7 +48,7 @@ lowlevel_init: write16 RTCSR_A, RTCSR_D - write8 SDMR3_A, #0x55 + write8 SDMR3_A, SDMR3_D0 /* Wait DRAM refresh 30 times */ mov.l RFCR_A, r1 @@ -61,7 +61,7 @@ lowlevel_init: write32 MCR_A, MCR_D2 - write8 SDMR3_A, #0 + write8 SDMR3_A, SDMR3_D1 write32 IRLMASK_A, IRLMASK_D @@ -92,6 +92,7 @@ WCR2_D: .long 0xcff86fbf WCR3_A:.long WCR3/* WCR3 Address */ WCR3_D:.long 0x0707 LED_A: .long 0x0436 /* LED Address */ +LED_D: .long 0xFF/* LED Data */ RTCNT_A: .long RTCNT /* RTCNT Address */ RTCNT_D: .long 0xA500 /* RTCNT Write Code A5h Data 00h */ RTCOR_A: .long RTCOR /* RTCOR Address */ @@ -99,7 +100,8 @@ RTCOR_D: .long 0xA534 /* RTCOR Write Code */ RTCSR_A: .long RTCSR /* RTCSR Address */ RTCSR_D: .long 0xA510 /* RTCSR Write Code */ SDMR3_A: .long 0xFF9400CC /* SDMR3 Address */ -SDMR3_D: .long 0x55 +SDMR3_D0: .long 0x55 +SDMR3_D1: .long 0x00 MCR_A: .long MCR /* MCR Address */ MCR_D1:.long 0x081901F4 /* MRSET:'0' */ MCR_D2:.long 0x481901F4 /* MRSET:'1' */ -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Hi! Am Donnerstag, den 08.01.2009, 07:19 -0800 schrieb Frans Meulenbroeks: Has someone experience in this area? Ideas? Suggestions? 1. For our systems we assume, that the env-block never gets bad in productive use, because the env-block is never written again. So we reduced the problem to number of initial/factory bad blocks. 2. the partitioning and environment-saving is done at production-time. 3. we put the environment in the last good block of the device. The search starts at the end of device and ends at the last block of the last data-partition with an error. Example-Partition-Table on an 32MB-NAND, with blocksize 16kb and max. 45 factory bad-blocks: * the part-size means the possible data size (without bad-blocks). * the real partition-size on device depends on the bad-blocks in this the partition and is calculated automatically at production-time (partition generation). part-size partition 200kb: uboot 1000kb:kernel 15000kb: rootfs 15832kb: datafs rest of device: rest (maximal 45*16kb (max bad blocks) + 16bk (envblock) = 736kb with an increasing number of initial/factory bad-blocks the rest-partition shrinks. So the env-block can be written on any nand-device without less than 45 (initial/factory) bad-blocks. Thanks alot! Frans Meulenbroeks - Manfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Manfred, Thanks for your suggestions. Did you modify u-boot to search from the last block of the device backwards? I feel putting the env at the end is quite a good idea. Unfortunately in our system we need to modify the env at runtime. For software upgrade we aim to go for a ping pong strategy (so having two kernels and two rfs-es in flash, and upgrade the non active kernel, then modify u-boot env so the next time we boot from the upgraded kernel). Unless of course there is a better strategy for this. Best regards, Frans. --- On Sun, 1/11/09, Schlaegl Manfred jun. manfred.schla...@gmx.at wrote: From: Schlaegl Manfred jun. manfred.schla...@gmx.at Subject: Re: [U-Boot] NAND bad environment block handling To: fransmeulenbro...@yahoo.com Cc: u-boot@lists.denx.de Date: Sunday, January 11, 2009, 12:10 PM Hi! Am Donnerstag, den 08.01.2009, 07:19 -0800 schrieb Frans Meulenbroeks: Has someone experience in this area? Ideas? Suggestions? 1. For our systems we assume, that the env-block never gets bad in productive use, because the env-block is never written again. So we reduced the problem to number of initial/factory bad blocks. 2. the partitioning and environment-saving is done at production-time. 3. we put the environment in the last good block of the device. The search starts at the end of device and ends at the last block of the last data-partition with an error. Example-Partition-Table on an 32MB-NAND, with blocksize 16kb and max. 45 factory bad-blocks: * the part-size means the possible data size (without bad-blocks). * the real partition-size on device depends on the bad-blocks in this the partition and is calculated automatically at production-time (partition generation). part-size partition 200kb: uboot 1000kb:kernel 15000kb: rootfs 15832kb: datafs rest of device: rest (maximal 45*16kb (max bad blocks) + 16bk (envblock) = 736kb with an increasing number of initial/factory bad-blocks the rest-partition shrinks. So the env-block can be written on any nand-device without less than 45 (initial/factory) bad-blocks. Thanks alot! Frans Meulenbroeks - Manfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Dear Manfred, In message 1231672254.3130.29.ca...@mobil.alm.archives.at you wrote: 1. For our systems we assume, that the env-block never gets bad in productive use, because the env-block is never written again. So we reduced the problem to number of initial/factory bad blocks. That's a pretty risky setup because it is based on an incorrect assumption - on NAND, block become not only bad when being erased or written to, but also after a certain number of read operations is exceeded. Yes, there is a maximum number of reads per block on NAND! People like to ignore that... See for example the Micron Technical Note Design and Use Considerations for NAND Flash Memory, http://download.micron.com/pdf/technotes/nand/tn2917.pdf Time to look into UBI, me thinks. 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: w...@denx.de No question is too silly to ask. Of course, some questions are too silly to to answer... - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
That's a pretty risky setup because it is based on an incorrect assumption - on NAND, block become not only bad when being erased or written to, but also after a certain number of read operations is exceeded. Yes, there is a maximum number of reads per block on NAND! People like to ignore that... See for example the Micron Technical Note Design and Use Considerations for NAND Flash Memory, http://download.micron.com/pdf/technotes/nand/tn2917.pdf Thanks for the link. I was not aware of read degradation. That is what most manufacturers do not tell you. Time to look into UBI, me thinks. For u-boot env settings?? My problem that the designated env blocks can be bad or become bad during the lifetime of the device. Not desirable especially not for expensive devices. Frans. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] sh/serial: use readx/writex accessors
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 0ba88ea..36770bb 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -18,6 +18,7 @@
*/
#include common.h
+#include asm/io.h
#include asm/processor.h
#if defined(CONFIG_CONS_SCIF0)
@@ -132,17 +133,17 @@ void serial_setbrg(void)
{
DECLARE_GLOBAL_DATA_PTR;
- *SCBRR = SCBRR_VALUE(gd-baudrate, CONFIG_SYS_CLK_FREQ);
+ writeb(SCBRR_VALUE(gd-baudrate, CONFIG_SYS_CLK_FREQ), SCBRR);
}
int serial_init(void)
{
- *SCSCR = (SCR_RE | SCR_TE);
- *SCSMR = 0;
- *SCSMR = 0;
- *SCFCR = (FCR_RFRST | FCR_TFRST);
- *SCFCR;
- *SCFCR = 0;
+ writew((SCR_RE | SCR_TE), SCSCR);
+ writew(0, SCSMR);
+ writew(0, SCSMR);
+ writew((FCR_RFRST | FCR_TFRST), SCFCR);
+ readw(SCFCR);
+ writew(0, SCFCR);
serial_setbrg();
return 0;
@@ -151,9 +152,9 @@ int serial_init(void)
static int serial_rx_fifo_level(void)
{
#if defined(SCRFDR)
- return (*SCRFDR 0) FIFOLEVEL_MASK;
+ return (readw(SCRFDR) 0) FIFOLEVEL_MASK;
#else
- return (*SCFDR 0) FIFOLEVEL_MASK;
+ return (readw(SCFDR) 0) FIFOLEVEL_MASK;
#endif
}
@@ -162,15 +163,15 @@ void serial_raw_putc(const char c)
unsigned int fsr_bits_to_clear;
while (1) {
- if (*SCFSR FSR_TEND) {/* Tx fifo is empty */
+ if (readw(SCFSR) FSR_TEND) { /* Tx fifo is empty */
fsr_bits_to_clear = FSR_TEND;
break;
}
}
- *SCFTDR = c;
+ writeb(c, SCFTDR);
if (fsr_bits_to_clear != 0)
- *SCFSR = ~fsr_bits_to_clear;
+ writew(readw(SCFSR) ~fsr_bits_to_clear, SCFSR);
}
void serial_putc(const char c)
@@ -197,21 +198,21 @@ int serial_tstc(void)
void handle_error(void)
{
- (void)*SCFSR;
- *SCFSR = FSR_ERR_CLEAR;
- (void)*SCLSR;
- *SCLSR = 0x00;
+ readw(SCFSR);
+ writew(FSR_ERR_CLEAR, SCFSR);
+ readw(SCLSR);
+ writew(0x00, SCLSR);
}
int serial_getc_check(void)
{
unsigned short status;
- status = *SCFSR;
+ status = readw(SCFSR);
if (status (FSR_FER | FSR_ER | FSR_BRK))
handle_error();
- if (*SCLSR LSR_ORER)
+ if (readw(SCLSR) LSR_ORER)
handle_error();
return status (FSR_DR | FSR_RDF);
}
@@ -224,15 +225,15 @@ int serial_getc(void)
while (!serial_getc_check())
;
- ch = *SCFRDR;
- status = *SCFSR;
+ ch = readb(SCFRDR);
+ status = readw(SCFSR);
- *SCFSR = RDRF_CLEAR;
+ writew(RDRF_CLEAR, SCFSR);
if (status (FSR_FER | FSR_FER | FSR_ER | FSR_BRK))
handle_error();
- if (*SCLSR LSR_ORER)
+ if (readw(SCLSR) LSR_ORER)
handle_error();
return ch;
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] sh/serial: coding style cleanup
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 1d76a19..0ba88ea 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -49,7 +49,7 @@
# define SCFRDR(vu_char *)(SCIF_BASE + 0x24)
#else
# define SCFTDR (vu_char *)(SCIF_BASE + 0xC)
-# define SCFSR (vu_short *)(SCIF_BASE + 0x10)
+# define SCFSR (vu_short *)(SCIF_BASE + 0x10)
# define SCFRDR (vu_char *)(SCIF_BASE + 0x14)
#endif
@@ -64,7 +64,7 @@
#elif defined(CONFIG_CPU_SH7763)
# if defined(CONFIG_CONS_SCIF2)
# define SCSPTR(vu_short *)(SCIF_BASE + 0x20)
-# define SCLSR (vu_short *)(SCIF_BASE + 0x24)
+# define SCLSR (vu_short *)(SCIF_BASE + 0x24)
# define LSR_ORER 1
# define FIFOLEVEL_MASK0x1F
# else
@@ -90,7 +90,7 @@
defined(CONFIG_CPU_SH7722) || \
defined(CONFIG_CPU_SH7203)
# define SCSPTR(vu_short *)(SCIF_BASE + 0x20)
-# define SCLSR (vu_short *)(SCIF_BASE + 0x24)
+# define SCLSR (vu_short *)(SCIF_BASE + 0x24)
# define LSR_ORER 1
# define FIFOLEVEL_MASK0x1F
#elif defined(CONFIG_CPU_SH7720)
@@ -106,31 +106,32 @@
/* SCBRR register value setting */
#if defined(CONFIG_CPU_SH7720)
-# define SCBRR_VALUE(bps, clk) (((clk*2)+16*bps)/(32*bps)-1)
+# define SCBRR_VALUE(bps, clk) (((clk * 2) + 16 * bps) / (32 * bps) - 1)
#elif defined(CONFIG_CPU_SH7723) defined(CONFIG_SCIF_A)
/* SH7723 SCIFA use bus clock. So clock *2 */
-# define SCBRR_VALUE(bps, clk) (((clk*2*2)+16*bps)/(32*bps)-1)
+# define SCBRR_VALUE(bps, clk) (((clk * 2 * 2) + 16 * bps) / (32 * bps) - 1)
#else /* Generic SuperH */
-# define SCBRR_VALUE(bps, clk) ((clk+16*bps)/(32*bps)-1)
+# define SCBRR_VALUE(bps, clk) ((clk + 16 * bps) / (32 * bps) - 1)
#endif
-#define SCR_RE (1 4)
-#define SCR_TE (1 5)
+#define SCR_RE (1 4)
+#define SCR_TE (1 5)
#define FCR_RFRST (1 1)/* RFCL */
#define FCR_TFRST (1 2)/* TFCL */
-#define FSR_DR (1 0)
-#define FSR_RDF(1 1)
-#define FSR_FER(1 3)
-#define FSR_BRK(1 4)
-#define FSR_FER(1 3)
-#define FSR_TEND (1 6)
-#define FSR_ER (1 7)
+#define FSR_DR (1 0)
+#define FSR_RDF(1 1)
+#define FSR_FER(1 3)
+#define FSR_BRK(1 4)
+#define FSR_FER(1 3)
+#define FSR_TEND (1 6)
+#define FSR_ER (1 7)
/*--*/
void serial_setbrg(void)
{
DECLARE_GLOBAL_DATA_PTR;
+
*SCBRR = SCBRR_VALUE(gd-baudrate, CONFIG_SYS_CLK_FREQ);
}
@@ -191,8 +192,8 @@ int serial_tstc(void)
return serial_rx_fifo_level() ? 1 : 0;
}
-#define FSR_ERR_CLEAR 0x0063
-#define RDRF_CLEAR 0x00fc
+#define FSR_ERR_CLEAR 0x0063
+#define RDRF_CLEAR 0x00fc
void handle_error(void)
{
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Am Sonntag, den 11.01.2009, 14:28 +0100 schrieb Wolfgang Denk: Dear Manfred, In message 1231672254.3130.29.ca...@mobil.alm.archives.at you wrote: 1. For our systems we assume, that the env-block never gets bad in productive use, because the env-block is never written again. So we reduced the problem to number of initial/factory bad blocks. That's a pretty risky setup because it is based on an incorrect assumption - on NAND, block become not only bad when being erased or written to, but also after a certain number of read operations is exceeded. Yes, there is a maximum number of reads per block on NAND! People like to ignore that... See for example the Micron Technical Note Design and Use Considerations for NAND Flash Memory, http://download.micron.com/pdf/technotes/nand/tn2917.pdf Yes I know. I think my description was a little bit misunderstanding: Our solution is only a solution for positioning env-block(s) and handling initial/factory bad blocks. This solution can(should) combined with redundant env-blocks too, if write/erase-wearout is an issue. The problem you discribe is a general nand-flash-problem. To keep the system aware of this you theoretically have to implement a redundant uboot partition too. It makes no sense to have two env-blocks(except for erase/write-wearout-issues), but only one u-boot binary in nand-flash. Time to look into UBI, me thinks. Yes I think too. It would make things much easier .. :-) Perhaps: Uboot + Environment (ev. Kernel) on NOR-Flash and filesystem-partitions on NAND/UBI. Best regards, Manfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Dear Frans Meulenbroeks, In message 817622.67175...@web33604.mail.mud.yahoo.com you wrote: Time to look into UBI, me thinks. For u-boot env settings?? Why not? Once the flash is UBI managed, there are virtually no bad blocks any more. My problem that the designated env blocks can be bad or become bad during the lifetime of the device. Not desirable especially not for expensive devices. As mentioned before, U-Boot supports bad block handling on NAND, so just allocate a few spare blocks to the environment area. 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: w...@denx.de Keep your eyes wide open before marriage, half shut afterwards. -- Benjamin Franklin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ARM: Add/Improve support for Atmel AT91RM9200DK/E
I checked out the latest snapshot of the AT91 branch and was able to build, a working version of u-boot. The Flash CFI support works in that I was able to write both the AT91RM9200EK's flash, and the AT49BV642D flash on my board. The snapshot I used was this one. http://git.denx.de/?p=u-boot/u-boot-at91.git;a=commit;h=df362482d656c1e17221845ab628467bbd9d0ef7 However few points. The board comes from the factory with a boot loader (BOOT.BIN) that decompresses and u-boot from address 1001 and then executes it. In order for this to work you need to define #define CONFIG_SKIP_LOWLEVEL_INIT to disable the low level init since it has already been done BY BOOT.BIN, and the boot loader is running out of ram, SO doing it again will result in a hang. Note as well to builD the code I had to follow the these instructions. mkdir at91rm9200ek make O=at91rm9200ek at91rm9200ek_config make O=at91rm9200ek This puts all the object files in the output directory at91rm9200ek. Otherwise I got a error complaining that make couldn't find /include/tools/mach-types.h This probably only applies to this branch, not the main. Anyways, thanks bunches to Ulf and Jean-Christophe. PS: You can download an u-boot via xmodem through the debug port. However this version of u-boot is too big to download via this way (limit seems to be 128k. In order to get the binary small enough I had to remove USB support. Matt Harper Tehama Wireless. --- Oppressing electrons since 1908 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question: about uboot support SD/MMC?
HI Folks: I've googled, and some said upstrem was implementing the SD/MMC framework. So people just have to write SDIO driver. Just wondering, is there any experimental code that i can try? Thanks. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
