October 2005 - U-Boot

[U-Boot-Users] Question about u-boot relocation
by Aitor Garcia 14 Oct '05

14 Oct '05

Hello everybody, I am using mx1fs2 board based on an arm920t core. I am new to u-boot and I have read the faq and now I am reading very carefully start.S initialization code to understand the relocation process. This is what I don't understand: Theoretically, when u-boot starts executing from flash, it configures some basic registers, configures the sdram controller, relocates itself to sdram and continues executing code from sdram. But in practice, I don't understand how it is possible that u-boot can run from flash because analyzing the binary it looks that it is only linked to run from sdram. vma=lma=sdram address. arm-unknown-linux-gnu-objdump -h u-boot u-boot: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 000138a4 08f00000 08f00000 00008000 2**5 Correct me if I'm wrong but I think that lma should be flash address. I would be very grateful if someone could give me any pointer. Best Regards, Aitor __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/

1 0

RE: [U-Boot-Users] Question on pre-loader to U-Boot
by Zhang, Chris (Ex CH01) 14 Oct '05

14 Oct '05

Thank you very much! So no source code need change, isn't it? THX and regards, zl -----Original Message----- From: Anders Larsen [mailto:alarsen@rea.de] Sent: 2005 10 14 15:34 To: Zhang, Chris (Ex CH01) Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] Question on pre-loader to U-Boot "Zhang, Chris (Ex CH01)" <Chris.Zhang(a)honeywell.com> schrieb am Freitag, 14. Oktober 2005 um 03:28 +0100: >So the . = 0x0000 0000 in the ld script file is a relative address. Is >it right? Yes. Cheers Anders

2 1

RE: [U-Boot-Users] Question on pre-loader to U-Boot
by Zhang, Chris (Ex CH01) 14 Oct '05

14 Oct '05

Thanks Larsen, So the . = 0x0000 0000 in the ld script file is a relative address. Is it right? Regards, zl -----Original Message----- From: Anders Larsen [mailto:alarsen@rea.de] Sent: 2005 10 13 19:44 To: Zhang, Chris (Ex CH01) Cc: u-boot-users(a)lists.sourceforge.net; wd(a)denx.de Subject: Re: [U-Boot-Users] Question on pre-loader to U-Boot "Zhang, Chris (Ex CH01)" <Chris.Zhang(a)honeywell.com> schreibt: >I am using at91rm9200dk u-boot from ATMEL. > >I noticed that ATMEL uses programs called loader.bin and boot.bin to >load U-Boot into SDRAM. The Load Address is 0x21f00000 (the upper 1M). > >My question is how does this value is choosen for U-Boot? I guess it is >related to linker behavior of U-Boot (right?), but there is no clue to >conclude such kind of address. Thanks for any hints. $ cat board/at91rm9200dk/config.mk TEXT_BASE = 0x21f00000 Cheers Anders

2 1

[U-Boot-Users] [PATCH] OMAP 5912/OSK: update EMIFS CS1 timings
by Kevin Hilman 13 Oct '05

13 Oct '05

The following patch adds some wait states to the EMIFS timings for CS1. Problems have been seen in the linux kernel's smc91x network driver due to improper bus timings. The latest 2.6 OMAP kernels currently have a workaround, but this fix belongs in u-boot. -- Kevin Hilman MontaVista Software -- http://www.mvista.com/

1 0

Re: [U-Boot-Users] Replacing AT91 u-boot
by kentropy 13 Oct '05

13 Oct '05

Peter, your explanation is fantastic ans exhaustive. > Only for this procedure you have to remove R159! Or if you destroy the existing u-boot in Parallel Flash ;-) > I can definitely confirm, that u-boot-1.1.2 works fine in that case. If > needed, I can send you the u-boot config. Could you please send it to me ? > Hope, that helps a step further... Yes, sometimes help and readme aren't clear enough for newbies ;-)

2 1

[U-Boot-Users] [PATCH] trivial bugfix, #ifdef CONFIG_SKIP_LOWLEVEL_INIT added in arm920t/start.S
by Peter Menzebach 13 Oct '05

13 Oct '05

The ifdef around cpu_init_crit was added, otherwise a reference to "lowlevel_init" still exists and could not be resolved by the linker. Best regards Peter Menzebach CHANGELOG: Patch by Peter Menzebach, 2005-10-13 ifdef CONFIG_SKIP_LOWLEVEL_INIT around cpu_init_crit added in cpu/arm920t/start.S --- u-boot/cpu/arm920t/start.S.orig 2005-10-06 23:47:43.000000000 +0200 +++ u-boot/cpu/arm920t/start.S 2005-10-13 18:56:27.000000000 +0200 @@ -237,6 +237,7 @@ */ +#ifndef CONFIG_SKIP_LOWLEVEL_INIT cpu_init_crit: /* * flush v4 I/D caches @@ -264,7 +265,7 @@ bl lowlevel_init mov lr, ip mov pc, lr - +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ /* *************************************************************************

1 0

[U-Boot-Users] Flash configuration
by Jose França (Ext_GTBC) 13 Oct '05

13 Oct '05

Hello u all! I'm configuring u-boot (for the first time) so that i can have 2 flash eprom chips, in two different banks, for a mpc8272 based board. They are organized the following way: BOOT Flash -> starts at 0xFFF00000 and has 512KB of size. (read-only) Linux Flash -> starts at 0x50000000 and has 64MB of size. (CFI compatible) Since CFG_FLASH_BASE is used throughout the u-boot code as a reference, which one should it be? The boot flash address or the linux flash address? I'm really confused here... All is setup so that the processor starts to boot from 0xFFF00000 and the reset vector set to 0xFFF00100. Should I use the cfi_flash driver, provided by u-boot? Or should I write a flash.c in my board directory (this is done already)? Do I have to change anything when I use the driver? Thanks in advance! Filipe

3 2

[U-Boot-Users] [Patch] Clean up lvalues in two places for gcc 4.0
by Jerry Van Baren 13 Oct '05

13 Oct '05

Hi Wolfgang, Attached is a patch I did last night (2005-10-12) to fix two places where gcc 4.0 refused to compile due to the lvalue constructs no longer being supported. The patches compile, I have not executed the resulting code: please double-check for correctness. fs/jffs2/compr_rubin.c | 3 ++- net/net.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) ---- Changelog ---- Clean up lvalue issues for gcc 4.0 Patch by Jerry Van Baren, 12 October 2005 Signed-off-by: Jerry Van Baren <gerald.vanbaren(a)smiths-aerospace.com> ---- Best regards, gvb Clean up lvalue issues for gcc 4.0 Patch by Jerry Van Baren, 12 October 2005 --- commit b62be760bf00fe3564dec9ab6da7c8503b1420aa tree 6859adbc0d2ef302dcc4b4a3d5dc7490593235fa parent 3df5bea0b0bddc196bf952c51d1dd54d966b82ba author Jerry Van Baren <vanbaren(a)dellserver.lan> Wed, 12 Oct 2005 21:52:39 -0400 committer Jerry Van Baren <vanbaren(a)dellserver.lan> Wed, 12 Oct 2005 21:52:39 -0400 fs/jffs2/compr_rubin.c | 3 ++- net/net.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/jffs2/compr_rubin.c b/fs/jffs2/compr_rubin.c index cf01f88..c1c28f3 100644 --- a/fs/jffs2/compr_rubin.c +++ b/fs/jffs2/compr_rubin.c @@ -86,7 +86,8 @@ void rubin_do_decompress(unsigned char * rec_q |= (temp >> (bit++ ^ 7)) & 1; if (bit > 31) { bit = 0; - temp = *(++((u32 *) in)); + in += sizeof(u32); + temp = *(u32 *)in; } } i0 = (bits[i] * p) >> 8; diff --git a/net/net.c b/net/net.c index 11b7700..ce2c9a6 100644 --- a/net/net.c +++ b/net/net.c @@ -819,7 +819,8 @@ static ushort CDP_compute_csum(const uch buff++; } while (len > 1) { - result += *((const ushort *)buff)++; + result += *(const ushort *)buff; + buff += sizeof(ushort); if (result & 0x80000000) result = (result & 0xFFFF) + (result >> 16); len -= 2;

2 2

[U-Boot-Users] printf with u-boot-1.1.2
by Shakthi Kannan 13 Oct '05

13 Oct '05

Greetings! I am using u-boot-1.1.2 with CodeSourcery's 3.4.3 cross-toolchain for ARM on the Versatile PB-ARM926EJ-S board. u-boot compiles fine. The hello_world.c in examples/ compiles fine. From the given example, I have removed all statements except the printf statement. It compiles fine. I load it address 04000000 (SDRAM on board, top bank). I execute it using "go 04000000", it runs and exits with rc=0x0. But, I don't see the printf string being printed. Only one character gets printed. I am wondering if printf uses \r after every character gets printed, so it basically overwrites. I am able to display a character, using putc(). getc() also works fine. These work if I load it a SDRAM address, say, 0x05000000, and give the entry point as 05000000 itself (go 05000000). But, the documentation mentions offset 0x4 as entry point. I'd appreciate any feedback on what I am doing wrong and how I can get the printf working. Thanks, SK -- Shakthi Kannan, MS Software Engineer, Specsoft (Hexaware Technologies) [E]: shakthimaan(a)yahoo.com [M]: (91) 98407-87007 [W]: http://www.shakthimaan.com [L]: Chennai, India __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 3

RE: [U-Boot-Users] broken rsync to U-Boot git archive
by Martin Krause 13 Oct '05

13 Oct '05

Hi Bryan, u-boot-users-admin(a)lists.sourceforge.net wrote on : > git clone rsync://source.denx.net/git/u-boot.git somedir > appears to be broken, at least when I tried it just now, I got errors I've done a quick test with cg-clone mkr@tq-sewsrv-4:~/git> cg-clone rsync://source.denx.net/git/u-boot.git u-boot_rsync defaulting to local storage area WARNING: The rsync access method is DEPRECATED and will be REMOVED in the future! receiving file list ... done .git/refs/heads/.origin-fetching sent 94 bytes received 144 bytes 476.00 bytes/sec total size is 41 speedup is 0.17 receiving file list ... done progress: 3428 objects, 17798822 bytes, 100% done info/packs pack/pack-2a2ae5b5d29e02e7330c674195b3423487f83452.idx pack/pack-2a2ae5b5d29e02e7330c674195b3423487f83452.pack pack/pack-a9332d1f4f7916094b9ebeef60378603168d77e2.idx pack/pack-a9332d1f4f7916094b9ebeef60378603168d77e2.pack sent 68739 bytes received 35065972 bytes 32790.21 bytes/sec total size is 34737257 speedup is 0.99 receiving file list ... done LABEL_2002_11_05_0120 [...] U_BOOT_0_1_0 sent 2461 bytes received 11842 bytes 28606.00 bytes/sec total size is 4879 speedup is 0.34 New branch: 0f3f901496b19c46937bfb0ebf142004bd564f1c Cloned to u-boot_rsync/ (origin rsync://source.denx.net/git/u-boot.git available as branch "origin") mkr@tq-sewsrv-4:~/git> Seems to work without problems. > rsync --version == 2.6.5 > git core == 0.99.4 > cogito == 0.13 > OS == Ubuntu Breezy Badger Preview Release I'm using: - git version 0.99.7.GIT - cogito-0.15.1 (b06f2a707963c8712f7a6bbd4b89bae758bcf92a) - rsync version 2.6.3 protocol version 28 - SuSE Linux 9.3 (i586) Regards, Martin

3 2

[U-Boot-Users] Question on pre-loader to U-Boot
by Zhang, Chris (Ex CH01) 13 Oct '05

13 Oct '05

Hello everyone, I am using at91rm9200dk u-boot from ATMEL. I noticed that ATMEL uses programs called loader.bin and boot.bin to load U-Boot into SDRAM. The Load Address is 0x21f00000 (the upper 1M). My question is how does this value is choosen for U-Boot? I guess it is related to linker behavior of U-Boot (right?), but there is no clue to conclude such kind of address. Thanks for any hints. Regards, zl

4 3

[U-Boot-Users] Cleanup of arm920t/start.s
by Paolo Broggini 13 Oct '05

13 Oct '05

Dear all, I would like to cleanup the file cpu/arm920t/start.S by moving the s3c24x0 specific code to their respective boards lowlevel_init.S Are there any particular reasons why this code should stay in start.S ? If I submit a patch, the smdk24x0 boards maintainers (or anybody else) can test it ? (I don't have the HW) Best regards -P.Broggini

2 2

Re: [U-Boot-Users] Debugging U-Boot on arm920t using BDI2000
by Ioritz Irazustabarrena 13 Oct '05

13 Oct '05

In the last post I forgot to tell that I'm porting U-Boot from Motorola's MX1FS2 board (ARM920t). My board's hardware is very similar. I've debugged U-Boot on SDRAM using BDI2000 to copy the image to SDRAM, but the bootloader doesn't work when it starts from flash, so the problem is on the relocation of code. As I said on the last post, I can't debug the relocation code. Some configuration parameters and addresses: SDRAM: 32 bit bus 32MB: 0x08000000-0x0A000000 FLASH: 16 bit bus 16MB: 0x10000000-0x11000000 TEXT_BASE = 0x8f00000 CFG_MONITOR_BASE=CFG_FLASH_BASE 0x10000000 arm-linux-objdump -D u-boot: 08f00000 <_start>: 8f00000: ea000012 b 8f00050 <reset> ... arm-linux-objdump -h u-boot: u-boot: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 000138a4 08f00000 08f00000 00008000 2**5 ... As I concluded in the previous post, it seems that the binary it's only compiled to be run from sdram, not from flash because LMA is 0x8f00000 but I think it should be 0x0000 or 0x10000000. Is this correct? Any help will be appreciated! Thanks in advance. Best regards. Ioritz _________________________________________________________________ Dale rienda suelta a tu tiempo libre. Encuentra mil ideas para exprimir tu ocio con MSN Entretenimiento. http://entretenimiento.msn.es/

1 0

[U-Boot-Users] [PATCH] eliminate assumptions about dataflash layout
by Anders Larsen 13 Oct '05

13 Oct '05

Hi, the dataflash driver contains a hard-coded partition table which might suit one particular board (which I doubt, however) but certainly isn't generally applicable. Furthermore, it write-protects the first two partitions, which violates the U-Boot standard of allowing the user enough rope to shoot himself in the foot. Besides, the dataflash partitions aren't even on sector boundaries (the dataflash chips have rather unusual sector sizes; 528 or 1056 bytes, which makes one wonder what the folks at Atmel are smoking). The patch below places the entire dataflash in one (writable) partition. Cheers Anders Signed-off-by: Anders Larsen <alarsen(a)rea.de> CHANGELOG: Don't write-protect arbitrary areas of Atmel dataflash Patch by Anders Larsen, 13 Oct 2005 --- drivers/dataflash.c | 7 ++----- include/dataflash.h | 4 ++-- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/dataflash.c b/drivers/dataflash.c index ded0395..a558dba 100644 --- a/drivers/dataflash.c +++ b/drivers/dataflash.c @@ -33,10 +33,7 @@ int cs[][CFG_MAX_DATAFLASH_BANKS] = { /*define the area offsets*/ dataflash_protect_t area_list[NB_DATAFLASH_AREA] = { - {0, 0x7fff, FLAG_PROTECT_SET}, /* ROM code */ - {0x8000, 0x1ffff, FLAG_PROTECT_SET}, /* u-boot code */ - {0x20000, 0x27fff, FLAG_PROTECT_CLEAR}, /* u-boot environment */ - {0x28000, 0x1fffff, FLAG_PROTECT_CLEAR}, /* data area size to tune */ + {0, 0x1fffff, FLAG_PROTECT_CLEAR}, /* size tuned below */ }; extern void AT91F_SpiInit (void); @@ -110,7 +107,7 @@ int AT91F_DataflashInit (void) break; } /* set the last area end to the dataflash size*/ - area_list[NB_DATAFLASH_AREA -1].end = + area_list[NB_DATAFLASH_AREA-1].end = (dataflash_info[i].Device.pages_number * dataflash_info[i].Device.pages_size)-1; diff --git a/include/dataflash.h b/include/dataflash.h index 650454e..825eec6 100644 --- a/include/dataflash.h +++ b/include/dataflash.h @@ -37,8 +37,8 @@ #include <asm/arch/hardware.h> #include "config.h" -/*number of protected area*/ -#define NB_DATAFLASH_AREA 4 +/*number of areas*/ +#define NB_DATAFLASH_AREA 1 /*define the area structure*/ typedef struct {

1 0

[U-Boot-Users] [PATCH] Add Flat OF tree support.
by Pantelis Antoniou 13 Oct '05

13 Oct '05

Hi all. As you well know, as part of the ongoing cleanup of the linux trees regarding PPC, it has been decreed that the preferred way to pass bootloader information shall be the flat OF tree. http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019408.html http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019362.html The following patch (broken in two parts), implements just that. Please be aware that in order to test it, you'll need a fairly recent dtc tool, which is available by git at rsync://ozlabs.org/dtc/dtc.git The xxd binary dumper is needed too which I got from ftp://ftp.uni-erlangen.de/pub/utilities/etc/xxd-1.10.tar.gz Linux patches will follow... Awaiting comments. Regards Pantelis P.S. Sorry for cross-posting, but it seems to be appropriate at this time. diff --git a/common/Makefile b/common/Makefile --- a/common/Makefile +++ b/common/Makefile @@ -51,7 +51,7 @@ COBJS = main.o ACEX1K.o altera.o bedbug. memsize.o miiphybb.o miiphyutil.o \ s_record.o serial.o soft_i2c.o soft_spi.o spartan2.o \ usb.o usb_kbd.o usb_storage.o \ - virtex2.o xilinx.o + virtex2.o xilinx.o ft_build.o OBJS = $(AOBJS) $(COBJS) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -34,6 +34,10 @@ #include <environment.h> #include <asm/byteorder.h> +#ifdef CONFIG_OF_FLAT_TREE +#include <ft_build.h> +#endif + /*cmd_boot.c*/ extern int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]); @@ -487,6 +491,9 @@ fixup_silent_linux () } #endif /* CONFIG_SILENT_CONSOLE */ +extern const unsigned char oftree_dtb[]; +extern const unsigned int oftree_dtb_len; + #ifdef CONFIG_PPC static void do_bootm_linux (cmd_tbl_t *cmdtp, int flag, @@ -509,6 +516,9 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl bd_t *kbd; void (*kernel)(bd_t *, ulong, ulong, ulong, ulong); image_header_t *hdr = &header; +#ifdef CONFIG_OF_FLAT_TREE + char *of_flat_tree; +#endif if ((s = getenv ("initrd_high")) != NULL) { /* a value of "no" or a similar string will act like 0, @@ -773,16 +783,24 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl initrd_start = 0; initrd_end = 0; } - +#ifdef CONFIG_OF_FLAT_TREE + if (initrd_start == 0) + of_flat_tree = (char *)(((ulong)kbd - OF_FLAT_TREE_MAX_SIZE) & ~0xF); + else + of_flat_tree = (char *)((initrd_start - OF_FLAT_TREE_MAX_SIZE) & ~0xF); +#endif debug ("## Transferring control to Linux (at address %08lx) ...\n", (ulong)kernel); SHOW_BOOT_PROGRESS (15); +#ifndef CONFIG_OF_FLAT_TREE + #if defined(CFG_INIT_RAM_LOCK) && !defined(CONFIG_E500) unlock_ram_in_cache(); #endif + /* * Linux Kernel Parameters: * r3: ptr to board info data @@ -792,6 +810,25 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl * r7: End of command line string */ (*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end); +#else + + ft_setup(of_flat_tree, OF_FLAT_TREE_MAX_SIZE, kbd); + /* ft_dump_blob(of_flat_tree); */ + +#if defined(CFG_INIT_RAM_LOCK) && !defined(CONFIG_E500) + unlock_ram_in_cache(); +#endif + /* + * Linux Kernel Parameters: + * r3: ptr to board info data + * r4: initrd_start or 0 if no initrd + * r5: initrd_end - unused if r4 is 0 + * r6: Start of command line string + * r7: End of command line string + */ + (*kernel) ((bd_t *)of_flat_tree, initrd_start, initrd_end, cmd_start, cmd_end); + +#endif } #endif /* CONFIG_PPC */ diff --git a/common/ft_build.c b/common/ft_build.c new file mode 100644 --- /dev/null +++ b/common/ft_build.c @@ -0,0 +1,751 @@ +/* + * OF flat tree builder + */ + +#include <common.h> +#include <malloc.h> +#include <environment.h> + +#include <asm/errno.h> + +#include <ft_build.h> + +#ifdef CONFIG_OF_FLAT_TREE + +/* align addr on a size boundary - adjust address up if needed -- Cort */ +#define _ALIGN(addr,size) (((addr)+(size)-1)&(~((size)-1))) + +static void ft_put_word(struct ft_cxt *cxt, u32 v) +{ + if (cxt->overflow) /* do nothing */ + return; + + /* check for overflow */ + if (cxt->p + 4 > cxt->pstr) { + cxt->overflow = 1; + return; + } + + *(u32 *) cxt->p = cpu_to_be32(v); + cxt->p += 4; +} + +static inline void ft_put_bin(struct ft_cxt *cxt, const void *data, int sz) +{ + u8 *p; + + if (cxt->overflow) /* do nothing */ + return; + + /* next pointer pos */ + p = (u8 *) _ALIGN((unsigned long)cxt->p + sz, 4); + + /* check for overflow */ + if (p > cxt->pstr) { + cxt->overflow = 1; + return; + } + + memcpy(cxt->p, data, sz); + if ((sz & 3) != 0) + memset(cxt->p + sz, 0, 4 - (sz & 3)); + cxt->p = p; +} + +void ft_begin_node(struct ft_cxt *cxt, const char *name) +{ + ft_put_word(cxt, OF_DT_BEGIN_NODE); + ft_put_bin(cxt, name, strlen(name) + 1); +} + +void ft_end_node(struct ft_cxt *cxt) +{ + ft_put_word(cxt, OF_DT_END_NODE); +} + +void ft_nop(struct ft_cxt *cxt) +{ + ft_put_word(cxt, OF_DT_NOP); +} + +static int lookup_string(struct ft_cxt *cxt, const char *name) +{ + u8 *p; + + p = cxt->pstr; + while (p < cxt->pstr_begin) { + if (strcmp(p, name) == 0) + return p - cxt->p_begin; + p += strlen(p) + 1; + } + + return -1; +} + +void ft_prop(struct ft_cxt *cxt, const char *name, const void *data, int sz) +{ + int len, off; + + if (cxt->overflow) + return; + + len = strlen(name) + 1; + + off = lookup_string(cxt, name); + if (off == -1) { + /* check if we have space */ + if (cxt->p + 12 + sz + len > cxt->pstr) { + cxt->overflow = 1; + return; + } + + cxt->pstr -= len; + memcpy(cxt->pstr, name, len); + off = cxt->pstr - cxt->p_begin; + } + + /* now put offset from beginning of *STRUCTURE* */ + /* will be fixed up at the end */ + ft_put_word(cxt, OF_DT_PROP); + ft_put_word(cxt, sz); + ft_put_word(cxt, off); + ft_put_bin(cxt, data, sz); +} + +void ft_prop_str(struct ft_cxt *cxt, const char *name, const char *str) +{ + ft_prop(cxt, name, str, strlen(str) + 1); +} + +void ft_prop_int(struct ft_cxt *cxt, const char *name, int val) +{ + u32 v = cpu_to_be32((u32) val); + + ft_prop(cxt, name, &v, 4); +} + +/* start construction of the flat OF tree */ +void ft_begin(struct ft_cxt *cxt, void *blob, int max_size) +{ + struct boot_param_header *bph = blob; + u32 off; + + /* clear the cxt */ + memset(cxt, 0, sizeof(*cxt)); + + cxt->bph = bph; + cxt->max_size = max_size; + + /* zero everything in the header area */ + memset(bph, 0, sizeof(*bph)); + + bph->magic = cpu_to_be32(OF_DT_HEADER); + bph->version = cpu_to_be32(0x10); + bph->last_comp_version = cpu_to_be32(0x10); + + /* start pointers */ + cxt->pres_begin = (u8 *) _ALIGN((unsigned long)(bph + 1), 8); + cxt->pres = cxt->pres_begin; + + off = (unsigned long)cxt->pres_begin - (unsigned long)bph; + bph->off_mem_rsvmap = cpu_to_be32(off); + + ((u64 *) cxt->pres)[0] = 0; /* phys = 0, size = 0, terminate */ + ((u64 *) cxt->pres)[1] = 0; + + cxt->p_anchor = cxt->pres + 16; /* over the terminator */ +} + +/* add a reserver physical area to the rsvmap */ +void ft_add_rsvmap(struct ft_cxt *cxt, u64 physaddr, u64 size) +{ + ((u64 *) cxt->pres)[0] = cpu_to_be64(physaddr); /* phys = 0, size = 0, terminate */ + ((u64 *) cxt->pres)[1] = cpu_to_be64(size); + + cxt->pres += 18; /* advance */ + + ((u64 *) cxt->pres)[0] = 0; /* phys = 0, size = 0, terminate */ + ((u64 *) cxt->pres)[1] = 0; + + /* keep track of size */ + cxt->res_size = cxt->pres + 16 - cxt->pres_begin; + + cxt->p_anchor = cxt->pres + 16; /* over the terminator */ +} + +void ft_begin_tree(struct ft_cxt *cxt) +{ + cxt->p_begin = cxt->p_anchor; + cxt->pstr_begin = (char *)cxt->bph + cxt->max_size; /* point at the end */ + + cxt->p = cxt->p_begin; + cxt->pstr = cxt->pstr_begin; +} + +int ft_end_tree(struct ft_cxt *cxt) +{ + struct boot_param_header *bph = cxt->bph; + int off, sz, sz1; + u32 tag, v; + u8 *p; + + ft_put_word(cxt, OF_DT_END); + + if (cxt->overflow) + return -ENOMEM; + + /* size of the areas */ + cxt->struct_size = cxt->p - cxt->p_begin; + cxt->strings_size = cxt->pstr_begin - cxt->pstr; + + /* the offset we must move */ + off = (cxt->pstr_begin - cxt->p_begin) - cxt->strings_size; + + /* the new strings start */ + cxt->pstr_begin = cxt->p_begin + cxt->struct_size; + + /* move the whole string area */ + memmove(cxt->pstr_begin, cxt->pstr, cxt->strings_size); + + /* now perform the fixup of the strings */ + p = cxt->p_begin; + while ((tag = be32_to_cpu(*(u32 *) p)) != OF_DT_END) { + p += 4; + + if (tag == OF_DT_BEGIN_NODE) { + p = (u8 *) _ALIGN((unsigned long)p + strlen(p) + 1, 4); + continue; + } + + if (tag == OF_DT_END_NODE || tag == OF_DT_NOP) + continue; + + if (tag != OF_DT_PROP) + return -EINVAL; + + sz = be32_to_cpu(*(u32 *) p); + p += 4; + + v = be32_to_cpu(*(u32 *) p); + v -= off; + *(u32 *) p = cpu_to_be32(v); /* move down */ + p += 4; + + p = (u8 *) _ALIGN((unsigned long)p + sz, 4); + } + + /* fix sizes */ + p = (char *)cxt->bph; + sz = (cxt->pstr_begin + cxt->strings_size) - p; + sz1 = _ALIGN(sz, 16); /* align at 16 bytes */ + if (sz != sz1) + memset(p + sz, 0, sz1 - sz); + bph->totalsize = cpu_to_be32(sz1); + bph->off_dt_struct = cpu_to_be32(cxt->p_begin - p); + bph->off_dt_strings = cpu_to_be32(cxt->pstr_begin - p); + + /* the new strings start */ + cxt->pstr_begin = cxt->p_begin + cxt->struct_size; + cxt->pstr = cxt->pstr_begin + cxt->strings_size; + + return 0; +} + +/**********************************************************************/ + +static inline int isprint(int c) +{ + return c >= 0x20 && c <= 0x7e; +} + +static int is_printable_string(const void *data, int len) +{ + const char *s = data; + const char *ss; + + /* zero length is not */ + if (len == 0) + return 0; + + /* must terminate with zero */ + if (s[len - 1] != '\0') + return 0; + + ss = s; + while (*s && isprint(*s)) + s++; + + /* not zero, or not done yet */ + if (*s != '\0' || (s + 1 - ss) < len) + return 0; + + return 1; +} + +static void print_data(const void *data, int len) +{ + int i; + const u8 *s; + + /* no data, don't print */ + if (len == 0) + return; + + if (is_printable_string(data, len)) { + printf(" = \"%s\"", (char *)data); + return; + } + + switch (len) { + case 1: /* byte */ + printf(" = <0x%02x>", (*(u8 *) data) & 0xff); + break; + case 2: /* half-word */ + printf(" = <0x%04x>", be16_to_cpu(*(u16 *) data) & 0xffff); + break; + case 4: /* word */ + printf(" = <0x%08x>", be32_to_cpu(*(u32 *) data) & 0xffffffffU); + break; + case 8: /* double-word */ + printf(" = <0x%16llx>", be64_to_cpu(*(uint64_t *) data)); + break; + default: /* anything else... hexdump */ + printf(" = ["); + for (i = 0, s = data; i < len; i++) + printf("%02x%s", s[i], i < len - 1 ? " " : ""); + printf("]"); + + break; + } +} + +void ft_dump_blob(const void *bphp) +{ + const struct boot_param_header *bph = bphp; + const uint64_t *p_rsvmap = (const uint64_t *) + ((const char *)bph + be32_to_cpu(bph->off_mem_rsvmap)); + const u32 *p_struct = (const u32 *) + ((const char *)bph + be32_to_cpu(bph->off_dt_struct)); + const u32 *p_strings = (const u32 *) + ((const char *)bph + be32_to_cpu(bph->off_dt_strings)); + u32 tag; + const u32 *p; + const char *s, *t; + int depth, sz, shift; + int i; + uint64_t addr, size; + + depth = 0; + shift = 4; + + for (i = 0;; i++) { + addr = be64_to_cpu(p_rsvmap[i * 2]); + size = be64_to_cpu(p_rsvmap[i * 2 + 1]); + if (addr == 0 && size == 0) + break; + + printf("/memreserve/ 0x%llx 0x%llx;\n", addr, size); + } + + p = p_struct; + while ((tag = be32_to_cpu(*p++)) != OF_DT_END) { + + /* printf("tag: 0x%08x (%d)\n", tag, p - p_struct); */ + + if (tag == OF_DT_BEGIN_NODE) { + s = (const char *)p; + p = (u32 *) _ALIGN((unsigned long)p + strlen(s) + 1, 4); + + printf("%*s%s {\n", depth * shift, "", s); + + depth++; + continue; + } + + if (tag == OF_DT_END_NODE) { + depth--; + + printf("%*s};\n", depth * shift, ""); + continue; + } + + if (tag == OF_DT_NOP) { + printf("%*s[NOP]\n", depth * shift, ""); + continue; + } + + if (tag != OF_DT_PROP) { + fprintf(stderr, "%*s ** Unknown tag 0x%08x\n", + depth * shift, "", tag); + break; + } + sz = be32_to_cpu(*p++); + s = (const char *)p_strings + be32_to_cpu(*p++); + t = (const char *)p; + p = (const u32 *)_ALIGN((unsigned long)p + sz, 4); + printf("%*s%s", depth * shift, "", s); + print_data(t, sz); + printf(";\n"); + } +} + +void ft_backtrack_node(struct ft_cxt *cxt) +{ + if (be32_to_cpu(*(u32 *) (cxt->p - 4)) != OF_DT_END_NODE) + return; /* XXX only for node */ + + cxt->p -= 4; +} + +/* note that the root node of the blob is "peeled" off */ +void ft_merge_blob(struct ft_cxt *cxt, void *blob) +{ + struct boot_param_header *bph = (struct boot_param_header *)blob; + u32 *p_struct = (u32 *) ((char *)bph + be32_to_cpu(bph->off_dt_struct)); + u32 *p_strings = + (u32 *) ((char *)bph + be32_to_cpu(bph->off_dt_strings)); + u32 tag, *p; + char *s, *t; + int depth, sz; + + if (be32_to_cpu(*(u32 *) (cxt->p - 4)) != OF_DT_END_NODE) + return; /* XXX only for node */ + + cxt->p -= 4; + + depth = 0; + p = p_struct; + while ((tag = be32_to_cpu(*p++)) != OF_DT_END) { + + /* printf("tag: 0x%08x (%d) - %d\n", tag, p - p_struct, depth); */ + + if (tag == OF_DT_BEGIN_NODE) { + s = (char *)p; + p = (u32 *) _ALIGN((unsigned long)p + strlen(s) + 1, 4); + + if (depth++ > 0) + ft_begin_node(cxt, s); + + continue; + } + + if (tag == OF_DT_END_NODE) { + ft_end_node(cxt); + if (--depth == 0) + break; + continue; + } + + if (tag == OF_DT_NOP) + continue; + + if (tag != OF_DT_PROP) + break; + + sz = be32_to_cpu(*p++); + s = (char *)p_strings + be32_to_cpu(*p++); + t = (char *)p; + p = (u32 *) _ALIGN((unsigned long)p + sz, 4); + + ft_prop(cxt, s, t, sz); + } +} + +void *ft_get_prop(void *bphp, const char *propname, int *szp) +{ + struct boot_param_header *bph = bphp; + uint32_t *p_struct = + (uint32_t *) ((char *)bph + be32_to_cpu(bph->off_dt_struct)); + uint32_t *p_strings = + (uint32_t *) ((char *)bph + be32_to_cpu(bph->off_dt_strings)); + uint32_t version = be32_to_cpu(bph->version); + uint32_t tag; + uint32_t *p; + char *s, *t; + char *ss; + int sz; + static char path[256], prop[256]; + + path[0] = '\0'; + + p = p_struct; + while ((tag = be32_to_cpu(*p++)) != OF_DT_END) { + + if (tag == OF_DT_BEGIN_NODE) { + s = (char *)p; + p = (uint32_t *) _ALIGN((unsigned long)p + strlen(s) + + 1, 4); + strcat(path, s); + strcat(path, "/"); + continue; + } + + if (tag == OF_DT_END_NODE) { + path[strlen(path) - 1] = '\0'; + ss = strrchr(path, '/'); + if (ss != NULL) + ss[1] = '\0'; + continue; + } + + if (tag == OF_DT_NOP) + continue; + + if (tag != OF_DT_PROP) + break; + + sz = be32_to_cpu(*p++); + s = (char *)p_strings + be32_to_cpu(*p++); + if (version < 0x10 && sz >= 8) + p = (uint32_t *) _ALIGN((unsigned long)p, 8); + t = (char *)p; + p = (uint32_t *) _ALIGN((unsigned long)p + sz, 4); + + strcpy(prop, path); + strcat(prop, s); + + if (strcmp(prop, propname) == 0) { + *szp = sz; + return t; + } + } + + return NULL; +} + +/********************************************************************/ + +extern unsigned char oftree_dtb[]; +extern unsigned int oftree_dtb_len; + +/* Function that returns a character from the environment */ +extern uchar(*env_get_char) (int); + +void ft_setup(void *blob, int size, bd_t * bd) +{ + DECLARE_GLOBAL_DATA_PTR; + u8 *end; + u32 *p; + int len; + struct ft_cxt cxt; + int i, k, nxt; + static char tmpenv[256]; + char *s, *lval, *rval; + ulong clock; + + ft_begin(&cxt, blob, size); + + /* fs_add_rsvmap not used */ + + ft_begin_tree(&cxt); + + ft_begin_node(&cxt, ""); + + ft_end_node(&cxt); + + /* copy RO tree */ + ft_merge_blob(&cxt, oftree_dtb); + + /* back into root */ + ft_backtrack_node(&cxt); + + ft_begin_node(&cxt, "u-boot-env"); + + for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) { + for (nxt = i; env_get_char(nxt) != '\0'; ++nxt) ; + s = tmpenv; + for (k = i; k < nxt && s < &tmpenv[sizeof(tmpenv) - 1]; ++k) + *s++ = env_get_char(k); + *s++ = '\0'; + lval = tmpenv; + s = strchr(tmpenv, '='); + if (s != NULL) { + *s++ = '\0'; + rval = s; + } else + continue; + ft_prop_str(&cxt, lval, rval); + } + + ft_end_node(&cxt); + + ft_begin_node(&cxt, "chosen"); + + ft_prop_str(&cxt, "name", "chosen"); + ft_prop_str(&cxt, "bootargs", getenv("bootargs")); + ft_prop_int(&cxt, "linux,platform", 0x600); /* what is this? */ + + ft_end_node(&cxt); + + ft_end_node(&cxt); /* end root */ + + ft_end_tree(&cxt); + + /* + printf("merged OF-tree\n"); + ft_dump_blob(blob); + */ + + /* paste the bd_t at the end of the flat tree */ + end = (char *)blob + + be32_to_cpu(((struct boot_param_header *)blob)->totalsize); + memcpy(end, bd, sizeof(*bd)); + +#ifdef __powerpc__ + + p = ft_get_prop(blob, "/u-boot-bd_t/memstart", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_memstart); + + p = ft_get_prop(blob, "/u-boot-bd_t/memsize", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_memsize); + + p = ft_get_prop(blob, "/u-boot-bd_t/flashstart", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_flashstart); + + p = ft_get_prop(blob, "/u-boot-bd_t/flashsize", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_flashsize); + + p = ft_get_prop(blob, "/u-boot-bd_t/flashoffset", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_flashoffset); + + p = ft_get_prop(blob, "/u-boot-bd_t/sramstart", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_sramstart); + + p = ft_get_prop(blob, "/u-boot-bd_t/sramsize", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_sramsize); + +#if defined(CONFIG_5xx) || defined(CONFIG_8xx) || defined(CONFIG_8260) \ + || defined(CONFIG_E500) + p = ft_get_prop(blob, "/u-boot-bd_t/immr_base", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_immr_base); +#endif + +#if defined(CONFIG_MPC5xxx) + p = ft_get_prop(blob, "/u-boot-bd_t/mbar_base", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_mbar_base); +#endif + +#if defined(CONFIG_MPC83XX) + p = ft_get_prop(blob, "/u-boot-bd_t/immrbar", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_immrbar); +#endif + +#if defined(CONFIG_MPC8220) + p = ft_get_prop(blob, "/u-boot-bd_t/mbar_base", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_mbar_base); + + p = ft_get_prop(blob, "/u-boot-bd_t/inpfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_nipfreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/pcifreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_pcifreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/pevfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_pevfreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/flbfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_flbfreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/vcofreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_vcofreq); +#endif + + p = ft_get_prop(blob, "/u-boot-bd_t/bootflags", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_bootflags); + + p = ft_get_prop(blob, "/u-boot-bd_t/ip_addr", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_ip_addr); + + p = ft_get_prop(blob, "/u-boot-bd_t/enetaddr", &len); + if (p != NULL) + memcpy(p, bd->bi_enetaddr, 6); + + p = ft_get_prop(blob, "/u-boot-bd_t/ethspeed", &len); + if (p != NULL) + *p = cpu_to_be32((uint32_t) bd->bi_ethspeed); + + p = ft_get_prop(blob, "/u-boot-bd_t/intfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_intfreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/busfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_busfreq); + +#ifdef CONFIG_CPM2 + + p = ft_get_prop(blob, "/u-boot-bd_t/cpmfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_cpmfreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/brgfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_brgfreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/sccfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_sccfreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/vco", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_vco); +#endif + +#if defined(CONFIG_MPC5xxx) + + p = ft_get_prop(blob, "/u-boot-bd_t/ipbfreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_ipbfreq); + + p = ft_get_prop(blob, "/u-boot-bd_t/pcifreq", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_pcifreq); +#endif + + p = ft_get_prop(blob, "/u-boot-bd_t/baudrate", &len); + if (p != NULL) + *p = cpu_to_be32(bd->bi_baudrate); + +#if defined(CONFIG_8xx) + clock = gd->cpu_clk; +#elif defined(CONFIG_8260) + clock = gd->brg_clk; +#else + clock = 0; +#endif + p = ft_get_prop(blob, "/cpus/" OF_CPU "/clock-frequency", &len); + if (p != NULL) + *p = cpu_to_be32(clock); + + p = ft_get_prop(blob, "/cpus/" OF_CPU "/timebase-frequency", &len); + if (p != NULL) + *p = cpu_to_be32(clock / 4); /* XXX I'm just guessing */ + +#endif /* __powerpc__ */ + + /* + printf("final OF-tree\n"); + ft_dump_blob(blob); + */ + +} + +#endif diff --git a/include/ft_build.h b/include/ft_build.h new file mode 100644 --- /dev/null +++ b/include/ft_build.h @@ -0,0 +1,66 @@ +/* + * OF Flat tree builder + * + */ + +#ifndef FT_BUILD_H +#define FT_BUILD_H + +#include <linux/types.h> +#include <asm/u-boot.h> + +/* Definitions used by the flattened device tree */ +#define OF_DT_HEADER 0xd00dfeed /* marker */ +#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */ +#define OF_DT_END_NODE 0x2 /* End node */ +#define OF_DT_PROP 0x3 /* Property: name off, size, + * content */ +#define OF_DT_NOP 0x4 /* nop */ +#define OF_DT_END 0x9 + +#define OF_DT_VERSION 0x10 + +struct boot_param_header { + u32 magic; /* magic word OF_DT_HEADER */ + u32 totalsize; /* total size of DT block */ + u32 off_dt_struct; /* offset to structure */ + u32 off_dt_strings; /* offset to strings */ + u32 off_mem_rsvmap; /* offset to memory reserve map */ + u32 version; /* format version */ + u32 last_comp_version; /* last compatible version */ + /* version 2 fields below */ + u32 boot_cpuid_phys; /* Physical CPU id we're booting on */ + /* version 3 fields below */ + u32 dt_strings_size; /* size of the DT strings block */ +}; + +struct ft_cxt { + struct boot_param_header *bph; + int max_size; /* maximum size of tree */ + int overflow; /* set when this happens */ + u8 *p, *pstr, *pres; /* running pointers */ + u8 *p_begin, *pstr_begin, *pres_begin; /* starting pointers */ + u8 *p_anchor; /* start of constructed area */ + int struct_size, strings_size, res_size; +}; + +void ft_begin_node(struct ft_cxt *cxt, const char *name); +void ft_end_node(struct ft_cxt *cxt); + +void ft_begin_tree(struct ft_cxt *cxt); +int ft_end_tree(struct ft_cxt *cxt); + +void ft_nop(struct ft_cxt *cxt); +void ft_prop(struct ft_cxt *cxt, const char *name, const void *data, int sz); +void ft_prop_str(struct ft_cxt *cxt, const char *name, const char *str); +void ft_prop_int(struct ft_cxt *cxt, const char *name, int val); +void ft_begin(struct ft_cxt *cxt, void *blob, int max_size); +void ft_add_rsvmap(struct ft_cxt *cxt, u64 physaddr, u64 size); + +void ft_setup(void *blob, int size, bd_t * bd); + +void ft_dump_blob(const void *bphp); +void ft_merge_blob(struct ft_cxt *cxt, void *blob); +void *ft_get_prop(void *bphp, const char *propname, int *szp); + +#endif diff --git a/board/stxxtc/Makefile b/board/stxxtc/Makefile --- a/board/stxxtc/Makefile +++ b/board/stxxtc/Makefile @@ -25,11 +25,19 @@ include $(TOPDIR)/config.mk LIB = lib$(BOARD).a -OBJS = $(BOARD).o +OBJS = $(BOARD).o oftree.o $(LIB): .depend $(OBJS) $(AR) crv $@ $(OBJS) +%.dtb: %.dts + dtc -f -V 0x10 -I dts -O dtb $< >$@ + +%.c: %.dtb + xxd -i $< \ + | sed -e "s/^unsigned char/const unsigned char/g" \ + | sed -e "s/^unsigned int/const unsigned int/g" > $@ + ######################################################################### .depend: Makefile $(SOBJS:.o=.S) $(OBJS:.o=.c) @@ -38,3 +46,4 @@ $(LIB): .depend $(OBJS) sinclude .depend ######################################################################### + diff --git a/board/stxxtc/oftree.dts b/board/stxxtc/oftree.dts new file mode 100644 --- /dev/null +++ b/board/stxxtc/oftree.dts @@ -0,0 +1,52 @@ +/ { + model = "STXXTC V1"; + compatible = "STXXTC"; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + linux,phandle = <1>; + #address-cells = <1>; + #size-cells = <0>; + PowerPC,MPC870@0 { + linux,phandle = <3>; + name = "PowerPC,MPC870"; + device_type = "cpu"; + reg = <0>; + clock-frequency = <0>; /* place-holder for runtime fillup */ + timebase-frequency = <0>; /* dido */ + linux,boot-cpu; + i-cache-size = <2000>; + d-cache-size = <2000>; + 32-bit; + }; + }; + + memory@0 { + device_type = "memory"; + reg = <00000000 00000000 00000000 20000000>; + }; + + /* copy of the bd_t information (place-holders) */ + u-boot-bd_t { + memstart = <0>; + memsize = <0>; + flashstart = <0>; + flashsize = <0>; + flashoffset = <0>; + sramstart = <0>; + sramsize = <0>; + + immr_base = <0>; + + bootflags = <0>; + ip_addr = <0>; + enetaddr = [ 00 00 00 00 00 00 ]; + ethspeed = <0>; + intfreq = <0>; + busfreq = <0>; + + baudrate = <0>; + }; + +}; diff --git a/board/stxxtc/stxxtc.c b/board/stxxtc/stxxtc.c --- a/board/stxxtc/stxxtc.c +++ b/board/stxxtc/stxxtc.c @@ -38,6 +38,13 @@ #include <watchdog.h> #endif +#include <ft_build.h> + +/****************************************************************/ + +extern const unsigned char oftree_dtb[]; +extern const unsigned int oftree_dtb_len; + /****************************************************************/ /* some sane bit macros */ diff --git a/include/configs/stxxtc.h b/include/configs/stxxtc.h --- a/include/configs/stxxtc.h +++ b/include/configs/stxxtc.h @@ -574,19 +574,14 @@ typedef unsigned int led_id_t; #define CONFIG_CRC32_VERIFY 1 #define CONFIG_HUSH_OLD_PARSER_COMPATIBLE 1 -/* Note: change below for your network setting!!! - * This was done just to facilitate manufacturing test and configuration. - */ -#define CONFIG_ETHADDR 00:e0:0c:07:9b:8a +/*****************************************************************************/ -#define CONFIG_SERVERIP 192.168.08.1 -#define CONFIG_IPADDR 192.168.08.85 -#define CONFIG_GATEWAYIP 192.168.08.1 -#define CONFIG_NETMASK 255.255.255.0 -#define CONFIG_HOSTNAME stx_xtc -#define CONFIG_ROOTPATH /xtcroot -#define CONFIG_BOOTFILE uImage -#define CONFIG_LOADADDR 0x1000000 +/* pass open firmware flat tree */ +#define CONFIG_OF_FLAT_TREE 1 +/* maximum size of the flat tree (8K) */ +#define OF_FLAT_TREE_MAX_SIZE 8192 + +#define OF_CPU "PowerPC,MPC870@0" #endif /* __CONFIG_H */

2 9

[U-Boot-Users] Question on multiple images stored in a table...
by sjhill＠realitydiluted.com 12 Oct '05

12 Oct '05

Greetings. I apologize if this has been discussed previously. The mailing list search function was painful for me. My question has to do with how the 'image_header_t' defined in 'include/image.h' is used. For my application, I want a list all of the images present in my system to be available at boot time such that I do not have do a 'imls' command to know where and what all of my images are my system. I would like to create an array of 'image_header_t' structures in flash that I would burn with my U-Boot image. During boot, I would read an I/O pin requesting that a certain image be booted independent of where it is located in flash memory. Has anyone done something similar to this? Thanks. -Steve

2 1

Re: [U-Boot-Users] Re: Problem building U-Boot for ARM target
by Paolo Broggini 12 Oct '05

12 Oct '05

Peter Pearse ha scritto: > Paolo Broggini wrote: > >>Now the questions are: >>1) Why the CFLAGS is in the macro since cc-option should check the >> compiler support for a particular option? Indeed the cc-option >> contained in config.mk is exactly the same as theone contained in >>linux kernel 2.6.x makefile. > > Because I cut and pasted it without thinking, and it worked for me > - $(CFLAGS) should be dropped. > I've added it to my todo list, you're welcome to submit a patch. I'll do it. Thanks again. -P.Broggini

1 0

Re: [U-Boot-Users] Re: Problem building U-Boot for ARM target
by Paolo Broggini 12 Oct '05

12 Oct '05

Peter Pearse ha scritto: > > No question is stupid - just giving you the info. I mean, it is quite obvious that it works by you (... and probably by a lot of other people to) > > Depends how much time you have available to sort the bug.... > Sometimes it's worth it in the long run. Definitely! but I'm far to be a "guru" in the make stuff. >>I tried the macro cc-option "by hand" (so without $CFLAGS) in a bash >> >> shell and I got the same results as above, i.e. the check > for option >> -mapcs-32 fails but the compiler support it and indeed the compilation >> works fine! May be a bug? Sorry forget about this I was making a mistake :-( The script suggested by Catalin works perfectly either in a bash or a sh shell. On the other hand, the U-Boot build process fails in both shell. So I have investigated a little bit the macro cc-option: cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \ > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;) I tried to drop the CFLAGS variable from the macro: cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null \ > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;) and the build process worked fine i.e. the check for -mapcs-32 was OK. Next step, in order to see the content of CFLAGS, I modified the macro as: cc-option = $(shell echo "$(CFLAGS)" > ./flags.txt; if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \ > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;) and this revealed that among a lot of other otions it contains the failing option -mabi=apcs-gnu !!! But this option is not set by anybody else just by: PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) So it is obvious why cc-option returns the wrong option! Now the questions are: 1) Why the CFLAGS is in the macro since cc-option should check the compiler support for a particular option? Indeed the cc-option contained in config.mk is exactly the same as theone contained in linux kernel 2.6.x makefile. 2) How is it possible that CFLAGS contains the failing option since $(call cc-option,-mapcs-32,-mabi=apcs-gnu) is not yet processed and not set by anybody else? 3) Why if I replace -mapcs-32 with -g everything works fine? I wish I never tried that!! Please Peter or Catalin since your compiler support both -mapcs-32 and -mabi=apcs-gnu options could you try the following? PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mfoo) Thanks for your patience! -P.Broggini

1 0

[U-Boot-Users] i.MX support for scb9328 cleaned up
by Konstantin Kletschke 12 Oct '05

12 Oct '05

I cleaned up board support for the scb9328 board. I did changes to the scb9328.h, it is very much more readable more. Many timings have been tuned, the system is much faster now. Also the board/scb9328/flash.c is removed, the patch will delete it! The cfi_flash.c is used now. If anybody is interested, it is at http://www.ludenkalle.de/u-boot-1.1.2-imx1/u-boot-1.1.2-imx1.diff It contains the code unlocking intel k3 devices. splitdiff output is at http://www.ludenkalle.de/u-boot-1.1.2-imx1/u-boot-1.1.2_* (directory viewing on http://www.ludenkalle.de/u-boot-1.1.2-imx1/ is allowed). May be I could get advice what still looks odd so I can fix it, so the stuff could be apllied. Or it can be applied as is... Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF

3 12

[U-Boot-Users] Problem building U-Boot for ARM target
by Paolo Broggini 11 Oct '05

11 Oct '05

Dear all, I'm using the GCC 3.2 toolchain for building U-Boot (current head of git) for an ARM target. I get the following error: cc1: invalid option 'abi=apcs-gnu' This option (correct me if I'm wrong) was introduced with a recent patch by Peter Pearse. Digging a bit in gcc.gnu.org it appears that this option comes only with GCC 4.0! Is this a known behaviour? BTW: removing this option from 'cpu/armxxx/config.mk' U-Boot builds fine! Best regards -P.Broggini

2 8

[U-Boot-Users] Re: U-Boot 1.1.3 does not boot with MPC8349E
by Florian Behrens 11 Oct '05

11 Oct '05

Hi, thanks for your help, but finally I found the problem myself (pulling out the USB TAP instead of a BDI2000 ;-). The text segment in U-Boot 1.1.3 is placed at 0xFE700000 in board/mpc8349ads/config.mk, while the README.mpc83xxads says to flash it to 0xFE000000. Changing the text segment address makes it working! You may choose to change either the README or the config.mk. Regards, Florian. Machen Sie aus 14 Cent spielend bis zu 100 Euro! Die neue Gaming-Area von Arcor - über 50 Onlinespiele im Angebot. http://www.arcor.de/rd/emf-gaming-1

1 0

[U-Boot-Users] [PATCH] AS option "allow_branch_to_undefined" removed into mips support
by Rodolfo Giometti 11 Oct '05

11 Oct '05

Hello, the attached patch agaist u-boot-1.1.3 (thanks to Tim Braun <tim.braun(a)librestream.com>) allow to remove the mips(el)-linux-as option named "allow_branch_to_undefined". I tested it with GNU assembler version 2.16.1. Also it fixes endianness support and adds support for toolchains named mips-linux- or mipsel-linux- (the former still untested). Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti(a)linux.it Linux Device Driver giometti(a)enneenne.com Embedded Systems home page: giometti.enneenne.com UNIX programming phone: +39 349 2432127

1 0

[U-Boot-Users] [PATCH] Target for each ARM supplied & supported combination of board and core module.
by Peter Pearse 11 Oct '05

11 Oct '05

Wolfgang Attached gzipped patch is intended to supply a separate target for each ARM supplied & supported combination of board and core module, whilst meeting U-Boot code style requirements, as we have discussed. It produces a working build of u-boot for each target. The configuration for each target is provided by inserting a link to the base board configuration header e.g. include/configs/integratorap.h. This link is removed by make clean. I hope this is acceptable. Patch produced using cg-diff in GIT cg-updated Tue Oct 11 15:01:56 BST 2005 CHANGELOG Provide targets for all ARM supplied & supported base-board/core module combinations. Patch by Peter Pearse, 11 Oct 2005. Regards Peter

1 0

Re: [U-Boot-Users] Debugging U-Boot on arm920t using BDI2000
by Ioritz Irazustabarrena Murgiondo 11 Oct '05

11 Oct '05

First Question: If I have understood everything correctly, u-boot ALWAYS relocates itselfs to RAM. This is the code in Start.S in cpu/arm920t that makes the relocation. relocate: /* relocate U-Boot to RAM */ adr r0, _start /* r0 <- current position of code */ ldr r1, _TEXT_BASE /* test if we run from flash or RAM */ cmp r0, r1 /* don't reloc during debugaitor This is how I get the values that _start and _TEXT_BASE take: arm-unknown-linux-gnu-gdb u-boot GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. ... This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-unknown-linux-gnu"... (gdb) info address _start Symbol "_start" is at 0x8f00000 in a file compiled without debugging. (gdb) info address _TEXT_BASE Symbol "_TEXT_BASE" is at 0x8f00040 in a file compiled without debugging. (gdb) x/1xw 0x8f00040 0x8f00040 <_TEXT_BASE>: 0x08f00000 (gdb) Both addresses TEXT_BASE & _start are SDRAM. According to this, this code will never relocate. Is this correct ?. u-boot$ arm-unknown-linux-gnu-objdump -h u-boot u-boot: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 000138a4 08f00000 08f00000 00008000 2**5 What I conclude is that the binary is prepared to be loaded and executed only from SDRAM. In fact, I´ve loaded u-boot in sdram (0x8f00000) using bdi2000, I have defined CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT and I have been able to debug u-boot using gdb. I know this is not the right way to debug u-boot. In conclusion, there are two things I don't understand: * I think that LMA address of text section should be Flash 0x10000000. Because the code must be loaded in non-volatile memory. VMA of course, should be SDRAM 0x8f00000. * I think that the code that makes the relocation must be loaded and executed from flash. VMA 0x10000000 and LMA 0x10000000. Second Question. You have told me that: > But for that you have to tell the debugger that the code is running > from an address that is different from the link address). This is what I´ve done: iim@viggen:~/.../u-boot-1.1.3$ arm-unknown-linux-gnu-gdb u-boot GNU gdb 6.3 ... This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-unknown-linux-gnu"... (gdb) symbol-file Discard symbol table from `/.../u-boot-1.1.3/u-boot'? (y or n) y No symbol file now. (gdb) add-symbol-file u-boot 0x0000 add symbol table from file "u-boot" at .text_addr = 0x0 (y or n) y Reading symbols from /.../u-boot-1.1.3/u-boot...done. (gdb) b _start_armboot Breakpoint 1 at 0x8f00394: file /.../u-boot-1.1.3/cpu/arm920t/start.S, line 435. (gdb) target remote 192.168.1.5:2001 Remote debugging using 192.168.1.5:2001 0x08f001c0 in ?? () (gdb) c Continuing. But the breakpoint is still in sdram (0x8f00394), and the program doesn´t stop in the breakpoint. Regards. Ioritz.

1 0

[U-Boot-Users] Problems with MPC8247, HRCW, PCI_MODCK and PLL multiplication factors
by Ron Kellam 11 Oct '05

11 Oct '05

I've a custom MPC8247, 32MB 64-bit SDRAM, 32MB 16-bit Flash, PCI-less system that I'm trying to bring up. In short, my current problem is that the PCI_MODCK bit in the SCCR register does not reflect the PCI_MODCK bit in the Hard Reset Configuration Word. Thus I can't get the clocks I want. The HRCW is 0x0A04F25A. The key elements of this are: - BPS = 10 for 16-bit flash - CIP = 1 for Exceptions at 0x000n_nnnn - PLLBP = 0 for Normal operation - ISB = 100 for Internal Space Base at 0xF0000000 - BMS = 1 for Boot Memory Space at 0x0000_0000..0x01FF_FFFF - PCI_MODCK = 1 for PCI low frequency range - MODCK_H = 1010 also - MODCK[1-3] - tied to 000 The Clock Configuration I'm after is from Table 16 of the MPC8272 Hardware Spec: MODCK_H-MODCK[1-3] = 1010_000: CPM Mult Fact = 2, CPU Mult Fact = 2, PCI Div Fact = 6 to give the following clocks from a 133MHz CLKIN - MAIN_CLK = 266Mhz - CPM_CLK = 133MHz - BUS_CLK = 133Mhz = CLKIN - SCC_CLK = 66MHz - BRG_CLK = 16.6Mhz - PCI_CLK = xx (don't really care) - CORE_CLK = 266Mhz Using the BDI2000 to break at reset, I get: - SCCR = 0x00000019 (which indicates PCI_MODCK=0, and wrong PCIDF) - SCMR = 0x1A510002 I've validated that the HRCW is actually getting read and used, as I can freely change ISB, CS6PC and other bits, and get the expected results. I've also commented out everything in the BDI2000 config bar the setting of SYPCR to disable the watchdog, so I don't think it's the BDI buggering things up. Does anyone have any ideas? I've scoured the Hardware Spec, Reference Manual, Errata, U-Boot mailing list and PPC Embedded mailing list, and turned up no useful information. Thanks in advance, Ron Kellam

1 1

RE: [U-Boot-Users] Problems with MPC8247, HRCW, PCI_MODCK and PLL multiplication factors
by Rune Torgersen 11 Oct '05

11 Oct '05

> From: Ron Kellam > In short, my current problem is that the PCI_MODCK bit in the > SCCR register does not reflect the PCI_MODCK bit in the Hard > Reset Configuration Word. Thus I can't get the clocks I want. Sounds like the PCI is enabled in hardware, because then the MODCK_H bits in the HRCW are ignored and the MODCK_H pins on the CPU are used instead.

2 1

[U-Boot-Users] at91 and lxt971 phy
by zoldnap＠freemail.hu 10 Oct '05

10 Oct '05

Hi! Is there someone using the combo in $SUBJECT? I'm using a modified at91rm9200dk.h config file, the ethernet relevant section: #define CONFIG_DRIVER_ETHER #define CONFIG_NET_RETRY_COUNT 20 /* * MII PHY configuration * */ #define CONFIG_MII 1 /* MII PHY management */ #define CONFIG_PHY_ADDR 0 /* PHY address */ #define CONFIG_PHY_CMD_DELAY 40 /* PHY COMMAND delay */ /* 32usec min. for LXT971A */ #define CONFIG_PHY_RESET_DELAY 300 /* PHY RESET recovery delay */ #define CONFIG_ETHADDR 02:80:ad:20:31:c8 #define CONFIG_IPADDR 192.168.0.100 #define CONFIG_SERVERIP 192.168.0.2 (for the full setup, see the bottom of the mail) after starting u-boot i do: U-Boot> tftp 21000000 zImage PHY not connected!! TFTP from server 192.168.0.2; our IP address is 192.168.0.100 Filename 'zImage'. Load address: 0x21000000 Loading: T T T T T T T T T T T T T T T T T T T T Abort U-Boot> On the server PC i'm using tftp-hpa server. Here is the dump of the ethernet traffic: 18:59:38.903037 arp who-has 192.168.0.2 tell 192.168.0.100 18:59:39.160951 arp reply 192.168.0.2 is-at 00:50:8d:53:ec:34 18:59:43.902587 arp who-has 192.168.0.2 tell 192.168.0.100 18:59:43.902626 arp reply 192.168.0.2 is-at 00:50:8d:53:ec:34 18:59:58.903396 IP 192.168.0.100.1373 > 192.168.0.2.tftp: 25 RRQ "zImage" octet timeout 5 18:59:58.918175 IP 192.168.0.2.32968 > 192.168.0.100.1373: UDP, length: 12 19:00:03.903759 IP 192.168.0.100.1373 > 192.168.0.2.tftp: 25 RRQ "zImage" octet timeout 5 19:00:03.905782 IP 192.168.0.2.32971 > 192.168.0.100.1373: UDP, length: 12 19:00:03.906187 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:03.906590 IP 192.168.0.2.32971 > 192.168.0.100.1373: UDP, length: 516 19:00:03.917236 arp who-has 192.168.0.100 tell 192.168.0.2 19:00:03.917566 arp reply 192.168.0.100 is-at 02:80:ad:20:31:c8 19:00:03.923288 IP 192.168.0.2.32968 > 192.168.0.100.1373: UDP, length: 12 19:00:08.903911 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:08.907847 IP 192.168.0.2.32971 > 192.168.0.100.1373: UDP, length: 516 19:00:13.904233 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:13.923953 IP 192.168.0.2.32968 > 192.168.0.100.1373: UDP, length: 12 19:00:18.904649 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:18.912829 IP 192.168.0.2.32971 > 192.168.0.100.1373: UDP, length: 516 19:00:23.904979 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:28.905379 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:33.905692 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:33.928161 IP 192.168.0.2.32968 > 192.168.0.100.1373: UDP, length: 12 19:00:38.906060 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:38.917350 IP 192.168.0.2.32971 > 192.168.0.100.1373: UDP, length: 516 19:00:38.926918 arp who-has 192.168.0.100 tell 192.168.0.2 19:00:39.926751 arp who-has 192.168.0.100 tell 192.168.0.2 19:00:39.927037 arp reply 192.168.0.100 is-at 02:80:ad:20:31:c8 19:00:43.906424 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:53.907197 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:00:58.907554 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:01:03.907910 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 19:01:08.908269 IP 192.168.0.100.1373 > 192.168.0.2.32971: UDP, length: 4 It looks like that u-boot is ignoring the returned packages for some reason. Maybe u-boot is still configured to think that the phy is a dm9161, as on the original AT91 DK board? How to change that to the LXT971? What could be that cause that outgoing packages are OK, but incoming packages are ignored? I'd appreciate any hints on this! Regards, Zoli

1 0

[U-Boot-Users] Bug in AT91RM9200.h
by Steven Scholz 10 Oct '05

10 Oct '05

Guys, A while ago I sent the following the the linux arm ML. I am sure this applies to U-Boot as well! > I just noticed the following: > > in incluse/asm-arm/mach-at91rm9200/AT91RM9200.h > > #define AT91C_SMC2_DBW (0x1 << 13) // (SMC2) Data Bus Width > > and drivers/pcmcia/at91_cf.c uses code like > > csr &= ~AT91C_SMC2_DBW; > > BUT: > > According to the User Man the "DBW: Data Bus Width" field is _TWO_ bits. > Thus it should be > > #define AT91C_SMC2_DBW (0x3 << 13) // (SMC2) Data Bus Width So please apply this trivial. * Fix define in AT91RM9200.h Patch by Steven Scholz, 10 Oct 2005 -- Steven Index: u-boot/include/asm-arm/arch-at91rm9200/AT91RM9200.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/asm-arm/arch-at91rm9200/AT91RM9200.h,v retrieving revision 1.11 diff -u -r1.11 AT91RM9200.h --- u-boot/include/asm-arm/arch-at91rm9200/AT91RM9200.h 4 Oct 2005 23:52:35 -0000 1.11 +++ u-boot/include/asm-arm/arch-at91rm9200/AT91RM9200.h 10 Oct 2005 12:20:39 -0000 @@ -255,7 +255,7 @@ #define AT91C_SMC2_WSEN ((unsigned int) 0x1 << 7) /* (SMC2) Wait State Enable */ #define AT91C_SMC2_TDF ((unsigned int) 0xF << 8) /* (SMC2) Data Float Time */ #define AT91C_SMC2_BAT ((unsigned int) 0x1 << 12) /* (SMC2) Byte Access Type */ -#define AT91C_SMC2_DBW ((unsigned int) 0x1 << 13) /* (SMC2) Data Bus Width */ +#define AT91C_SMC2_DBW ((unsigned int) 0x3 << 13) /* (SMC2) Data Bus Width */ #define AT91C_SMC2_DBW_16 ((unsigned int) 0x1 << 13) /* (SMC2) 16-bit. */ #define AT91C_SMC2_DBW_8 ((unsigned int) 0x2 << 13) /* (SMC2) 8-bit. */ #define AT91C_SMC2_DRP ((unsigned int) 0x1 << 15) /* (SMC2) Data Read Protocol */

1 1

[U-Boot-Users] [PATCH] Make target for all ARM supplied and supported development boards - patch 007
by Peter Pearse 10 Oct '05

10 Oct '05

The attached patch provides a make target for all ARM supplied and supported development boards. It also ensures that all boards use the preferred mechanism for initial setup. I have modified the other boards using arm cpus sx1 ns9750dev omap1510inn omap1610inn omap2420h4 omap5912osk omap730p2 to use the same mechanism. It replaces my rejected patch 006 (thanks for the comments & suggestions Wolfgang) which contained an unintentional change to MAKEALL. The patch was made against the GIT head:- commit bccae9039e59ac09a776429119389a6a4e679fd7 tree 9361bea6cc2bca3d22876433406886cfc1e359de parent 6ebc79211420cd856c9825cf3ade8bd6fd54fee5 author Wolfgang Denk <wd(a)pollux.denx.de> Thu, 06 Oct 2005 01:50:50 +0200 committer Wolfgang Denk <wd(a)pollux.denx.de> Thu, 06 Oct 2005 01:50:50 +0200 Tested with MAKEALL (unpatched ;-} ) arm. CHANGELOG: Provide make target for all ARM supplied & supported development boards Ensure all boards use lowlevel_init(), rather than platformsetup(). Patch 007 from Peter Pearse <peter.pearse(a)arm.com> 7th Oct 2005 Regards Peter Pearse

3 5

[U-Boot-Users] dataflash problem
by zoldnap＠freemail.hu 10 Oct '05

10 Oct '05

Hi, I'm using u-boot 1.1.3 with an AT91 board, however I'm having problems with the dataflash support: U-Boot downloaded successfully U-Boot 1.1.3 (Oct 9 2005 - 21:49:00) U-Boot code: 21F00000 -> 21F149B8 BSS: -> 21F19290 RAM Configuration: Bank #0: 20000000 32 MB Atmel: Flash: 0 kB DataFlash:AT45DB161 Nb pages: 4096 Page Size: 528 Size= 2162688 bytes Logical address: 0xC0000000 Area 0: C0000000 to C0007FFF (RO) Area 1: C0008000 to C001FFFF (RO) Area 2: C0020000 to C0027FFF Area 3: C0028000 to C020FFFF *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial U-Boot> flinfo DataFlash:AT45DB161 Nb pages: 4096 Page Size: 528 Size= 2162688 bytes Logical address: 0xC0000000 Area 0: C0000000 to C0007FFF (RO) Area 1: C0008000 to C001FFFF (RO) Area 2: C0020000 to C0027FFF Area 3: C0028000 to C020FFFF Bank # 1: Atmel: Unknown Chip Type U-Boot> md C0020000 c0020000:Error Timeout -F- Data Abort detected To me, this seems like u-boot is not honouring that C0000000 should be mapped to the dataflash, instead it wants to read the physical memory at C0000000 which is obviously non existing on this platform. the "about the "Atmel: Flash: 0 kB" message is normal, since I'm having no NAND and using the atmel developed loader.bin for booting u-boot. SPI support also seems to be okay, since it recognizes the exact type of my dataflash device.. Can you give some hints how to start finding out what is causing this problem? Best regards, Zoli Here is my at91rm9200dk.h: /* ARM asynchronous clock */ #define AT91C_MAIN_CLOCK 179712000 /* from 18.432 MHz crystal (18432000 / 4 * 39) */ #define AT91C_MASTER_CLOCK 59904000 /* peripheral clock (AT91C_MASTER_CLOCK / 3) */ /* #define AT91C_MASTER_CLOCK 44928000 */ /* peripheral clock (AT91C_MASTER_CLOCK / 4) */ #define AT91_SLOW_CLOCK 32768 /* slow clock */ #define CONFIG_ARM920T 1 /* This is an ARM920T Core */ #define CONFIG_AT91RM9200 1 /* It's an Atmel AT91RM9200 SoC */ #define CONFIG_AT91RM9200DK 1 /* on an AT91RM9200DK Board */ #undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */ #define USE_920T_MMU 1 #define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS 1 #define CONFIG_INITRD_TAG 1 #ifndef CONFIG_SKIP_LOWLEVEL_INIT #define CFG_USE_MAIN_OSCILLATOR 1 /* flash */ #define MC_PUIA_VAL 0x00000000 #define MC_PUP_VAL 0x00000000 #define MC_PUER_VAL 0x00000000 #define MC_ASR_VAL 0x00000000 #define MC_AASR_VAL 0x00000000 #define EBI_CFGR_VAL 0x00000000 #define SMC2_CSR_VAL 0x00003284 /* 16bit, 2 TDF, 4 WS */ /* clocks */ #define PLLAR_VAL 0x20263E04 /* 179.712000 MHz for PCK */ #define PLLBR_VAL 0x10483E0E /* 48.054857 MHz (divider by 2 for USB) */ #define MCKR_VAL 0x00000202 /* PCK/3 = MCK Master Clock = 59.904000MHz from PLLA */ /* sdram */ #define PIOC_ASR_VAL 0xFFFF0000 /* Configure PIOC as peripheral (D16/D31) */ #define PIOC_BSR_VAL 0x00000000 #define PIOC_PDR_VAL 0xFFFF0000 #define EBI_CSA_VAL 0x00000002 /* CS1=SDRAM */ #define SDRC_CR_VAL 0x2188c155 /* set up the SDRAM */ #define SDRAM 0x20000000 /* address of the SDRAM */ #define SDRAM1 0x20000080 /* address of the SDRAM */ #define SDRAM_VAL 0x00000000 /* value written to SDRAM */ #define SDRC_MR_VAL 0x00000002 /* Precharge All */ #define SDRC_MR_VAL1 0x00000004 /* refresh */ #define SDRC_MR_VAL2 0x00000003 /* Load Mode Register */ #define SDRC_MR_VAL3 0x00000000 /* Normal Mode */ #define SDRC_TR_VAL 0x000002E0 /* Write refresh rate */ #endif /* CONFIG_SKIP_LOWLEVEL_INIT */ /* * Size of malloc() pool */ #define CFG_MALLOC_LEN (CFG_ENV_SIZE + 128*1024) #define CFG_GBL_DATA_SIZE 128 /* size in bytes reserved for initial data */ #define CONFIG_BAUDRATE 115200 /* * Hardware drivers */ /* define one of these to choose the DBGU, USART0 or USART1 as console */ #define CONFIG_DBGU #undef CONFIG_USART0 #undef CONFIG_USART1 #undef CONFIG_HWFLOW /* don't include RTS/CTS flow control support */ #undef CONFIG_MODEM_SUPPORT /* disable modem initialization stuff */ #define CONFIG_BOOTDELAY 3 /* #define CONFIG_ENV_OVERWRITE 1 */ #define CONFIG_COMMANDS \ ((CONFIG_CMD_DFL | \ CFG_CMD_DHCP ) & \ ~(CFG_CMD_BDI | \ CFG_CMD_IMI | \ CFG_CMD_AUTOSCRIPT | \ CFG_CMD_FPGA | \ CFG_CMD_MISC | \ CFG_CMD_LOADS )) /* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */ #include <cmd_confdefs.h> #define CFG_MAX_NAND_DEVICE 0 /* Max number of NAND devices */ #define SECTORSIZE 512 #define ADDR_COLUMN 1 #define ADDR_PAGE 2 #define ADDR_COLUMN_PAGE 3 #define NAND_ChipID_UNKNOWN 0x00 #define NAND_MAX_FLOORS 1 #define NAND_MAX_CHIPS 1 #define AT91_SMART_MEDIA_ALE (1 << 22) /* our ALE is AD22 */ #define AT91_SMART_MEDIA_CLE (1 << 21) /* our CLE is AD21 */ #define NAND_DISABLE_CE(nand) do { *AT91C_PIOC_SODR = AT91C_PIO_PC0;} while(0) #define NAND_ENABLE_CE(nand) do { *AT91C_PIOC_CODR = AT91C_PIO_PC0;} while(0) #define NAND_WAIT_READY(nand) while (!(*AT91C_PIOC_PDSR & AT91C_PIO_PC2)) #define WRITE_NAND_COMMAND(d, adr) do{ *(volatile __u8 *)((unsigned long)adr | AT91_SMART_MEDIA_CLE) = (__u8)(d); } while(0) #define WRITE_NAND_ADDRESS(d, adr) do{ *(volatile __u8 *)((unsigned long)adr | AT91_SMART_MEDIA_ALE) = (__u8)(d); } while(0) #define WRITE_NAND(d, adr) do{ *(volatile __u8 *)((unsigned long)adr) = (__u8)d; } while(0) #define READ_NAND(adr) ((volatile unsigned char)(*(volatile __u8 *)(unsigned long)adr)) /* the following are NOP's in our implementation */ #define NAND_CTL_CLRALE(nandptr) #define NAND_CTL_SETALE(nandptr) #define NAND_CTL_CLRCLE(nandptr) #define NAND_CTL_SETCLE(nandptr) #define CONFIG_NR_DRAM_BANKS 1 #define PHYS_SDRAM 0x20000000 #define PHYS_SDRAM_SIZE 0x2000000 /* 32 megs */ #define CFG_MEMTEST_START PHYS_SDRAM #define CFG_MEMTEST_END CFG_MEMTEST_START + PHYS_SDRAM_SIZE - (1024*1024) #define CONFIG_DRIVER_ETHER #define CONFIG_NET_RETRY_COUNT 20 #define CONFIG_HAS_DATAFLASH 1 #define CFG_SPI_WRITE_TOUT (5*CFG_HZ) #define CFG_MAX_DATAFLASH_BANKS 2 #define CFG_MAX_DATAFLASH_PAGES 16384 #define CFG_DATAFLASH_LOGIC_ADDR_CS0 0xC0000000 /* Logical adress for CS0 */ #define CFG_DATAFLASH_LOGIC_ADDR_CS3 0xD0000000 /* Logical adress for CS3 */ #define PHYS_FLASH_1 0x10000000 #define PHYS_FLASH_SIZE 0x200000 /* 2 megs main flash */ #define CFG_FLASH_BASE PHYS_FLASH_1 #define CFG_MAX_FLASH_BANKS 1 #define CFG_MAX_FLASH_SECT 256 #define CFG_FLASH_ERASE_TOUT (2*CFG_HZ) /* Timeout for Flash Erase */#define CFG_FLASH_WRITE_TOUT (2*CFG_HZ) /* Timeout for Flash Write */ #undef CFG_ENV_IS_IN_DATAFLASH #ifdef CFG_ENV_IS_IN_DATAFLASH #define CFG_ENV_OFFSET 0x20000 #define CFG_ENV_ADDR (CFG_DATAFLASH_LOGIC_ADDR_CS0 + CFG_ENV_OFFSET) #define CFG_ENV_SIZE 0x2000 /* 0x8000 */ #else #define CFG_ENV_IS_IN_FLASH 1 #ifdef CONFIG_SKIP_LOWLEVEL_INIT #define CFG_ENV_ADDR (PHYS_FLASH_1 + 0x60000) /* after u-boot.bin */ #define CFG_ENV_SIZE 0x10000 /* sectors are 64K here */ #else #define CFG_ENV_ADDR (PHYS_FLASH_1 + 0xe000) /* between boot.bin and u-boot.bin.gz */ #define CFG_ENV_SIZE 0x2000 /* 0x8000 */ #endif /* CONFIG_SKIP_LOWLEVEL_INIT */ #endif /* CFG_ENV_IS_IN_DATAFLASH */ #define CFG_LOAD_ADDR 0x21000000 /* default load address */ #ifdef CONFIG_SKIP_LOWLEVEL_INIT #define CFG_BOOT_SIZE 0x00 /* 0 KBytes */ #define CFG_U_BOOT_BASE PHYS_FLASH_1 #define CFG_U_BOOT_SIZE 0x60000 /* 384 KBytes */ #else #define CFG_BOOT_SIZE 0x6000 /* 24 KBytes */ #define CFG_U_BOOT_BASE (PHYS_FLASH_1 + 0x10000) #define CFG_U_BOOT_SIZE 0x10000 /* 64 KBytes */ #endif /* CONFIG_SKIP_LOWLEVEL_INIT */ #define CFG_BAUDRATE_TABLE {115200 , 19200, 38400, 57600, 9600 } #define CFG_PROMPT "U-Boot> " /* Monitor Command Prompt */ #define CFG_CBSIZE 256 /* Console I/O Buffer Size */ #define CFG_MAXARGS 16 /* max number of command args */#define CFG_PBSIZE (CFG_CBSIZE +sizeof(CFG_PROMPT)+16) /* Print Buffer Size */ #ifndef __ASSEMBLY__ /*----------------------------------------------------------------------- * Board specific extension for bd_info * * This structure is embedded in the global bd_info (bd_t) structure * and can be used by the board specific code (eg board/...) */ struct bd_info_ext { /* helper variable for board environment handling * * env_crc_valid == 0 => uninitialised * env_crc_valid > 0 => environment crc in flash is valid * env_crc_valid < 0 => environment crc in flash is invalid */ int env_crc_valid; }; #endif #define CFG_HZ 1000 #define CFG_HZ_CLOCK AT91C_MASTER_CLOCK/2 /* AT91C_TC0_CMR is implicitly set to */ /* AT91C_TC_TIMER_DIV1_CLOCK */ #define CONFIG_STACKSIZE (32*1024) /* regular stack */ #ifdef CONFIG_USE_IRQ #error CONFIG_USE_IRQ not supported #endif #endif #define CFG_AUTO_COMPLETE 1 -- zoldnap(a)freemail.hu <zoldnap(a)freemail.hu>

2 2

[U-Boot-Users] [PATCH] Remove warnings - patch PMP008
by Peter Pearse 10 Oct '05

10 Oct '05

The attached, gzipped, patch removes warnings left by my patch 006 and uses a nicer mechanism to manipulate the load scripts to load the cpu code of the core module. Patch made against cg-update of GIT head at Fri Oct 7 16:09:29 BST 2005 Tested with MAKEALL arm. CHANGELOG: Remove warnings form cpu/arm720t & cpu/arm1136 files. sed the linker scripts, rather than pre-process them. Patch by Peter Pearse, 7 Oct 2005 Regards Peter Pearse

2 2

Re: [U-Boot-Users] (no subject)
by Wolfgang Denk 09 Oct '05

09 Oct '05

Dear Cliff, your port of U-Boot for the pxa255_idp has been broken since it was added, without any patches / fixes in my queue? Are you still maintaining this board? Or is it broken and orphaned and should be removed? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de About the use of language: it is impossible to sharpen a pencil with a blunt ax. It is equally vain to try to do it with ten blunt axes instead. -- Edsger Dijkstra

1 0

[U-Boot-Users] (no subject)
by Andy Fleming 09 Oct '05

09 Oct '05

Here's a patch which puts the PHYs for the 3rd and 4th eTSECS into RGMII mode on the 8548 CDS.

2 1

[U-Boot-Users] NS7520 processor support patch
by Arthur Shipkowski 09 Oct '05

09 Oct '05

This patch adds support for the NS7520 processor as CONFIG_NETARM_NS7520. The patch adds its support to the current Net+ARM related files when possible. The sole exception is the Ethernet driver, because the Ethernet support is not like that on the prior Net+ARM parts nor like that on the NS9750. This patch has been tested against current CVS with MAKEALL arm. CHANGELOG: * Patch by Art Shipkowski, 12 May 2005: Implemented support for the NetSilicon NS7520 processor. Art Shipkowski Videon Central Software Engineer (814)235-1111 x307 art(a)videon-central.com

2 1

[U-Boot-Users] cfi_flash.c bug regarding intel k3 devices
by Konstantin Kletschke 09 Oct '05

09 Oct '05

Hi! cfi_flash.c handles intel k3 devices not correct, they power up with all sectors locked. Similair to flash_unlock_seq for amd devices, there must exist a flash_unlock_seq_intelk3 to do this for intel devices. --- u-boot-1.1.2/drivers/cfi_flash.c 2004-12-18 23:35:45.000000000 +0100 +++ u-boot-1.1.2-imx1/drivers/cfi_flash.c 2005-05-12 15:59:06.000000000 +0200 @@ -111,6 +111,9 @@ #define AMD_ADDR_START 0x555 #define AMD_ADDR_ACK 0x2AA +#define INTEL_CMD_UNLOCK_START 0x60 +#define INTEL_CMD_UNLOCK_ACK 0xD0 + #define FLASH_OFFSET_CFI 0x55 #define FLASH_OFFSET_CFI_RESP 0x10 #define FLASH_OFFSET_PRIMARY_VENDOR 0x13 @@ -180,6 +183,7 @@ static void flash_make_cmd (flash_info_t * info, uchar cmd, void *cmdbuf); static void flash_write_cmd (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static void flash_unlock_seq (flash_info_t * info, flash_sect_t sect); +static void flash_unlock_seq_intelk3 (flash_info_t * info, flash_sect_t sect); static int flash_isequal (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static int flash_isset (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); static int flash_toggle (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd); @@ -239,7 +243,6 @@ } #endif - /*----------------------------------------------------------------------- * read a character at a port width address */ @@ -397,6 +400,7 @@ switch (info->vendor) { case CFI_CMDSET_INTEL_STANDARD: case CFI_CMDSET_INTEL_EXTENDED: + flash_unlock_seq_intelk3 (info, sect); flash_write_cmd (info, sect, 0, FLASH_CMD_CLEAR_STATUS); flash_write_cmd (info, sect, 0, FLASH_CMD_BLOCK_ERASE); flash_write_cmd (info, sect, 0, FLASH_CMD_ERASE_CONFIRM); @@ -858,6 +862,12 @@ flash_write_cmd (info, sect, AMD_ADDR_ACK, AMD_CMD_UNLOCK_ACK); } +static void flash_unlock_seq_intelk3 (flash_info_t * info, flash_sect_t sect) +{ + flash_write_cmd (info, sect, 0, INTEL_CMD_UNLOCK_START); + flash_write_cmd (info, sect, 0, INTEL_CMD_UNLOCK_ACK); +} + /*----------------------------------------------------------------------- */ static int flash_isequal (flash_info_t * info, flash_sect_t sect, uint offset, uchar cmd) May be there must be added an "if" to filter intel k3 devices only, can somebody confirm this? Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF

3 6

[U-Boot-Users] [PATCH][BUGFIX] AT91RM9200: eliminate hard-coded buffer address
by Anders Larsen 09 Oct '05

09 Oct '05

Hi, the driver for the AT91RM9200 on-chip Ethernet interface uses a hard-coded address of the transfer buffer descriptor table. This is a ticking time-bomb (well, in fact it just blew up here overwriting U-Boot), AND the driver will not work at all on boards with less than 16MiB of RAM. The patch below lets the linker decide where to place the buffer (due to this, I had to change the start-address for the csb637 board - AFAICT other AT91RM9200-based boards are not impaired by the larger size of U-Boot). The Atmel errata #11 states that the transfer buffer descriptor table must be aligned on a 16-word boundary. As it turned out, this is insufficient - it seems the table must be aligned on a boundary at least as large as the table itself (in Linux this is not an issue - the table is aligned on a PAGE_SIZE (4096) boundary). Cheers Anders Signed-off-by: Anders Larsen <alarsen(a)rea.de> CHANGELOG: Eliminate the hard-coded address of the Ethernet transfer buffer Patch by Anders Larsen, 07 Oct 2005 --- board/csb637/config.mk | 2 +- cpu/arm920t/at91rm9200/ether.c | 23 ++++++++--------------- 2 files changed, 9 insertions(+), 16 deletions(-) diff --git a/board/csb637/config.mk b/board/csb637/config.mk --- a/board/csb637/config.mk +++ b/board/csb637/config.mk @@ -1 +1 @@ -TEXT_BASE = 0x23fe0000 +TEXT_BASE = 0x23fc0000 diff --git a/cpu/arm920t/at91rm9200/ether.c b/cpu/arm920t/at91rm9200/ether.c --- a/cpu/arm920t/at91rm9200/ether.c +++ b/cpu/arm920t/at91rm9200/ether.c @@ -44,21 +44,19 @@ typedef struct { #define RBF_LOCAL2 (1<<24) #define RBF_LOCAL1 (1<<23) -/* Emac Buffers in last 512KBytes of SDRAM*/ -/* Be careful, buffer size is limited to 512KBytes !!! */ -#define RBF_FRAMEMAX 100 -/*#define RBF_FRAMEMEM 0x200000 */ -#define RBF_FRAMEMEM 0x21F80000 +#define RBF_FRAMEMAX 64 #define RBF_FRAMELEN 0x600 -#define RBF_FRAMEBTD RBF_FRAMEMEM -#define RBF_FRAMEBUF (RBF_FRAMEMEM + RBF_FRAMEMAX*sizeof(rbf_t)) - - #ifdef CONFIG_DRIVER_ETHER #if (CONFIG_COMMANDS & CFG_CMD_NET) +/* alignment as per Errata #11 (64 bytes) is insufficient! */ +rbf_t rbfdt[RBF_FRAMEMAX] __attribute((aligned(512))); +rbf_t *rbfp; + +unsigned char rbf_framebuf[RBF_FRAMEMAX][RBF_FRAMELEN] __attribute((aligned(4))); + /* structure to interface the PHY */ AT91S_PhyOps PhyOps; @@ -153,9 +150,6 @@ UCHAR at91rm9200_EmacWritePhy (AT91PS_EM } -rbf_t *rbfdt; -rbf_t *rbfp; - int eth_init (bd_t * bd) { int ret; @@ -188,9 +182,8 @@ int eth_init (bd_t * bd) p_mac->EMAC_CFG |= AT91C_EMAC_CSR; /* Clear statistics */ /* Init Ehternet buffers */ - rbfdt = (rbf_t *) RBF_FRAMEBTD; for (i = 0; i < RBF_FRAMEMAX; i++) { - rbfdt[i].addr = RBF_FRAMEBUF + RBF_FRAMELEN * i; + rbfdt[i].addr = rbf_framebuf[i]; rbfdt[i].size = 0; } rbfdt[RBF_FRAMEMAX - 1].addr |= RBF_WRAP;

2 1

[U-Boot-Users] [PATCH] Fix ARM compilation error
by Anders Larsen 09 Oct '05

09 Oct '05

Hi, the patch below eliminates two calls of the libgcc helper functions _divsi3 and _modsi3 when using a (standard) Hardware-FP toolchain (the unsigned counterparts _udivsi3 and _umodsi3 are already included in libarm.a). "For historical reasons", the ARM community uses toolchains built for hardware-FP, even though so far no ARM CPU comes with FPU. Go figure. Cheers Anders Signed-off-by: Anders Larsen <alarsen(a)rea.de> CHANGELOG: Fixed compilation for ARM when using a (standard) Hard-FP toolchain Patch by Anders Larsen, 07 Oct 2005 --- drivers/cfi_flash.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cfi_flash.c b/drivers/cfi_flash.c --- a/drivers/cfi_flash.c +++ b/drivers/cfi_flash.c @@ -221,7 +221,7 @@ static void flash_printqry (flash_info_t cfiptr_t cptr; int x, y; - for (x = 0; x < 0x40; x += 16 / info->portwidth) { + for (x = 0; x < 0x40; x += 16U / info->portwidth) { cptr.cp = flash_make_addr (info, sect, x + FLASH_OFFSET_CFI_RESP); @@ -807,7 +807,7 @@ static void flash_make_cmd (flash_info_t #else for (i = 1; i <= info->portwidth; i++) #endif - *cp++ = (i % info->chipwidth) ? '\0' : cmd; + *cp++ = (i & (info->chipwidth - 1)) ? '\0' : cmd; } /*

2 1

[U-Boot-Users] problem about transplant u-boot to S3C44B0
by du rui 08 Oct '05

08 Oct '05

I have transplant u-boot to my S3C44B0 board and i run hello world demo but it's prompt => go c008000 ## Starting application at 0x0C008000 ... then it's dead i want know what reason cause it __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs

2 1

[U-Boot-Users] can u-boot relocate to sram
by K.M.Yin 07 Oct '05

07 Oct '05

Dear sir we want to relocate the u-boot to sram instead of DDR ram after boot up from flash. is it possible to achieved that just change the relocated address which is referred by the start.S. Best Regards K.M.Yin

2 1

[U-Boot-Users] how to port u-boot to DM270 on DM270GHK EVB
by Lu yunfeng 07 Oct '05

07 Oct '05

> Dear all, > > Can anybody tell me how to port u-boot to DM270 on TI DM270GHK EBV? how many files must be modified? I just need a serial poer and a network port(CS8900) for internace. > > Regards, > Yunfeng >

1 0

[U-Boot-Users] how to port u-boot to DM270 on DM270GHK EVB
by Lu yunfeng 07 Oct '05

07 Oct '05

Dear all , I 'm a fresh man to u-boot! My boss want me to port u-boot to TI DM270, how many file must be modified in u-boot directory tree? can any one tell me the general procedure of porting the u-boot to DM270? Regards, YF.

2 3

RE: [U-Boot-Users] [PATCH] - OMAP242x fix for GP device booting.
by Woodruff, Richard 06 Oct '05

06 Oct '05

Wolfgang, I'll submit something early next week. I'm currently unable to spend cycles. Your suggested compile work around seems fine as what is on head isn't currently in a workable state. Where it left last, I'll do a pull and submit to just fix internals. Then we will see about the cfi_flash driver. GP_DEVICE has had two definitions I'm not sure how they crossed in the patch order. Regards, Richard W. > -----Original Message----- > From: wd(a)denx.de [mailto:wd@denx.de] > Sent: Thursday, October 06, 2005 3:46 PM > To: Woodruff, Richard > Cc: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] [PATCH] - OMAP242x fix for GP device booting. > > Dear Richard, > > in message <71555548814716479478431542AA5F8A0197FEDC(a)dlee2k04.ent.ti.com> > you wrote: > > > > This patch fixes booting on OMAP242x GP devices, and it unlocks a GP > > Actually it does not - it breaks compiling the code. > > > SRAM suitable for DSS subsystem access. One other minor change is to > > the DDR's DLL count value when used in unlock mode. This change allows > > standard low speed operation for 100MHz DDR's. > > The change to "include/asm-arm/arch-arm1136/omap2420.h" redefines > GP_DEVICE; I'll comment out the second (new) definition for now, but > I'm pretty sure that this is wrong. > > Please submit a patch. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > Physician: One upon whom we set our hopes when ill and our dogs when > well. - Ambrose Bierce

2 1

RE: [U-Boot-Users] [PATCH] - OMAP242x fix for GP device booting.
by Woodruff, Richard 06 Oct '05

06 Oct '05

Sorry for the top reply. Mailed to quickly. Regards, Richard W.

1 0

[U-Boot-Users] Burst I/O on PPC440GP
by Gregg Nemas 06 Oct '05

06 Oct '05

I am trying to perform I/O with a device attached to the external peripheral bus on a PPC440GP embedded processor. I am able to address the device and read and write to it, but I am only able to do non-burst I/O. Do I need to do something special to enable burst transactions? I've programmed the EBC0_B5CR and EBC0_B5AP device control registers appropriately to enable burst mode, but the transactions are still single I/O. I've been testing this by using the u-boot mw.l command. Do I need to use PPC-specific instructions to perform burst I/O, or should an ordinary programmed I/O (using 32-bit write operations) be automatically queued up and converted to burst transactions? The TLB I've added for the I/O region has the caching inhibit (I) and guarded (G) bits set. Does caching or speculative access need to be enabled to allow bursting? Even if I added a TLB entry, it wouldn't do me any good in Linux, since it manages TLBs itself. So how would I do this from a Linux kernel driver? Thanks. Gregg

3 3

[U-Boot-Users] [PATCH] - OMAP242x fix for GP device booting.
by Woodruff, Richard 06 Oct '05

06 Oct '05

Hello, This patch fixes booting on OMAP242x GP devices, and it unlocks a GP SRAM suitable for DSS subsystem access. One other minor change is to the DDR's DLL count value when used in unlock mode. This change allows standard low speed operation for 100MHz DDR's. Regards, Richard W.

2 2

[U-Boot-Users] [PATCH] driver for SMSC lan911x ethernet chips
by Tim Braun 06 Oct '05

06 Oct '05

Here's a patch to u-boot 1.1.3 which provides a driver (CONFIG_NET_MULTI style) for the SMSC 911x chips. It's based on minimal changes to the SMSC simple reference driver for linux. My u-boot development is done using a uclibc little-endian MIPS tool chain under cygwin, so there are a few tweaks in the patch file for that. I believe the driver itself is target processor / toolchain independent. CHANGELOG entry : * Patch by Tim Braun, 05/10/06: Add support for SMSC LAN911x ethernet devices. Define CONFIG_LAN911x_BASE and CONFIG_DRIVER_LAN911x to use it. Tim Braun, Sr. Des. Eng. LibreStream Technologies 200-55 Rothwell Rd. Winnipeg R3P 2M5

1 0

Re: [U-Boot-Users] [PATCH] AMD/Spansion write buffer support, splitted
by Wolfgang Denk 06 Oct '05

06 Oct '05

Dear Alex, in message <1128604461.4345232d18143@webmail.televes.com:443> you wrote: > > > Are these two patches in alternative? Or additional? Or just for > > disussion? Or what? > > So, Should I say alternative?. Maybe the second is most a RFC. I understand that I should dump the first and apply the second one? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de "If you want to eat hippopatomus, you've got to pay the freight." - attributed to an IBM guy, about why IBM software uses so much memory

2 1

Re: [U-Boot-Users] [PATCH] AMD/Spansion write buffer support, splitted
by Wolfgang Denk 06 Oct '05

06 Oct '05

Dear Alex, in message <1125386352.431408702216a@webmail.televes.com:443> you wrote: > > This patch: > - Adds flash_write_cfibuffer support for AMD/Spansion Flashes. > > This was splitted from previous patch. I am confused. I have two messages from you (sent from different addresses, but both on Tue, 30 Aug 2005, with two different patches: > Signed-off-by: Thomas Schaefer <thomas.schaefer(a)kontron.com> > Signed-off-by: Alexandre Bastos <alebas(a)televes.com> > > CHANGELOG: > * Add support for AMD/Spansion Flashes in flash_write_cfibuffer > Patch by Alex Bastos and Thomas Schaefer, 2005-08-29 ... > Content-Type: text/x-patch; name="20050830_cfi_flash_A.diff" and [no CHANGELOG entry] ... > It may be enough shifting the address each time it is needed > (in fact, only two times). > >Suggestions? ... > Content-Type: text/x-patch; name="20050830_cfi_flash_B.diff" Are these two patches in alternative? Or additional? Or just for disussion? Or what? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de I paid too much for it, but its worth it.

2 1

[U-Boot-Users] [PATCH] Make target for all ARM supplied and supported - patch 006
by Peter Pearse 06 Oct '05

06 Oct '05

The attached patch provides a make target for all ARM supplied and supported development boards. I hope the approach adopted here is more acceptable than my previous attempt of 29 Sept 2005. It also ensures that all boards use the preferred mechanism for initial setup. I have modified the other boards using arm cpus sx1 ns9750dev omap1510inn omap1610inn omap2420h4 omap5912osk omap730p2 to use the same mechanism. None of the maintainers have objected and it is "only" a matter of changing the function name, file name & Makefile entry for each. Patch against GITHead updated 6th Oct 2005. Tested with MAKEALL arm. CHANGELOG: Patch 006 from Peter Pearse <peter.pearse(a)arm.com> 6th Oct 2005 Provide make target for all ARM supplied & supported development boards Ensure all boards use lowlevel_init(), rather than platformsetup(). Regards Peter.pearse

1 0

[U-Boot-Users] " Problem in copying files into /mnt/jffs2 directory "
by nreddy＠netenrich.com 06 Oct '05

06 Oct '05

Hi All, I am working on PPC405ep (walnut board) board which has 4MB AMD flash and working fine . Recently we have increased FLASH size to 8MB and modified Flash drivers accordingly. I have taken some help from uboot users. Thanks for giving such kind of invaluable help. Now the system is up and running well, but i get into some other problem like when copying files to /mnt/jffs2 directory it is taking so much extra time to copy files. But when i was using 4MB flash it was taking 1/4 of this time. Can some one throw a lite on this. Thanks & Regards, --Nagi

2 1