Re: [U-Boot-Users] RFC: U-Boot version numbering
[EMAIL PROTECTED] wrote on : Kumar Gala wrote: On Aug 1, 2008, at 10:32 AM, Wolfgang Denk wrote: Hello, I would like to get your general opinion about changing the U-Boot version numbering scheme. To be honest, I never really understood myself how this is supposed to work and if the next version should be 1.3.4 or 1.4.0 or 2.0.0, i. e. which changes / additions are important enough to increment the PATCHLEVEL or even VERSION number. I therefor suggest to drop this style of version numbering and change to a timestamp based version number system which has been quite successfully used by other projects (like Ubuntu) or is under discussion (for Linux). My suggestion for the new version numbers is as follows: VERSION = 1 (at least for the time being) PATCHLEVEL = current year - 2000 SUBLEVEL = current month Both PATCHLEVEL and SUBLEVEL shall always be 2 digits (at least for the next 91+ years to come) so listings for example on an FTP server shall be in a sane sorting order. If we accept this system, the next release which probably comes out in October 2008 would be v1.08.10, and assuming the one after that comes out in January 2009 would be named v1.09.01 If we go to date based versions. I'd prefer we keep year as 4 digits: v1.2008.10 v1.2009.01 It just seems easier to me at a visual level when I look at try and compare versions. - k I vote for this one, but starting at v2. Me too! Best Regards, Martin -- TQ-Systems GmbH Muehlstrasse 2, Gut Delling, D-82229 Seefeld Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913 Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl http://www.tq-group.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Grant Likely schrieb: On Sun, Aug 3, 2008 at 11:49 AM, Timur Tabi [EMAIL PROTECTED] wrote: On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk [EMAIL PROTECTED] wrote: If the DTB can be at any flash location, you can for example have a fall-back version which is used to bring up U-Boot in a minimal configuration for recovery mode if the new DTB fails to work. I think that a recovery DTB would have to be part of U-Boot itself to be effective. If the normal DTB is not available, then it's likely the backup one would also be unavailable. Better to just not depend on the DTB at all for basic operation. ie. don't brick the board if the DTB is unavailable. If the DTB is not available or invalid, the settings in the config header file could be used as default values. At least, U-Boot should start with a limited function volume to be able to load valid DTB. It's also possible to have no DTB at all for platforms not (or not yet) supporting the flat device tree. Kind regards, Jens - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Feng Kan schrieb: Albert ARIBAUD wrote: Wolfgang Denk a écrit : Hello, I would like to get your general opinion about changing the U-Boot version numbering scheme. To be honest, I never really understood myself how this is supposed to work and if the next version should be 1.3.4 or 1.4.0 or 2.0.0, i. e. which changes / additions are important enough to increment the PATCHLEVEL or even VERSION number. I therefor suggest to drop this style of version numbering and change to a timestamp based version number system which has been quite successfully used by other projects (like Ubuntu) or is under discussion (for Linux). My suggestion for the new version numbers is as follows: VERSION = 1 (at least for the time being) PATCHLEVEL = current year - 2000 SUBLEVEL = current month Both PATCHLEVEL and SUBLEVEL shall always be 2 digits (at least for the next 91+ years to come) so listings for example on an FTP server shall be in a sane sorting order. If we accept this system, the next release which probably comes out in October 2008 would be v1.08.10, and assuming the one after that comes out in January 2009 would be named v1.09.01 Comments? A minor :) issue I can see is that there might be *some* confusion because of an apparent, numerical rollback from 1.3.4 back to 1.08.xx. You're bound to encounter some folks who will ask, again and again, why you're working on 1.02.yy when 1.3.4 is out there. Now an obvious solution would be to use 2 as the major number. If you're serious about not knowing when a major number bump-up is required, then you should be fairly ok with starting at 2.08.01 rather than 1.08.01. :) Joke aside: you'll get questions *anyway*, and the scheme is as fine to me as it it. Another, maybe trickier, issue is: you won't be able to cleanly number interim releases if you encounter a really serious bug right after you've produced this month's release, will you? Amicalement, Perhaps the Version itself can be removed, there doesn't seems to be a point about it. You can just do v2008.1. You can add a third field for the day for those really serious bugs:) Partially ack. In principle, the version prefix is unnecessary, because year and month are clear. But it helps when sorting the version due to the existing v1. For subversions I suggest a sequential number as suffix or an arbitrary string, e.g.: v2.2008.10-001 v2.2008.10-rc2 v2.2008.10-projectX v2.2008.10-experimental_091 Any opinions about upper case / lower case notation? Kind regards, Jens - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Timur Tabi a écrit : On Sun, Aug 3, 2008 at 2:06 PM, Grant Likely [EMAIL PROTECTED] wrote: Better to just not depend on the DTB at all for basic operation. ie. don't brick the board if the DTB is unavailable. Is it even possible to have a recovery mode U-Boot that is not tied to the specific board it's built for? Either U-Boot is reliable, or it's generic (i.e. uses the DTB for configuration). I just don't see how it can be both. A recovery U-boot would only need to be generic enough to provide a console and means to upload and run code through that console. If that works well, then you have a reliable and (as) generic (as it gets) recovery u-boot (granted, it would still depend on the console working out-of-the-boot without any HW tricks like enabling voltage converters and such). Amicalement, -- Albert. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] 85xx: Not enough room for program headers
Hi, With today's top of the tree U-Boot I'm getting this: ./MAKEALL MPC8555CDS Configuring for MPC8555CDS board... ppc_85xx-ld: u-boot: Not enough room for program headers (allocated 3, need 4) ppc_85xx-ld: final link failed: Bad value make: *** [u-boot] Błąd 1 ppc_85xx-size: './u-boot': No such file Is this known, anyone working on fixing this perhaps? kind regards, Rafal - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 85xx: Not enough room for program headers
In message [EMAIL PROTECTED] you wrote: Hi, With today's top of the tree U-Boot I'm getting this: ./MAKEALL MPC8555CDS Configuring for MPC8555CDS board... ppc_85xx-ld: u-boot: Not enough room for program headers (allocated 3, need= 4) ppc_85xx-ld: final link failed: Bad value make: *** [u-boot] B=B3=B1d 1 ppc_85xx-size: './u-boot': No such file Hm... using ELDK 4.2 I get this: - ./MAKEALL MPC8555CDS Configuring for MPC8555CDS board... textdata bss dec hex filename 196852 15284 26492 238628 3a424 ./u-boot Is this known, anyone working on fixing this perhaps? Which toolchain did you use? 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: [EMAIL PROTECTED] You don't have to stay up nights to succeed; you have to stay awake days. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] AT91SAM9261-EK USB storage not working...
Hi Remy, Le jeudi 31 juillet 2008 à 15:24 +0200, Remy Bohmer a écrit : Hello Stelian and others, I have made some progress here, and I would like to inform you all: [...] I have done a lot of debugging/testing etc. and I noticed that binary deliverables of U-boot for the evaluationkit work properly with USB-storage devices on the AT91SAM9261-EK kit. They were all based on U-boot 1.1.3, 1.1.4, 1.1.5 Atmel versions. But, I was not able to get a working version when I build such a code tree myself. I use gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126) An hour ago I got the stupid idea to get an older compiler: gcc version 3.4.2 (release) (CodeSourcery ARM Q3D 2004) FYI, I have been using a CS toolchain here too (2007q3) and had optimisation problems with it (net/net.c:NetReceive() gets miscompiled when using -Os, but behaves correctly when compiled with -O2). I didn't have any problems with the (older) ELDK 4.1 gcc compiler. Maybe you should try it first. -- Stelian Pop [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 85xx: Not enough room for program headers
Wolfgang Denk wrote: With today's top of the tree U-Boot I'm getting this: ./MAKEALL MPC8555CDS Configuring for MPC8555CDS board... ppc_85xx-ld: u-boot: Not enough room for program headers (allocated 3, need= 4) ppc_85xx-ld: final link failed: Bad value make: *** [u-boot] B=B3=B1d 1 ppc_85xx-size: './u-boot': No such file Hm... using ELDK 4.2 I get this: - ./MAKEALL MPC8555CDS Configuring for MPC8555CDS board... textdata bss dec hex filename 196852 15284 26492 238628 3a424 ./u-boot Is this known, anyone working on fixing this perhaps? Which toolchain did you use? Mine was ELDK 4.1; it seems the two gcc/linker versions lay out the binary differently then.. kind regards, Rafal - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 0/7 v2] SMDK6400 support
Hi,
this is version 2 of the smdk6400 patch series. I hope, I took care of all
comments, apart of these ones:
On Thu, 31 Jul 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
+#ifdef CONFIG_NAND_SPL
+static u_char nand_read_byte(struct mtd_info *mtd)
+{
+ struct nand_chip *this = mtd-priv;
add an empty line
+ return readb(this-IO_ADDR_R);
+}
+
+static void nand_write_byte(struct mtd_info *mtd, u_char byte)
+{
+ struct nand_chip *this = mtd-priv;
add an empty line
+ writeb(byte, this-IO_ADDR_W);
+}
Sorry, looks like a matter of taste to me. There are also very few lines
over 80 characters left, but fixing them would look too awkward...
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]
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/7 v2] Add definition for the AM29LV800BB AMD NOR-flash
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
drivers/mtd/jedec_flash.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 9845e93..020647a 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -234,6 +234,23 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1,7),
}
},
+ {
+ .mfr_id = MANUFACTURER_AMD,
+ .dev_id = AM29LV800BB,
+ .name = AMD AM29LV800BB,
+ .uaddr = {
+ [1] = MTD_UADDR_0x0555_0x02AA /* x16 */
+ },
+ .DevSize= SIZE_1MiB,
+ .CmdSet = CFI_CMDSET_AMD_LEGACY,
+ .NumEraseRegions= 4,
+ .regions= {
+ ERASEINFO(0x04000, 1),
+ ERASEINFO(0x02000, 2),
+ ERASEINFO(0x08000, 1),
+ ERASEINFO(0x1, 15),
+ }
+ },
#endif
};
--
1.5.4
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/7 v2] NAND_CMD_READOOB is not supported by all chips, read OOB with the page instead
I _think_ this should work with all NAND chips. Otherwise we might have to
introduce a configuration variable.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
nand_spl/nand_boot.c | 61 +
1 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index 563a80b..78eaf75 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -128,21 +128,6 @@ static int nand_command(struct mtd_info *mtd, int block,
int page, int offs, u8
}
#endif
-static int nand_is_bad_block(struct mtd_info *mtd, int block)
-{
- struct nand_chip *this = mtd-priv;
-
- nand_command(mtd, block, 0, CFG_NAND_BAD_BLOCK_POS, NAND_CMD_READOOB);
-
- /*
-* Read one byte
-*/
- if (this-read_byte(mtd) != 0xff)
- return 1;
-
- return 0;
-}
-
static int nand_read_page(struct mtd_info *mtd, int block, int page, uchar
*dst)
{
struct nand_chip *this = mtd-priv;
@@ -150,8 +135,6 @@ static int nand_read_page(struct mtd_info *mtd, int block,
int page, uchar *dst)
u_char *ecc_code;
u_char *oob_data;
int i;
- int eccsize = CFG_NAND_ECCSIZE;
- int eccbytes = CFG_NAND_ECCBYTES;
int eccsteps = CFG_NAND_ECCSTEPS;
uint8_t *p = dst;
int stat;
@@ -163,11 +146,11 @@ static int nand_read_page(struct mtd_info *mtd, int
block, int page, uchar *dst)
*/
ecc_calc = (u_char *)(CFG_SDRAM_BASE + 0x1);
ecc_code = ecc_calc + 0x100;
- oob_data = ecc_calc + 0x200;
+ oob_data = p + CFG_NAND_PAGE_SIZE; /* Append OOB to the page data */
- for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
+ for (i = 0; eccsteps; eccsteps--, i += CFG_NAND_ECCBYTES, p +=
CFG_NAND_ECCSIZE) {
this-enable_hwecc(mtd, NAND_ECC_READ);
- this-read_buf(mtd, p, eccsize);
+ this-read_buf(mtd, p, CFG_NAND_ECCSIZE);
this-calculate_ecc(mtd, p, ecc_calc[i]);
}
this-read_buf(mtd, oob_data, CFG_NAND_OOBSIZE);
@@ -179,7 +162,7 @@ static int nand_read_page(struct mtd_info *mtd, int block,
int page, uchar *dst)
eccsteps = CFG_NAND_ECCSTEPS;
p = dst;
- for (i = 0 ; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
+ for (i = 0; eccsteps; eccsteps--, i += CFG_NAND_ECCBYTES, p +=
CFG_NAND_ECCSIZE) {
/* No chance to do something with the possible error message
* from correct_data(). We just hope that all possible errors
* are corrected by this routine.
@@ -195,6 +178,7 @@ static int nand_load(struct mtd_info *mtd, int offs, int
uboot_size, uchar *dst)
int block;
int blockcopy_count;
int page;
+ unsigned read = 0;
/*
* offs has to be aligned to a block address!
@@ -202,18 +186,29 @@ static int nand_load(struct mtd_info *mtd, int offs, int
uboot_size, uchar *dst)
block = offs / CFG_NAND_BLOCK_SIZE;
blockcopy_count = 0;
- while (blockcopy_count (uboot_size / CFG_NAND_BLOCK_SIZE)) {
- if (!nand_is_bad_block(mtd, block)) {
- /*
-* Skip bad blocks
-*/
- for (page = 0; page CFG_NAND_PAGE_COUNT; page++) {
- nand_read_page(mtd, block, page, dst);
- dst += CFG_NAND_PAGE_SIZE;
+ while (blockcopy_count ((uboot_size + CFG_NAND_BLOCK_SIZE - 1) /
CFG_NAND_BLOCK_SIZE)) {
+ /*
+* Skip bad blocks
+*/
+ int badblock = 0;
+ for (page = 0; page CFG_NAND_PAGE_COUNT; page++) {
+ nand_read_page(mtd, block, page, dst);
+ if ((!page
+#ifdef CFG_NAND_BBT_2NDPAGE
+|| page == 1
+#endif
+ ) dst[CFG_NAND_PAGE_SIZE] != 0xff) {
+ badblock = 1;
+ break;
}
+ /* Overwrite skipped pages */
+ if (read = offs)
+ dst += CFG_NAND_PAGE_SIZE;
+ read += CFG_NAND_PAGE_SIZE;
+ }
+ if (!badblock)
blockcopy_count++;
- }
block++;
}
@@ -241,12 +236,18 @@ void nand_boot(void)
nand_chip.dev_ready = NULL; /* preset to NULL */
board_nand_init(nand_chip);
+ if (nand_chip.select_chip)
+ nand_chip.select_chip(nand_info, 0);
+
/*
* Load U-Boot image from NAND into RAM
*/
ret = nand_load(nand_info, CFG_NAND_U_BOOT_OFFS, CFG_NAND_U_BOOT_SIZE,
(uchar *)CFG_NAND_U_BOOT_DST);
+ if (nand_chip.select_chip)
+
[U-Boot-Users] [PATCH 4/7 v2] USB: Add support for OHCI controller on s3c6400
Notice: USB on s3c6400 currently works _only_ with switched off MMU. One could
try to enable the MMU, but map addresses 1-to-1, and disable data cache, then
it should work too and we could still profit from instruction cache.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
cpu/arm1176/s3c64xx/Makefile |1 +
cpu/arm1176/s3c64xx/usb.c| 45 ++
drivers/usb/usb_ohci.c |1 +
3 files changed, 47 insertions(+), 0 deletions(-)
create mode 100644 cpu/arm1176/s3c64xx/usb.c
diff --git a/cpu/arm1176/s3c64xx/Makefile b/cpu/arm1176/s3c64xx/Makefile
index 66ac4aa..8cee691 100644
--- a/cpu/arm1176/s3c64xx/Makefile
+++ b/cpu/arm1176/s3c64xx/Makefile
@@ -27,6 +27,7 @@ LIB = $(obj)lib$(SOC).a
COBJS-y= interrupts.o
COBJS-$(CONFIG_S3C6400)+= cpu_init.o speed.o
+COBJS-$(CONFIG_USB_OHCI_NEW) += usb.o
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
diff --git a/cpu/arm1176/s3c64xx/usb.c b/cpu/arm1176/s3c64xx/usb.c
new file mode 100644
index 000..274a4ed
--- /dev/null
+++ b/cpu/arm1176/s3c64xx/usb.c
@@ -0,0 +1,45 @@
+/*
+ * URB OHCI HCD (Host Controller Driver) initialization for USB on the S3C64XX.
+ *
+ * Copyright (C) 2008,
+ * Guennadi Liakhovetski, DENX Software Engineering [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include common.h
+#include s3c6400.h
+
+int usb_cpu_init(void)
+{
+ OTHERS_REG |= 0x1;
+ return 0;
+}
+
+int usb_cpu_stop(void)
+{
+ OTHERS_REG = ~0x1;
+ return 0;
+}
+
+void usb_cpu_init_fail(void)
+{
+ OTHERS_REG = ~0x1;
+}
diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c
index fd60edb..0bfa4d7 100644
--- a/drivers/usb/usb_ohci.c
+++ b/drivers/usb/usb_ohci.c
@@ -69,6 +69,7 @@
#if defined(CONFIG_ARM920T) || \
defined(CONFIG_S3C2400) || \
defined(CONFIG_S3C2410) || \
+defined(CONFIG_S3C6400) || \
defined(CONFIG_440EP) || \
defined(CONFIG_PCI_OHCI) || \
defined(CONFIG_MPC5200) || \
--
1.5.4
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 5/7 v2] serial: add s3c64xx serial driver
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
drivers/serial/Makefile |1 +
drivers/serial/s3c64xx.c | 186 ++
2 files changed, 187 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/s3c64xx.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index c9e797e..2a11ae5 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -30,6 +30,7 @@ COBJS-y += mcfuart.o
COBJS-y += ns9750_serial.o
COBJS-y += ns16550.o
COBJS-y += s3c4510b_uart.o
+COBJS-$(CONFIG_S3C64XX) += s3c64xx.o
COBJS-y += serial.o
COBJS-y += serial_max3100.o
COBJS-y += serial_pl010.o
diff --git a/drivers/serial/s3c64xx.c b/drivers/serial/s3c64xx.c
new file mode 100644
index 000..1763bc3
--- /dev/null
+++ b/drivers/serial/s3c64xx.c
@@ -0,0 +1,186 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include common.h
+
+#include s3c6400.h
+
+#ifdef CONFIG_SERIAL1
+#define UART_NRS3C64XX_UART0
+
+#elif defined(CONFIG_SERIAL2)
+#define UART_NRS3C64XX_UART1
+
+#elif defined(CONFIG_SERIAL3)
+#define UART_NRS3C64XX_UART2
+
+#else
+#error Bad: you didn't configure serial ...
+#endif
+
+#define barrier() asm volatile( ::: memory)
+
+/* See table in 31.6.11 */
+static const int udivslot[] = {
+ 0,
+ 0x0080,
+ 0x0808,
+ 0x0888,
+ 0x,
+ 0x4924,
+ 0x4a52,
+ 0x54aa,
+ 0x,
+ 0xd555,
+ 0xd5d5,
+ 0xddd5,
+ 0x,
+ 0xdfdd,
+ 0xdfdf,
+ 0xffdf,
+};
+
+void serial_setbrg(void)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+ u32 reg, pclk_ratio = get_PCLK() / gd-baudrate;
+ int i;
+
+ /* PCLK / (16 * baudrate) - 1 */
+ reg = pclk_ratio / 16 - 1;
+ i = pclk_ratio - (reg + 1) * 16;
+
+ uart-UBRDIV = reg;
+ uart-UDIVSLOT = udivslot[i];
+
+ for (i = 0; i 100; i++)
+ barrier();
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ *
+ */
+int serial_init(void)
+{
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+
+ /* reset and enable FIFOs, set triggers to the maximum */
+ uart-UFCON = 0xff;
+ uart-UMCON = 0;
+ /* 8N1 */
+ uart-ULCON = 3;
+ /* No interrupts, no DMA, pure polling */
+ uart-UCON = 5;
+
+ serial_setbrg();
+
+ return 0;
+}
+
+/*
+ * Read a single byte from the serial port. Returns 1 on success, 0
+ * otherwise. When the function is succesfull, the character read is
+ * written into its argument c.
+ */
+int serial_getc(void)
+{
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+
+ /* wait for character to arrive */
+ while (!(uart-UTRSTAT 0x1));
+
+ return uart-URXH 0xff;
+}
+
+#ifdef CONFIG_HWFLOW
+static int hwflow = 0; /* turned off by default */
+int hwflow_onoff(int on)
+{
+ switch (on) {
+ case 1:
+ hwflow = 1; /* turn on */
+ break;
+ case -1:
+ hwflow = 0; /* turn off */
+ break;
+ }
+ return hwflow;
+}
+#endif
+
+#ifdef CONFIG_MODEM_SUPPORT
+static int be_quiet;
+void disable_putc(void)
+{
+ be_quiet = 1;
+}
+
+void enable_putc(void)
+{
+ be_quiet = 0;
+}
+#endif
+
+
+/*
+ * Output a single byte to the serial port.
+ */
+void serial_putc(const char c)
+{
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+
+#ifdef CONFIG_MODEM_SUPPORT
+ if (be_quiet)
+ return;
+#endif
+
+ /* wait for room in the tx FIFO */
+ while (!(uart-UTRSTAT 0x2));
+
+#ifdef CONFIG_HWFLOW
+ /* Wait for CTS up */
+ while (hwflow !(uart-UMSTAT 0x1));
+#endif
+
+ uart-UTXH = c;
+
+ /* If \n, also do \r */
+ if (c == '\n')
+ serial_putc('\r');
+}
+
+/*
+ * Test whether a character is in the RX buffer
+ */
+int serial_tstc(void)
+{
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+
+ return
[U-Boot-Users] [PATCH 6/7 v2] NAND: add NAND driver for s3c64xx
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c64xx.c | 307
2 files changed, 308 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/s3c64xx.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 7bd22a0..236cf03 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -33,6 +33,7 @@ COBJS-y += nand_bbt.o
COBJS-y += nand_util.o
COBJS-y += fsl_upm.o
+COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mtd/nand/s3c64xx.c b/drivers/mtd/nand/s3c64xx.c
new file mode 100644
index 000..f2211f7
--- /dev/null
+++ b/drivers/mtd/nand/s3c64xx.c
@@ -0,0 +1,307 @@
+/*
+ * (C) Copyright 2006 DENX Software Engineering
+ *
+ * Implementation for U-Boot 1.1.6 by Samsung
+ *
+ * (C) Copyright 2008
+ * Guennadi Liakhovetki, DENX Software Engineering, [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+
+#include nand.h
+#include s3c6400.h
+
+#include asm/io.h
+
+#ifdef CONFIG_NAND_SPL
+#define printf(arg...) do {} while (0)
+#endif
+
+/* Nand flash definition values by jsgood */
+#ifdef S3C_NAND_DEBUG
+/*
+ * Function to print out oob buffer for debugging
+ * Written by jsgood
+ */
+static void print_oob(const char *header, struct mtd_info *mtd)
+{
+ int i;
+ struct nand_chip *chip = mtd-priv;
+
+ printf(%s:\t, header);
+
+ for(i = 0; i 64; i++)
+ printf(%02x , chip-oob_poi[i]);
+
+ printf(\n);
+}
+#endif /* S3C_NAND_DEBUG */
+
+#ifdef CONFIG_NAND_SPL
+static u_char nand_read_byte(struct mtd_info *mtd)
+{
+ struct nand_chip *this = mtd-priv;
+ return readb(this-IO_ADDR_R);
+}
+
+static void nand_write_byte(struct mtd_info *mtd, u_char byte)
+{
+ struct nand_chip *this = mtd-priv;
+ writeb(byte, this-IO_ADDR_W);
+}
+
+static void nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ int i;
+ struct nand_chip *this = mtd-priv;
+
+ for (i = 0; i len; i++)
+ buf[i] = readb(this-IO_ADDR_R);
+}
+#endif
+
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+ int ctrl = readl(NFCONT);
+
+ switch (chip) {
+ case -1:
+ ctrl |= 6;
+ break;
+ case 0:
+ ctrl = ~2;
+ break;
+ case 1:
+ ctrl = ~4;
+ break;
+ default:
+ return;
+ }
+
+ writel(ctrl, NFCONT);
+}
+
+/*
+ * Hardware specific access to control-lines function
+ * Written by jsgood
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd)
+{
+ struct nand_chip *this = mtd-priv;
+
+ switch (cmd) {
+ case NAND_CTL_SETCLE:
+ this-IO_ADDR_W = (void __iomem *)NFCMMD;
+ break;
+ case NAND_CTL_CLRCLE:
+ this-IO_ADDR_W = (void __iomem *)NFDATA;
+ break;
+ case NAND_CTL_SETALE:
+ this-IO_ADDR_W = (void __iomem *)NFADDR;
+ break;
+ case NAND_CTL_CLRALE:
+ this-IO_ADDR_W = (void __iomem *)NFDATA;
+ break;
+ case NAND_CTL_SETNCE:
+ s3c_nand_select_chip(mtd, 0);
+ break;
+ case NAND_CTL_CLRNCE:
+ s3c_nand_select_chip(mtd, -1);
+ break;
+ }
+}
+
+/*
+ * Function for checking device ready pin
+ * Written by jsgood
+ */
+static int s3c_nand_device_ready(struct mtd_info *mtdinfo)
+{
+ while (!(readl(NFSTAT) NFSTAT_RnB)) {}
+ return 1;
+}
+
+#ifdef CFG_S3C_NAND_HWECC
+/*
+ * This function is called before encoding ecc codes to ready ecc engine.
+ * Written by jsgood
+ */
+static void s3c_nand_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+ u_long nfcont, nfconf;
+
+ /*
+* The original driver used 4-bit ECC for new MLC chips, i.e., for
+* those with non-zero ID[3][3:2], which anyway only holds for ST
+* (Numonyx) chips
+*/
+ nfconf = readl(NFCONF) ~NFCONF_ECC_4BIT;
+
+
[U-Boot-Users] [PATCH 7/7 v2] ARM: Add support for S3C6400 based SMDK6400 board
SMDK6400 can only boot U-Boot from NAND-flash. This patch adds a nand_spl driver for it too. The board can also boot from the NOR flash, but due to hardware limitations it can only address 64KiB on it, which is not enough for U-Boot. Ported from u-boot-1.1.6 version by Samsung. Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED] --- MAKEALL|1 + Makefile | 17 ++ board/samsung/smdk6400/Makefile| 54 + board/samsung/smdk6400/config.mk | 30 +++ board/samsung/smdk6400/lowlevel_init.S | 316 board/samsung/smdk6400/smdk6400.c | 130 board/samsung/smdk6400/u-boot-nand.lds | 62 ++ include/configs/smdk6400.h | 304 ++ nand_spl/board/samsung/smdk6400/Makefile | 106 ++ nand_spl/board/samsung/smdk6400/config.mk | 40 nand_spl/board/samsung/smdk6400/u-boot.lds | 61 ++ 11 files changed, 1121 insertions(+), 0 deletions(-) create mode 100644 board/samsung/smdk6400/Makefile create mode 100644 board/samsung/smdk6400/config.mk create mode 100644 board/samsung/smdk6400/lowlevel_init.S create mode 100644 board/samsung/smdk6400/smdk6400.c create mode 100644 board/samsung/smdk6400/u-boot-nand.lds create mode 100644 include/configs/smdk6400.h create mode 100644 nand_spl/board/samsung/smdk6400/Makefile create mode 100644 nand_spl/board/samsung/smdk6400/config.mk create mode 100644 nand_spl/board/samsung/smdk6400/u-boot.lds diff --git a/MAKEALL b/MAKEALL index ee83cca..a3ed47d 100755 --- a/MAKEALL +++ b/MAKEALL @@ -515,6 +515,7 @@ LIST_ARM11=\ imx31_litekit \ imx31_phycore \ mx31ads \ + smdk6400\ # diff --git a/Makefile b/Makefile index b104617..0c5b8a6 100644 --- a/Makefile +++ b/Makefile @@ -2677,6 +2677,23 @@ mx31ads_config : unconfig omap2420h4_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm1136 omap2420h4 NULL omap24xx +# +## ARM1176 Systems +# +smdk6400_noUSB_config \ +smdk6400_config: unconfig + @mkdir -p $(obj)include $(obj)board/samsung/smdk6400 + @mkdir -p $(obj)nand_spl/board/samsung/smdk6400 + @echo #define CONFIG_NAND_U_BOOT $(obj)include/config.h + @if [ -z $(findstring smdk6400_noUSB_config,$@) ]; then \ + echo RAM_TEXT = 0x57e0 $(obj)board/samsung/smdk6400/config.tmp;\ + $(MKCONFIG) $(@:_config=) arm arm1176 smdk6400 samsung s3c64xx; \ + else \ + echo RAM_TEXT = 0xc7e0 $(obj)board/samsung/smdk6400/config.tmp;\ + $(MKCONFIG) $(@:_noUSB_config=) arm arm1176 smdk6400 samsung s3c64xx; \ + fi + @echo CONFIG_NAND_U_BOOT = y $(obj)include/config.mk + # # i386 # diff --git a/board/samsung/smdk6400/Makefile b/board/samsung/smdk6400/Makefile new file mode 100644 index 000..d35dc8b --- /dev/null +++ b/board/samsung/smdk6400/Makefile @@ -0,0 +1,54 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED] +# +# (C) Copyright 2008 +# Guennadi Liakhovetki, DENX Software Engineering, [EMAIL PROTECTED] +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := smdk6400.o +SOBJS := lowlevel_init.o +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) crv $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +#.depend: Makefile $(SOBJS:.o=.S)
Re: [U-Boot-Users] [PATCH 0/7 v2] SMDK6400 support
In message [EMAIL PROTECTED] you wrote: Sorry, looks like a matter of taste to me. There are also very few lines over 80 characters left, but fixing them would look too awkward... This is not a matter of taste. Please fix these, too! 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: [EMAIL PROTECTED] It is the quality rather than the quantity that matters. - Lucius Annaeus Seneca (4 B.C. - A.D. 65) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] :o)
Hello, - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 0/7 v3] SMDK6400 support
Version 3: now all lines over 80 characters are gone. And a couple more checkpatch warnings with them. 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] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/7 v3] Add definition for the AM29LV800BB AMD NOR-flash
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
drivers/mtd/jedec_flash.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 9845e93..020647a 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -234,6 +234,23 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1,7),
}
},
+ {
+ .mfr_id = MANUFACTURER_AMD,
+ .dev_id = AM29LV800BB,
+ .name = AMD AM29LV800BB,
+ .uaddr = {
+ [1] = MTD_UADDR_0x0555_0x02AA /* x16 */
+ },
+ .DevSize= SIZE_1MiB,
+ .CmdSet = CFI_CMDSET_AMD_LEGACY,
+ .NumEraseRegions= 4,
+ .regions= {
+ ERASEINFO(0x04000, 1),
+ ERASEINFO(0x02000, 2),
+ ERASEINFO(0x08000, 1),
+ ERASEINFO(0x1, 15),
+ }
+ },
#endif
};
--
1.5.4
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/7 v3] NAND_CMD_READOOB is not supported by all chips, read OOB with the page instead
I _think_ this should work with all NAND chips. Otherwise we might have to
introduce a configuration variable.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
nand_spl/nand_boot.c | 64 ++---
1 files changed, 34 insertions(+), 30 deletions(-)
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index 563a80b..0de4c4b 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -128,21 +128,6 @@ static int nand_command(struct mtd_info *mtd, int block,
int page, int offs, u8
}
#endif
-static int nand_is_bad_block(struct mtd_info *mtd, int block)
-{
- struct nand_chip *this = mtd-priv;
-
- nand_command(mtd, block, 0, CFG_NAND_BAD_BLOCK_POS, NAND_CMD_READOOB);
-
- /*
-* Read one byte
-*/
- if (this-read_byte(mtd) != 0xff)
- return 1;
-
- return 0;
-}
-
static int nand_read_page(struct mtd_info *mtd, int block, int page, uchar
*dst)
{
struct nand_chip *this = mtd-priv;
@@ -150,8 +135,6 @@ static int nand_read_page(struct mtd_info *mtd, int block,
int page, uchar *dst)
u_char *ecc_code;
u_char *oob_data;
int i;
- int eccsize = CFG_NAND_ECCSIZE;
- int eccbytes = CFG_NAND_ECCBYTES;
int eccsteps = CFG_NAND_ECCSTEPS;
uint8_t *p = dst;
int stat;
@@ -163,11 +146,12 @@ static int nand_read_page(struct mtd_info *mtd, int
block, int page, uchar *dst)
*/
ecc_calc = (u_char *)(CFG_SDRAM_BASE + 0x1);
ecc_code = ecc_calc + 0x100;
- oob_data = ecc_calc + 0x200;
+ oob_data = p + CFG_NAND_PAGE_SIZE; /* Append OOB to the page data */
- for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
+ for (i = 0; eccsteps;
+eccsteps--, i += CFG_NAND_ECCBYTES, p += CFG_NAND_ECCSIZE) {
this-enable_hwecc(mtd, NAND_ECC_READ);
- this-read_buf(mtd, p, eccsize);
+ this-read_buf(mtd, p, CFG_NAND_ECCSIZE);
this-calculate_ecc(mtd, p, ecc_calc[i]);
}
this-read_buf(mtd, oob_data, CFG_NAND_OOBSIZE);
@@ -179,7 +163,8 @@ static int nand_read_page(struct mtd_info *mtd, int block,
int page, uchar *dst)
eccsteps = CFG_NAND_ECCSTEPS;
p = dst;
- for (i = 0 ; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
+ for (i = 0; eccsteps;
+eccsteps--, i += CFG_NAND_ECCBYTES, p += CFG_NAND_ECCSIZE) {
/* No chance to do something with the possible error message
* from correct_data(). We just hope that all possible errors
* are corrected by this routine.
@@ -195,6 +180,7 @@ static int nand_load(struct mtd_info *mtd, int offs, int
uboot_size, uchar *dst)
int block;
int blockcopy_count;
int page;
+ unsigned read = 0;
/*
* offs has to be aligned to a block address!
@@ -202,18 +188,30 @@ static int nand_load(struct mtd_info *mtd, int offs, int
uboot_size, uchar *dst)
block = offs / CFG_NAND_BLOCK_SIZE;
blockcopy_count = 0;
- while (blockcopy_count (uboot_size / CFG_NAND_BLOCK_SIZE)) {
- if (!nand_is_bad_block(mtd, block)) {
- /*
-* Skip bad blocks
-*/
- for (page = 0; page CFG_NAND_PAGE_COUNT; page++) {
- nand_read_page(mtd, block, page, dst);
- dst += CFG_NAND_PAGE_SIZE;
+ while (blockcopy_count ((uboot_size + CFG_NAND_BLOCK_SIZE - 1) /
+ CFG_NAND_BLOCK_SIZE)) {
+ /*
+* Skip bad blocks
+*/
+ int badblock = 0;
+ for (page = 0; page CFG_NAND_PAGE_COUNT; page++) {
+ nand_read_page(mtd, block, page, dst);
+ if ((!page
+#ifdef CFG_NAND_BBT_2NDPAGE
+|| page == 1
+#endif
+ ) dst[CFG_NAND_PAGE_SIZE] != 0xff) {
+ badblock = 1;
+ break;
}
+ /* Overwrite skipped pages */
+ if (read = offs)
+ dst += CFG_NAND_PAGE_SIZE;
+ read += CFG_NAND_PAGE_SIZE;
+ }
+ if (!badblock)
blockcopy_count++;
- }
block++;
}
@@ -241,12 +239,18 @@ void nand_boot(void)
nand_chip.dev_ready = NULL; /* preset to NULL */
board_nand_init(nand_chip);
+ if (nand_chip.select_chip)
+ nand_chip.select_chip(nand_info, 0);
+
/*
* Load U-Boot image from NAND into RAM
*/
ret = nand_load(nand_info, CFG_NAND_U_BOOT_OFFS, CFG_NAND_U_BOOT_SIZE,
(uchar
[U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer.
De-hard code the range in RAM we search for API signature, which might not be
uniform accross architectures and board configurations. Instead use current
global_data pointer as a hint to narrow down the range the [malloc'ed] signature
could reside.
Signed-off-by: Rafal Czubak [EMAIL PROTECTED]
Signed-off-by: Rafal Jaworowski [EMAIL PROTECTED]
---
api_examples/crt0.S | 17 +++--
api_examples/glue.c | 17 -
api_examples/glue.h |6 +++---
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/api_examples/crt0.S b/api_examples/crt0.S
index 8d4f706..80b7297 100644
--- a/api_examples/crt0.S
+++ b/api_examples/crt0.S
@@ -24,14 +24,16 @@
*/
#if defined(CONFIG_PPC)
-
.text
.globl _start
_start:
+ /* Store global data ptr as a hint for U-Boot address range */
+ lis %r11, [EMAIL PROTECTED]
+ addi%r11, %r11, [EMAIL PROTECTED]
+ stw %r2, 0(%r11)
b main
-
.globl syscall
syscall:
lis %r11, [EMAIL PROTECTED]
@@ -39,12 +41,15 @@ syscall:
lwz %r11, 0(%r11)
mtctr %r11
bctr
-
+#else
+#error No support for this arch!
+#endif
.globl syscall_ptr
syscall_ptr:
.align 4
.long 0
-#else
-#error No support for this arch!
-#endif
+
+ .globl gd_ptr
+gd_ptr:
+ .long 0
diff --git a/api_examples/glue.c b/api_examples/glue.c
index 2bf47ae..7218b86 100644
--- a/api_examples/glue.c
+++ b/api_examples/glue.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2007 Semihalf
+ * (C) Copyright 2007-2008 Semihalf
*
* Written by: Rafal Jaworowski [EMAIL PROTECTED]
*
@@ -57,16 +57,23 @@ static int valid_sig(struct api_signature *sig)
*
* returns 1/0 depending on found/not found result
*/
-int api_search_sig(struct api_signature **sig) {
-
+int api_search_sig(struct api_signature **sig)
+{
unsigned char *sp;
+ uint32_t start = 0, end = 0;
if (sig == NULL)
return 0;
- sp = (unsigned char *)API_SEARCH_START;
+ if (gd_ptr == NULL)
+ return 0;
+
+ /* Global data ptr helps to narrow down the search range */
+ start = (uint32_t)gd_ptr ~(API_SEARCH_LEN - 1);
+ end = start + API_SEARCH_LEN - API_SIG_MAGLEN;
- while ((sp + (int)API_SIG_MAGLEN) (unsigned char *)API_SEARCH_END) {
+ sp = (unsigned char *)start;
+ while ((sp + API_SIG_MAGLEN) (unsigned char *)end) {
if (!memcmp(sp, API_SIG_MAGIC, API_SIG_MAGLEN)) {
*sig = (struct api_signature *)sp;
if (valid_sig(*sig))
diff --git a/api_examples/glue.h b/api_examples/glue.h
index a82f783..76cb580 100644
--- a/api_examples/glue.h
+++ b/api_examples/glue.h
@@ -30,11 +30,11 @@
#ifndef _API_GLUE_H_
#define _API_GLUE_H_
-#define API_SEARCH_START (255 * 1024 * 1024) /* start at 1MB below
top RAM */
-#define API_SEARCH_END (256 * 1024 * 1024 - 1) /* ...and search to the
end */
+#define API_SEARCH_LEN (2 * 1024 * 1024) /* 2MB search range */
intsyscall(int, int *, ...);
-void * syscall_ptr;
+extern void *syscall_ptr;
+extern gd_t *gd_ptr;
intapi_search_sig(struct api_signature **sig);
--
1.5.2.2
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] API: Provide syscall entry point implementation for the ARM architecture.
(Tested on ARM920-based EP93xx system) Signed-off-by: Rafal Czubak [EMAIL PROTECTED] Acked-by: Rafal Jaworowski [EMAIL PROTECTED] --- api_examples/Makefile |6 +++--- api_examples/crt0.S | 17 +++-- lib_arm/board.c |5 + 3 files changed, 23 insertions(+), 5 deletions(-) diff --git a/api_examples/Makefile b/api_examples/Makefile index 5666f48..d09f8f8 100644 --- a/api_examples/Makefile +++ b/api_examples/Makefile @@ -24,9 +24,9 @@ ifeq ($(ARCH),ppc) LOAD_ADDR = 0x4 endif -#ifeq ($(ARCH),arm) -#LOAD_ADDR = 0xc10 -#endif +ifeq ($(ARCH),arm) +LOAD_ADDR = 0x100 +endif include $(TOPDIR)/config.mk diff --git a/api_examples/crt0.S b/api_examples/crt0.S index 80b7297..a9e2dea 100644 --- a/api_examples/crt0.S +++ b/api_examples/crt0.S @@ -1,5 +1,5 @@ /* - * (C) Copyright 2007 Semihalf + * (C) Copyright 2007-2008 Semihalf * * Written by: Rafal Jaworowski [EMAIL PROTECTED] * @@ -25,7 +25,6 @@ #if defined(CONFIG_PPC) .text - .globl _start _start: /* Store global data ptr as a hint for U-Boot address range */ @@ -41,6 +40,20 @@ syscall: lwz %r11, 0(%r11) mtctr %r11 bctr + +#elif defined(CONFIG_ARM) + .text + .globl _start +_start: + ldr ip, =gd_ptr + str r8, [ip] + b main + + .globl syscall +syscall: + ldr ip, =syscall_ptr + ldr pc, [ip] + #else #error No support for this arch! #endif diff --git a/lib_arm/board.c b/lib_arm/board.c index a093860..c47b52c 100644 --- a/lib_arm/board.c +++ b/lib_arm/board.c @@ -431,6 +431,11 @@ void start_armboot (void) jumptable_init (); +#if defined(CONFIG_API) + /* Initialize API */ + api_init (); +#endif + console_init_r (); /* fully init console as a device */ #if defined(CONFIG_MISC_INIT_R) -- 1.5.2.2 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 4/7 v3] USB: Add support for OHCI controller on s3c6400
Notice: USB on s3c6400 currently works _only_ with switched off MMU. One could
try to enable the MMU, but map addresses 1-to-1, and disable data cache, then
it should work too and we could still profit from instruction cache.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
cpu/arm1176/s3c64xx/Makefile |1 +
cpu/arm1176/s3c64xx/usb.c| 45 ++
drivers/usb/usb_ohci.c |1 +
3 files changed, 47 insertions(+), 0 deletions(-)
create mode 100644 cpu/arm1176/s3c64xx/usb.c
diff --git a/cpu/arm1176/s3c64xx/Makefile b/cpu/arm1176/s3c64xx/Makefile
index fa4ee3f..4ab1811 100644
--- a/cpu/arm1176/s3c64xx/Makefile
+++ b/cpu/arm1176/s3c64xx/Makefile
@@ -30,6 +30,7 @@ LIB = $(obj)lib$(SOC).a
COBJS-y= interrupts.o
COBJS-$(CONFIG_S3C6400)+= cpu_init.o speed.o
+COBJS-$(CONFIG_USB_OHCI_NEW) += usb.o
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
diff --git a/cpu/arm1176/s3c64xx/usb.c b/cpu/arm1176/s3c64xx/usb.c
new file mode 100644
index 000..274a4ed
--- /dev/null
+++ b/cpu/arm1176/s3c64xx/usb.c
@@ -0,0 +1,45 @@
+/*
+ * URB OHCI HCD (Host Controller Driver) initialization for USB on the S3C64XX.
+ *
+ * Copyright (C) 2008,
+ * Guennadi Liakhovetski, DENX Software Engineering [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include common.h
+#include s3c6400.h
+
+int usb_cpu_init(void)
+{
+ OTHERS_REG |= 0x1;
+ return 0;
+}
+
+int usb_cpu_stop(void)
+{
+ OTHERS_REG = ~0x1;
+ return 0;
+}
+
+void usb_cpu_init_fail(void)
+{
+ OTHERS_REG = ~0x1;
+}
diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c
index fd60edb..0bfa4d7 100644
--- a/drivers/usb/usb_ohci.c
+++ b/drivers/usb/usb_ohci.c
@@ -69,6 +69,7 @@
#if defined(CONFIG_ARM920T) || \
defined(CONFIG_S3C2400) || \
defined(CONFIG_S3C2410) || \
+defined(CONFIG_S3C6400) || \
defined(CONFIG_440EP) || \
defined(CONFIG_PCI_OHCI) || \
defined(CONFIG_MPC5200) || \
--
1.5.4
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 5/7 v3] serial: add s3c64xx serial driver
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
Also added my copyright to the driver.
drivers/serial/Makefile |1 +
drivers/serial/s3c64xx.c | 189 ++
2 files changed, 190 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/s3c64xx.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index c9e797e..2a11ae5 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -30,6 +30,7 @@ COBJS-y += mcfuart.o
COBJS-y += ns9750_serial.o
COBJS-y += ns16550.o
COBJS-y += s3c4510b_uart.o
+COBJS-$(CONFIG_S3C64XX) += s3c64xx.o
COBJS-y += serial.o
COBJS-y += serial_max3100.o
COBJS-y += serial_pl010.o
diff --git a/drivers/serial/s3c64xx.c b/drivers/serial/s3c64xx.c
new file mode 100644
index 000..9580909
--- /dev/null
+++ b/drivers/serial/s3c64xx.c
@@ -0,0 +1,189 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, [EMAIL PROTECTED]
+ *
+ * (C) Copyright 2008
+ * Guennadi Liakhovetki, DENX Software Engineering, [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include common.h
+
+#include s3c6400.h
+
+#ifdef CONFIG_SERIAL1
+#define UART_NRS3C64XX_UART0
+
+#elif defined(CONFIG_SERIAL2)
+#define UART_NRS3C64XX_UART1
+
+#elif defined(CONFIG_SERIAL3)
+#define UART_NRS3C64XX_UART2
+
+#else
+#error Bad: you didn't configure serial ...
+#endif
+
+#define barrier() asm volatile( ::: memory)
+
+/* See table in 31.6.11 */
+static const int udivslot[] = {
+ 0,
+ 0x0080,
+ 0x0808,
+ 0x0888,
+ 0x,
+ 0x4924,
+ 0x4a52,
+ 0x54aa,
+ 0x,
+ 0xd555,
+ 0xd5d5,
+ 0xddd5,
+ 0x,
+ 0xdfdd,
+ 0xdfdf,
+ 0xffdf,
+};
+
+void serial_setbrg(void)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+ u32 reg, pclk_ratio = get_PCLK() / gd-baudrate;
+ int i;
+
+ /* PCLK / (16 * baudrate) - 1 */
+ reg = pclk_ratio / 16 - 1;
+ i = pclk_ratio - (reg + 1) * 16;
+
+ uart-UBRDIV = reg;
+ uart-UDIVSLOT = udivslot[i];
+
+ for (i = 0; i 100; i++)
+ barrier();
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ *
+ */
+int serial_init(void)
+{
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+
+ /* reset and enable FIFOs, set triggers to the maximum */
+ uart-UFCON = 0xff;
+ uart-UMCON = 0;
+ /* 8N1 */
+ uart-ULCON = 3;
+ /* No interrupts, no DMA, pure polling */
+ uart-UCON = 5;
+
+ serial_setbrg();
+
+ return 0;
+}
+
+/*
+ * Read a single byte from the serial port. Returns 1 on success, 0
+ * otherwise. When the function is succesfull, the character read is
+ * written into its argument c.
+ */
+int serial_getc(void)
+{
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+
+ /* wait for character to arrive */
+ while (!(uart-UTRSTAT 0x1));
+
+ return uart-URXH 0xff;
+}
+
+#ifdef CONFIG_HWFLOW
+static int hwflow; /* turned off by default */
+int hwflow_onoff(int on)
+{
+ switch (on) {
+ case 1:
+ hwflow = 1; /* turn on */
+ break;
+ case -1:
+ hwflow = 0; /* turn off */
+ break;
+ }
+ return hwflow;
+}
+#endif
+
+#ifdef CONFIG_MODEM_SUPPORT
+static int be_quiet;
+void disable_putc(void)
+{
+ be_quiet = 1;
+}
+
+void enable_putc(void)
+{
+ be_quiet = 0;
+}
+#endif
+
+
+/*
+ * Output a single byte to the serial port.
+ */
+void serial_putc(const char c)
+{
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+
+#ifdef CONFIG_MODEM_SUPPORT
+ if (be_quiet)
+ return;
+#endif
+
+ /* wait for room in the tx FIFO */
+ while (!(uart-UTRSTAT 0x2));
+
+#ifdef CONFIG_HWFLOW
+ /* Wait for CTS up */
+ while (hwflow !(uart-UMSTAT 0x1));
+#endif
+
+ uart-UTXH = c;
+
+ /* If \n, also do \r */
+ if (c == '\n')
+ serial_putc('\r');
+}
+
+/*
+ * Test whether a
[U-Boot-Users] [PATCH 6/7 v3] NAND: add NAND driver for s3c64xx
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c64xx.c | 307
2 files changed, 308 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/s3c64xx.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 7bd22a0..236cf03 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -33,6 +33,7 @@ COBJS-y += nand_bbt.o
COBJS-y += nand_util.o
COBJS-y += fsl_upm.o
+COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mtd/nand/s3c64xx.c b/drivers/mtd/nand/s3c64xx.c
new file mode 100644
index 000..162ec26
--- /dev/null
+++ b/drivers/mtd/nand/s3c64xx.c
@@ -0,0 +1,307 @@
+/*
+ * (C) Copyright 2006 DENX Software Engineering
+ *
+ * Implementation for U-Boot 1.1.6 by Samsung
+ *
+ * (C) Copyright 2008
+ * Guennadi Liakhovetki, DENX Software Engineering, [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+
+#include nand.h
+#include s3c6400.h
+
+#include asm/io.h
+
+#ifdef CONFIG_NAND_SPL
+#define printf(arg...) do {} while (0)
+#endif
+
+/* Nand flash definition values by jsgood */
+#ifdef S3C_NAND_DEBUG
+/*
+ * Function to print out oob buffer for debugging
+ * Written by jsgood
+ */
+static void print_oob(const char *header, struct mtd_info *mtd)
+{
+ int i;
+ struct nand_chip *chip = mtd-priv;
+
+ printf(%s:\t, header);
+
+ for (i = 0; i 64; i++)
+ printf(%02x , chip-oob_poi[i]);
+
+ printf(\n);
+}
+#endif /* S3C_NAND_DEBUG */
+
+#ifdef CONFIG_NAND_SPL
+static u_char nand_read_byte(struct mtd_info *mtd)
+{
+ struct nand_chip *this = mtd-priv;
+ return readb(this-IO_ADDR_R);
+}
+
+static void nand_write_byte(struct mtd_info *mtd, u_char byte)
+{
+ struct nand_chip *this = mtd-priv;
+ writeb(byte, this-IO_ADDR_W);
+}
+
+static void nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ int i;
+ struct nand_chip *this = mtd-priv;
+
+ for (i = 0; i len; i++)
+ buf[i] = readb(this-IO_ADDR_R);
+}
+#endif
+
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+ int ctrl = readl(NFCONT);
+
+ switch (chip) {
+ case -1:
+ ctrl |= 6;
+ break;
+ case 0:
+ ctrl = ~2;
+ break;
+ case 1:
+ ctrl = ~4;
+ break;
+ default:
+ return;
+ }
+
+ writel(ctrl, NFCONT);
+}
+
+/*
+ * Hardware specific access to control-lines function
+ * Written by jsgood
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd)
+{
+ struct nand_chip *this = mtd-priv;
+
+ switch (cmd) {
+ case NAND_CTL_SETCLE:
+ this-IO_ADDR_W = (void __iomem *)NFCMMD;
+ break;
+ case NAND_CTL_CLRCLE:
+ this-IO_ADDR_W = (void __iomem *)NFDATA;
+ break;
+ case NAND_CTL_SETALE:
+ this-IO_ADDR_W = (void __iomem *)NFADDR;
+ break;
+ case NAND_CTL_CLRALE:
+ this-IO_ADDR_W = (void __iomem *)NFDATA;
+ break;
+ case NAND_CTL_SETNCE:
+ s3c_nand_select_chip(mtd, 0);
+ break;
+ case NAND_CTL_CLRNCE:
+ s3c_nand_select_chip(mtd, -1);
+ break;
+ }
+}
+
+/*
+ * Function for checking device ready pin
+ * Written by jsgood
+ */
+static int s3c_nand_device_ready(struct mtd_info *mtdinfo)
+{
+ while (!(readl(NFSTAT) NFSTAT_RnB)) {}
+ return 1;
+}
+
+#ifdef CFG_S3C_NAND_HWECC
+/*
+ * This function is called before encoding ecc codes to ready ecc engine.
+ * Written by jsgood
+ */
+static void s3c_nand_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+ u_long nfcont, nfconf;
+
+ /*
+* The original driver used 4-bit ECC for new MLC chips, i.e., for
+* those with non-zero ID[3][3:2], which anyway only holds for ST
+* (Numonyx) chips
+*/
+ nfconf = readl(NFCONF) ~NFCONF_ECC_4BIT;
+
+
Re: [U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer.
In message [EMAIL PROTECTED] you wrote: De-hard code the range in RAM we search for API signature, which might not be uniform accross architectures and board configurations. Instead use current global_data pointer as a hint to narrow down the range the [malloc'ed] signature could reside. Which is the exact rationale of this? Note that the GD pointer can point basicly anywhere - some part of dual ported RAM, SRAM, OCM, ... 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: [EMAIL PROTECTED] Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] sequoia uarts
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: I have verified that the Sequoia (440EPx) does not have its UARTs properly configured. The attached patch corrects this by setting three bits in SDR0_PFC1 to enable 4-wire mode, and to select cts/rts functionality for the UARTs. Also, I modified the GPIO settings for We definitely do NOT want any hardware handshake on the serial console. Never. Best regards, Wolfgang Denk Perhaps my comments were not clear. Please let me try again: The schematic for the Sequoia shows two uarts. U-boot leaves the SDR0_PFC1[U0IM] bit cleared to 0, which means that the 440EPx will only have one uart, operating in 8-wire mode. So, U-boot does not set the CPU to the correct mode to enable two uarts. This is independent of whether you want RTS/CTS or not, and as far as I can see, it must be fixed if both uart ports are going to work. This also applies to the GPIOs. They are not set correctly to connect the uarts to the I/O pins - the wrong functions and polarities are selected. This too is dictated by the schematic. The wires go where they go, and the GPIOs should be configured to match the schematic (or the schematic should be changed to match the software, but we know that isn't going to happen). :-) The remaining point is the SDR0_PFC1[U0ME] and SDR0_PFC1[U1ME] bits, which determine whether the control signals are RTS/CTS or DCD/DSR. These signals are wired to the DB-9 jacks on pins 7 and 8. According to the RS232 standard, these pins are RTS/CTS, and there is nothing software can do to change their meaning. So, I believe my patch should be applied as written, so that the software and hardware agree as to function. That said, /what we choose to do with the lines is up to us/. If we don't want to enable RTS/CTS processing in the drivers, that is fine. We can leave the function disabled. But the hardware registers must be configured to at least match the schematic wiring. Anything else makes no sense. Steve - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On 8/3/08, Wolfgang Denk [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] you wrote: What about creating a tool that parses a device tree and creates (or updates) the board header file? This will retain compatibility with other platforms, clean up the existing header files (they won't need to contain as much information), and reduce the amount of changes to U-Boot itself. That's a good idea. I have used variation on this concept in the past and they have worked out well. A much more powerful concept is to have U-Boot read and interpret the DT dynamically - only then can you use the same U-Boot binary image on different board configurations, which is an important feature for many board vendors. A combination of the two approaches may be best. During the build process feed uboot all of the DTS files you want it to be able to handle. That will let it figure out the right config flags to set when building the image. This will allow uboot to compile with the minimal set of needed features and make it much easier to get started with. Of course current DTS file will need some more info added like DRAM timings. Sybase uses this process for cell phone databases. You start with a full feature db engine and develop your code against it. When your code is finished you run all of the commands and the engine tracks which SQL features you used. It then generates a new, smaller db engine that only supports those features. BTW, how do know which DT to dynamically interpret? If you are installing a universal uboot you still are going to have to install a different DT in each model. If you're installing a different DT you might as well install a different uboot. I guess the intention is to have three pieces - uboot, DT, kernel. -- Jon Smirl [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Jon Smirl wrote: BTW, how do know which DT to dynamically interpret? If you are installing a universal uboot you still are going to have to install a different DT in each model. If you're installing a different DT you might as well install a different uboot. That's what I was thinking, too. Maybe on some boards, the DTB can be stored on some other type of memory that is easier to update during the manufacturing process. In that case, I can see how some vendors would like on u-boot.bin for all boards. Other than that, I don't see the point of having a generic u-boot.bin. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] API: Optimize signature searching scheme in the glue layer.
In message [EMAIL PROTECTED] you wrote: The idea was to discover the proximity of where to look for the API signature in run-time and only search within some range around it. This way we'd drop static definitions of the search range. I think this is pretty unreliable. The assumption was that global data should be close enough to U-Boot's malloc area (where the signature is stored) and this works for us on PPC and ARM. Do you see any problems with this approach in general i.e. can it really happen that after relocation we end up with global data stored at distant location than other U-Boot data? I don't know exactly what other architectures are doing. In any case, you try to build logic on some implementation as it happens to be right now, but since this is nowhere an officially documented interface - it can change any time without warning. To be honest, I am not even sure if the GD data get copied to RAM on PowerPC, and if so, if it's done on all of them. 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: [EMAIL PROTECTED] Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
In message [EMAIL PROTECTED] you wrote: Why? One address is as good as any other. I think statistically you'll find that that isn't true. A built-in DTB is more likely to be present on the flash than an external DTB would be. Please present the data your statistics is based on. 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: [EMAIL PROTECTED] Superior ability breeds superior ambition. -- Spock, Space Seed, stardate 3141.9 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Why? One address is as good as any other. I think statistically you'll find that that isn't true. A built-in DTB is more likely to be present on the flash than an external DTB would be. Please present the data your statistics is based on. Give me a break, Wolfgang. I don't have any data, but what I'm saying makes sense. A system is more likely to have one binary blob present than two bloba. That has to be obvious. -- Timur Tabi Linux kernel developer at Freescale - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: mailing list transfer
Hi Wolfgang, yes, please do so. I just returned from vacation and got unsubscribed again :-( Matthias On Friday 01 August 2008 17:17, Wolfgang Denk wrote: Hello, I would like to get your general opinion about moving the u-boot-users mailing list away from SourceForge and host it on lists.denx.de instead. There is a couple of reasons for this: SourceForge has freuently been slow; there have been reports from many users who got unsubscribed repeatedly for no clear reason; the mailing list archive at SF is painful to use; and, most of all, we have only limited ways to change the configuration, and with any other request we depend on the mercy of SF support, which is, ummm, slw. Another reason is that this would make it easier for us to cross-link between messages on the mailing list and entries in the upcoming bug and patch tracking system. If we have a majority agreeing with this change, I suggest to proceed as follows: * The new mailing list will be created as [EMAIL PROTECTED] * The mailing list archive will be transferred from SF to DENX * The archive services (gmane etc.) will be notified about the change * All currently subscribed users and their settings will be transferred from SF to DENX * After a cut-off date, all users are requested to use the new ML only [that will be the complicated part]. * The ML at SF will be set to read-only to make clear it is no longer * in use. Do you think this is a reasonable plan? Any hints, ideas, tips? Best regards, Wolfgang Denk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Hi, in general I totally ack to a new version numbering scheme. When we are releasing U-Boot for some of our hardware this is typically done asynchronous to the U-Boot release cycle. We (often) cannot wait until a new U-Boot is released. So we take the current U-Boot version + build date/time as effective version. We also used CONFIG_IDENT_STRING to identify a special version some time ago. But I do not like it much. Do you see a better way to identify a special U-Boot version? EXTRAVERSION could be fine, but it is already used to release candidates etc. What is common practice in other companies? Matthias On Friday 01 August 2008 17:32, Wolfgang Denk wrote: Hello, I would like to get your general opinion about changing the U-Boot version numbering scheme. To be honest, I never really understood myself how this is supposed to work and if the next version should be 1.3.4 or 1.4.0 or 2.0.0, i. e. which changes / additions are important enough to increment the PATCHLEVEL or even VERSION number. I therefor suggest to drop this style of version numbering and change to a timestamp based version number system which has been quite successfully used by other projects (like Ubuntu) or is under discussion (for Linux). My suggestion for the new version numbers is as follows: VERSION = 1 (at least for the time being) PATCHLEVEL = current year - 2000 SUBLEVEL = current month Both PATCHLEVEL and SUBLEVEL shall always be 2 digits (at least for the next 91+ years to come) so listings for example on an FTP server shall be in a sane sorting order. If we accept this system, the next release which probably comes out in October 2008 would be v1.08.10, and assuming the one after that comes out in January 2009 would be named v1.09.01 Comments? Best regards, Wolfgang Denk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
On Fri, Aug 01, 2008 at 12:16:13PM -0500, Jatin Sharma wrote: I have to increase u-boot's partition size on my board to make room for an application to be compiled as part of u-boot binary. I am currently running u-boot version 1.3.1-rc1 and my current NOR partition is as follows: Partition Address /dev/mtd0 -RCW, 64k 0xFF80 /dev/mtd1 Kernel 2M0xFF81 /dev/mtd2 cramfs 4.8M 0xFFA1 /dev/mtd3 U-Boot 384K 0xFFF0 /dev/mtd4 Env 64K 0xFFF6 /dev/mtd5 EnvB 64K 0xFFF7 /dev/mtd6 DTB 64K 0xFFF9 I have updated to Flattened Device Tree to reflect the new partition as follows. Also, I have updated the TEXT_BASE to 0xFFE6 in the config.mk under board/my board directory. Partition Address /dev/mtd0 -RCW, 64k 0xFF80 /dev/mtd1 Kernel 2M0xFF81 /dev/mtd2 cramfs 4.3M 0xFFA1 /dev/mtd3 U-Boot 1M 0xFFE6 /dev/mtd4 Env 64K 0xFFF6 /dev/mtd5 EnvB 64K 0xFFF7 /dev/mtd6 DTB 64K 0xFFF9 U-Boot binary with the updated FDT doesn't boot. You changed the address where u-boot starts. Does the CPU know about this when it branches to the boot vector? -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree after ft_board_setup()
and before the tree is handled to the kernel.
The idea is that users may want to add or manipulate nodes w/changing the u-boot
binary. The current point in the code we do this we have yet to determine the
final size and have yet to do the final fixup of the initrd information.
If its desirable for the 'fdtcmd' support to have the proper initrd information
a bit of code reorder will be in order.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/fdt_support.c | 21 +
include/fdt_support.h |1 +
lib_ppc/bootm.c |1 +
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 93b144e..b1aa7df 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -30,6 +30,10 @@
#include fdt_support.h
#include exports.h
+#ifdef CFG_HUSH_PARSER
+#include hush.h
+#endif
+
/*
* Global data (for the gd-bd)
*/
@@ -529,3 +533,20 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev)
fdt_strerror(err));
}
#endif /* defined(CONFIG_MPC83XX) || defined(CONFIG_MPC85xx) */
+
+int ft_env_setup(void *blob, bd_t *bd)
+{
+ int rcode = 0;
+
+ working_fdt = blob;
+
+#ifndef CFG_HUSH_PARSER
+ if (run_command (getenv (fdtcmd), 0) 0)
+ rcode = 1;
+#else
+ if (parse_string_outer (getenv (fdtcmd),
+ FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP) != 0)
+ rcode = 1;
+#endif
+ return rcode;
+}
diff --git a/include/fdt_support.h b/include/fdt_support.h
index a7c6326..a60b5f0 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -67,6 +67,7 @@ void ft_board_setup(void *blob, bd_t *bd);
void ft_cpu_setup(void *blob, bd_t *bd);
void ft_pci_setup(void *blob, bd_t *bd);
#endif
+int ft_env_setup(void *blob, bd_t *bd);
#endif /* ifdef CONFIG_OF_LIBFDT */
#endif /* ifndef __FDT_SUPPORT_H */
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index a872d31..d7a1236 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -194,6 +194,7 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
/* Call the board-specific fixup routine */
ft_board_setup(of_flat_tree, gd-bd);
#endif
+ ft_env_setup(of_flat_tree, gd-bd);
}
/* Fixup the fdt memreserve now that we know how big it is */
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? 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: [EMAIL PROTECTED] Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] POWERPC: Add synchronization to write_bat in lib_ppc/bat_rw.c
Perform sync/isync as required by the architecture.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
lib_ppc/bat_rw.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib_ppc/bat_rw.c b/lib_ppc/bat_rw.c
index 8546333..a40b377 100644
--- a/lib_ppc/bat_rw.c
+++ b/lib_ppc/bat_rw.c
@@ -25,9 +25,12 @@
#include common.h
#include asm/processor.h
#include asm/mmu.h
+#include asm/io.h
int write_bat (ppc_bat_t bat, unsigned long upper, unsigned long lower)
{
+ sync();
+
switch (bat) {
case DBAT0:
mtspr (DBAT0L, lower);
@@ -99,6 +102,9 @@ int write_bat (ppc_bat_t bat, unsigned long upper, unsigned
long lower)
return (-1);
}
+ sync();
+ isync();
+
return (0);
}
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] POWERPC 86xx: Move BAT setup code to C
This is needed because we will be possibly be locating
devices at physical addresses above 32bits, and the asm
preprocessing does not appear to deal with ULL constants
properly. We now call write_bat in lib_ppc/bat_rw.c.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
cpu/mpc86xx/cpu_init.c | 25 ++
cpu/mpc86xx/start.S| 119
2 files changed, 25 insertions(+), 119 deletions(-)
diff --git a/cpu/mpc86xx/cpu_init.c b/cpu/mpc86xx/cpu_init.c
index 78ba1ea..1fda3fe 100644
--- a/cpu/mpc86xx/cpu_init.c
+++ b/cpu/mpc86xx/cpu_init.c
@@ -26,8 +26,10 @@
* cpu_init.c - low level cpu init
*/
+#include config.h
#include common.h
#include mpc86xx.h
+#include asm/mmu.h
#include asm/fsl_law.h
DECLARE_GLOBAL_DATA_PTR;
@@ -121,3 +123,26 @@ int cpu_init_r(void)
{
return 0;
}
+
+/* Set up BAT registers */
+void setup_bats(void)
+{
+ write_bat(DBAT0, CFG_DBAT0U, CFG_DBAT0L);
+ write_bat(IBAT0, CFG_IBAT0U, CFG_IBAT0L);
+ write_bat(DBAT1, CFG_DBAT1U, CFG_DBAT1L);
+ write_bat(IBAT1, CFG_IBAT1U, CFG_IBAT1L);
+ write_bat(DBAT2, CFG_DBAT2U, CFG_DBAT2L);
+ write_bat(IBAT2, CFG_IBAT2U, CFG_IBAT2L);
+ write_bat(DBAT3, CFG_DBAT3U, CFG_DBAT3L);
+ write_bat(IBAT3, CFG_IBAT3U, CFG_IBAT3L);
+ write_bat(DBAT4, CFG_DBAT4U, CFG_DBAT4L);
+ write_bat(IBAT4, CFG_IBAT4U, CFG_IBAT4L);
+ write_bat(DBAT5, CFG_DBAT5U, CFG_DBAT5L);
+ write_bat(IBAT5, CFG_IBAT5U, CFG_IBAT5L);
+ write_bat(DBAT6, CFG_DBAT6U, CFG_DBAT6L);
+ write_bat(IBAT6, CFG_IBAT6U, CFG_IBAT6L);
+ write_bat(DBAT7, CFG_DBAT7U, CFG_DBAT7L);
+ write_bat(IBAT7, CFG_IBAT7U, CFG_IBAT7L);
+
+ return;
+}
diff --git a/cpu/mpc86xx/start.S b/cpu/mpc86xx/start.S
index c39dc46..03f2128 100644
--- a/cpu/mpc86xx/start.S
+++ b/cpu/mpc86xx/start.S
@@ -358,125 +358,6 @@ invalidate_bats:
sync
blr
-
- /* setup_bats - set them up to some initial state */
- /* Skip any BATS setup in early_bats */
- .globl setup_bats
-setup_bats:
-
- addis r0, r0, 0x
-
- /* IBAT 0 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr IBAT0L, r4
- mtspr IBAT0U, r3
- isync
-
- /* DBAT 0 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr DBAT0L, r4
- mtspr DBAT0U, r3
- isync
-
- /* IBAT 1 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr IBAT1L, r4
- mtspr IBAT1U, r3
- isync
-
- /* DBAT 1 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr DBAT1L, r4
- mtspr DBAT1U, r3
- isync
-
- /* IBAT 2 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr IBAT2L, r4
- mtspr IBAT2U, r3
- isync
-
- /* DBAT 2 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr DBAT2L, r4
- mtspr DBAT2U, r3
- isync
-
- /* IBAT 3 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr IBAT3L, r4
- mtspr IBAT3U, r3
- isync
-
- /* DBAT 3 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr DBAT3L, r4
- mtspr DBAT3U, r3
- isync
-
- /* IBAT 4 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr IBAT4L, r4
- mtspr IBAT4U, r3
- isync
-
- /* DBAT 4 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr DBAT4L, r4
- mtspr DBAT4U, r3
- isync
-
- /* IBAT 7 */
- addis r4, r0, [EMAIL PROTECTED]
- ori r4, r4, [EMAIL PROTECTED]
- addis r3, r0, [EMAIL PROTECTED]
- ori r3, r3, [EMAIL PROTECTED]
- mtspr IBAT7L, r4
- mtspr IBAT7U, r3
- isync
-
- /* DBAT 7 */
-
[U-Boot-Users] [PATCH] POWERPC: Change 86xx platforms to use CONFIG_NR_CPUS
Currently, they use CONFIG_NUM_CPUS, which is different than 85xx for no good reason. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- cpu/mpc86xx/start.S |4 ++-- include/configs/MPC8610HPCD.h |2 +- include/configs/MPC8641HPCN.h |2 +- include/configs/sbc8641d.h|2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/cpu/mpc86xx/start.S b/cpu/mpc86xx/start.S index 03f2128..83072bb 100644 --- a/cpu/mpc86xx/start.S +++ b/cpu/mpc86xx/start.S @@ -183,7 +183,7 @@ boot_warm: /* if this is a multi-core system we need to check which cpu * this is, if it is not cpu 0 send the cpu to the linux reset * vector */ -#if (CONFIG_NUM_CPUS 1) +#if (CONFIG_NR_CPUS 1) mfspr r0, MSSCR0 andi. r0, r0, 0x0020 rlwinm r0,r0,27,31,31 @@ -979,7 +979,7 @@ unlock_ram_in_cache: * Sri: Much of this initialization is not required. Linux * rewrites the bats, and the sprs and also enables the L1 cache. */ -#if (CONFIG_NUM_CPUS 1) +#if (CONFIG_NR_CPUS 1) .globl secondary_cpu_setup secondary_cpu_setup: /* Do only core setup on all cores except cpu0 */ diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 1cba270..b97e56d 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -17,7 +17,7 @@ #define CONFIG_MPC86xx 1 /* MPC86xx */ #define CONFIG_MPC8610 1 /* MPC8610 specific */ #define CONFIG_MPC8610HPCD 1 /* MPC8610HPCD board specific */ -#define CONFIG_NUM_CPUS1 /* Number of CPUs in the system */ +#define CONFIG_NR_CPUS 2 /* Number of CPUs in the system */ #define CONFIG_LINUX_RESET_VEC 0x100 /* Reset vector used by Linux */ #define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h index ccba409..78a9d11 100644 --- a/include/configs/MPC8641HPCN.h +++ b/include/configs/MPC8641HPCN.h @@ -36,7 +36,7 @@ #define CONFIG_MPC86xx 1 /* MPC86xx */ #define CONFIG_MPC8641 1 /* MPC8641 specific */ #define CONFIG_MPC8641HPCN 1 /* MPC8641HPCN board specific */ -#define CONFIG_NUM_CPUS2 /* Number of CPUs in the system */ +#define CONFIG_NR_CPUS 2 /* Number of CPUs in the system */ #define CONFIG_LINUX_RESET_VEC 0x100 /* Reset vector used by Linux */ #ifdef RUN_DIAG diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h index 3cd9ff8..76712fd 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -40,7 +40,7 @@ #define CONFIG_MPC86xx 1 /* MPC86xx */ #define CONFIG_MPC8641 1 /* MPC8641 specific */ #define CONFIG_SBC8641D1 /* SBC8641D board specific */ -#define CONFIG_NUM_CPUS 2 /* Number of CPUs in the system */ +#define CONFIG_NR_CPUS 2 /* Number of CPUs in the system */ #define CONFIG_LINUX_RESET_VEC 0x100 /* Reset vector used by Linux */ #ifdef RUN_DIAG -- 1.5.5.1 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
No, I don't think I made changes to let CPU know about this when it branches to the boot vector. After I posted this message, I learned the reset vector for the PPC architecture lies at 0xFFF00100. Does it mean the u-boot has to start at the address 0xFFF0? If not, how can I let CPU know to look for u-boot at this new address? Please let me know if it is documented somewhere. Thanks, Jatin 2008/8/4 Scott Wood [EMAIL PROTECTED]: On Fri, Aug 01, 2008 at 12:16:13PM -0500, Jatin Sharma wrote: I have to increase u-boot's partition size on my board to make room for an application to be compiled as part of u-boot binary. I am currently running u-boot version 1.3.1-rc1 and my current NOR partition is as follows: Partition Address /dev/mtd0 -RCW, 64k 0xFF80 /dev/mtd1 Kernel 2M0xFF81 /dev/mtd2 cramfs 4.8M 0xFFA1 /dev/mtd3 U-Boot 384K 0xFFF0 /dev/mtd4 Env 64K 0xFFF6 /dev/mtd5 EnvB 64K 0xFFF7 /dev/mtd6 DTB 64K 0xFFF9 I have updated to Flattened Device Tree to reflect the new partition as follows. Also, I have updated the TEXT_BASE to 0xFFE6 in the config.mk under board/my board directory. Partition Address /dev/mtd0 -RCW, 64k 0xFF80 /dev/mtd1 Kernel 2M0xFF81 /dev/mtd2 cramfs 4.3M 0xFFA1 /dev/mtd3 U-Boot 1M 0xFFE6 /dev/mtd4 Env 64K 0xFFF6 /dev/mtd5 EnvB 64K 0xFFF7 /dev/mtd6 DTB 64K 0xFFF9 U-Boot binary with the updated FDT doesn't boot. You changed the address where u-boot starts. Does the CPU know about this when it branches to the boot vector? -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
Jatin Sharma wrote: After I posted this message, I learned the reset vector for the PPC architecture lies at 0xFFF00100. Well, it depends on what kind of PPC chip... Does it mean the u-boot has to start at the address 0xFFF0? Yes (or possibly zero, if the RCW is set appropriately). If not, how can I let CPU know to look for u-boot at this new address? You edit the VHDL/Verilog. :-) -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u-boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
I have Freescale MPC8347. Can you confirm that I have to have U-Boot start at 0xFFF0? Thanks, Jatin 2008/8/4 Scott Wood [EMAIL PROTECTED]: Jatin Sharma wrote: After I posted this message, I learned the reset vector for the PPC architecture lies at 0xFFF00100. Well, it depends on what kind of PPC chip... Does it mean the u-boot has to start at the address 0xFFF0? Yes (or possibly zero, if the RCW is set appropriately). If not, how can I let CPU know to look for u-boot at this new address? You edit the VHDL/Verilog. :-) -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
Jatin Sharma wrote: I have Freescale MPC8347. Can you confirm that I have to have U-Boot start at 0xFFF0? Your choices are 0xfff0 and zero, based on the BMS (Boot Memory Space) bit of the low reset control word. -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
Scott Wood wrote: Jatin Sharma wrote: I have Freescale MPC8347. Can you confirm that I have to have U-Boot start at 0xFFF0? Your choices are 0xfff0 and zero, based on the BMS (Boot Memory Space) bit of the low reset control word. Grr, that should say high reset control word. -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 7/7 v3] ARM: Add support for S3C6400 based SMDK6400 board
This is just to apologise for not CC-ing the ARM-maintainer in the original post. I did forward him the patch afterwards, sorry. 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] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u-boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. - k My original way long ago initial cut didn't do the board and /chosen fixups as part of the bootm execution. My original intent was that we would run fdt chosen and fdt bd and whatever else was necessary before running bootm, including addressing Kumar's need. Unfortunately, it would have also broken backwards compatibility and so the concept was sacrificed for backwards compatibility. :-/ Is there a better way of doing this... perhaps have a flag that says if fdt chosen and/or fdt bd is run, don't re-run it as part of bootm? Maybe have an env variable that suppressed the calling of fdt chosen and fdt bd in bootm (nofdtfixup?)? Still ugly, but it would maintain backwards compatibility but also allow us finer grained control of when fdt chosen and fdt bd (add fdt cpu?) is run and allow our users to wedge additional fdt stuff in the boot sequence. gvb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 85xx: Not enough room for program headers
Rafal,
Can you try the following patch and see if works for you (make sure the
resulting image actually boots the board). If so I'll fixup all the .lds
I changed to match.
diff --git a/board/freescale/mpc8555cds/u-boot.lds
b/board/freescale/mpc8555cds/u-boot.lds
index a18b3a7..e7fbe5d 100644
--- a/board/freescale/mpc8555cds/u-boot.lds
+++ b/board/freescale/mpc8555cds/u-boot.lds
@@ -23,6 +23,11 @@
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD ;
+}
+
SECTIONS
{
/* Read-only sections, merged into text segment: */
@@ -54,7 +59,7 @@ SECTIONS
*(.text)
*(.fixup)
*(.got1)
- }
+ } :text
_etext = .;
PROVIDE (etext = .);
.rodata:
@@ -63,7 +68,7 @@ SECTIONS
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
- }
+ } :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
@@ -115,12 +120,12 @@ SECTIONS
.bootpg ADDR(.text) + 0x7f000 :
{
cpu/mpc85xx/start.o(.bootpg)
- } = 0x
+ } :text = 0x
.resetvec ADDR(.text) + 0x7fffc :
{
*(.resetvec)
- } = 0x
+ } :text = 0x
. = ADDR(.text) + 0x8;
@@ -131,7 +136,7 @@ SECTIONS
*(.dynbss)
*(.bss)
*(COMMON)
- }
+ } :NONE
. = ALIGN(4);
_end = . ;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message Pine.LNX. [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u- boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. - k My original way long ago initial cut didn't do the board and /chosen fixups as part of the bootm execution. My original intent was that we would run fdt chosen and fdt bd and whatever else was necessary before running bootm, including addressing Kumar's need. Unfortunately, it would have also broken backwards compatibility and so the concept was sacrificed for backwards compatibility. :-/ Is there a better way of doing this... perhaps have a flag that says if fdt chosen and/or fdt bd is run, don't re-run it as part of bootm? Maybe have an env variable that suppressed the calling of fdt chosen and fdt bd in bootm (nofdtfixup?)? Still ugly, but it would maintain backwards compatibility but also allow us finer grained control of when fdt chosen and fdt bd (add fdt cpu?) is run and allow our users to wedge additional fdt stuff in the boot sequence. Is that really any better than having the ability to execute an environment variable that has 'fdt' commands in it as part of bootm? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u-boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. So just run the needed commands before you run bootm as part of your boot command sequence. 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: [EMAIL PROTECTED] One difference between a man and a machine is that a machine is quiet when well oiled. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
In message [EMAIL PROTECTED] you wrote: Your choices are 0xfff0 and zero, based on the BMS (Boot Memory Space) bit of the low reset control word. -Scott ...and of the two options, I recommend 0xfff0 (boot high). Note that the start of u-boot is 0xfff0 but the reset vector itself is 0xfff00100 (or 0x0100 for boot low). The first 0x100 bytes has the u-boot signature and version info. I disagree. High-booting systems are a PITA. You always lose a full megabyte at the end of the flash of which usually only 256 kB or less are needed for U-Boot, wasting 0.75 MB. Also, systems with varying number of flash banks and/or flash sizes are not really straightforward to handle. Low-booting is much, much saner. 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: [EMAIL PROTECTED] A Stanford research group advertised for participants in a study of obsessive-compulsive disorder. They were looking for therapy clients who had been diagnosed with this disorder. The response was grati- fying; they got 3,000 responses about three days after the ad came out. All from the same person. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Your choices are 0xfff0 and zero, based on the BMS (Boot Memory Space) bit of the low reset control word. -Scott ...and of the two options, I recommend 0xfff0 (boot high). Note that the start of u-boot is 0xfff0 but the reset vector itself is 0xfff00100 (or 0x0100 for boot low). The first 0x100 bytes has the u-boot signature and version info. I disagree. High-booting systems are a PITA. You always lose a full megabyte at the end of the flash of which usually only 256 kB or less are needed for U-Boot, wasting 0.75 MB. Also, systems with varying number of flash banks and/or flash sizes are not really straightforward to handle. Low-booting is much, much saner. Best regards, Wolfgang Denk Arrr, my insanity. Wolfgang is correct, of course. Sorry, gvb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Kumar Gala wrote: On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u-boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. - k My original way long ago initial cut didn't do the board and /chosen fixups as part of the bootm execution. My original intent was that we would run fdt chosen and fdt bd and whatever else was necessary before running bootm, including addressing Kumar's need. Unfortunately, it would have also broken backwards compatibility and so the concept was sacrificed for backwards compatibility. :-/ Is there a better way of doing this... perhaps have a flag that says if fdt chosen and/or fdt bd is run, don't re-run it as part of bootm? Maybe have an env variable that suppressed the calling of fdt chosen and fdt bd in bootm (nofdtfixup?)? Still ugly, but it would maintain backwards compatibility but also allow us finer grained control of when fdt chosen and fdt bd (add fdt cpu?) is run and allow our users to wedge additional fdt stuff in the boot sequence. Is that really any better than having the ability to execute an environment variable that has 'fdt' commands in it as part of bootm? - k I don't like it that bootm is calling out to all sorts of functions that could better be scripted. It complicates the bootm code (badly!), it prevents users from doing clever things (because it hard codes the calls and sequences of the calls to loosely related functions), and it violates the unix principle of doing only one thing and doing it well (bootm code is one big ugly awkward swissarmyknife[tm] tool). Best regards, gvb P.S. This battle was probably lost many years ago, but it still makes me feel better to pound the desk and shout. Oh-oh, people are looking... - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
David Hawkins wrote: Arrr, my insanity. Wolfgang is correct, of course. Gee, and I was just going to ask why on earth you liked high-boot :) I've seen one novel use of high-boot that could make it useful if you're lazy and can't be bothered plugging in your debugger ;) Or the hardware weenies have it in a different building. Assuming your board has a toggle switch that sets the state of BMS in the RCW (as most Freescale boards do), you can put a 'good' version of U-Boot at say the high-boot location, and the test version at the low-boot. If the low-boot version doesn't boot, power-down, flip the BMS toggle switch, power-up and boot-high, reflash to the next low-boot test version, and continue. I personally haven't tried the trick, but it sounded like a nice idea. That works great. It saved my a$$ there more than once. :-/ (The Freescale eval boards generally support this - very handy.) Low-boot is the only sane method for booting, since high-boot sticks the bootloader 8MB into your 32MB/64MB/etc Flash ... I mean who uses 8MB Flash these days ... :) Cheers, Dave Best regards, gvb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u- boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) This assumes I know the best location for the device tree before bootm which I'd argue isn't really true. Especially if my dtb is in flash. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:44 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote: Kumar Gala wrote: On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands that the user can supply to manipulate the device tree after ft_board_setup() and before the tree is handled to the kernel. Where exactly is the needed, i. e. which spoecific situation do you have in mind where this function cannot be implemented as part of either a preboot or a standard bootcmd command sequence? The situation is if we are fixing up or adding properties or nodes via the ft_board_setup() how do I go about modifying that before the device tree is handed to the kernel. An example would be if we start adding the i2c node via code in u- boot and after we have done that we want to add a frequency property at runtime w/o changing the u-boot code. - k My original way long ago initial cut didn't do the board and / chosen fixups as part of the bootm execution. My original intent was that we would run fdt chosen and fdt bd and whatever else was necessary before running bootm, including addressing Kumar's need. Unfortunately, it would have also broken backwards compatibility and so the concept was sacrificed for backwards compatibility. :-/ Is there a better way of doing this... perhaps have a flag that says if fdt chosen and/or fdt bd is run, don't re-run it as part of bootm? Maybe have an env variable that suppressed the calling of fdt chosen and fdt bd in bootm (nofdtfixup?)? Still ugly, but it would maintain backwards compatibility but also allow us finer grained control of when fdt chosen and fdt bd (add fdt cpu?) is run and allow our users to wedge additional fdt stuff in the boot sequence. Is that really any better than having the ability to execute an environment variable that has 'fdt' commands in it as part of bootm? - k I don't like it that bootm is calling out to all sorts of functions that could better be scripted. It complicates the bootm code (badly!), it prevents users from doing clever things (because it hard codes the calls and sequences of the calls to loosely related functions), and it violates the unix principle of doing only one thing and doing it well (bootm code is one big ugly awkward swissarmyknife[tm] tool). Best regards, gvb P.S. This battle was probably lost many years ago, but it still makes me feel better to pound the desk and shout. Oh-oh, people are looking... I think this was lost long ago. If we went with simple it would have just done the register setup and transfer and thats it. leaving it to other commands to do decompression of images, etc. Also we already have a number env vars that impact how bootm works. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Kumar Gala wrote: On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) This assumes I know the best location for the device tree before bootm which I'd argue isn't really true. Especially if my dtb is in flash. Why not? Wouldn't it be just another environment variable, like the load address for the kernel? -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] you wrote: I don't like it that bootm is calling out to all sorts of functions that could better be scripted. It complicates the bootm code (badly!), it prevents users from doing clever things (because it hard codes the calls and sequences of the calls to loosely related functions), and it violates the unix principle of doing only one thing and doing it well (bootm code is one big ugly awkward swissarmyknife[tm] tool). I agree 100%. P.S. This battle was probably lost many years ago, but it still makes me feel better to pound the desk and shout. Oh-oh, people are looking... Ther is two of us. I'm your ally when it comes to ripping out unnecessary and complicted stuff out of bootm :-) Just send patches... 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: [EMAIL PROTECTED] Children are natural mimics who act like their parents despite every effort to teach them good manners. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] you wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) And exactly this has to be considered a bug in the current bootm implementation. Throwing out this design error would make more sense to me than adding another quirk. 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: [EMAIL PROTECTED] To the systems programmer, users and applications serve only to provide a test load. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Increasing U-Boot partition size
Arrr, my insanity. Wolfgang is correct, of course. Gee, and I was just going to ask why on earth you liked high-boot :) I've seen one novel use of high-boot that could make it useful if you're lazy and can't be bothered plugging in your debugger ;) Assuming your board has a toggle switch that sets the state of BMS in the RCW (as most Freescale boards do), you can put a 'good' version of U-Boot at say the high-boot location, and the test version at the low-boot. If the low-boot version doesn't boot, power-down, flip the BMS toggle switch, power-up and boot-high, reflash to the next low-boot test version, and continue. I personally haven't tried the trick, but it sounded like a nice idea. Low-boot is the only sane method for booting, since high-boot sticks the bootloader 8MB into your 32MB/64MB/etc Flash ... I mean who uses 8MB Flash these days ... :) Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] NAND: Coding-style fixes
On Thu, Jul 31, 2008 at 12:42:43PM +0200, Guennadi Liakhovetski wrote:
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
drivers/mtd/nand/nand_base.c | 33 +
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 6416d15..49bf51d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -596,7 +596,7 @@ static void nand_command (struct mtd_info *mtd, unsigned
command, int column, in
/*
* program and erase have their own busy handlers
* status and sequential in needs no delay
- */
+ */
switch (command) {
This is already fixed in u-boot-nand-flash/testing.
-Scott
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 4/7 v3] USB: Add support for OHCI controller on s3c6400
On Mon, 4 Aug 2008, Jean-Christophe PLAGNIOL-VILLARD wrote: diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c index fd60edb..0bfa4d7 100644 --- a/drivers/usb/usb_ohci.c +++ b/drivers/usb/usb_ohci.c @@ -69,6 +69,7 @@ #if defined(CONFIG_ARM920T) || \ defined(CONFIG_S3C2400) || \ defined(CONFIG_S3C2410) || \ +defined(CONFIG_S3C6400) || \ defined(CONFIG_440EP) || \ defined(CONFIG_PCI_OHCI) || \ defined(CONFIG_MPC5200) || \ Can we start to avoid 10km if defined in the code? Maybe we can find an other way do it? Sure, I think, the USB-custodian will be glad to see patches. 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] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 5/7 v3] serial: add s3c64xx serial driver
On Mon, 4 Aug 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 14:45 Mon 04 Aug , Guennadi Liakhovetski wrote:
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
Also added my copyright to the driver.
drivers/serial/Makefile |1 +
drivers/serial/s3c64xx.c | 189
++
2 files changed, 190 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/s3c64xx.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index c9e797e..2a11ae5 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -30,6 +30,7 @@ COBJS-y += mcfuart.o
COBJS-y += ns9750_serial.o
COBJS-y += ns16550.o
COBJS-y += s3c4510b_uart.o
+COBJS-$(CONFIG_S3C64XX) += s3c64xx.o
COBJS-y += serial.o
COBJS-y += serial_max3100.o
COBJS-y += serial_pl010.o
I've send a patch that break it.
Could you rebase it on the current Wolfgang tree HEAD?
Ok, will have a look.
+/* See table in 31.6.11 */
+static const int udivslot[] = {
+ 0,
+ 0x0080,
+ 0x0808,
+ 0x0888,
+ 0x,
+ 0x4924,
+ 0x4a52,
+ 0x54aa,
+ 0x,
+ 0xd555,
+ 0xd5d5,
+ 0xddd5,
+ 0x,
+ 0xdfdd,
+ 0xdfdf,
+ 0xffdf,
+};
Can we have something more readable?
No. This are recommended values as mentioned in the comment to the table
referenced above.
+void serial_setbrg(void)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ s3c64xx_uart *const uart = s3c64xx_get_base_uart(UART_NR);
+ u32 reg, pclk_ratio = get_PCLK() / gd-baudrate;
why not
u32 reg;
u32 pclk_ratio = get_PCLK() / gd-baudrate;
There is more than one way to do it.
+ int i;
+
+ /* PCLK / (16 * baudrate) - 1 */
+ reg = pclk_ratio / 16 - 1;
+ i = pclk_ratio - (reg + 1) * 16;
=
i = pclk_ratio - (pclk_ratio / 16 - 1 + 1) * 16;
=
i = pclk_ratio - (pclk_ratio / 16 ) * 16;
=
i = pclk_ratio - pclk_ratio;
=
i = 0;
Please, think again. This is integer arithmetics, not analysis.
+
+ uart-UBRDIV = reg;
+ uart-UDIVSLOT = udivslot[i];
base on the cose
uart-UDIVSLOT = udivslot[0];
See above.
+static int hwflow; /* turned off by default */
why not?
static int hwflow = 0;/* turned off by default */
Because static are always initialised to 0, and, in fact, checkpatch.pl
produces warnings on these, and rightfully so.
+static int be_quiet;
why not?
static int be_quiet = 0;
See above.
Thanks for your comments
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]
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 3:55 PM, Scott Wood wrote: Kumar Gala wrote: On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) This assumes I know the best location for the device tree before bootm which I'd argue isn't really true. Especially if my dtb is in flash. Why not? Wouldn't it be just another environment variable, like the load address for the kernel? Right now the fdt is placed at the first 4k page after the kernel is decompressed. I don't now where that address is. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
Kumar Gala wrote: On Aug 4, 2008, at 3:55 PM, Scott Wood wrote: Why not? Wouldn't it be just another environment variable, like the load address for the kernel? Right now the fdt is placed at the first 4k page after the kernel is decompressed. I don't now where that address is. Do we really need to do it that way, though? -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
On Aug 4, 2008, at 4:07 PM, Wolfgang Denk wrote: In message F388F9D5-B685-4DD8- [EMAIL PROTECTED] you wrote: So just run the needed commands before you run bootm as part of your boot command sequence. This doesnt work. Lets say I want to remove a node or property that ft_board_setup() adds. If I do what you are suggesting the node or prop will get added back: fdt addr FOO fdt boardsetup (we assume this adds /bar/prop) fdt rm /bar/prop bootm (will call ft_board_setup and add /bar/prop back) And exactly this has to be considered a bug in the current bootm implementation. Throwing out this design error would make more sense to me than adding another quirk. Ok. What do we think 'bootm' at its lowest level should do? - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 2/7 v3] NAND_CMD_READOOB is not supported by all chips, read OOB with the page instead
On Mon, Aug 04, 2008 at 02:45:33PM +0200, Guennadi Liakhovetski wrote:
I _think_ this should work with all NAND chips. Otherwise we might have to
introduce a configuration variable.
Which small-page NAND chips can't handle READOOB? On large page devices,
nand_command changes it to READ0.
That said, doing it all at once could result in smaller, faster, and
simpler code.
@@ -150,8 +135,6 @@ static int nand_read_page(struct mtd_info *mtd, int
block, int page, uchar *dst)
u_char *ecc_code;
u_char *oob_data;
int i;
- int eccsize = CFG_NAND_ECCSIZE;
- int eccbytes = CFG_NAND_ECCBYTES;
Any particular reason for this change? It's more readable as is, IMHO.
@@ -195,6 +180,7 @@ static int nand_load(struct mtd_info *mtd, int offs, int
uboot_size, uchar *dst)
int block;
int blockcopy_count;
int page;
+ unsigned read = 0;
unsigned int, please.
+ int badblock = 0;
+ for (page = 0; page CFG_NAND_PAGE_COUNT; page++) {
+ nand_read_page(mtd, block, page, dst);
+ if ((!page
+#ifdef CFG_NAND_BBT_2NDPAGE
+ || page == 1
+#endif
Please use page == 0 rather than !page when checking for an actual value
of zero as opposed to a zero that means not valid or similar.
+ ) dst[CFG_NAND_PAGE_SIZE] != 0xff) {
+ badblock = 1;
+ break;
}
+ /* Overwrite skipped pages */
+ if (read = offs)
+ dst += CFG_NAND_PAGE_SIZE;
+ read += CFG_NAND_PAGE_SIZE;
+ }
I don't follow the logic here -- you're discarding a number of good
blocks equal to the offset? That might make sense if we were starting at
block zero, and defining the offset as not including any bad blocks
before the image -- but the first block we read is at the start of the
image, not the start of flash.
@@ -241,12 +239,18 @@ void nand_boot(void)
nand_chip.dev_ready = NULL; /* preset to NULL */
board_nand_init(nand_chip);
+ if (nand_chip.select_chip)
+ nand_chip.select_chip(nand_info, 0);
+
/*
* Load U-Boot image from NAND into RAM
*/
ret = nand_load(nand_info, CFG_NAND_U_BOOT_OFFS, CFG_NAND_U_BOOT_SIZE,
(uchar *)CFG_NAND_U_BOOT_DST);
+ if (nand_chip.select_chip)
+ nand_chip.select_chip(nand_info, -1);
+
This seems like an unrelated change, that wasn't described in the
changelog.
-Scott
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 6/7 v3] NAND: add NAND driver for s3c64xx
On Mon, Aug 04, 2008 at 02:46:15PM +0200, Guennadi Liakhovetski wrote:
+#ifdef CONFIG_NAND_SPL
+static u_char nand_read_byte(struct mtd_info *mtd)
+{
+ struct nand_chip *this = mtd-priv;
+ return readb(this-IO_ADDR_R);
+}
+
+static void nand_write_byte(struct mtd_info *mtd, u_char byte)
+{
+ struct nand_chip *this = mtd-priv;
+ writeb(byte, this-IO_ADDR_W);
+}
+
+static void nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ int i;
+ struct nand_chip *this = mtd-priv;
+
+ for (i = 0; i len; i++)
+ buf[i] = readb(this-IO_ADDR_R);
+}
+#endif
We should probably move this under nand_spl/, and let boards select it
if they need it.
+/*
+ * Hardware specific access to control-lines function
+ * Written by jsgood
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd)
+{
+ struct nand_chip *this = mtd-priv;
+
+ switch (cmd) {
+ case NAND_CTL_SETCLE:
+ this-IO_ADDR_W = (void __iomem *)NFCMMD;
+ break;
+ case NAND_CTL_CLRCLE:
+ this-IO_ADDR_W = (void __iomem *)NFDATA;
+ break;
+ case NAND_CTL_SETALE:
+ this-IO_ADDR_W = (void __iomem *)NFADDR;
+ break;
+ case NAND_CTL_CLRALE:
+ this-IO_ADDR_W = (void __iomem *)NFDATA;
+ break;
+ case NAND_CTL_SETNCE:
+ s3c_nand_select_chip(mtd, 0);
+ break;
+ case NAND_CTL_CLRNCE:
+ s3c_nand_select_chip(mtd, -1);
+ break;
+ }
+}
This interface has changed in u-boot-nand-flash/testing. Can you rebase
against it?
-Scott
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/2] mpc8313erdb: Enable NAND in config.
Signed-off-by: Scott Wood [EMAIL PROTECTED] --- Applied to u-boot-nand-flash/testing. include/configs/MPC8313ERDB.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index d547681..3a644d3 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -224,6 +224,8 @@ #define CFG_MAX_NAND_DEVICE1 #define NAND_MAX_CHIPS 1 #define CONFIG_MTD_NAND_VERIFY_WRITE +#define CONFIG_CMD_NAND 1 +#define CONFIG_NAND_FSL_ELBC 1 #define CFG_BR1_PRELIM ( CFG_NAND_BASE \ | (2BR_DECC_SHIFT)/* Use HW ECC */ \ -- 1.5.6.rc1.6.gc53ad - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/2] NAND boot: MPC8313ERDB support
Note that with older board revisions, NAND boot may only work after a
power-on reset, and not after a warm reset. I suspect there are hardware
issues involved.
I don't have a newer board to test on, though previous implementations
have been reported to work on boards with a 33MHz crystal (which current
revisions have). If you have such a board, please let me know if it
works after a warm reset.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
Applied to u-boot-nand-flash/testing.
Makefile| 10 ++-
board/freescale/mpc8313erdb/config.mk |6 +
board/freescale/mpc8313erdb/mpc8313erdb.c | 32 +
board/freescale/mpc8313erdb/sdram.c |5 +-
cpu/mpc83xx/nand_init.c | 112 +
cpu/mpc83xx/start.S | 152 +++
include/configs/MPC8313ERDB.h | 82 ++---
include/mpc83xx.h |2 +
include/nand.h |2 +
lib_ppc/time.c |4 +-
nand_spl/board/freescale/mpc8313erdb/Makefile | 101 +++
nand_spl/board/freescale/mpc8313erdb/u-boot.lds | 52
nand_spl/nand_boot.c|4 +-
nand_spl/nand_boot_fsl_elbc.c | 150 ++
14 files changed, 585 insertions(+), 129 deletions(-)
create mode 100644 cpu/mpc83xx/nand_init.c
create mode 100644 nand_spl/board/freescale/mpc8313erdb/Makefile
create mode 100644 nand_spl/board/freescale/mpc8313erdb/u-boot.lds
create mode 100644 nand_spl/nand_boot_fsl_elbc.c
diff --git a/Makefile b/Makefile
index 4875c89..cb8c0f5 100644
--- a/Makefile
+++ b/Makefile
@@ -1997,8 +1997,11 @@ TASREG_config : unconfig
#
MPC8313ERDB_33_config \
-MPC8313ERDB_66_config: unconfig
+MPC8313ERDB_66_config \
+MPC8313ERDB_NAND_33_config \
+MPC8313ERDB_NAND_66_config: unconfig
@mkdir -p $(obj)include
+ @mkdir -p $(obj)board/freescale/mpc8313erdb
@if [ $(findstring _33_,$@) ] ; then \
$(XECHO) -n ...33M ... ; \
echo #define CFG_33MHZ $(obj)include/config.h ; \
@@ -2006,6 +2009,11 @@ MPC8313ERDB_66_config: unconfig
if [ $(findstring _66_,$@) ] ; then \
$(XECHO) -n ...66M... ; \
echo #define CFG_66MHZ $(obj)include/config.h ; \
+ fi ; \
+ if [ $(findstring _NAND_,$@) ] ; then \
+ $(XECHO) -n ...NAND... ; \
+ echo TEXT_BASE = 0x0010
$(obj)/board/freescale/mpc8313erdb/config.tmp ; \
+ echo #define CONFIG_NAND_U_BOOT $(obj)include/config.h ; \
fi ;
@$(MKCONFIG) -a MPC8313ERDB ppc mpc83xx mpc8313erdb freescale
diff --git a/board/freescale/mpc8313erdb/config.mk
b/board/freescale/mpc8313erdb/config.mk
index f768264..fd72a14 100644
--- a/board/freescale/mpc8313erdb/config.mk
+++ b/board/freescale/mpc8313erdb/config.mk
@@ -1 +1,7 @@
+ifndef NAND_SPL
+sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
+endif
+
+ifndef TEXT_BASE
TEXT_BASE = 0xFE00
+endif
diff --git a/board/freescale/mpc8313erdb/mpc8313erdb.c
b/board/freescale/mpc8313erdb/mpc8313erdb.c
index 7cbdb7b..ebb703d 100644
--- a/board/freescale/mpc8313erdb/mpc8313erdb.c
+++ b/board/freescale/mpc8313erdb/mpc8313erdb.c
@@ -29,6 +29,8 @@
#include pci.h
#include mpc83xx.h
#include vsc7385.h
+#include ns16550.h
+#include nand.h
DECLARE_GLOBAL_DATA_PTR;
@@ -50,6 +52,7 @@ int checkboard(void)
return 0;
}
+#ifndef CONFIG_NAND_SPL
static struct pci_region pci_regions[] = {
{
bus_start: CFG_PCI1_MEM_BASE,
@@ -128,3 +131,32 @@ void ft_board_setup(void *blob, bd_t *bd)
#endif
}
#endif
+#else /* CONFIG_NAND_SPL */
+void board_init_f(ulong bootflag)
+{
+ board_early_init_f();
+ NS16550_init((NS16550_t)(CFG_IMMR + 0x4500),
+CFG_NS16550_CLK / 16 / CONFIG_BAUDRATE);
+ puts(NAND boot... );
+ init_timebase();
+ initdram(0);
+ relocate_code(CFG_NAND_U_BOOT_RELOC + 0x1, (gd_t *)gd,
+ CFG_NAND_U_BOOT_RELOC);
+}
+
+void board_init_r(gd_t *gd, ulong dest_addr)
+{
+ nand_boot();
+}
+
+void putc(char c)
+{
+ if (gd-flags GD_FLG_SILENT)
+ return;
+
+ if (c == '\n')
+ NS16550_putc((NS16550_t)(CFG_IMMR + 0x4500), '\r');
+
+ NS16550_putc((NS16550_t)(CFG_IMMR + 0x4500), c);
+}
+#endif
diff --git a/board/freescale/mpc8313erdb/sdram.c
b/board/freescale/mpc8313erdb/sdram.c
index afd8b9d..3a6347f 100644
--- a/board/freescale/mpc8313erdb/sdram.c
+++ b/board/freescale/mpc8313erdb/sdram.c
@@ -58,8 +58,10 @@ static void resume_from_sleep(void)
*/
static long fixed_sdram(void)
{
- volatile immap_t *im = (volatile immap_t *)CFG_IMMR;
u32 msize = CFG_DDR_SIZE * 1024 * 1024;
+
Re: [U-Boot-Users] [PATCH 5/7 v3] serial: add s3c64xx serial driver
In message [EMAIL PROTECTED] you wrote:
+/* See table in 31.6.11 */
+static const int udivslot[] = {
+ 0,
+ 0x0080,
+ 0x0808,
+ 0x0888,
+ 0x,
+ 0x4924,
+ 0x4a52,
+ 0x54aa,
+ 0x,
+ 0xd555,
+ 0xd5d5,
+ 0xddd5,
+ 0x,
+ 0xdfdd,
+ 0xdfdf,
+ 0xffdf,
+};
Can we have something more readable?
No. This are recommended values as mentioned in the comment to the table
referenced above.
Bout perhaps you could add some documentation what all these magic
numbers mean? Of course we can all download the documetnation, study
it for hours and finally uinderstand this, too - but it would be
nicer if you could save us this effort.
+ u32 reg, pclk_ratio = get_PCLK() / gd-baudrate;
why not
u32 reg;
u32 pclk_ratio = get_PCLK() / gd-baudrate;
There is more than one way to do it.
Indeed. But the one that is better readable is preferred.
+ /* PCLK / (16 * baudrate) - 1 */
+ reg = pclk_ratio / 16 - 1;
+ i = pclk_ratio - (reg + 1) * 16;
=
i = pclk_ratio - (pclk_ratio / 16 - 1 + 1) * 16;
=
i = pclk_ratio - (pclk_ratio / 16 ) * 16;
=
i = pclk_ratio - pclk_ratio;
=
i = 0;
Please, think again. This is integer arithmetics, not analysis.
So perhaps you want to elucidate your code in a comment?
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: [EMAIL PROTECTED]
grep me no patterns and I'll tell you no lines.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fdt: add fdtcmd env var to allow post processing of device tree before boot
In message [EMAIL PROTECTED] you wrote: Why not? Wouldn't it be just another environment variable, like the load address for the kernel? Right now the fdt is placed at the first 4k page after the kernel is decompressed. I don't now where that address is. Who places it there? We were talking about the bootm arguments, which are different things, I think? 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: [EMAIL PROTECTED] That Microsoft, the Trabant of the operating system world, may be glancing over the Berlin Wall at the Audis and BMWs and Mercedes. In their own universe Trabants and Ladas were mainstream too... -- Evan Leibovitch - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] simplify bootm command
If we really want to simplify what bootm does than I think we should remove ft_board_setup() from lib_ppc/bootm.c and expect any actually modification of the device tree to have already occurred. Is this something we'd really be willing to do? - k diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c index 81803dd..8a86d52 100644 --- a/lib_ppc/bootm.c +++ b/lib_ppc/bootm.c @@ -190,10 +190,6 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[], fdt_error (/chosen node create failed); goto error; } -#ifdef CONFIG_OF_BOARD_SETUP - /* Call the board-specific fixup routine */ - ft_board_setup(of_flat_tree, gd-bd); -#endif } /* Fixup the fdt memreserve now that we know how big it is */ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
