Re: [U-Boot] how can i change u-boot load address?
Dear Roman, In message [EMAIL PROTECTED] you wrote: Can the value of TEXT_BASE be arbitrary chosen for test purposes? No, it cannot. You have to define a memory map for your system, which will result in certain restrictions for the choice of TEXT_BASE. In general, you have to understand what you are doing, and in detail. I'm trying to understand how it's done on ARM -- On ARM it's being done wrong - no real relocation is preformed; instead, U-Boot is liked to a fixed address in RAM. The startup code (mostly assembler) can run from ROM (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] Vulcans believe peace should not depend on force. -- Amanda, Journey to Babel, stardate 3842.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v2] ppc4xx: Add AMCC Arches boardsupport(dual 460GT)
Dear Victor Gallardo, In message [EMAIL PROTECTED] you wrote: I reviewed this again. It cannot be part of default config. We need to do it at PREBOOT because eth_register() updates this variable each time at boot. It assigns ethact to the first ethernet port it discovers. In Arches, we need the second Ethernet port set as ethact. Updating it at preboot allows us to update after eth_register has set it. Are you sure? I think there must be something wrong with your configuration, then. Did you set ethprime ? 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] The more we disagree, the more chance there is that at least one of us is right. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how can i change u-boot load address?
Hi Wolfgang Denk, wd wrote: I'm trying to understand how it's done on ARM -- On ARM it's being done wrong - no real relocation is preformed; instead, U-Boot is liked to a fixed address in RAM. The startup code (mostly assembler) can run from ROM (too). If you can tell me what exactly is wrong with ARM startup, i will try to find a solution. Can u point the platform and its startup functions where it is been done correctly. Then i will try to fixup th error in ARM. Thanks in advance Regards Gururaja -- View this message in context: http://www.nabble.com/how-can-i-change-u-boot-load-address--tp19836732p19853320.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Antwort: Re: Antwort: Re: PATCH: IXP465 support and some IXP4xx rework, Sidewinder board support
Hi, Here are my patches. Maybe you want to test them. I didn't use or update the ixdp465 but you can use the sidewinder_config as starting point. Order is: ixp425_rework.patch ixp465.patch I see only the ixp465.patch. Some comments: - remove c++ comment - i prefer sdram controller inizialization in board specific part Clean up the code of print_cpuinfo. npe_less_fw.patch sidewinder.patch HS I can't comment anymore because your patch is not inlined in the email Regards Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] ppc4xx: Fix DU440 GPIO configuration
From: Matthias Fuchs [EMAIL PROTECTED] Signed-off-by: Matthias Fuchs [EMAIL PROTECTED] --- board/esd/du440/du440.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/board/esd/du440/du440.c b/board/esd/du440/du440.c index 8765cc1..5cff9f5 100644 --- a/board/esd/du440/du440.c +++ b/board/esd/du440/du440.c @@ -52,15 +52,15 @@ int board_early_init_f(void) * Setup the GPIO pins */ out_be32((void*)GPIO0_OR, 0x | CFG_GPIO0_EP_EEP); - out_be32((void*)GPIO0_TCR, 0x000f | CFG_GPIO0_EP_EEP); + out_be32((void*)GPIO0_TCR, 0x001f | CFG_GPIO0_EP_EEP); out_be32((void*)GPIO0_OSRL, 0x50055400); - out_be32((void*)GPIO0_OSRH, 0x550050aa); + out_be32((void*)GPIO0_OSRH, 0x55005000); out_be32((void*)GPIO0_TSRL, 0x50055400); out_be32((void*)GPIO0_TSRH, 0x55005000); out_be32((void*)GPIO0_ISR1L, 0x5000); out_be32((void*)GPIO0_ISR1H, 0x); out_be32((void*)GPIO0_ISR2L, 0x); - out_be32((void*)GPIO0_ISR2H, 0x0100); + out_be32((void*)GPIO0_ISR2H, 0x); out_be32((void*)GPIO0_ISR3L, 0x); out_be32((void*)GPIO0_ISR3H, 0x); @@ -73,9 +73,9 @@ int board_early_init_f(void) CFG_GPIO1_LEDPOST | CFG_GPIO1_LEDDU); out_be32((void*)GPIO1_ODR, CFG_GPIO1_LEDDU); - out_be32((void*)GPIO1_OSRL, 0x5c28); + out_be32((void*)GPIO1_OSRL, 0x0c28); out_be32((void*)GPIO1_OSRH, 0x); - out_be32((void*)GPIO1_TSRL, 0x0c00); + out_be32((void*)GPIO1_TSRL, 0xcc00); out_be32((void*)GPIO1_TSRH, 0x); out_be32((void*)GPIO1_ISR1L, 0x5550); out_be32((void*)GPIO1_ISR1H, 0x); -- 1.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Antwort: Re: PATCH: IXP465 support and some IXP4xx rework, Sidewinder board support
michael [EMAIL PROTECTED] schrieb am 07.10.2008 12:14:48: Hi, [EMAIL PROTECTED] wrote: Hi, on the matter of getting u-boot work with the ADI Sidewinder Reference Platform, I found the previously posted patches and used them as starting point for my own patch set. The Sidewinder board works with this patch, including ECC (optional). There is a minimum set of ifdefs in cpu/ixp/start.S and no board-specific low-level.S and thus no endless code-duplication. The SDRAM parameters are handled by configuration definitions. The ixp425.h and ixp465.h header files should be merged but that can follow in a different patch, possibly renaming the defines and fixing all board specific code. I think that you use my patchset. It is true? Almost. I used it as base but modified it quite a bit. There is almost no difference between IXP465 and IXP425 anymore (except header files), no lowlevel-init.S anymore and correct CPU info display. BTW: ixdp425_config, ixdpg425_config and pdnb3_config are broken if IxNpeMicrocode.o is not present HS ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how can i change u-boot load address?
Dear Roman, In message [EMAIL PROTECTED] you wrote: On ARM it's being done wrong - no real relocation is preformed; What do you mean by real relocation? As per start.S bootcode is copied from ROM to RAM. Copied to a fixed address where it is actiually already linked for. See my previous message with a lenghty explanation why this is a poor design when dealing with variable sized memory. The problem with the ARM implementation is that the link address is fixed, i. e. it cannot be adjusted to varying RAM sizes. Usually one ports U-Boot on a board with predefined hardware layout, i.e. flash, SDRAM and peripherals are fixed. If hardware changes, say SDRAM size, no big deal to make two/three distinct u-boot images -- after all it ends up by changing TEXT_BASE only, as I understand. This may be your opinion, but it is an isolated one and not shared by *many* board vendors who offer different configurations of boards with smaller and bigger amounts of RAM etc. For these, having only a single binary image of U-Boot for all board configurations is a MAJOR win. Also consider systems which use memory modules. Just try to imagine you have to install a new version of the BIOS on your PC just because you add or remove a memory module. Would you buy such a PC? 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] (null cookie; hope that's ok) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH: IXP465 support and some IXP4xx rework, Sidewinder board support
Hi, [EMAIL PROTECTED] wrote: Hi, on the matter of getting u-boot work with the ADI Sidewinder Reference Platform, I found the previously posted patches and used them as starting point for my own patch set. The Sidewinder board works with this patch, including ECC (optional). There is a minimum set of ifdefs in cpu/ixp/start.S and no board-specific low-level.S and thus no endless code-duplication. The SDRAM parameters are handled by configuration definitions. The ixp425.h and ixp465.h header files should be merged but that can follow in a different patch, possibly renaming the defines and fixing all board specific code. I think that you use my patchset. It is true? The new initialisation routine was also tested on an IXP425, it really works on both. Great :) The npe_less_fw.patch allows to have NPE-C firmware and still use NPE-B. There is no need to load firmware to NPE-C if you are not going to use it. This work was done for Erhardt+Leimer GmbH. Regards Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how can i change u-boot load address?
Hi, -Original Message- From: Wolfgang Denk [mailto:[EMAIL PROTECTED] Subject: Re: [U-Boot] how can i change u-boot load address? U wouldnt see mapping the vector on (most) ARM Platforms because they use u-boot as secondary bootloader I don't have reliable statistical data to judge if the most is correct, or if it actually is only a few configurations that do this. I meant to say the arm supplied board (integrator[ap/cp], versatile[ap/cp], realview). I said most because ARM Integrator Board doesnt use Arm Bootmonitor hence its code has remapping functionality. From what I'm seeing, most systems use U-oot as primary (and only) boot loader. S its my mistake. sorry for that. Regards Gururaja ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
Dirk Behme said the following on 10/07/2008 04:42 AM:
Scott Wood wrote:
On Fri, Oct 03, 2008 at 12:40:25PM +0200, [EMAIL PROTECTED]
wrote:
+#include common.h
+#include asm/io.h
+#include asm/arch/mem.h
+#include linux/mtd/nand_ecc.h
+
+#if defined(CONFIG_CMD_NAND)
+
+#include nand.h
Move the #ifdef to the Makefile.
Did this. Additionally, I moved OMAP3 NAND driver to
drivers/mtd/nand/omap3.c.
I would recommend having a nand_omap_gpmc.c if the driver can be made
generic enough.
+/*
+ * nand_read_buf16 - [DEFAULT] read chip data into buffer
+ * @mtd:MTD device structure
+ * @buf:buffer to store date
+ * @len:number of bytes to read
+ *
+ * Default read function for 16bit buswith
+ */
+static void omap_nand_read_buf(struct mtd_info *mtd, u_char *buf,
int len)
+{
+int i;
+struct nand_chip *this = mtd-priv;
+u16 *p = (u16 *) buf;
+len = 1;
+
+for (i = 0; i len; i++)
+p[i] = readw(this-IO_ADDR_R);
+}
How does this differ from the default implementation?
It doesn't differ ;)
So I removed this and tried to use default nand_read_buf16() instead:
nand-read_buf = nand_read_buf16;
in board_nand_init(). But this doesn't compile as nand_read_buf16() is
static in nand_base.c. How do I use it in OMAP3 NAND driver? Marked it
as FIXME in patch.
Probably does not need an explicit initialization, mtd nand_scan should
populate that. in fact IMHO, the read/write buf ops might be duplicating
mtd's implementation.. :(
+/*
+ * omap_calculate_ecc - Generate non-inverted ECC bytes.
+ *
+ * Using noninverted ECC can be considered ugly since writing a blank
+ * page ie. padding will clear the ECC bytes. This is no problem as
+ * long nobody is trying to write data on the seemingly unused page.
+ * Reading an erased page will produce an ECC mismatch between
+ * generated and read ECC bytes that has to be dealt with separately.
Is this a hardware limitation? If so, say so in the comment. If not,
why do it this way?
Don't know.
All: Any help?
The issue is simple: assume we read a page of 0xFF's(fresh erased), IF
using H/w ECC engine within GPMC, the result of read will be 0x0 while
the ECC offsets of the spare area will be 0xFF which will result in an
ECC mismatch.
+.eccbytes = 12,
+.eccpos = {
+ 2, 3, 4, 5,
+ 6, 7, 8, 9,
+ 10, 11, 12, 13},
+.oobfree = { {20, 50} }/* don't care */
Bytes 64-69 of a 64-byte OOB are free?
What don't we care about?
+static struct nand_ecclayout hw_nand_oob_64 = {
Don't know (or understand?).
All: Any help?
I do not get it either.. ECCPOS is in offset bytes, and oobfree should
be {.offset=20,.length=44} /*I always hated struct initialization done
as above..*/, but then,
===
--- u-boot-arm.orig/drivers/mtd/nand/nand_base.c
+++ u-boot-arm/drivers/mtd/nand/nand_base.c
@@ -2730,6 +2730,151 @@ int nand_scan_tail(struct mtd_info *mtd)
return 0;
}
+#if defined(CONFIG_OMAP) (defined(CONFIG_OMAP3_BEAGLE) \
+|| defined(CONFIG_OMAP3_EVM) || defined(CONFIG_OVERO))
+void nand_switch_ecc(struct mtd_info *mtd)
NACK. First, explain why you need to be able to dynamically switch ECC
modes.
Two topics here, changes in cmd_nand.c and nand_base.c.
cmd_nand.c:
We need to be able to switch ECC at runtime cause some images have to
be written to NAND with HW ECC and some with SW ECC. This depends on
what user (reader) of these parts expect.
OMAP3 has a boot ROM which is able to read a second level loader
(called x-loader) from NAND and start/execute it. This 2nd level
loader has to be written by U-Boot using HW ECC as ROM code does HW
ECC to read the image. All other parts, e.g. Linux kernel, use SW ECC
as default. For this we have to use SW ECC to write images, then.
Therefore we add an additional user command in cmd_nand.c to switch
ECC depending on what user wants to write.
why not use h/w ecc which rom code understands in kernel and u-boot. H/w
ecc will be faster in comparison to doing s/w ecc and there is good
support in MTD to do it, then there would be no reason for s/w ecc IMHO..
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Antwort: Re: Antwort: Re: Antwort: Re: PATCH: IXP465 support and some IXP4xx rework, Sidewinder board support
michael [EMAIL PROTECTED] schrieb am 07.10.2008 14:16:15: Here are my patches. Maybe you want to test them. I didn't use or update the ixdp465 but you can use the sidewinder_config as starting point. Order is: ixp425_rework.patch ixp465.patch I see only the ixp465.patch. ??? The mail included all 4 patches. Some comments: - remove c++ comment Ok. - i prefer sdram controller inizialization in board specific part I don't because that will be 99,999% the same code for all IXP46x boards. That's avoidable code duplication. And the SDRAM initialisation is specified by intel to very specific steps, anyway. All important differences can be (and are) expressed as variables. What would you do differently? If you do it completely different, add a define like CFG_CUSTOM_DRAM_INIT that disables the generic code and forces you to add your own. Clean up the code of print_cpuinfo. What do you mean? I can't comment anymore because your patch is not inlined in the email Sorry, I didn't find out how to inline patches with Lotus Notes, yet. :-( Yes, that software really sucks :-( HS ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
Unfortunately, except Nishanth's comments, I didn't get any further
help (e.g. from TI) for this yet. So I started to look at this myself.
Please forgive everything I missed as I'm no NAND expert. Maybe you
like to explain some additional details regarding what I missed ;)
First version of updated NAND patch in attachment. This is RFC only.
I'd like to fix anything still open. When this is done and when
everybody is fine with this, I will send an updated v3 of whole OMAP3
patch set including the then final NAND patch (and the fixes for all
other comments).
Scott Wood wrote:
On Fri, Oct 03, 2008 at 12:40:25PM +0200, [EMAIL PROTECTED] wrote:
+#include common.h
+#include asm/io.h
+#include asm/arch/mem.h
+#include linux/mtd/nand_ecc.h
+
+#if defined(CONFIG_CMD_NAND)
+
+#include nand.h
Move the #ifdef to the Makefile.
Did this. Additionally, I moved OMAP3 NAND driver to
drivers/mtd/nand/omap3.c.
+/*
+ * nand_read_buf16 - [DEFAULT] read chip data into buffer
+ * @mtd: MTD device structure
+ * @buf: buffer to store date
+ * @len: number of bytes to read
+ *
+ * Default read function for 16bit buswith
+ */
+static void omap_nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ int i;
+ struct nand_chip *this = mtd-priv;
+ u16 *p = (u16 *) buf;
+ len = 1;
+
+ for (i = 0; i len; i++)
+ p[i] = readw(this-IO_ADDR_R);
+}
How does this differ from the default implementation?
It doesn't differ ;)
So I removed this and tried to use default nand_read_buf16() instead:
nand-read_buf = nand_read_buf16;
in board_nand_init(). But this doesn't compile as nand_read_buf16() is
static in nand_base.c. How do I use it in OMAP3 NAND driver? Marked it
as FIXME in patch.
+static void omap_nand_write_buf(struct mtd_info *mtd, const uint8_t *buf,
+ int len)
+{
+ int i;
+ int j = 0;
+ struct nand_chip *chip = mtd-priv;
+
+ for (i = 0; i len; i++) {
+ writeb(buf[i], chip-IO_ADDR_W);
+ for (j = 0; j 10; j++) ;
+ }
+
+}
+
+/*
+ * omap_nand_read_buf - read data from NAND controller into buffer
+ * @mtd:MTD device structure
+ * @buf:buffer to store date
+ * @len:number of bytes to read
+ *
+ */
+static void omap_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ int i;
+ int j = 0;
+ struct nand_chip *chip = mtd-priv;
+
+ for (i = 0; i len; i++) {
+ buf[i] = readb(chip-IO_ADDR_R);
+ while (GPMC_BUF_EMPTY == (readl(GPMC_STATUS) GPMC_BUF_FULL));
+ }
+}
I'm a bit confused... with 16-bit NAND, you check GMPC_STATUS[BUF_FULL]
when writing, but with 8-bit NAND, you check it when reading? And 8-bit
writes have an arbitrary, cpu-speed-dependent delay, and 16-bit reads
have no delay at all?
Removed 8-bit stuff completely as it isn't used.
+static void omap_hwecc_init(struct nand_chip *chip)
+{
+ unsigned long val = 0x0;
+
+ /* Init ECC Control Register */
+ /* Clear all ECC | Enable Reg1 */
+ val = ((0x0001 8) | 0x0001);
+ __raw_writel(val, GPMC_BASE + GPMC_ECC_CONTROL);
+ __raw_writel(0x3fcff000, GPMC_BASE + GPMC_ECC_SIZE_CONFIG);
+}
Why raw?
Removed all _raw_ . At ARM, it seems that __raw_writex()/readx() are
the same as writex()/readx().
+/*
+ * omap_correct_data - Compares the ecc read from nand spare area with
+ * ECC registers values
+ * and corrects one bit error if it has occured
+ * @mtd:MTD device structure
+ * @dat:page data
+ * @read_ecc: ecc read from nand flash
+ * @calc_ecc: ecc read from ECC registers
+ */
+static int omap_correct_data(struct mtd_info *mtd, u_char *dat,
+u_char *read_ecc, u_char *calc_ecc)
+{
+ return 0;
+}
This obviously is not correcting anything. If the errors are corrected
automatically by the controller, say so in the comments.
I replaced this with the version from Nishanth's U-Boot v2:
http://git.denx.de/?p=u-boot/u-boot-v2.git;a=blob;f=drivers/nand/nand_omap_gpmc.c;h=afd676a74194c63a1e3cf581d210235a9d4c78ba;hb=HEAD
+/*
+ * omap_calculate_ecc - Generate non-inverted ECC bytes.
+ *
+ * Using noninverted ECC can be considered ugly since writing a blank
+ * page ie. padding will clear the ECC bytes. This is no problem as
+ * long nobody is trying to write data on the seemingly unused page.
+ * Reading an erased page will produce an ECC mismatch between
+ * generated and read ECC bytes that has to be dealt with separately.
Is this a hardware limitation? If so, say so in the comment. If not,
why do it this way?
Don't know.
All: Any help?
+ * @mtd: MTD structure
+ * @dat: unused
+ * @ecc_code: ecc_code buffer
+ */
+static int omap_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
+
Re: [U-Boot] Run hello world with Uboot !
http://www.denx.de/wiki/DULG/UBootStandalone Kind regards, Andrejs Cainikovs thaoth wrote: Hi, I'm working on SH7727 T-Engine Board (MS7727CP02)(sh3) and I'm trying to load Hello World example in U-boot (use Serial, ymodem and hello_world.bin), ... = loady 0x8e00 ## Ready for binary (ymodem) download to 0x8E00 at 115200 bps... CCCxyzModem - CRC mode, 2(SOH)/69(STX)/0(CAN) packets, 5 retries ## Total Size = 0x000112ec = 70380 Bytes = go 0x8e00 ## Starting application at 0x8E00 ... ... but my board reset when I run Hello world. I also try with hello_world.srec (serial, Kermit mode) and an uboot image: mkimage -A sh -O u-boot -T standalone -C none -a 0x8c00 -e 0x8c00 -n 'Hello Image' -d examples/hello_world hello.img ... = loady ## Ready for binary (ymodem) download to 0x8E00 at 115200 bps... CCxyzModem - CRC mode, 2(SOH)/69(STX)/0(CAN) packets, 4 retries ## Total Size = 0x0001132c = 70444 Bytes = bootm 0x8e00 * kernel: cmdline image address = 0x8e00 ## Booting kernel from Legacy Image at 8e00 ... Image Name: Hello Image Image Type: SuperH U-Boot Standalone Program (uncompressed) Data Size:70380 Bytes = 68.7 kB Load Address: 8c00 Entry Point: 8c00 Verifying Checksum ... OK Wrong Image Type for bootm command ERROR: can't get kernel image! ... Could you give me an advice? I think i have wrong image format? But how can I get correct format ? Best regards. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PATCH: IXP465 support and some IXP4xx rework, Sidewinder board support
Hi, on the matter of getting u-boot work with the ADI Sidewinder Reference Platform, I found the previously posted patches and used them as starting point for my own patch set. The Sidewinder board works with this patch, including ECC (optional). There is a minimum set of ifdefs in cpu/ixp/start.S and no board-specific low-level.S and thus no endless code-duplication. The SDRAM parameters are handled by configuration definitions. The ixp425.h and ixp465.h header files should be merged but that can follow in a different patch, possibly renaming the defines and fixing all board specific code. The new initialisation routine was also tested on an IXP425, it really works on both. The npe_less_fw.patch allows to have NPE-C firmware and still use NPE-B. There is no need to load firmware to NPE-C if you are not going to use it. This work was done for Erhardt+Leimer GmbH. Note: I hope this can be merged, however, your description at http://www.denx.de/wiki/U-Boot/Patches makes me worry. I can only use Lotus Notes and that's a bit limited. No, I cannot use another MUA from here, really! If you can accept them at attachments (patches with description header, diff index and Signed-off-by line, I use quilt locallly). Sincerly, Hendrik Sattler PS: please CC on answers as I am not subscribed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how can i change u-boot load address?
Dear Gururaja Hebbar K R, In message [EMAIL PROTECTED] you wrote: U wouldnt see mapping the vector on (most) ARM Platforms because they use u-boot as secondary bootloader I don't have reliable statistical data to judge if the most is correct, or if it actually is only a few configurations that do this. I said most because ARM Integrator Board doesnt use Arm Bootmonitor hence its code has remapping functionality. From what I'm seeing, most systems use U-oot as primary (and only) boot loader. 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] The only person who always got his work done by Friday was Robinson Crusoe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Run hello world with Uboot !
Dear Mathieu, In message [EMAIL PROTECTED] you wrote: I've also tried to go 0x8004 with the same result. Tried? You mean you do not know the exact entry point address? Did you read the FAQ??? 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] The only way to learn a new programming language is by writing pro- grams in it.- Brian Kernighan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Olimex SAM9-L9260 board support
Dear Wolfgang Denk,
Regarding the following:
+#define ROUND(A, B)(((A) + (B)) ~((B) - 1))
+/*
+ * Size of malloc() pool
+ */
+#define CFG_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE + 128*1024, 0x1000)
I tried to include the common.h file in my configuration file but this
breaks u-boot compilation (it's
not safe to include common.h standalone) .I noticed that none of other
board configuration files
include common.h
If I replace the ROUND(A,B) macro with #define DIV_ROUND_UP(n,d) (((n)
+ (d) - 1) / (d))
macro when i try to make u-boot I obtain the following errors:
start.S: Assembler messages:
start.S:339: Error: invalid constant (802d) after fixup
It appears to me that the solution for the moment is to use the following fixed
macro:
define ROUND(A, B) (((A) + (B) -1) ~((B) - 1))
Regarding the following:
+#ifdef CONFIG_RESET_PHY_R
+void reset_phy(void)
+{
+#ifdef CONFIG_MACB
+/*
+ * Initialize ethernet HW addr prior to starting Linux,
+ * needed for nfsroot
+ */
+eth_init(gd-bd);
+#endif
Please do NOT do this. It's a violation of the U-Boot design
principles, which clearly say that only such periphereals that are
actually being used by U-Boot shall be initialized, and even if they
are being used, these shall be deactivated after use.
I removed the reset_phy() function and I do not use anymore CONFIG_RESET_PHY_R.
I use setenv ethaddr to configure the MAC address of the Ethernet controller.
Is it ok to resend the patch with the above changes ?
Best regards,
Cristian Birsan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
On Tue, Oct 07, 2008 at 11:42:38AM +0200, Dirk Behme wrote: Is it OK if config gets written before control, or if this whole thing gets done out of order with respect to other raw writes? Hmm. I replaced this with the version from Nishanth's U-Boot v2 (see link above). If this isn't ok, can you explain a little more? I was referring to the raw accessors, which you removed, so it's OK. I.e. with patch in attachment we don't touch nand_base.c any more, but still have an #ifdeffed user command in cmd_nand.c. If you don't like this, please give a hint how to better do this. If at all possible, fix Linux to accept hardware ECC. Otherwise, either add something to the MTD API that the nand command can call, or have your own board-specific command defined in the board file. Don't put platform-specific ifdefs in generic files. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
On Tue, Oct 07, 2008 at 06:25:11AM -0500, Nishanth Menon wrote:
Dirk Behme said the following on 10/07/2008 04:42 AM:
It doesn't differ ;)
So I removed this and tried to use default nand_read_buf16() instead:
nand-read_buf = nand_read_buf16;
in board_nand_init(). But this doesn't compile as nand_read_buf16() is
static in nand_base.c. How do I use it in OMAP3 NAND driver? Marked it
as FIXME in patch.
Probably does not need an explicit initialization, mtd nand_scan should
populate that.
Correct, NULL methods will be filled in with defaults if applicable.
+/*
+ * omap_calculate_ecc - Generate non-inverted ECC bytes.
+ *
+ * Using noninverted ECC can be considered ugly since writing a blank
+ * page ie. padding will clear the ECC bytes. This is no problem as
+ * long nobody is trying to write data on the seemingly unused page.
+ * Reading an erased page will produce an ECC mismatch between
+ * generated and read ECC bytes that has to be dealt with separately.
Is this a hardware limitation? If so, say so in the comment. If not,
why do it this way?
Don't know.
All: Any help?
The issue is simple: assume we read a page of 0xFF's(fresh erased), IF
using H/w ECC engine within GPMC, the result of read will be 0x0 while
the ECC offsets of the spare area will be 0xFF which will result in an
ECC mismatch.
Right, I'd just like to see an explicit statement that this is the only way
to do HW ECC that the hardware supports (following verification of that
fact, of course), along with a pointer to where in the code the ECC error
when reading an empty page is dealt with.
+.eccbytes = 12,
+.eccpos = {
+ 2, 3, 4, 5,
+ 6, 7, 8, 9,
+ 10, 11, 12, 13},
+.oobfree = { {20, 50} }/* don't care */
Bytes 64-69 of a 64-byte OOB are free?
What don't we care about?
+static struct nand_ecclayout hw_nand_oob_64 = {
Don't know (or understand?).
All: Any help?
I do not get it either.. ECCPOS is in offset bytes, and oobfree should
be {.offset=20,.length=44} /*I always hated struct initialization done
as above..*/, but then,
Why not offset 14, length 50?
We need to be able to switch ECC at runtime cause some images have to
be written to NAND with HW ECC and some with SW ECC. This depends on
what user (reader) of these parts expect.
OMAP3 has a boot ROM which is able to read a second level loader
(called x-loader) from NAND and start/execute it. This 2nd level
loader has to be written by U-Boot using HW ECC as ROM code does HW
ECC to read the image. All other parts, e.g. Linux kernel, use SW ECC
as default. For this we have to use SW ECC to write images, then.
Therefore we add an additional user command in cmd_nand.c to switch
ECC depending on what user wants to write.
why not use h/w ecc which rom code understands in kernel and u-boot. H/w
ecc will be faster in comparison to doing s/w ecc and there is good
support in MTD to do it, then there would be no reason for s/w ecc IMHO..
Agreed.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
Menon, Nishanth wrote:
I do not get it either.. ECCPOS is in offset bytes, and oobfree should
be {.offset=20,.length=44} /*I always hated struct initialization done
as above..*/, but then,
Why not offset 14, length 50?
How about this part being used by ubi/jffs2 or some fs.. I cant think
off-hand if there an implication, but yep, I suspect there is no reason why
not..
The higher levels allocate their OOB usage from the regions that the
low-level driver claims are free.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
Scott Wood wrote: On Tue, Oct 07, 2008 at 11:42:38AM +0200, Dirk Behme wrote: Is it OK if config gets written before control, or if this whole thing gets done out of order with respect to other raw writes? Hmm. I replaced this with the version from Nishanth's U-Boot v2 (see link above). If this isn't ok, can you explain a little more? I was referring to the raw accessors, which you removed, so it's OK. :) I.e. with patch in attachment we don't touch nand_base.c any more, but still have an #ifdeffed user command in cmd_nand.c. If you don't like this, please give a hint how to better do this. If at all possible, fix Linux to accept hardware ECC. Yes, as mentioned by Nishanth, too, this will be possible. But I don't think in the short term, and not with breaking compatibility with kernels already out there. So for the moment I like to have both options, HW SW ECC. Otherwise, either add something to the MTD API that the nand command can call, or have your own board-specific command defined in the board file. Don't put platform-specific ifdefs in generic files. Do you have any example how to extend MTD API and/or can link to example where board-specific command is already used? Thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
Scott Wood wrote:
On Tue, Oct 07, 2008 at 06:25:11AM -0500, Nishanth Menon wrote:
Dirk Behme said the following on 10/07/2008 04:42 AM:
It doesn't differ ;)
So I removed this and tried to use default nand_read_buf16() instead:
nand-read_buf = nand_read_buf16;
in board_nand_init(). But this doesn't compile as nand_read_buf16() is
static in nand_base.c. How do I use it in OMAP3 NAND driver? Marked it
as FIXME in patch.
Probably does not need an explicit initialization, mtd nand_scan should
populate that.
Correct, NULL methods will be filled in with defaults if applicable.
ok, will do so, this is easy :)
+/*
+ * omap_calculate_ecc - Generate non-inverted ECC bytes.
+ *
+ * Using noninverted ECC can be considered ugly since writing a blank
+ * page ie. padding will clear the ECC bytes. This is no problem as
+ * long nobody is trying to write data on the seemingly unused page.
+ * Reading an erased page will produce an ECC mismatch between
+ * generated and read ECC bytes that has to be dealt with separately.
Is this a hardware limitation? If so, say so in the comment. If not,
why do it this way?
Don't know.
All: Any help?
The issue is simple: assume we read a page of 0xFF's(fresh erased), IF
using H/w ECC engine within GPMC, the result of read will be 0x0 while
the ECC offsets of the spare area will be 0xFF which will result in an
ECC mismatch.
Right, I'd just like to see an explicit statement that this is the only way
to do HW ECC that the hardware supports (following verification of that
fact, of course), along with a pointer to where in the code the ECC error
when reading an empty page is dealt with.
Will add Nishanth's explanation to comment and check code for this.
+.eccbytes = 12,
+.eccpos = {
+ 2, 3, 4, 5,
+ 6, 7, 8, 9,
+ 10, 11, 12, 13},
+.oobfree = { {20, 50} }/* don't care */
Bytes 64-69 of a 64-byte OOB are free?
What don't we care about?
+static struct nand_ecclayout hw_nand_oob_64 = {
Don't know (or understand?).
All: Any help?
I do not get it either.. ECCPOS is in offset bytes, and oobfree should
be {.offset=20,.length=44} /*I always hated struct initialization done
as above..*/, but then,
Why not offset 14, length 50?
Seems I need a closer look what we are talking about here ;)
We need to be able to switch ECC at runtime cause some images have to
be written to NAND with HW ECC and some with SW ECC. This depends on
what user (reader) of these parts expect.
OMAP3 has a boot ROM which is able to read a second level loader
(called x-loader) from NAND and start/execute it. This 2nd level
loader has to be written by U-Boot using HW ECC as ROM code does HW
ECC to read the image. All other parts, e.g. Linux kernel, use SW ECC
as default. For this we have to use SW ECC to write images, then.
Therefore we add an additional user command in cmd_nand.c to switch
ECC depending on what user wants to write.
why not use h/w ecc which rom code understands in kernel and u-boot. H/w
ecc will be faster in comparison to doing s/w ecc and there is good
support in MTD to do it, then there would be no reason for s/w ecc IMHO..
Agreed.
As already mentioned in previous post, I think for the the moment we
have to go with both ways.
To summarize the open points I will look at:
a) Remove unnecessary nand-read_buf init
b) Add comment and check code for HW ecc issue with erased page
c) Fix offset 14, length 50 issue
d) Extend MTD API with a call to switch HW/SW ecc, remove
platform-specific ifdefs in generic files
Nishanth M.: Would be nice to get some help for these changes. E.g.
can you say if this HW ecc issue with erased page is handled correctly
in exisiting code?
Thanks for the help
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
-Original Message-
From: Scott Wood [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 07, 2008 12:30 PM
To: Nishanth Menon
Cc: Dirk Behme; u-boot@lists.denx.de; Kamat, Nishant; Menon, Nishanth
Subject: Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib
common files, add NAND support
+.eccbytes = 12,
+.eccpos = {
+ 2, 3, 4, 5,
+ 6, 7, 8, 9,
+ 10, 11, 12, 13},
+.oobfree = { {20, 50} }/* don't care */
Bytes 64-69 of a 64-byte OOB are free?
What don't we care about?
+static struct nand_ecclayout hw_nand_oob_64 = {
Don't know (or understand?).
All: Any help?
I do not get it either.. ECCPOS is in offset bytes, and oobfree should
be {.offset=20,.length=44} /*I always hated struct initialization done
as above..*/, but then,
Why not offset 14, length 50?
How about this part being used by ubi/jffs2 or some fs.. I cant think off-hand
if there an implication, but yep, I suspect there is no reason why not..
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] iMX31: Add iMX31 support to boots from NAND
This serie of patches adds support to iMX31PDK board to boot directly from NAND. Notice these patches don't add support to MTD NAND Flash support to U-Boot (like reading and saving environment parameters in Flash because MTD NAND Flash driver still needs further revision). For people willing to test it follow these simple steps: Create a local copy of u-boot-arm/testing: $ git clone git://git.denx.de/u-boot-arm-next.git u-boot-arm $ cd u-boot-arm $ git checkout -b local_test origin/testing Apply patches: $ patch -p1 ../0001-iMX31-Reducing-start.S-size-to-let-boot-from-NAND.patch $ patch -p1 ../0002-iMX31-Add-support-to-copy-NAND-Flash-code-to-RAM.patch $ patch -p1 ../0003-iMX31-Add-support-to-iMX31PDK-board-and-let-it-boot.patch Set up your cross-compile (we are using one from LTIB): $ export PATH=$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/ $ export CROSS_COMPILE=arm-none-linux-gnueabi- Compile U-Boot to iMX31PDK board: $ make mx31pdk_config $ make Flash u-boot.bin to NAND flash (we are using ATK to do that)es doesn't add U-Boot support to erase/write on NAND. These patches will be applied against u-boot-arm/testing, against Magnus Lilja patches. Thanks to Kenneth Johansson about the idea to reduce start.S size. Thanks very much to Magnus Lilja and Fabio Estevam for all the help testing these patches. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] iMX31: Reducing start.S size to let boot from NAND
From eeb4a71a3565098ba43aeb83be163731065a039d Mon Sep 17 00:00:00 2001 From: Alan Carvalho de Assis [EMAIL PROTECTED] Date: Sun, 5 Oct 2008 19:57:22 -0300 Subject: [PATCH] iMX31: Reducing start.S size to let boot from NAND iMX31 NAND Flash Controller has a 2KB RAM buffer, but the current start.S file is too much big to let NAND copy routine to fit in. This patch will reduce the start.S when booting from NAND Flash. Signed-off-by: Alan Carvalho de Assis [EMAIL PROTECTED] --- cpu/arm1136/start.S | 24 ++-- 1 files changed, 22 insertions(+), 2 deletions(-) diff --git a/cpu/arm1136/start.S b/cpu/arm1136/start.S index 51b664d..b24fe41 100644 --- a/cpu/arm1136/start.S +++ b/cpu/arm1136/start.S @@ -32,6 +32,15 @@ #include version.h .globl _start _start: b reset +#ifdef CONFIG_BOOT_FROM_NAND + b . /* Undefined Instruction */ + b . /* Software Interrupt*/ + b . /* Prefetch Abort*/ + b . /* Data Abort*/ + b . /* Reserved */ + b . /* IRQ */ + b . /* FIQ */ +#else #ifdef CONFIG_ONENAND_IPL ldr pc, _hang ldr pc, _hang @@ -68,6 +77,7 @@ _irq: .word irq _fiq: .word fiq _pad: .word 0x12345678 /* now 16*4=64 */ #endif /* CONFIG_ONENAND_IPL */ +#endif /* CONFIG_BOOT_FROM_NAND */ .global _end_vect _end_vect: @@ -151,6 +161,7 @@ next: bl cpu_init_crit #endif +_cstartup: #ifndef CONFIG_SKIP_RELOCATE_UBOOT relocate: /* relocate U-Boot to RAM */ adr r0, _start /* r0 - current position of code */ @@ -239,12 +250,18 @@ cpu_init_crit: * Jump to board specific initialization... The Mask ROM will have already initialized * basic memory. Go here to bump up clock rate and handle wake up conditions. */ +#ifdef CONFIG_BOOT_FROM_NAND + ldr sp, =CFG_INTERNAL_SRAM_STACK/* Initial stack point in the SRAM */ + ldr r0, =_cstartup /* load the return address */ + mov lr, r0 /* set the return address after remap */ + b lowlevel_init /* relative branch enables remap*/ +#endif mov ip, lr /* persevere link reg across call */ bl lowlevel_init /* go setup pll,mux,memory */ mov lr, ip /* restore link */ mov pc, lr /* back to my caller */ -#ifndef CONFIG_ONENAND_IPL +#if !defined(CONFIG_ONENAND_IPL) !defined(CONFIG_BOOT_FROM_NAND) /* * * @@ -357,11 +374,12 @@ cpu_init_crit: .macro get_fiq_stack@ setup FIQ stack ldr sp, FIQ_STACK_START .endm -#endif /* CONFIG_ONENAND_IPL */ +#endif /* CONFIG_ONENAND_IPL/CONFIG_BOOT_FROM_NAND */ /* * exception handlers */ +#ifndef CONFIG_BOOT_FROM_NAND #ifdef CONFIG_ONENAND_IPL .align 5 do_hang: @@ -436,3 +454,5 @@ arm1136_cache_flush: mcr p15, 0, r1, c7, c5, 0 @ invalidate I cache mov pc, lr @ back to caller #endif /* CONFIG_ONENAND_IPL */ +#endif /* CONFIG_BOOT_FROM_NAND */ + -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12 v2] ARM: OMAP3: Add memory and syslib common files, add NAND support
Dirk Behme wrote: Otherwise, either add something to the MTD API that the nand command can call, or have your own board-specific command defined in the board file. Don't put platform-specific ifdefs in generic files. Do you have any example how to extend MTD API You'd need to add callbacks in the device structures; since this is a workaround for legacy support, and not something that is desireable in most cases, I'd go with the latter option of a board-specific command. and/or can link to example where board-specific command is already used? grep -rI U_BOOT_CMD board/ -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] iMX31: Add support to iMX31PDK board boots from NAND Flash
From ae5af322e53d00d021f6d4aa39c6916e1d3e12b7 Mon Sep 17 00:00:00 2001
From: Alan Carvalho de Assis [EMAIL PROTECTED]
Date: Sun, 5 Oct 2008 20:00:59 -0300
Subject: [PATCH] iMX31: Add support to iMX31PDK board boots from NAND Flash
This patch adds support to iMX31PDK board to boot directly from NAND
Flash. In order to it works the previous patches (which reduces start.S
size and copy NAND code to RAM) need be applied first.
Signed-off-by: Alan Carvalho de Assis [EMAIL PROTECTED]
---
board/freescale/mx31pdk/lowlevel_init.S | 95 +-
board/freescale/mx31pdk/u-boot.lds |3 +
include/configs/mx31pdk.h | 16 --
3 files changed, 105 insertions(+), 9 deletions(-)
diff --git a/board/freescale/mx31pdk/lowlevel_init.S
b/board/freescale/mx31pdk/lowlevel_init.S
index a94ea7f..71ab612 100644
--- a/board/freescale/mx31pdk/lowlevel_init.S
+++ b/board/freescale/mx31pdk/lowlevel_init.S
@@ -20,11 +20,98 @@
* MA 02111-1307 USA
*/
-/*
- * This is just to keep the linker happy.
- */
+#include asm/arch/mx31-regs.h
+
+.macro REG reg, val
+ ldr r2, =\reg
+ ldr r3, =\val
+ str r3, [r2]
+.endm
+
+.macro REG8 reg, val
+ ldr r2, =\reg
+ ldr r3, =\val
+ strb r3, [r2]
+.endm
+
+.macro DELAY loops
+ ldr r2, =\loops
+1:
+ subsr2, r2, #1
+ nop
+ bcs 1b
+.endm
.globl lowlevel_init
lowlevel_init:
- mov pc, lr
+ /* Store return address on the stack since lr is re-used in this file */
+ /* and all other registers are re-used as well */
+ str lr, [sp]
+
+ /* Also setup the Peripheral Port Remap register inside the core */
+ ldr r0, =ARM_PPMRR/* start from AIPS 2GB region */
+ mcr p15, 0, r0, c15, c2, 4
+
+ REG IPU_CONF, IPU_CONF_DI_EN
+ REG CCM_CCMR, 0x074B0BF5
+
+ DELAY 0x4
+
+ REG CCM_CCMR, 0x074B0BF5 | CCMR_MPE
+ REG CCM_CCMR, (0x074B0BF5 | CCMR_MPE) ~CCMR_MDS
+
+ /* Set up clock to 532MHz */
+ REG CCM_PDR0, 0xFF871D58
+ REG CCM_MPCTL, 0x0033280C
+ REG CCM_SPCTL, PLL_PD(1) | PLL_MFD(4) | PLL_MFI(12) | PLL_MFN(1)
+
+ /* Set up CPLD on CS5 */
+ REG CSCR_U(5), 0xD843
+ REG CSCR_L(5), 0x22252521
+ REG CSCR_A(5), 0x0A00
+
+ /* Set up MX31 DDR Memory Controller */
+ REG 0x43FAC26C, 0 /* SDCLK */
+ REG 0x43FAC270, 0 /* CAS */
+ REG 0x43FAC274, 0 /* RAS */
+ REG 0x43FAC27C, 0x1000 /* CS2 CSD0) */
+ REG 0x43FAC284, 0 /* DQM3 */
+ REG 0x43FAC288, 0 /* DQM2, DQM1, DQM0, SD31-SD0, A25-A0, MA10
0x288..0x2DC) */
+ REG 0x43FAC28C, 0
+ REG 0x43FAC290, 0
+ REG 0x43FAC294, 0
+ REG 0x43FAC298, 0
+ REG 0x43FAC29C, 0
+ REG 0x43FAC2A0, 0
+ REG 0x43FAC2A4, 0
+ REG 0x43FAC2A8, 0
+ REG 0x43FAC2AC, 0
+ REG 0x43FAC2B0, 0
+ REG 0x43FAC2B4, 0
+ REG 0x43FAC2B8, 0
+ REG 0x43FAC2BC, 0
+ REG 0x43FAC2C0, 0
+ REG 0x43FAC2C4, 0
+ REG 0x43FAC2C8, 0
+ REG 0x43FAC2CC, 0
+ REG 0x43FAC2D0, 0
+ REG 0x43FAC2D4, 0
+ REG 0x43FAC2D8, 0
+ REG 0x43FAC2DC, 0
+ REG 0xB8001010, 0x0004
+ REG 0xB8001004, 0x006ac73a
+ REG 0xB8001000, 0x9210
+ REG 0x8f00, 0x12344321
+ REG 0xB8001000, 0xa210
+ REG 0x8000, 0x12344321
+ REG 0x8000, 0x12344321
+ REG 0xB8001000, 0xb210
+ REG80x8033, 0xda
+ REG80x8100, 0xff
+ REG 0xB8001000, 0x82226080
+ REG 0x8000, 0xDEADBEEF
+ REG 0xB8001010, 0x000c
+
+ /* Copy from NAND to RAM */
+ b nand_copy
diff --git a/board/freescale/mx31pdk/u-boot.lds
b/board/freescale/mx31pdk/u-boot.lds
index 1460adc..8602f3e 100644
--- a/board/freescale/mx31pdk/u-boot.lds
+++ b/board/freescale/mx31pdk/u-boot.lds
@@ -35,6 +35,9 @@ SECTIONS
.text :
{
cpu/arm1136/start.o (.text)
+ board/freescale/mx31pdk/lowlevel_init.o (.text)
+ cpu/arm1136/mx31/nand_copy.o (.text)
+ . = 2K; /* lowlevel NAND needs to fit in 2KB of NFC buffer */
*(.text)
}
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index 6df1a00..d4362e3 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -38,6 +38,9 @@
#define CONFIG_MX31_HCLK_FREQ 2600
#define CONFIG_MX31_CLK32 32768
+/* We are booting from NAND. Used to shrink start.S */
+#define CONFIG_BOOT_FROM_NAND 1
+
#define CONFIG_DISPLAY_CPUINFO
#define CONFIG_DISPLAY_BOARDINFO
@@ -45,11 +48,6 @@
#define CONFIG_SETUP_MEMORY_TAGS 1
#define CONFIG_INITRD_TAG 1
-/* No support for NAND boot for i.MX31 PDK yet, so we rely on some other
Re: [U-Boot] [PATCH 2/3] iMX31: Add support to copy NAND Flash code to RAM
Alan Carvalho de Assis wrote: From 473120de8390abd78014cac9fe0925cb49f57fbe Mon Sep 17 00:00:00 2001 From: Alan Carvalho de Assis [EMAIL PROTECTED] Date: Sun, 5 Oct 2008 19:59:47 -0300 Subject: [PATCH] iMX31: Add support to copy NAND Flash code to RAM This code is executed from internal 2KB NAND Flash Controller RAM buffer and will copy the remaining U-Boot code from NAND Flash verifying its bad blocks (case it exists). Signed-off-by: Alan Carvalho de Assis [EMAIL PROTECTED] --- cpu/arm1136/mx31/Makefile |2 + cpu/arm1136/mx31/nand_copy.S | 263 + include/asm-arm/arch-mx31/mx31-regs.h | 69 + Please use the nand_spl infrastructure to whatever extent is practical. Does this code really need to be in assembly to fit? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SDRAM controller initialization code
Hi, I'm using Yosemite board (PPC440EP) for my development with U-Boot firmware version 1.3.4. Where in source code, I can find code regarding 'initializaiton of SDRAM controller'? Also, code regarding 'initialization of EBC'? (please be more explanable) Thanks in advance, Muzammal Ahmed ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help With TFTP
Hello. I seem to be having a small problem with transfering files from my machine to the at91sam9261-ek board via tftp. I'm using the following: --Files Used (Build From newest Buildroot using at91sam9261ek_defconfig)-- Bootstrap: at91sam9261ek-dataflashboot-2.3.4.bin U-Boot: at91sam9261ek-u-boot-1.2.0-atmel-20081003.bin Kernel: at91sam9261ek-linux-2.6.24.3-20081003.gz FS: rootfs.arm-20081003.ext2 AutoScript: autoscript.at91sam9261ek --TFPT Server Computer-- ipaddr: 192.168.50.95 gatewayip: 192.168.50.1 netmask: 255.255.255.0 --My Computer-- ipaddr: 10.0.2.54 gatewayip: 10.0.0.1 netmask: 255.255.0.0 --at91sam9261ek Board-- ipaddr: 10.0.2.105 gatewayip: 10.0.0.1 netmask: 255.255.0.0 [serverip: 192.186.50.95] I EraseAll on DataFlash/NandFlash and transfer the Bootstrap/U-Boot to my board via SAMBA and then boot up. I then do the default defenv run config run get, however, run get never completes. I get a lot of Timeouts (~1000) and then it eventually does Retry count exceeded; starting again. run config requests the autoscript.at91sam9261ek file and completes in about 1 seconds (500byte file). run get downloads about 800KB's of the 1.5MB linux kernal (I can see the percentage of the file transfer on the TFTP Server machine) in about 30 seconds and then stops and retries again from the beginning. When I use My Computer to request the kernel via a FTPT Client I am able to receive the file in about 2 or 3 seconds. Also the rootfs is 5MB's and I can receive that in about 6 seconds; as a result I don't think it is a problem with the TFTP Server. I think the problem is that U-Boot shows operating at 100M full duplex mode when my board is probably Half Duplex. I am unable to find how to force the connection type via u-boot. --Various Other Notes-- The dhcp command does not work for me in uboot, it just BOOTP 1,2,3,4... etc forever but since I'm able to get small files I didn't think this was too big an issue; this is probably a security thing on my internal network. Also the at91sam9261ek board is unable to connect to a tftp server hosted on my computer which is why I use the external server; again probably security on my network. I am able to transfer the files via serial port however this takes ~50 mins for a 5MB file which gets on my nervs a bit *smiles*, but, at the very least makes it more of an inconvinence than a major problem. Would anyone know how I might be able to solve this problem? Maybe by increasing the MAX_NET_RETRY_COUNT, perhaps by an environment variable inside u-boot *hopes*? I wasn't able to find the exact file/line to change if recompiling u-boot is needed. Or maybe by trying to set it to half-duplex? Or maybe I have some other settings wrong? If you need more information I can try to provide it. I attached an example U-Boot Log below. Thanks UBOOT Log U-Boot RomBOOT Start AT91Bootstrap... AT45DB642D detected Loading from Dataflash[0x8400] to SDRAM[0x23F0] ... Loading complete, [0x00032000] bytes Start application at [0x23F0] U-Boot 1.2.0 (Oct 3 2008 - 13:40:25) DRAM: 64 MB NAND: NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3, 3V 8-bit) NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bi t) 256 MiB DataFlash:AT45DB642 Nb pages: 8192 Page Size: 1056 Size= 8650752 bytes Logical address: 0xC000 Area 0: C000 to C00041FF (RO) Bootstrap (16kB) Area 1: C0004200 to C00083FF Environment (8kB) Area 2: C0008400 to C0039BFF (RO) U-Boot(192kB) Area 3: C0039C00 to C0041FFF (RO) Secondary Boot (32kB) Area 4: C0042000 to C01CDFFF OS Area 5: C01CE000 to C083 FS In:serial Out: serial Err: serial dm9000 i/o: 0x3000, id: 0x9a46 MAC: 04:25:fe:ed:00:18 operating at 100M full duplex mode Hit any key to stop autoboot: 0 U-Boot defenv Can't overwrite ethaddr len=149: root=/dev/ram rw initrd=0x2118C000,600 ramdisk_size=15360 ip=10.0 .2.105:192.168.50.95:10.0.0.1:255.255.0.0 console=ttyS0,115200,mem=64M U-Boot run config dm9000 i/o: 0x3000, id: 0x9a46 MAC: 04:25:fe:ed:00:18 operating at 100M full duplex mode TFTP from server 192.168.50.95; our IP address is 10.0.2.105; sending through ga teway 10.0.0.1 Filename 'autoscript.at91sam9261ek'. Load address: 0x2118c000 Loading: T T T T T T T T T T T T T T T T T T T T #T T T T T T T T T T T T T T T T T done Bytes transferred = 553 (229 hex) ## Executing script at 2118c000 Can't overwrite ethaddr U-Boot run get dm9000 i/o: 0x3000, id: 0x9a46 MAC: 04:25:fe:ed:00:18 operating at 100M full duplex mode TFTP from server
Re: [U-Boot] [PATCH 1/6] Make DDR interleaving mode work correctly
If Kim and Jon approve, I'll pull these 6 patches into my 85xx-next branch.
On Fri, Oct 3, 2008 at 11:36 AM, Haiying Wang
[EMAIL PROTECTED] wrote:
Fix some bugs:
1. Correctly set intlv_ctl in cs_config.
2. Correctly set sa, ea in cs_bnds when bank interleaving mode is enabled.
3. Set base_address and total memory for each ddr controller in memory
controller interleaving mode.
Signed-off-by: Haiying Wang [EMAIL PROTECTED]
---
cpu/mpc8xxx/ddr/ctrl_regs.c | 61 +++---
cpu/mpc8xxx/ddr/main.c |5 +++
include/asm-ppc/fsl_ddr_sdram.h | 12 +++
3 files changed, 66 insertions(+), 12 deletions(-)
diff --git a/cpu/mpc8xxx/ddr/ctrl_regs.c b/cpu/mpc8xxx/ddr/ctrl_regs.c
index e6c2a5c..6297141 100644
--- a/cpu/mpc8xxx/ddr/ctrl_regs.c
+++ b/cpu/mpc8xxx/ddr/ctrl_regs.c
@@ -95,16 +95,10 @@ static void set_csn_config(int i, fsl_ddr_cfg_regs_t *ddr,
col_bits_cs_n = dimm_params[i/2].n_col_addr - 8;
}
- /* FIXME: intlv_en, intlv_ctl only on CS0_CONFIG */
- if (i != 0) {
- intlv_en = 0;
- intlv_ctl = 0;
- }
-
ddr-cs[i].config = (0
| ((cs_n_en 0x1) 31)
| ((intlv_en 0x3) 29)
- | ((intlv_en 0xf) 24)
+ | ((intlv_ctl 0xf) 24)
| ((ap_n_en 0x1) 23)
/* XXX: some implementation only have 1 bit starting at left */
@@ -874,8 +868,13 @@ compute_fsl_memctl_config_regs(const memctl_options_t
*popts,
for (i = 0; i CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
phys_size_t sa = 0;
phys_size_t ea = 0;
- if (popts-ba_intlv_ctl i 0) {
- /* Don't set up boundaries if bank interleaving */
+
+ if (popts-ba_intlv_ctl (i 0)
+ ((popts-ba_intlv_ctl 0x60) != FSL_DDR_CS2_CS3 )) {
+ /* Don't set up boundaries for other CS
+* other than CS0, if bank interleaving
+* is enabled and not CS2+CS3 interleaved.
+*/
break;
}
@@ -894,7 +893,9 @@ compute_fsl_memctl_config_regs(const memctl_options_t
*popts,
* on each controller is twice the amount present on
* each controller.
*/
- ea = (2 * common_dimm-total_mem dbw_cap_adj) - 1;
+ unsigned long long rank_density
+ = dimm_params[0].capacity;
+ ea = (2 * (rank_density dbw_cap_adj)) - 1;
}
else if (!popts-memctl_interleaving popts-ba_intlv_ctl) {
/*
@@ -906,8 +907,44 @@ compute_fsl_memctl_config_regs(const memctl_options_t
*popts,
* controller needs to be programmed into its
* respective CS0_BNDS.
*/
- sa = common_dimm-base_address;
- ea = sa + (common_dimm-total_mem dbw_cap_adj) - 1;
+ unsigned long long rank_density
+ =
dimm_params[i/2].rank_density;
+ switch (popts-ba_intlv_ctl
FSL_DDR_CS0_CS1_CS2_CS3) {
+ case FSL_DDR_CS0_CS1_CS2_CS3:
+ /* CS0+CS1+CS2+CS3 interleaving, only CS0_CNDS
+* needs to be set.
+*/
+ sa = common_dimm-base_address;
+ ea = sa + (4 * (rank_density
dbw_cap_adj))-1;
+ break;
+ case FSL_DDR_CS0_CS1_AND_CS2_CS3:
+ /* CS0+CS1 and CS2+CS3 interleaving, CS0_CNDS
+* and CS2_CNDS need to be set.
+*/
+ if (!(i1)) {
+ sa = dimm_params[i/2].base_address;
+ ea = sa + (i * (rank_density
+ dbw_cap_adj)) - 1;
+ }
+ break;
+ case FSL_DDR_CS0_CS1:
+ /* CS0+CS1 interleaving, CS0_CNDS needs
+* to be set
+*/
+ sa = common_dimm-base_address;
+ ea = sa + (2 * (rank_density
dbw_cap_adj))-1;
+ break;
+ case FSL_DDR_CS2_CS3:
+ /* CS2+CS3 interleaving*/
+ if (i == 2) {
+
[U-Boot] Problem with flash on a MPC5200B board
Hi Everyone I'm pretty new to U-Boot and Embedded system globally, but in the last few weeks I have learn a lot and I'm now trying to port correctly U-Boot v 1.3.4 to a custom board based on a Icecube. I'm able to boot a linux kernel with it when I use the RAM with the bootm command. Unfortunately, I must make it work with the FLASH. The chip used for the flash is a S29GL128 or a S29GL256 from Spansion, they are 16bits chips but the bus is only 8bits. By reading the datasheet, these chips are supposed to support the Common Flash Interface so I'm trying to make then work with the CFI driver of U-Boot. Here is what I get when booting with DEBUG activated: U-Boot 1.3.4 (Oct 7 2008 - 16:39:49) CPU: MPC5200B v2.2, Core v1.4 at 378 MHz Bus 84 MHz, IPB 84 MHz, PCI 21 MHz Board: Icecube Based Board I2C: 93 kHz, ready DRAM: 64 MB Top of RAM usable for U-Boot at: 0400 Reserving 551k for U-Boot at: 03f76000 Reserving 130k for malloc() at: 03f55800 Reserving 68 Bytes for Board Info at: 03f557bc Reserving 60 Bytes for Global Data at: 03f55780 Stack Pointer at: 03f55768 New Stack Pointer is: 03f55768 Now running in RAM - U-Boot at: 03f76000 FLASH: flash detect cfi fwc addr ff00 cmd f0 f0 8bit x 8 bit fwc addr ff00 cmd f0 f0 8bit x 8 bit fwc addr ff55 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr ff10 is= 0 51 fwc addr ff000555 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr ff10 is= 0 51 fwc addr ff00 cmd f0 f0f0 16bit x 8 bit fwc addr ff00 cmd f0 f0f0 16bit x 8 bit fwc addr ffaa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr ff20 is= 5151 5151 is= cmd 52(R) addr ff22 is= 5252 5252 is= cmd 59(Y) addr ff24 is= 5959 5959 device interface is 2 found port 2 chip 1 port 16 bits chip 8 bits 00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 06 [EMAIL PROTECTED]'6... 10 : 06 09 13 03 05 03 02 19 02 00 06 00 01 ff 00 00 20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 ... fwc addr ff00 cmd f0 f0f0 16bit x 8 bit fwc addr ff001554 cmd aa 16bit x 8 bit fwc addr ff000aaa cmd 55 16bit x 8 bit fwc addr ff001554 cmd 90 9090 16bit x 8 bit fwc addr ff00 cmd f0 f0f0 16bit x 8 bit fwc addr ffaa cmd 98 9898 16bit x 8 bit manufacturer is 2 manufacturer id is 0x5 device id is 0x56 device id2 is 0x0 cfi version is 0x3133 size_ratio 1 port 16 bits chip 8 bits found 1 erase regions erase region 0: 0x02ff erase_region_count = 256 erase_region_size = 131072 ERROR: too many flash sectors fwc addr ff00 cmd f0 f0 8bit x 8 bit flash_protect ON: from 0xFFF0 to 0xFFF43FFF flash_protect ON: from 0xFFFE to 0x 32 MB basetask = 0, tasks = 2 task_org = 0x03fb4c00 TDT start = 0x0040, end = 0x01b8 PCI: Bus Dev VenId DevId Class Int PCI Scan: Found Bus 0, Device 24, Function 0 00 18 168c 001b 0200 00 PCI Scan: Found Bus 0, Device 26, Function 0 00 1a 1057 5809 0680 00 In:serial Out: serial Err: serial U-Boot relocated to 03f76000 Net: mpc5xxx_fec_init_phy... Begin mpc5xxx_fec_init_phy... Done FEC ETHERNET Type boot to boot to Linux (default) Type help for a list of commands So I got an ERROR: too many flash sectors and a 32 MB size ... I know for sure that the chip is 16 MB so there is a kind of inconsistency... I'm also a bit confuse about what #define I should use to force my board to communicate in 8bit even if it's capable of 16bit. I though that I simply had to #undef FLASH_CFI_16BIT but that doesn't seem to do the trick. I'm not sure to understand the debug output I got... fwc addr ff00 cmd f0 f0 8bit x 8 bit ... fwc addr ff00 cmd f0 f0f0 16bit x 8 bit Also is the value of erase_region_count = 256 should be the number of sector on the chip Because I know that the ship have a maximum of 128 sectors... If someone could brief me a bit about the debug output posted above I would greatly appreciate. I'm pretty sure I have nearly complete the port except for this FLASH issue... Help/Suggestion/Comments are welcome Thank you Sylvain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Olimex SAM9-L9260 board support
Dear all,
In the previous patch i removed the code from the section below.
+#ifdef CONFIG_RESET_PHY_R
+void reset_phy(void)
+{
+#ifdef CONFIG_MACB
+/*
+ * Initialize ethernet HW addr prior to starting Linux,
+ * needed for nfsroot
+ */
+eth_init(gd-bd);
+#endif
Please do NOT do this. It's a violation of the U-Boot design
principles, which clearly say that only such periphereals that are
actually being used by U-Boot shall be initialized, and even if they
are being used, these shall be deactivated after use.
Carelessly leaving ports or devices in an initialized stated has been
the source for problems too many times before.
Don't do that.
The u-boot works but when I try to use nfs as root filesystem i encounter the
following issue:
.
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfffc4000 irq 21 (00:00:00:00:00:00)
eth0: attached PHY driver [KS8721BL] (mii_bus:phy_addr=:01, irq=-1)
.
From previous messages i understand that the MAC is set to 00:00:00:00:00:00
which is bad.
IP-Config: Failed to open eth0
I used again setenv ethaddr 00:04:25:12:34:56 in u-boot. After saveenv and
reboot i used md command to display the EMAC 0xFFFC4000 (named MACB in the
driver )
registers
U-Boot md 0xfff4c000
fff4c000:
fff4c010:
fff4c020:
fff4c030:
fff4c040:
fff4c050:
fff4c060:
fff4c070:
fff4c080:
fff4c090:
fff4c0a0:
fff4c0b0:
fff4c0c0:
fff4c0d0:
fff4c0e0: 4000[EMAIL PROTECTED]
fff4c0f0: 53504932 20202020 00010154 01902IPST...
Offset 0x98 Specific Address 1 Bottom Register EMAC_SA1B Read-write
Offset 0x9C Specific Address 1 Top RegisterEMAC_SA1T Read-write
The register EMAC_SA1T and EMAC_SA1B coresponding to top and bottom of the MAC
address are 0
Nfs works only with the ugly code that was removed.
I'm spinning in a circle :(
Please send me any suggestion.
Best regards,
Cristian Birsan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot Saveenv question -- final tested solution
Suresh Bhaskaran wrote: -Original Message- From: Jerry Van Baren [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2008 10:07 AM To: Suresh Bhaskaran Cc: Andrejs Cainikovs; u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot Saveenv question Suresh Bhaskaran wrote: 1. I verified flash contents using the md.w command in u-boot 2. I've already verified correct flash r/w operation using the cp.w command 3. Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile 4. Flinfo shows the correct flash configuration (sectors, etc) of the flash I can see the new env variable (e.g. set serverip 10.0.0.1) at the end of the saveenv area in flash (after I do a saveenv). (the original entry is removed from the list in flash, and the new updated entry is added to the end of the list in flash). Still, when I reboot u-boot, I don't get the new environment variable updated from flash. What am I missing? Thanks. Suresh Please don't top post. Are you using DHCP (BOOTP)? If you are, serverip is probably being sent by your DHCP server and overriding the value you have set in your env. I'm assuming you are *not* getting env CRC failure warnings on boot. If neither of the above guesses solve the problem, please copy what is printed to the console on start up. Without more information, we're just guessing. Best regards, gvb - Thanks for help: I've got it working: Final answer: Sorry, workaround for you, this isn't the final answer. 1. If *only* CONFIG_ENV_OVERWRITE is turned on in board file, then crc is not written to flash [don't know if it's bug, or if I am setting incorrect flags] This may work for you, but there is something else wrong for you. From the README file: If CONFIG_ENV_OVERWRITE is #defined in your config file, the write protection for vendor parameters is completely disabled. Anybody can change or delete these parameters. so CONFIG_ENV_OVERWRITE controls some logic WRT what can be changed in the env, but it doesn't directly affect flash writing. 2. But if CFG_ENV_ADDR_REDUND is also set, then it sets CRC to flash, and it works correctly. s/CFG/CONFIG/ What version is your u-boot? They have been renamed CONFIG_* for several months now. Again from the README: - CONFIG_ENV_ADDR_REDUND CONFIG_ENV_SIZE_REDUND These settings describe a second storage area used to hold a redundant copy of the environment data, so that there is a valid backup copy in case there is a power failure during a saveenv operation. ...so this *does* directly affect flash writing. In particular, it causes extra flash writing. My first suspicion is that you have a buffering/caching problem so that a non-redundant flash write doesn't actually go to completion (doesn't actually make it into the flash or the writes get reordered by the processor's bus interface unit). By setting the redundancy config option, your program does another flash write operation which forces the hung write out to flash. I would check if your data cache is disabled or handled properly if enabled and I would check if you have the right sync magic to flush the flash write operations out the bus interface unit properly. In any case, setup 2. works for me. Thanks for all the help. Suresh Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] Make DDR interleaving mode work correctly
Andy Fleming wrote: If Kim and Jon approve, I'll pull these 6 patches into my 85xx-next branch. On Fri, Oct 3, 2008 at 11:36 AM, Haiying Wang [EMAIL PROTECTED] wrote: Fix some bugs: 1. Correctly set intlv_ctl in cs_config. 2. Correctly set sa, ea in cs_bnds when bank interleaving mode is enabled. 3. Set base_address and total memory for each ddr controller in memory controller interleaving mode. Signed-off-by: Haiying Wang [EMAIL PROTECTED] Sounds good by me. ACK. jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Olimex SAM9-L9260 board support
Dear Cristian Birsan, In message [EMAIL PROTECTED] you wrote: I used again setenv ethaddr 00:04:25:12:34:56 in u-boot. After saveenv and reboot i used md command to display the EMAC 0xFFFC4000 (named MACB in the driver ) registers setenv affects only the U-Boot environment variables. It doe snot program any device registers for you. And PLEASE: restrict your line length to 70 characters or less. Nfs works only with the ugly code that was removed. I'm spinning in a circle :( Please read the previous postings, and the FAQ. Please send me any suggestion. Fix your Linux driver to pick up the MAC address from some convenient place; using a kernel boot argument is one option, using the device tree is another one. The former is less effort, the latter is more, but would earn you a lot of credits :-) 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 may be that your whole purpose in life is simply to serve as a warning to others. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3 v4] ppc4xx: Add AMCC Arches board support (dual 460GT)
The Arches Evaluation board is based on the AMCC 460GT SoC chip.
This board is a dual processor board with each processor providing
independent resources for Rapid IO, Gigabit Ethernet, and serial
communications. Each 460GT has it's own 512MB DDR2 memory, 32MB NOR
FLASH, UART, EEPROM and temperature sensor, along with a shared debug
port. The two 460GT's will communicate with each other via shared
memory, Gigabit Ethernet and x1 PCI-Express.
Signed-off-by: Adam Graham [EMAIL PROTECTED]
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
v2:
- Added Arches (460GT) support to the existing Canyonlands (460) board
files since the Canyonlands board files support all current AMCC
PPC460EX/GT boards.
v3:
- Correct tab/spaces in canyonlands.h file.
v4:
- Fix commit text (line to long)
- remove unneed timeout for ETH_PLL lock
- remove CONFIG_EXTRA_ENV_SETTINGS from USB connectivity section
- seperated CONFIG_CMD_xxx on a per board bases
- Use ethprime to set Arches default ethernet port to 1
MAKEALL |1 +
Makefile |3 +-
board/amcc/canyonlands/canyonlands.c | 140 ++
board/amcc/canyonlands/init.S| 17 +++
include/configs/amcc-common.h| 17 +++-
include/configs/canyonlands.h| 219 +++---
include/ppc440.h |3 +
7 files changed, 383 insertions(+), 17 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 9ccb9ac..847c1fa 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -161,6 +161,7 @@ LIST_4xx= \
alpr\
AP1000 \
AR405 \
+ arches \
ASH405 \
bamboo \
bamboo_nand \
diff --git a/Makefile b/Makefile
index 7c13ce8..2af11c4 100644
--- a/Makefile
+++ b/Makefile
@@ -1206,7 +1206,8 @@ bubinga_config: unconfig
CANBT_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc ppc4xx canbt esd
-# Canyonlands Glacier use different U-Boot images
+# Arches, Canyonlands Glacier use different U-Boot images
+arches_config \
canyonlands_config \
glacier_config:unconfig
@mkdir -p $(obj)include
diff --git a/board/amcc/canyonlands/canyonlands.c
b/board/amcc/canyonlands/canyonlands.c
index e9eba49..b6ee2ab 100644
--- a/board/amcc/canyonlands/canyonlands.c
+++ b/board/amcc/canyonlands/canyonlands.c
@@ -38,11 +38,52 @@ DECLARE_GLOBAL_DATA_PTR;
#define BOARD_CANYONLANDS_PCIE 1
#define BOARD_CANYONLANDS_SATA 2
#define BOARD_GLACIER 3
+#define BOARD_ARCHES 4
+
+#if defined(CONFIG_ARCHES)
+/*
+ * FPGA read/write helper macros
+ */
+static inline int board_fpga_read(int offset)
+{
+ int data;
+
+ data = in_8((void *)(CFG_FPGA_BASE + offset));
+
+ return data;
+}
+
+static inline void board_fpga_write(int offset, int data)
+{
+ out_8((void *)(CFG_FPGA_BASE + offset), data);
+}
+
+/*
+ * CPLD read/write helper macros
+ */
+static inline int board_cpld_read(int offset)
+{
+ int data;
+
+ out_8((void *)(CFG_CPLD_ADDR), offset);
+ data = in_8((void *)(CFG_CPLD_DATA));
+
+ return data;
+}
+
+static inline void board_cpld_write(int offset, int data)
+{
+ out_8((void *)(CFG_CPLD_ADDR), offset);
+ out_8((void *)(CFG_CPLD_DATA), data);
+}
+#endif /* defined(CONFIG_ARCHES) */
int board_early_init_f(void)
{
+#if !defined(CONFIG_ARCHES)
u32 sdr0_cust0;
u32 pvr = get_pvr();
+#endif
/*
* Setup the interrupt controller polarities, triggers, etc.
@@ -79,6 +120,7 @@ int board_early_init_f(void)
mtdcr(uic3vr, 0x); /* int31 highest, base=0x000 */
mtdcr(uic3sr, 0x); /* clear all */
+#if !defined(CONFIG_ARCHES)
/* SDR Setting - enable NDFC */
mfsdr(SDR0_CUST0, sdr0_cust0);
sdr0_cust0 = SDR0_CUST0_MUX_NDFC_SEL|
@@ -88,6 +130,7 @@ int board_early_init_f(void)
SDR0_CUST0_NDFC_BAC_ENCODE(3) |
(0x8000 (28 + CFG_NAND_CS));
mtsdr(SDR0_CUST0, sdr0_cust0);
+#endif
/*
* Configure PFC (Pin Function Control) registers
@@ -98,6 +141,7 @@ int board_early_init_f(void)
/* Enable PCI host functionality in SDR0_PCI0 */
mtsdr(SDR0_PCI0, 0xe000);
+#if !defined(CONFIG_ARCHES)
/* Enable ethernet and take out of reset */
out_8((void *)CFG_BCSR_BASE + 6, 0);
@@ -123,10 +167,12 @@ int board_early_init_f(void)
gpio_config(16, GPIO_OUT, GPIO_ALT1, GPIO_OUT_1);
gpio_config(19, GPIO_OUT, GPIO_ALT1, GPIO_OUT_1);
}
+#endif
return 0;
}
+#if !defined(CONFIG_ARCHES)
static void canyonlands_sata_init(int board_type)
{
u32 reg;
@@ -147,7 +193,26 @@ static void canyonlands_sata_init(int board_type)
SDR_WRITE(SDR0_SRST1, 0x);
}
}
+#endif /* !defined(CONFIG_ARCHES) */
+
+int get_cpu_num(void)
[U-Boot] [PATCH 2/3 v4] ppc4xx: Add static support for 44x IBM SDRAM Controller
This patch add the capability to configure a PPC440 based IBM SDRAM
Controller with static, compiled-in, values. PPC440 memory subsystem
includes a Memory Queue core.
Signed-off-by: Adam Graham [EMAIL PROTECTED]
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
v2:
- No changes.
v3:
- No changes.
v4:
- Fix commit text (line to long)
- Fix typo (it's to its)
cpu/ppc4xx/44x_spd_ddr2.c | 71 +---
1 files changed, 53 insertions(+), 18 deletions(-)
diff --git a/cpu/ppc4xx/44x_spd_ddr2.c b/cpu/ppc4xx/44x_spd_ddr2.c
index f1d7684..735d476 100644
--- a/cpu/ppc4xx/44x_spd_ddr2.c
+++ b/cpu/ppc4xx/44x_spd_ddr2.c
@@ -60,6 +60,26 @@
SDRAM_ #mnemonic, SDRAM_##mnemonic, data); \
} while (0)
+#if defined(CONFIG_440)
+/*
+ * This DDR2 setup code can dynamically setup the TLB entries for the DDR2
+ * memory region. Right now the cache should still be disabled in U-Boot
+ * because of the EMAC driver, that need its buffer descriptor to be located
+ * in non cached memory.
+ *
+ * If at some time this restriction doesn't apply anymore, just define
+ * CONFIG_4xx_DCACHE in the board config file and this code should setup
+ * everything correctly.
+ */
+#ifdef CONFIG_4xx_DCACHE
+/* enable caching on SDRAM */
+#define MY_TLB_WORD2_I_ENABLE 0
+#else
+/* disable caching on SDRAM */
+#define MY_TLB_WORD2_I_ENABLE TLB_WORD2_I_ENABLE
+#endif /* CONFIG_4xx_DCACHE */
+#endif /* CONFIG_440 */
+
#if defined(CONFIG_SPD_EEPROM)
/*-+
@@ -131,22 +151,6 @@
#define NUMLOOPS 64 /* memory test loops */
/*
- * This DDR2 setup code can dynamically setup the TLB entries for the DDR2
memory
- * region. Right now the cache should still be disabled in U-Boot because of
the
- * EMAC driver, that need it's buffer descriptor to be located in non cached
- * memory.
- *
- * If at some time this restriction doesn't apply anymore, just define
- * CONFIG_4xx_DCACHE in the board config file and this code should setup
- * everything correctly.
- */
-#ifdef CONFIG_4xx_DCACHE
-#define MY_TLB_WORD2_I_ENABLE 0 /* enable caching on
SDRAM */
-#else
-#define MY_TLB_WORD2_I_ENABLE TLB_WORD2_I_ENABLE /* disable caching on
SDRAM */
-#endif
-
-/*
* Newer PPC's like 440SPe, 460EX/GT can be equipped with more than 2GB of
SDRAM.
* To support such configurations, we only map the first 2GB via the TLB's.
We
* need some free virtual address space for the remaining peripherals like, SoC
@@ -2956,9 +2960,10 @@ static void test(void)
/*-
* Function: initdram
- * Description: Configures the PPC405EX(r) DDR1/DDR2 SDRAM memory
- * banks. The configuration is performed using static, compile-
+ * Description: Configures the PPC4xx IBM DDR1/DDR2 SDRAM memory controller.
+ * The configuration is performed using static, compile-
* time parameters.
+ * Configures the PPC405EX(r) and PPC460EX/GT
*---*/
phys_size_t initdram(int board_type)
{
@@ -2974,6 +2979,18 @@ phys_size_t initdram(int board_type)
#if !defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SPL)
unsigned long val;
+#if defined(CONFIG_440)
+ mtdcr(SDRAM_R0BAS, CFG_SDRAM_R0BAS);
+ mtdcr(SDRAM_R1BAS, CFG_SDRAM_R1BAS);
+ mtdcr(SDRAM_R2BAS, CFG_SDRAM_R2BAS);
+ mtdcr(SDRAM_R3BAS, CFG_SDRAM_R3BAS);
+ mtdcr(SDRAM_PLBADDULL, CFG_SDRAM_PLBADDULL); /* MQ0_BAUL */
+ mtdcr(SDRAM_PLBADDUHB, CFG_SDRAM_PLBADDUHB); /* MQ0_BAUH */
+ mtdcr(SDRAM_CONF1LL,CFG_SDRAM_CONF1LL);
+ mtdcr(SDRAM_CONF1HB,CFG_SDRAM_CONF1HB);
+ mtdcr(SDRAM_CONFPATHB, CFG_SDRAM_CONFPATHB);
+#endif
+
/* Set Memory Bank Configuration Registers */
mtsdram(SDRAM_MB0CF, CFG_SDRAM0_MB0CF);
@@ -3067,6 +3084,14 @@ phys_size_t initdram(int board_type)
mfsdram(SDRAM_MCOPT2, val);
mtsdram(SDRAM_MCOPT2, val | SDRAM_MCOPT2_DCEN_ENABLE);
+#if defined(CONFIG_440)
+ /*
+* Program TLB entries with caches enabled, for best performace
+* while auto-calibrating and ECC generation
+*/
+ program_tlb(0, 0, (CFG_MBYTES_SDRAM 20), 0);
+#endif
+
#if defined(CONFIG_PPC4xx_DDR_AUTOCALIBRATION)
#if !defined(CONFIG_NAND_U_BOOT) !defined(CONFIG_NAND_SPL)
/*--
@@ -3080,6 +3105,16 @@ phys_size_t initdram(int board_type)
ecc_init(CFG_SDRAM_BASE, CFG_MBYTES_SDRAM 20);
#endif /* defined(CONFIG_DDR_ECC) */
+#if defined(CONFIG_440)
+ /*
+* Now after initialization (auto-calibration and ECC generation)
+* remove the TLB entries with caches enabled and program again with
+
[U-Boot] [PATCH 3/3 v4] ppc4xx: Add routine to retrieve CPU number
Provide a weak defined routine to retrieve the CPU number for reference boards
that have multiple CPU's. Default behavior is the existing single CPU print
output. Reference boards with multiple CPU's need to provide a board specific
routine. See board/amcc/arches/arches.c for an example.
Signed-off-by: Adam Graham [EMAIL PROTECTED]
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
v2:
- Correct return code of the generic get_cpu_num routine and make the
return code a defined value.
v3:
- Correct tab/spaces in ppc4xx.h
v4:
- Fix commit text (line to long)
- Remove starting underscores from NA_OR_UNKNOWN_CPU
cpu/ppc4xx/cpu.c | 19 ++-
include/ppc4xx.h |3 +++
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/cpu/ppc4xx/cpu.c b/cpu/ppc4xx/cpu.c
index bc9335a..67f88f8 100644
--- a/cpu/ppc4xx/cpu.c
+++ b/cpu/ppc4xx/cpu.c
@@ -41,6 +41,18 @@ DECLARE_GLOBAL_DATA_PTR;
void board_reset(void);
+/*
+ * To provide an interface to detect CPU number for boards that support
+ * more then one CPU, we implement the weak default functions here.
+ *
+ * Returns CPU number
+ */
+int __get_cpu_num(void)
+{
+ return NA_OR_UNKNOWN_CPU;
+}
+int get_cpu_num(void) __attribute__((weak, alias(__get_cpu_num)));
+
#if defined(CONFIG_405GP) || \
defined(CONFIG_440EP) || defined(CONFIG_440GR) || \
defined(CONFIG_440EPX) || defined(CONFIG_440GRX)
@@ -274,8 +286,13 @@ int checkcpu (void)
#if !defined(CONFIG_IOP480)
char addstr[64] = ;
sys_info_t sys_info;
+ int cpu_num;
- puts (CPU: );
+ cpu_num = get_cpu_num();
+ if (cpu_num = 0)
+ printf(CPU%d: , cpu_num);
+ else
+ puts(CPU: );
get_sys_info(sys_info);
diff --git a/include/ppc4xx.h b/include/ppc4xx.h
index e216663..61209a7 100644
--- a/include/ppc4xx.h
+++ b/include/ppc4xx.h
@@ -218,4 +218,7 @@ static inline void set_mcsr(u32 val)
#endif /* __ASSEMBLY__ */
+/* for multi-cpu support */
+#define NA_OR_UNKNOWN_CPU -1
+
#endif /* __PPC4XX_H__ */
--
1.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Red Black Tree support
On Mon, Oct 6, 2008 at 4:26 PM, Wolfgang Denk [EMAIL PROTECTED] wrote: Dear Kyungmin Park, In message [EMAIL PROTECTED] you wrote: RB-tree support on U-Boot Now it's used at UBI module. Of course other modules can use it. ... I understand the code is a verbatim copy from the LInux kernel? Otherwise the coding style violations would not be acceptable. Yes it's from kernel. I just removed EXPORT_SYMBOL. diff --git a/lib_generic/Makefile b/lib_generic/Makefile index 7df5a2c..83b41ca 100644 --- a/lib_generic/Makefile +++ b/lib_generic/Makefile @@ -45,6 +45,7 @@ COBJS-y += string.o COBJS-y += strmhz.o COBJS-y += vsprintf.o COBJS-y += zlib.o +COBJS-y += rbtree.o I expect that only few systems will actually use this, so it must be configurable. It makes no sense to build this for ALL systems. Please add a config option. Agreed, I will add CONFIG_RBTREE. I will re-send the updated patch. Thank you, Kyungmin Park ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Red Black Tree support v2
RB-tree support on U-Boot
Now it's used at UBI module. Of course other modules can use it.
If you want to use it, please define CONFIG_RBTREE
Signed-off-by: Kyungmin Park [EMAIL PROTECTED]
---
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
new file mode 100644
index 000..a4956c4
--- /dev/null
+++ b/include/linux/rbtree.h
@@ -0,0 +1,160 @@
+/*
+ Red Black Trees
+ (C) 1999 Andrea Arcangeli [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
+
+ linux/include/linux/rbtree.h
+
+ To use rbtrees you'll have to implement your own insert and search cores.
+ This will avoid us to use callbacks and to drop drammatically performances.
+ I know it's not the cleaner way, but in C (not in C++) to get
+ performances and genericity...
+
+ Some example of insert and search follows here. The search is a plain
+ normal search over an ordered tree. The insert instead must be implemented
+ int two steps: as first thing the code must insert the element in
+ order as a red leaf in the tree, then the support library function
+ rb_insert_color() must be called. Such function will do the
+ not trivial work to rebalance the rbtree if necessary.
+
+---
+static inline struct page * rb_search_page_cache(struct inode * inode,
+unsigned long offset)
+{
+ struct rb_node * n = inode-i_rb_page_cache.rb_node;
+ struct page * page;
+
+ while (n)
+ {
+ page = rb_entry(n, struct page, rb_page_cache);
+
+ if (offset page-offset)
+ n = n-rb_left;
+ else if (offset page-offset)
+ n = n-rb_right;
+ else
+ return page;
+ }
+ return NULL;
+}
+
+static inline struct page * __rb_insert_page_cache(struct inode * inode,
+ unsigned long offset,
+ struct rb_node * node)
+{
+ struct rb_node ** p = inode-i_rb_page_cache.rb_node;
+ struct rb_node * parent = NULL;
+ struct page * page;
+
+ while (*p)
+ {
+ parent = *p;
+ page = rb_entry(parent, struct page, rb_page_cache);
+
+ if (offset page-offset)
+ p = (*p)-rb_left;
+ else if (offset page-offset)
+ p = (*p)-rb_right;
+ else
+ return page;
+ }
+
+ rb_link_node(node, parent, p);
+
+ return NULL;
+}
+
+static inline struct page * rb_insert_page_cache(struct inode * inode,
+unsigned long offset,
+struct rb_node * node)
+{
+ struct page * ret;
+ if ((ret = __rb_insert_page_cache(inode, offset, node)))
+ goto out;
+ rb_insert_color(node, inode-i_rb_page_cache);
+ out:
+ return ret;
+}
+---
+*/
+
+#ifndef_LINUX_RBTREE_H
+#define_LINUX_RBTREE_H
+
+#include linux/stddef.h
+
+struct rb_node
+{
+ unsigned long rb_parent_color;
+#defineRB_RED 0
+#defineRB_BLACK1
+ struct rb_node *rb_right;
+ struct rb_node *rb_left;
+} __attribute__((aligned(sizeof(long;
+/* The alignment might seem pointless, but allegedly CRIS needs it */
+
+struct rb_root
+{
+ struct rb_node *rb_node;
+};
+
+
+#define rb_parent(r) ((struct rb_node *)((r)-rb_parent_color ~3))
+#define rb_color(r) ((r)-rb_parent_color 1)
+#define rb_is_red(r) (!rb_color(r))
+#define rb_is_black(r) rb_color(r)
+#define rb_set_red(r) do { (r)-rb_parent_color = ~1; } while (0)
+#define rb_set_black(r) do { (r)-rb_parent_color |= 1; } while (0)
+
+static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
+{
+ rb-rb_parent_color = (rb-rb_parent_color 3) | (unsigned long)p;
+}
+static inline void rb_set_color(struct rb_node *rb, int color)
+{
+ rb-rb_parent_color = (rb-rb_parent_color ~1) | color;
+}
+
+#define RB_ROOT(struct rb_root) { NULL, }
+#definerb_entry(ptr, type, member)
Re: [U-Boot] how can i change u-boot load address?
Hello 2008/10/7 Wolfgang Denk [EMAIL PROTECTED]: The advantage of the PowerPC implementation with relocation is that we can measure the actual size of memory present on the board, and then relocate U-Boot to the very end of the RAM, leaving nearly th When you say end of the RAM', I think you mean higher addresses, i.e. 0x_ downwards or lower 0x000_ onwards? (this depends on how to look at memory map, written on a sheet of paper -- straight or upside down :-) ). So the bottom line of PPC architecture is that it tries to have unified booting/relocation process for every platform? For instance, always copy itself in the upper addresses, occupying, say, 128kB or so of RAM. whole RAM usable as one big contiguous area for applications like loading Linux kernel, ramdisk, etc. [skip] Just try to imagine you have to install a new version of the BIOS on your PC just because you add or remove a memory module. Would you buy such a PC? Well, you convinced me; but despite its flaws and drawbacks the current ARM port architecture exists and it is here to stay for quite awhile, unless there will be some hero ready to break it up and build a new from scratch. -- Roman Mashak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] Make DDR interleaving mode work correctly
On Oct 7, 2008, at 4:38 PM, Andy Fleming wrote: If Kim and Jon approve, I'll pull these 6 patches into my 85xx-next branch. The code doesn't impact 83xx and thus not sure why you need Kim's ack. - k On Fri, Oct 3, 2008 at 11:36 AM, Haiying Wang [EMAIL PROTECTED] wrote: Fix some bugs: 1. Correctly set intlv_ctl in cs_config. 2. Correctly set sa, ea in cs_bnds when bank interleaving mode is enabled. 3. Set base_address and total memory for each ddr controller in memory controller interleaving mode. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
