October 2006 - U-Boot

Re: [U-Boot-Users] Updated mpc86xx U-Boot Tree
by Wolfgang Denk 10 Oct '06

10 Oct '06

Dear Jon, in message <E1GQ3Bk-00065e-D6(a)jdl.com> you wrote: > > I have updated the u-boot-86xx tree on jdl.com to have > the recent modifications for the build system introduced > in the denx.de mainline. > > http://www.jdl.com/git_repos/ I had a look at your U-Boot tree. I think you need to rework it to make it usable. First: there is not a single CHANGELOG entry for any of the many commits you checked in!!! Second: in the git log I see things like "Conflicts: board/stxxtc/Makefile" - what does that mean? Have such conflicts been sorted out? Are they still present in the tree? Have the board maintainers been contacted? Third: there are many coding style violations like trailing white space in doc/README.mpc8641hpcn, drivers/tsec.c, include/asm-ppc/immap_86xx.h, net/bootp.c; bad indentation (spaces instead of TABs) in cpu/mpc86xx/start.S, drivers/tsec.c, include/asm-ppc/immap_86xx.h; excessive empty lines in include/configs/MPC8641HPCN.h; trailing empty lines in board/cds/common/via.c, board/mpc8641hpcn/init.S, cpu/mpc86xx/start.S; bad brace style (missing space between function name and '(' nearly everywhere); bad indentation (not by multiple of 8 chars = using TABs in many files). Some code is so ugly that I'm not going to accept it. For example "cpu/mpc86xx/i2c.c": 195 if (i2c_wait4bus() < 0) 196 goto exit; 197 198 if (i2c_write_addr(dev, I2C_WRITE, 0) == 0) 199 goto exit; 200 201 if (__i2c_write(&a[4 - alen], alen) != alen) 202 goto exit; 203 204 if (i2c_write_addr(dev, I2C_READ, 1) == 0) 205 goto exit; 206 207 i = __i2c_read(data, length); 208 209 exit: 210 writeb(MPC86xx_I2CCR_MEN, I2CCCR); 211 212 return !(i == length); Grrrgh... Also, I don't want to see big blocks of code with local variable declarations (without need) like here: "cpu/mpc86xx/spd_sdram.c": 799 { 800 unsigned int refresh_clk; 801 unsigned int refresh_time_ns[8] = { ... 824 } Either declare variables at function entry, or move the code into a separate function, but don't add such blocks of declarations + code. For long #ifdef / #endif sequences I want to see a comment with the #endif which makes clear which #ifdef it closes, especially for long and/or nested constructs. Also, please don't write code like this: "cpu/mpc86xx/spd_sdram.c": 1260 if (!ddr1_enabled && !ddr2_enabled) 1261 return 0; 1262 else { 1263 printf("Non-interleaved"); 1264 return memsize_total * 1024 * 1024; 1265 } If the "else" needs parens, then parens shall be used for the "if", too. And here the "else" is just bogus because of the previous "return 0". It just adds unnecessary indentation and makes the code hard to read. Please add short comments at the end of the lines, i. e. avoid code like this: 1300 /* 8K */ 1301 dma_xfer((uint *)0x2000, 0x2000, (uint *)0); 1302 /* 16K */ 1303 dma_xfer((uint *)0x4000, 0x4000, (uint *)0); 1304 /* 32K */ 1305 dma_xfer((uint *)0x8000, 0x8000, (uint *)0); 1306 /* 64K */ 1307 dma_xfer((uint *)0x10000, 0x10000, (uint *)0); 1308 /* 128k */ 1309 dma_xfer((uint *)0x20000, 0x20000, (uint *)0); 1310 /* 256k */ 1311 dma_xfer((uint *)0x40000, 0x40000, (uint *)0); 1312 /* 512k */ 1313 dma_xfer((uint *)0x80000, 0x80000, (uint *)0); 1314 /* 1M */ 1315 dma_xfer((uint *)0x100000, 0x100000, (uint *)0); 1316 /* 2M */ 1317 dma_xfer((uint *)0x200000, 0x200000, (uint *)0); 1318 /* 4M */ 1319 dma_xfer((uint *)0x400000, 0x400000, (uint *)0); This is ugly and difficult to read. Reformat for example like this: dma_xfer((uint *)0x002000, 0x002000, (uint *)0); /* 8K */ dma_xfer((uint *)0x004000, 0x004000, (uint *)0); /* 16K */ dma_xfer((uint *)0x008000, 0x008000, (uint *)0); /* 32K */ dma_xfer((uint *)0x010000, 0x010000, (uint *)0); /* 64K */ dma_xfer((uint *)0x020000, 0x020000, (uint *)0); /* 128k */ dma_xfer((uint *)0x040000, 0x040000, (uint *)0); /* 256k */ dma_xfer((uint *)0x080000, 0x080000, (uint *)0); /* 512k */ dma_xfer((uint *)0x100000, 0x100000, (uint *)0); /* 1M */ dma_xfer((uint *)0x200000, 0x200000, (uint *)0); /* 2M */ dma_xfer((uint *)0x400000, 0x400000, (uint *)0); /* 4M */ etc. etc. Note that your current repo is so wrecked that I cannot pull from it, even if you add fixes for the aforementioned problems on top of it. Instead, the fixes should to be implemented on a patch by patch base. If possible I would like to be able to pull from a (new) repo, but of course I will accept standard patches through the mailing list as well. 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 The software required `Windows 95 or better', so I installed Linux.

1 0

[U-Boot-Users] Open Firmware support questions
by Jerry Van Baren 09 Oct '06

09 Oct '06

Hi All, I've been working with the u-boot OF support and have some questions, but don't know who to ask. It appears that Pantelis Antoniou submitted the original ft_build.[ch] code <http://patchwork.ozlabs.org/linuxppc/patch?id=2238> but there is no copyright or license information in the files. Are these files his or did they come from somewhere else? My current state of affairs (not quite ready for prime time) is in: http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summa… Things I'm working on: * Added a "of" command to dump the blob * Works well enough but is not in its final form * Required a change to vsprintf to parse a "ll" (long long) attribute as well as the existing "q" attribute for 64 bit entries. * Printing a 64 bit entry (example: interrupt "reg" value has two 32 bit entries) doesn't work properly. Example print: interrupt-controller@f8200000 { linux,phandle = <0xf8200000>; #address-cells = <0x00000000>; #interrupt-cells = <0x00000002>; interrupt-controller; reg = <0x00000000f8200004>; built-in; device_type = "pci-pic"; }; The reg value <0x00000000f8200004> should print <0xf8200000f8200004> or, better(?), <0xf8200000 f8200004> The "better" format listed above is how it appears in the *.dts tree definition, but the ft_dump.c routine doesn't appear to do that format. It sees the size value of 8 and prints it as a single long long rather than two longs (should be just a formatting issue, but currently the print is broken). Note that the tree itself appears to be OK, looking at the ASM output file. * Looking at improving(?) the build mechanism * Use the "asm" output format rather than a binary dump and then regeneration via xxd. * My thought (unimplemented as of yet) is to append "_of" to the configuration so "PQ2FADS-ZU_lowboot_config" would become "PQ2FADS-ZU_lowboot_config_of" for the OF version. The configuration mechanism would then add the definition FTOBJS := pq2fads.o to the "include/config.mk" file. * Questions: * Is the "_of" tag reasonable or is there a better way? I'm assuming we don't want to force everybody with an ADS-type board over to using OF. * Where should we put the original *.dts files? I picked up the original mpc8260ads.dts file from the kernel source, Vitaly Bordug's repository: linux-2.6-PQ/arch/powerpc/boot/dts/mpc8272ads.dts I forgot what the agreement ended up being for ownership between the kernel people and Wolfgang (if there was any agreement ;-). gvb

2 2

Re: [U-Boot-Users] nand flash controller on 440ep/epx
by Jeff Mann 09 Oct '06

09 Oct '06

Stefan: >Use the least significant 2 bit's in the CFG_NAND_BASE_LIST to select the CS. >In your case this would look like this: >#define CFG_NAND_BASE_LIST { CFG_NAND_BASE + 1, CFG_NAND_BASE + 2 } >The driver could then configure the correct CS in the new device select function, and would of course mask the least significant 2 bit's in the IO_ADDR_W/_R accesses. >Is this too "hackish"? That would work. Is simple, and would work for initialization. It would involve using a proper mask for nand_baseaddr[..] when setting the location of the nand read/write/control registers to ignore the CS data. So..... Nand_init(...) calls nand_init_chip(...) which then calls board_nand_init(...) I think the most appropriate place to select the proper Chip select is in the board_nand_init() function. This function is only passed an address of the chip nand_chip struct address. So I still think that an entry in the nand_chip struct should be used for tracking the chip select to keep the chip select code out of nand.c and keep the code as simple as possible. So, I like the #define CFG_NAND_BASE_LIST { CFG_NAND_BASE + 1, CFG_NAND_BASE + 2 } configuration method, but I still think that the struct nand_chip needs a chip select variable. Do we assume the use of the nand flash controller on PPC 440 EP, Epx, GP, and GPx processors by default (unless still using the legacy drivers like the bamboo board)? What do you think? -Jeff

2 1

[U-Boot-Users] [PATCH, 4th resend] Support uImage files for the AVR32 architecture
by Haavard Skinnemoen 09 Oct '06

09 Oct '06

Define IH_CPU_AVR32, make it possible to generate AVR32 uImage files with mkimage and make cmd_bootm recognize them. Signed-off-by: Haavard Skinnemoen <hskinnemoen(a)atmel.com> --- I've already sent this patch three times to the list, and I have still not gotten any response. It is really important for us to know if you intend to merge this or not; until then, there is no point for us to change the architecture ID as there will still be a possibility that someone else comes along and takes it. Keeping the current AVR32 architecture ID will mean that our version of busybox will be incompatible with the upstream version because it clashes with the Blackfin ID. And the longer it takes before we get an "official" ID, the harder it will be for us to change it. So if we don't get this issue resolved soon, I see no point in trying to contribute our changes back to you at all. This would be very unfortunate and effectively create an incompatible fork of u-boot with small chances of ever merging in the future. It's up to you. Haavard common/cmd_bootm.c | 3 +++ include/image.h | 1 + tools/mkimage.c | 1 + 3 files changed, 5 insertions(+), 0 deletions(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index fdf7180..2168e67 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -260,6 +260,8 @@ #elif defined(__nios2__) if (hdr->ih_arch != IH_CPU_NIOS2) #elif defined(__blackfin__) if (hdr->ih_arch != IH_CPU_BLACKFIN) +#elif defined(__avr32__) + if (hdr->ih_arch != IH_CPU_AVR32) #else # error Unknown CPU type #endif @@ -1236,6 +1238,7 @@ #endif case IH_CPU_INVALID: arch = "Invalid CPU"; break; case IH_CPU_ALPHA: arch = "Alpha"; break; case IH_CPU_ARM: arch = "ARM"; break; + case IH_CPU_AVR32: arch = "AVR32"; break; case IH_CPU_I386: arch = "Intel x86"; break; case IH_CPU_IA64: arch = "IA64"; break; case IH_CPU_MIPS: arch = "MIPS"; break; diff --git a/include/image.h b/include/image.h index 139df0b..d9f2d46 100644 --- a/include/image.h +++ b/include/image.h @@ -76,6 +76,7 @@ #define IH_CPU_NIOS 13 /* Nios-32 */ #define IH_CPU_MICROBLAZE 14 /* MicroBlaze */ #define IH_CPU_NIOS2 15 /* Nios-II */ #define IH_CPU_BLACKFIN 16 /* Blackfin */ +#define IH_CPU_AVR32 17 /* AVR32 */ /* * Image Types diff --git a/tools/mkimage.c b/tools/mkimage.c index fea3e5b..2cb2524 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -94,6 +94,7 @@ table_entry_t arch_name[] = { { IH_CPU_SPARC, "sparc", "SPARC", }, { IH_CPU_SPARC64, "sparc64", "SPARC 64 Bit", }, { IH_CPU_BLACKFIN, "blackfin", "Blackfin", }, + { IH_CPU_AVR32, "avr32", "AVR32", }, { -1, "", "", }, }; -- 1.4.1.1

4 7

[U-Boot-Users] [Fwd: How to flash new u-boot files in NAND flash without JTAG adaptator ?]
by bertrand.mercier 09 Oct '06

09 Oct '06

2 1

[U-Boot-Users] Problem when booting on NOR flash : kernel booting is stopped : why ?
by bertrand.mercier 09 Oct '06

09 Oct '06

Hello, Our hardware context: We have a DaVinci TMSDM6446 target board. Our Problem : When CS2 ChipSelect is on "FLASH" = NOR and S3 red switch = 1010111111 (COUT0 on left to YOUT0 on right) So we boot from NOR flash, then on the gtkterm emulator terminal, we see that the kernel booting is stopped just after "booting the." string (see below or enclosure file ) : U-Boot 1.1.3 (Mar 15 2006 - 11:42:19) U-Boot code: 81080000 -> 81097320 BSS: -> 810A0230 RAM Configuration: Bank #0: 80000000 256 MB MY AMD Flash: 16 MB In: serial Out: serial Err: serial ARM Clock :- 283MZ DDR Clock :- 189MZ Hit any key to stop autoboot: 3 2 1 0 ## Booting image at 02050000 ... Image Name: Linux-2.6.10_mvl402 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1322948 Bytes = 1.3 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux..................................................................................... done, booting the. Questions : 1- What is occured in your oppinion ? 2- How can I debug this ? with which tools ? I've no JTAG available for the moment. thank you Bertrand MERCIER 01 64 53 80 27 bertrand.mercier(a)tesbv.com

1 0

[U-Boot-Users] Buffer overflow in print_data() in ft_build.c
by Fredrik Roubert 09 Oct '06

09 Oct '06

Hi! In print_data() in ft_build.c, printf() is used to print strings of arbitrary length from the device tree, which will cause a buffer overflow that crashes U-Boot if any of these strings is longer than CFG_PBSIZE. (I encountered this while debugging my flat device tree while having a very long kernel parameter line.) The attached patch changes print_data() to use puts() instead, which doesn't have the buffer overflow problem. Cheers // Fredrik Roubert -- Visserij 192 | +32 473 344527 / +46 708 776974 BE-9000 Gent | http://www.df.lth.se/~roubert/ diff -ur u-boot-2006-06-30-2020.orig/common/ft_build.c u-boot-2006-06-30-2020/common/ft_build.c --- u-boot-2006-06-30-2020.orig/common/ft_build.c 2006-06-30 20:16:37.000000000 +0200 +++ u-boot-2006-06-30-2020/common/ft_build.c 2006-10-09 12:12:56.000000000 +0200 @@ -293,7 +293,9 @@ return; if (is_printable_string(data, len)) { - printf(" = \"%s\"", (char *)data); + puts(" = \""); + puts(data); + puts("\""); return; }

2 1

[U-Boot-Users] [QUESTION] INCA-IP2
by KRONSTORFER Horst 09 Oct '06

09 Oct '06

hi! anybody working on supporting this chip right now? regards -h

2 1

[U-Boot-Users] [patch] move ar flags to ARFLAGS
by Mike Frysinger 09 Oct '06

09 Oct '06

i like to run `make -s` to better pick out warnings and stuff ... the hardcoded "$(AR) crv" gets in the way ive moved all of the "crv" stuff to the toplevel config.mk as ARFLAGS so people can change as they see fit without having to edit a ton of makefiles -mike

2 1

[U-Boot-Users] [patch] change-post-behaviour-for-tqm5200-boards
by Martin Krause 09 Oct '06

09 Oct '06

Change POST behaviour for TQM5200 boards Patch by Martin Krause, 8 Mar 2006 Now a POST memory test is only performed on STK52XX base boards (and there only if pin PSC6_3 is read as "1" during boot time). On all other TQM5200 base boards no memory test is performed during POST (regardless of the state of pin PSC6_3). Signed-off-by: Martin Krause <martin.krause(a)tqs.de> CHANGELOG: * Change POST behaviour for TQM5200 boards Patch by Martin Krause, 8 Mar 2006

2 3