From: Mike Frysinger Date: Wed, 10 Oct 2007 19:18:47 -0400 Subject: [U-Boot-Users] embedding environment by hand In-Reply-To: <20071010230328.A4A2B24899@gemini.denx.de> References: <20071010230328.A4A2B24899@gemini.denx.de> Message-ID: <200710101918.48152.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wednesday 10 October 2007, Wolfgang Denk wrote: > In message <200710101825.30341.vapier@gentoo.org> you wrote: > > first a little background ... the Blackfin processor has a custom object > > format for booting code (called a "loader file" or "LDR" for short). > > this custom object format is what actually gets burned into say parallel > > or spi or nand flash. i have to hope that the Blackfin processor isnt > > alone in having a custom object format ;), so hopefully the changes i > > propose here will be> useful to others. > > Never heard about such a thing. All the rest of the world is using > ELF as long as images need a structure that must be processable by > tools, and raw binary blobs for anything else. we're talking about the format below that ... "u-boot" is a perfectly standard ELF. however, the processor itself does not understand ELF. so at power on, a few pins tell the processor where to start executing ... parallel, spi, uart, whatever. the processor will start fetching data from the defined place and load up the image into memory. > Don't you use any GNU toolchain there? Isn't there any support for > the GNU linker? Can't you use standard tools? the Blackfin port is fully integrated into the GNU toolchain and doing everything the "correct" way. > > the exact object format is irrelevant here, but the point is that while > > the environment is actually embedded inside of the LDR image, it cannot > > be embedded with the standard method of creating the data array > > "environment" in environment.c and making sure the environment.o object > > gets linked at an exact offset. this is because we take the u-boot.bin > > and run it through another utility to get u-boot.ldr. the offsets in > > u-boot.bin do not correlate in any way to the offsets in u-boot.ldr nor > > can they as the LDR format may different drastically by processor. > > Ummm... this sounds like linking to me, and if your linker tool > performs such shifting and reordering, it also has to adjust the code > that references such shifted or reordered memory. If it doesn't, I > don't understand what it does at all except from corrupting perfectly > good images ;-) i could update BFD and define a new object format so that we could do: objcopy -O LDR u-boot u-boot.ldr but the end result would be exactly the same -- the offset into the binary blow "u-boot.ldr" would not correspond to the offset into the binary blow "u-boot.bin". with these comments in mind, i think you can re-evaluate the previous e-mail ;) > > --- common/environment.c (revision 950) > > +++ common/environment.c (working copy) > > This makes no sense to me. ./tools/envcrc --binary > environment.bin and then this bin file can be given to any other tool so that it can be embedded as need be -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20071010/b62af489/attachment.pgp