April 2008 - U-Boot

Re: [U-Boot-Users] Fixup entries
by kenneth johansson 10 Apr '08

10 Apr '08

On Thu, 2008-04-10 at 01:03 +0200, Joakim Tjernlund wrote: > > -----Original Message----- > > From: kenneth johansson [mailto:kenneth@southpole.se] > > Sent: den 10 april 2008 01:00 > > To: Joakim Tjernlund > > Cc: u-boot-users(a)lists.sourceforge.net > > Subject: RE: [U-Boot-Users] Fixup entries > > > > On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote: > > > > > > > -----Original Message----- > > > > From: Kenneth Johansson [mailto:kenneth@southpole.se] > > > > Wonder if there is something else in u-boot that use function pointers > > > > and work by accident due to the fact that the old address in flash is > > > > still valid. > > > > > > Oh yes, there are a few such pointers. And the conversion to using fixups instead > > > is a bit lazy. Several manual relocations has only been nullified by setting > > > gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel > > > free to send patches :) > > > > > > Jocke > > > > > > > If by lazy you mean less error prone and obviously simpler :). clearly > > using -mrelocatable is the smarter thing to do. > > > > I had this misconception that the GOT was all that was needed for > > relocation. > > Could not find any useful information on what rules apply to gcc and > > binutils for handling stuff in this fixup section. > > > > Anybody have any information on this? > > Nope, never found anything either. To see a working one in u-boot, look at > mpc83xx start.S and its linker scripts. I have it working that is not the problem the problem is that I would like to know why it is :-)

1 0

Re: [U-Boot-Users] Fixup entries
by kenneth johansson 10 Apr '08

10 Apr '08

On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote: > > > -----Original Message----- > > From: Kenneth Johansson [mailto:kenneth@southpole.se] > > Wonder if there is something else in u-boot that use function pointers > > and work by accident due to the fact that the old address in flash is > > still valid. > > Oh yes, there are a few such pointers. And the conversion to using fixups instead > is a bit lazy. Several manual relocations has only been nullified by setting > gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel > free to send patches :) > > Jocke > If by lazy you mean less error prone and obviously simpler :). clearly using -mrelocatable is the smarter thing to do. I had this misconception that the GOT was all that was needed for relocation. Could not find any useful information on what rules apply to gcc and binutils for handling stuff in this fixup section. Anybody have any information on this?

2 1

[U-Boot-Users] FIS DTC
by Michal Simek 09 Apr '08

09 Apr '08

Hi Jon, David and others, I am working on FIS for Microblaze CPU. I would like to use it. I have one problem. I download latest DTC version from Jon git server. Version: DTC 1.1.0-g1577696b I tryied to convert DTS to DTB for Microblaze CPU. (DTS is below) #dtc -f -O dtb -b 0 -V 16 system.dts DTC: dts->dtb on file "system.dts" system.dts:27 syntax error FATAL ERROR: Couldn't read input tree I got this error - I don't understand what is wrong. Older DTC version has no problem with it. This part is no problem - I can use older version of DTC(Version: DTC 1.1.0-g2512a7eb-dirty ). The second things is around mkimage utility. I want to generate ITB file from ITS description. Latest DTC compiler has problem with it too. Can you tell me which version are you using? I tryied to complile ITS to ITB with older DTC version and this version don't know about data label in kernel specification. I had no problem to add (for FDT + kernel version) DTB file but kernel file is not loaded. Is label data = "/incbin/("./linux.bin")"; OK? linux bin is in the same dirctore where is microblaze.its file. Latest DTC has problem with ITS too $ mkimage -f microblaze.its microblaze.itb FIT format handling Trying to execute "dtc -I dts -O dtb -p 500 microblaze.its > microblaze.itb.tmp" DTC: dts->dtb on file "microblaze.its" microblaze.its:5 syntax error FATAL ERROR: Couldn't read input tree mkimage: Can't read microblaze.itb.tmp: Invalid argument $ dtc -v Version: DTC 1.1.0-g1577696b [monstr@monstr linux-eu-2.6.24]$ # mkimage -f microblaze.its microblaze.itb FIT format handling Trying to execute "dtc -I dts -O dtb -p 500 microblaze.its > microblaze.itb.tmp" DTC: dts->dtb on file "microblaze.its" microblaze.its:5 syntax error FATAL ERROR: Couldn't read input tree mkimage: Can't read microblaze.itb.tmp: Invalid argument # cat -n microblaze.its 1 /* 2 * Simple U-boot uImage source file containing a single kernel 3 */ 4 / { 5 description = "Simple image with single Linux kernel"; 6 #address-cells = <1>; 7 8 images { 9 kernel@1 { 10 description = "Vanilla Linux kernel"; 11 data = /incbin/("./linux.bin"); 12 type = "kernel"; 13 arch = "microblaze"; 14 os = "linux"; 15 compression = "none"; 16 load = <20000000>; 17 entry = <20000000>; 18 hash@1 { 19 algo = "crc32"; 20 }; 21 hash@2 { 22 algo = "sha1"; 23 }; 24 }; 25 }; 26 27 configurations { 28 default = "config@1"; 29 config@1 { 30 description = "Boot Linux kernel"; 31 kernel = "kernel@1"; 32 }; 33 }; 34 }; Thanks for help, Michal Simek www.monstr.eu 1 /* 2 * (C) Copyright 2007-2008 Michal Simek 3 * 4 * Michal SIMEK <monstr(a)monstr.eu> 5 * 6 * This program is free software; you can redistribute it and/or 7 * modify it under the terms of the GNU General Public License as 8 * published by the Free Software Foundation; either version 2 of 9 * the License, or (at your option) any later version. 10 * 11 * This program is distributed in the hope that it will be useful, 12 * but WITHOUT ANY WARRANTY; without even the implied warranty of 13 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 14 * GNU General Public License for more details. 15 * 16 * You should have received a copy of the GNU General Public License 17 * along with this program; if not, write to the Free Software 18 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, 19 * MA 02111-1307 USA 20 * 21 * CAUTION: This file is automatically generated by libgen. 22 * Version: Xilinx EDK 9.2.02 EDK_Jm_SP2.3 23 * Generate by FDT v1.00.a 24 */ 25 26 / { 27 #address-cells = <1>; 28 #size-cells = <1>; 29 compatible = "xlnx,microblaze"; 30 model = "testing"; 31 DDR_SDRAM_32Mx16: memory@20000000 { 32 device_type = "memory"; 33 reg = < 20000000 4000000 >; 34 } ; 35 chosen { 36 bootargs = "root=/dev/xsysace/disc0/part2"; 37 } ; 38 cpus { 39 #address-cells = <1>; 40 #cpus = <1>; 41 #size-cells = <0>; 42 cpu@0 { 43 clock-frequency = <2faf080>; 44 compatible = "xlnx,microblaze-7.00.a"; 45 d-cache-baseaddr = <20000000>; 46 d-cache-highaddr = <21ffffff>; 47 d-cache-line-size = <10>; 48 d-cache-size = <4000>; 49 device_type = "cpu"; 50 i-cache-baseaddr = <20000000>; 51 i-cache-highaddr = <21ffffff>; 52 i-cache-line-size = <10>; 53 i-cache-size = <4000>; 54 model = "microblaze,7.00.a"; 55 reg = <0>; 56 timebase-frequency = <2faf080>; 57 xlnx,addr-tag-bits = <b>; 58 xlnx,allow-dcache-wr = <1>; 59 xlnx,allow-icache-wr = <1>; 60 xlnx,area-optimized = <0>; 61 xlnx,cache-byte-size = <4000>; 62 xlnx,d-lmb = <1>; 63 xlnx,d-opb = <0>; 64 xlnx,d-plb = <1>; 65 xlnx,data-size = <20>; 66 xlnx,dcache-addr-tag = <b>; 67 xlnx,dcache-byte-size = <4000>; 68 xlnx,dcache-line-len = <4>; 69 xlnx,dcache-use-fsl = <1>; 70 xlnx,debug-enabled = <1>; 71 xlnx,div-zero-exception = <1>; 72 xlnx,dopb-bus-exception = <0>; 73 xlnx,dynamic-bus-sizing = <1>; 74 xlnx,edge-is-positive = <1>; 75 xlnx,family = "spartan3e"; 76 xlnx,fpu-exception = <1>; 77 xlnx,fsl-data-size = <20>; 78 xlnx,fsl-exception = <0>; 79 xlnx,fsl-links = <1>; 80 xlnx,i-lmb = <1>; 81 xlnx,i-opb = <0>; 82 xlnx,i-plb = <1>; 83 xlnx,icache-line-len = <4>; 84 xlnx,icache-use-fsl = <1>; 85 xlnx,ill-opcode-exception = <1>; 86 xlnx,instance = "microblaze_0"; 87 xlnx,interconnect = <1>; 88 xlnx,interrupt-is-edge = <0>; 89 xlnx,iopb-bus-exception = <0>; 90 xlnx,mmu-dtlb-size = <4>; 91 xlnx,mmu-itlb-size = <2>; 92 xlnx,mmu-tlb-access = <3>; 93 xlnx,mmu-zones = <2>; 94 xlnx,number-of-pc-brk = <2>; 95 xlnx,number-of-rd-addr-brk = <0>; 96 xlnx,number-of-wr-addr-brk = <0>; 97 xlnx,opcode-0x0-illegal = <1>; 98 xlnx,pvr = <2>; 99 xlnx,pvr-user1 = <12>; 100 xlnx,pvr-user2 = <12345678>; 101 xlnx,reset-msr = <0>; 102 xlnx,sco = <0>; 103 xlnx,unaligned-exceptions = <1>; 104 xlnx,use-barrel = <1>; 105 xlnx,use-dcache = <1>; 106 xlnx,use-div = <1>; 107 xlnx,use-extended-fsl-instr = <0>; 108 xlnx,use-fpu = <2>; 109 xlnx,use-hw-mul = <2>; 110 xlnx,use-icache = <1>; 111 xlnx,use-mmu = <3>; 112 xlnx,use-msr-instr = <1>; 113 xlnx,use-pcmp-instr = <1>; 114 } ; 115 } ; 116 mb_plb: plb@0 { 117 #address-cells = <1>; 118 #size-cells = <1>; 119 compatible = "xlnx,plb-v46-1.00.a"; 120 ranges ; 121 Buttons_3Bit: gpio@40800000 { 122 compatible = "xlnx,xps-gpio-1.00.a"; 123 interrupt-parent = <&xps_intc_0>; 124 interrupts = < 6 2 >; 125 reg = < 40800000 100000 >; 126 xlnx,all-inputs = <1>; 127 xlnx,all-inputs-2 = <0>; 128 xlnx,dout-default = <0>; 129 xlnx,dout-default-2 = <0>; 130 xlnx,family = "spartan3e"; 131 xlnx,gpio-width = <3>; 132 xlnx,interrupt-present = <1>; 133 xlnx,is-bidir = <0>; 134 xlnx,is-bidir-2 = <1>; 135 xlnx,is-dual = <0>; 136 xlnx,tri-default = <ffffffff>; 137 xlnx,tri-default-2 = <ffffffff>; 138 } ; 139 Character_LCD_2x16: gpio@40900000 { 140 compatible = "xlnx,xps-gpio-1.00.a"; 141 reg = < 40900000 100000 >; 142 xlnx,all-inputs = <0>; 143 xlnx,all-inputs-2 = <0>; 144 xlnx,dout-default = <0>; 145 xlnx,dout-default-2 = <0>; 146 xlnx,family = "spartan3e"; 147 xlnx,gpio-width = <7>; 148 xlnx,interrupt-present = <0>; 149 xlnx,is-bidir = <1>; 150 xlnx,is-bidir-2 = <1>; 151 xlnx,is-dual = <0>; 152 xlnx,tri-default = <ffffffff>; 153 xlnx,tri-default-2 = <ffffffff>; 154 } ; 155 DIP_Switches_4Bit: gpio@40700000 { 156 compatible = "xlnx,xps-gpio-1.00.a"; 157 interrupt-parent = <&xps_intc_0>; 158 interrupts = < 7 2 >; 159 reg = < 40700000 100000 >; 160 xlnx,all-inputs = <1>; 161 xlnx,all-inputs-2 = <0>; 162 xlnx,dout-default = <0>; 163 xlnx,dout-default-2 = <0>; 164 xlnx,family = "spartan3e"; 165 xlnx,gpio-width = <4>; 166 xlnx,interrupt-present = <1>; 167 xlnx,is-bidir = <0>; 168 xlnx,is-bidir-2 = <1>; 169 xlnx,is-dual = <0>; 170 xlnx,tri-default = <ffffffff>; 171 xlnx,tri-default-2 = <ffffffff>; 172 } ; 173 Ethernet_MAC: ethernet@40c00000 { 174 compatible = "xlnx,xps-ethernetlite-1.00.a"; 175 device_type = "network"; 176 interrupt-parent = <&xps_intc_0>; 177 interrupts = < 2 0 >; 178 local-mac-address = [ 00 00 00 00 00 00 ]; 179 reg = < 40c00000 100000 >; 180 xlnx,duplex = <1>; 181 xlnx,family = "spartan3e"; 182 xlnx,rx-ping-pong = <0>; 183 xlnx,tx-ping-pong = <0>; 184 } ; 185 LEDs_8Bit: gpio@40600000 { 186 compatible = "xlnx,xps-gpio-1.00.a"; 187 reg = < 40600000 100000 >; 188 xlnx,all-inputs = <0>; 189 xlnx,all-inputs-2 = <0>; 190 xlnx,dout-default = <0>; 191 xlnx,dout-default-2 = <0>; 192 xlnx,family = "spartan3e"; 193 xlnx,gpio-width = <8>; 194 xlnx,interrupt-present = <0>; 195 xlnx,is-bidir = <0>; 196 xlnx,is-bidir-2 = <1>; 197 xlnx,is-dual = <0>; 198 xlnx,tri-default = <ffffffff>; 199 xlnx,tri-default-2 = <ffffffff>; 200 } ; 201 RS232_DCE: serial@40200000 { 202 compatible = "xlnx,xps-uart16550-1.00.a"; 203 interrupt-parent = <&xps_intc_0>; 204 interrupts = < 4 2 >; 205 reg = < 40200000 100000 >; 206 xlnx,family = "spartan3e"; 207 xlnx,has-external-rclk = <0>; 208 xlnx,has-external-xin = <0>; 209 xlnx,is-a-16550 = <1>; 210 } ; 211 RS232_DTE: serial@40100000 { 212 compatible = "xlnx,xps-uartlite-1.00.a"; 213 interrupt-parent = <&xps_intc_0>; 214 interrupts = < 3 0 >; 215 reg = < 40100000 100000 >; 216 xlnx,baudrate = <1c200>; 217 xlnx,data-bits = <8>; 218 xlnx,family = "spartan3e"; 219 xlnx,odd-parity = <0>; 220 xlnx,use-parity = <0>; 221 } ; 222 SPI_FLASH: xps-spi@40a00000 { 223 compatible = "xlnx,xps-spi-1.00.a"; 224 interrupt-parent = <&xps_intc_0>; 225 interrupts = < 5 2 >; 226 reg = < 40a00000 100000 >; 227 xlnx,family = "spartan3e"; 228 xlnx,fifo-exist = <1>; 229 xlnx,num-offchip-ss-bits = <4>; 230 xlnx,num-ss-bits = <4>; 231 xlnx,sck-ratio = <20>; 232 } ; 233 debug_module: debug@40300000 { 234 compatible = "xlnx,mdm-1.00.a"; 235 reg = < 40300000 100000 >; 236 xlnx,family = "spartan3e"; 237 xlnx,interconnect = <1>; 238 xlnx,jtag-chain = <2>; 239 xlnx,mb-dbg-ports = <1>; 240 xlnx,uart-width = <8>; 241 xlnx,use-uart = <1>; 242 xlnx,write-fsl-ports = <1>; 243 } ; 244 mpmc@20000000 { 245 #address-cells = <1>; 246 #size-cells = <1>; 247 compatible = "xlnx,mpmc-3.00.a"; 248 } ; 249 xps_intc_0: interrupt-controller@40000000 { 250 #interrupt-cells = <2>; 251 compatible = "xlnx,xps-intc-1.00.a"; 252 interrupt-controller ; 253 reg = < 40000000 100000 >; 254 xlnx,num-intr-inputs = <8>; 255 } ; 256 xps_timer_0: timer@40400000 { 257 compatible = "xlnx,xps-timer-1.00.a"; 258 interrupt-parent = <&xps_intc_0>; 259 interrupts = < 0 2 >; 260 reg = < 40400000 100000 >; 261 xlnx,count-width = <20>; 262 xlnx,family = "spartan3e"; 263 xlnx,gen0-assert = <1>; 264 xlnx,gen1-assert = <1>; 265 xlnx,one-timer-only = <0>; 266 xlnx,trig0-assert = <1>; 267 xlnx,trig1-assert = <1>; 268 } ; 269 xps_timer_1: timer@40500000 { 270 compatible = "xlnx,xps-timer-1.00.a"; 271 interrupt-parent = <&xps_intc_0>; 272 interrupts = < 1 2 >; 273 reg = < 40500000 100000 >; 274 xlnx,count-width = <20>; 275 xlnx,family = "spartan3e"; 276 xlnx,gen0-assert = <1>; 277 xlnx,gen1-assert = <1>; 278 xlnx,one-timer-only = <1>; 279 xlnx,trig0-assert = <1>; 280 xlnx,trig1-assert = <1>; 281 } ; 282 } ; 283 } ;

4 6

[U-Boot-Users] Fixup entries
by Kenneth Johansson 09 Apr '08

09 Apr '08

What is the fixup section used for ? of the 274 cards that build on my MAKEALL not one has any entries into this section.

3 3

[U-Boot-Users] Make your rod massive
by mcmanus 09 Apr '08

09 Apr '08

Get your lady's attention like never before, visit our website here now http://www.Candibers.com/

1 0

Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
by Stefan Roese 09 Apr '08

09 Apr '08

On Tuesday 08 April 2008, Joakim Tjernlund wrote: > > > Anyhow, we can go with the other solution instead, define the symbol in > > > start.S instead, if one is needed. > > > > If it cannot be avoided ;-) > > ... Stefan, maybe you can #define EXC_OFF_SYS_RESET for 405 to something > that fits with my relocation patch? Not sure if this could be done, since EXC_OFF_SYS_RESET is used for other things as well, and changing its value might bring other problems. And this really sounds like a bad hack, to change EXC_OFF_SYS_RESET to something "strange". So, no I don't want to fix this problem this way. Since I'm really short in time currently, and I need U-Boot running on 4xx again, I vote for reverting this patch now. I'll try to come up with a "generic" solution for the next merge window. Wolfgang? What do you think? Best regards, Stefan ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office(a)denx.de =====================================================================

3 4

Re: [U-Boot-Users] Linux kernel startup (s3c24xx)
by Tiju 09 Apr '08

09 Apr '08

Hi Herald, >> We changed the memory clock to a lower frequency(90MHz to 67MHz) and >> the the "Bad Data CRC" error has gone. Thanks alot. >ok, this most likely means that you have some problems with your >hardware design, probably exceeding the maximum permitted capacitive bus >load. >well, how do you copy the image into ram? It doesn't really matter from >where the image is copied. What matters is that apparently the source >of the copy is not equal to the destination of the copy. Even if you >copy 'directly' via JTAG there is a source and a destination. and the >destination will suffer through corruption if SDRAM timing or bus clock >are wrong. The settings for the UPLLCON and MPLLCON were being done for 16MHz external clock. Now we have changed that and made the settings for 12MHz clock(our board clock). Now, core is running at 271.5MHz, and the rest at 1:8:16 (FCLK:HCLK:PCLK). Now we have managed to get the output as follows: U-Boot 1.3.2 (Apr 9 2008 - 09:45:21) DRAM: 1 Flash: 32 MB Using default environment In: serial Out: serial Err: serial Hit any key to stop autoboot: 3 U-Boot 1.3.2 (Apr 9 2008 - 09:45:21) DRAM: 128 MB Flash: 32 MB Using default environment In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting image at 33000000 ... Image Name: Linux kernel Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 1167125 Bytes = 1.1 MB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... Uncompressing Linux.............................................................. ................ done, booting the kernel. and then it hangs. We are writing the kernel image directly to the ram to 33000000 via JTAG. How do I proceed from here? Thanks alot for your previous mails. It is helping us alot in debugging the hardware and softwares. Thank You, Tiju From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/

2 1

Re: [U-Boot-Users] Linux kernel startup (s3c24xx)
by Tiju 09 Apr '08

09 Apr '08

Hi Herald, The environment variables are as follows: DPB2440 # printenv bootargs=root=ramfs devfs=mount console=ttyS0,115200 bootcmd=bootm bootdelay=3 baudrate=115200 bootfile="uImage.bin" stdin=serial stdout=serial stderr=serial Thankyou, Best Regards, Tiju Bollywood, fun, friendship, sports and more. You name it, we have it on http://in.promos.yahoo.com/groups/bestofyahoo/

1 0

[U-Boot-Users] [PATCH/review] Blackfin: fix up comment about CONFIG_BFIN_BOOT_MODE
by Mike Frysinger 09 Apr '08

09 Apr '08

Looks like I missed one place in the BFIN_BOOT_MODE -> CONFIG_BFIN_BOOT_MODE. Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- include/asm-blackfin/blackfin-config-pre.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-blackfin/blackfin-config-pre.h b/include/asm-blackfin/blackfin-config-pre.h index f2c44f7..93e95d6 100644 --- a/include/asm-blackfin/blackfin-config-pre.h +++ b/include/asm-blackfin/blackfin-config-pre.h @@ -1,7 +1,7 @@ /* * blackfin-config-pre.h - common defines for Blackfin boards in config.h * - * Copyright (c) 2007 Analog Devices Inc. + * Copyright (c) 2007-2008 Analog Devices Inc. * * Licensed under the GPL-2 or later. */ @@ -20,7 +20,7 @@ #define CFG_BFIN_CMD_OTP 0x04 #define CFG_BFIN_CMD_CACHE_DUMP 0x08 -/* Bootmode defines -- your config needs to select this via BFIN_BOOT_MODE. +/* Bootmode defines -- your config needs to select this via CONFIG_BFIN_BOOT_MODE. * Depending on your cpu, some of these may not be valid, check your HRM. * The actual values here are meaningless as long as they're unique. */ -- 1.5.4.4

1 1

Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
by David Hawkins 09 Apr '08

09 Apr '08

Hi Joakim, >> See for example cpu/mpc8xx/start.S - while at the moment we really >> start with .text, it would technically be more approrpriate to change >> the first 256 bytes (from monitor base to EXC_OFF_SYS_RESET) into >> .rodata or something like this. > > Ahh, now I see what you mean and it gave me an idea ... While you're chewing on ideas, here's a couple of points about mpc83xx/start.S The reset configuration words that start at the beginning of Flash are *optional*, and depend on the reset configurations words source pin strapping (CFG_RS[0:2]). If CFG_RS[0:2] = 000b, then the RCWs are read from the local bus chip-select 0. Nominally this means read from flash, but hardware can subvert the bus to the flash and supply the RCWs from an alternative source, eg. on the MPC8349EA-MDS-PB, the RCWs can be driven onto the local bus by an on-board CPLD (which in turn gets the RCWs from dip switches). On my custom MPC8349EA board, I can deliver the RCWs from the Flash, or if flash is blank, from the FPGA, or I can change the CFG_RS[0:2] source so that the processor uses hard-coded RCWs, or an I2C boot EEPROM. If the RCWs were placed in their own section, then that section could be made optional. In the case of it being used, and boot-low being used (RCWH[BMS] = 0), then the RCW+U-Boot magic+string section would need be 100h bytes in size, and be concatenated with the U-Boot image. Otherwise the RCW area could be left as a separate binary image, that the user has to burn to Flash. (Eg. for a user that for some bizarre reason wants to put RCWH[BMS] = 1 :) ). How about a 100-byte section called .rcw, or .rcwdata? I'm not sure if these comments will make life easier or worse ... Cheers, Dave

1 0