Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: comp.arch.embedded Subject: Re: Patch fixed strings in .hex file Date: Wed, 17 Jan 2024 17:39:37 +0100 Lines: 50 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net 7B3mFm6n3VD3JmL7v9BIQw5vdOuBDMdj7w3quR0nYuCWz+6DIc Cancel-Lock: sha1:d0VljqX/CEJp3ia7HESNDzUDLEU= sha256:4zv1/RrdbceyeIY6EEWy7jNvAidAAoV4stwTjhUP+Kg= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com comp.arch.embedded:32144 Am 17.01.2024 um 12:54 schrieb pozz: > Il 17/01/2024 11:27, David Brown ha scritto: >> While it is possible to do all this using patching of odd places in >> your file, using specific locations is often a better choice.  Since >> you haven't already said "Thanks for the advice - I tried it that way, >> it worked, and I'm happy" in response to any post, I would say that >> now is the time to take fixed location solutions seriously. > > There are many suggested solutions and I think all of them can be used > with success. Just for sake of curiosity and studying, I'm exploring all > of them. > > Sincerely I don't *like* solutions where you need to choose a fixed > location by yourself. Why you should make a job that can be done by the > linker? It's not you vs. the linker. You co-operate. You need to tell the linker about your chip anyway ("code is from 0x1000 to 0xc000, data is from 0xc000 to 0xd000"). So you can as well tell it "version stamp is from 0xcc00 to 0xd000, data only before 0xcc00". If you have your identification information in a fixed place, you can, for example, more easily analyze field returns. It's easy for your field service has to change something, and it's easy to do software updates that preserve the identification information. You don't need to figure out which software build is running on the chip and what the address of the structure happens to be in that one. >> Now your post-build scripts have a simple fixed address to patch the >> binaries. > > How the post-build script should know the exact address of a certain > field in the struct? By defining the struct in a compatible way. For example.... > volatile const struct post_build_data { >   uint32_t serial_number; >   uint64_t mac_address; ...this is a bad idea, because in most (but probably not all) chips, uint64_t after uint32_t means there's 32 bits of padding, so if you need serial-before-mac, you should at least make the padding explicit. There also might be endian problems. Using only char/uint8_t fields gives you a very high chance of identical structure layout everywhere (`uint8_t mac_address[8]`). Stefan