From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 21 Nov 2006 13:33:23 -0500 Subject: [U-Boot-Users] Reading out version_string from a binary In-Reply-To: <20061121130236.GC3803@igloo.df.lth.se> References: <20061121130236.GC3803@igloo.df.lth.se> Message-ID: <45634673.2060800@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Fredrik Roubert wrote: > Hi! > > I use U-Boot (1.1.4) on a custom PowerPC (MPC8347) based board, and from > my application I need to read out the value of version_string from the > U-Boot binary, for logging. I've written some code that does this (see > attached sample program), but would like some comments if someone has > suggestions on how to do it more robust. > > On MPC83XX, version_string is stored at the beginning of .rodata, so if > only the offset for .rodata is found, reading out version_string is > quite straightforward. > > The offset of .rodata changes, however, when code is added or removed > from U-Boot. I've found that an offset is being written at the end of > start.o, from which it is possible to calculate the offset of .rodata, > and even though this works for my current needs, it's hardly what one > would call a robust solutions. > > Does anyone have ideas about a better way to do this? > > Cheers // Fredrik Roubert Looking in cpu/mpc83xx/start.S I find: /* * Version string - must be in data segment because MPC83xx uses the * first 256 bytes for the Hard Reset Configuration Word table (see * below). Similarly, can't have the U-Boot Magic Number as the first * thing in the image - don't know how this will affect the image tools, * but I guess I'll find out soon. */ .data .globl version_string version_string: .ascii U_BOOT_VERSION .ascii " (", __DATE__, " - ", __TIME__, ")" .ascii " ", CONFIG_IDENT_STRING, "\0" so your statement that it is in .rodata is only part of the story - it actually is in .data but is initialized so a copy is in .rodata. I see several ways to accomplish what you want. 1) (Easiest) Duplicate the above stuff at a fixed location. The best fixed location would be in the gap between the HRCW and the 0x100 trap offset. Big hole, mostly unused, fixed location. Problem solved, at least for the 83xx CPU and potentially could be applied to most or all of the PowerPC family. 2) Put the above string in a new section and use the linker control file (lds) to put it in a fixed location, at least for your board. Lots of work with no obvious benefit and more hassle (unnecessary fixed locations are Evil). 3) Variant of #1: the string _should be_ constant, and having someone scribbling on it (which .data implies is permissible) would be a Bad Thing[tm] in my book. The variant on #1 would be to _move_ the string (rather than replicate it) after the HRCW in the .text section in start.S and fix up the users of the string so that they can find it OK after relocation. You could make an argument that this is a Better Way[tm]. gvb