Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #32148

Re: Patch fixed strings in .hex file

Show all headers | View raw

On 2024-01-17, Stefan Reuther <stefan.news@arcor.de> wrote:
> 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.

Yes, defintely that.  Or make the packing explicit.  And add compile
time checks to verify the offsets of fields withing the structure and
fail if they're not what is expected.  That has saved my many times.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 13:19 +0100
  Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 13:51 +0100
    Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 15:42 +0100
      Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 16:36 +0100
        Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 16:57 +0100
      Re: Patch fixed strings in .hex file dalai lamah <antonio12358@hotmail.com> - 2024-01-16 16:47 +0100
        Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 18:50 +0100
  Re: Patch fixed strings in .hex file Herbert Kleebauer <klee@unibwm.de> - 2024-01-16 15:07 +0100
    Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 15:42 +0100
  Re: Patch fixed strings in .hex file Grant Edwards <invalid@invalid.invalid> - 2024-01-16 15:24 +0000
    Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 16:38 +0100
      Re: Patch fixed strings in .hex file Grant Edwards <invalid@invalid.invalid> - 2024-01-16 18:32 +0000
    Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 17:01 +0100
  Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 16:39 +0100
    Re: Patch fixed strings in .hex file Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2024-01-17 20:19 +0200
  Re: Patch fixed strings in .hex file Stefan Reuther <stefan.news@arcor.de> - 2024-01-16 17:44 +0100
    Re: Patch fixed strings in .hex file Grant Edwards <invalid@invalid.invalid> - 2024-01-16 18:39 +0000
    Re: Patch fixed strings in .hex file Michael Schwingen <news-1513678000@discworld.dascon.de> - 2024-01-16 19:30 +0000
  Re: Patch fixed strings in .hex file Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2024-01-16 19:35 +0100
    Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-17 08:45 +0100
      Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-17 09:07 +0100
      Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-17 11:27 +0100
        Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-17 12:54 +0100
          Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-17 13:54 +0100
          Re: Patch fixed strings in .hex file Stefan Reuther <stefan.news@arcor.de> - 2024-01-17 17:39 +0100
            Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-17 18:28 +0100
            Re: Patch fixed strings in .hex file Grant Edwards <invalid@invalid.invalid> - 2024-01-17 19:00 +0000
            Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-19 09:10 +0100
      Re: Patch fixed strings in .hex file Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2024-01-18 18:49 +0100
  Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-17 09:57 +0100
  Re: Patch fixed strings in .hex file Don Y <blockedofcourse@foo.invalid> - 2024-01-17 10:03 -0700
  Re: Patch fixed strings in .hex file Paul Rubin <no.email@nospam.invalid> - 2024-01-17 21:42 -0800

csiph-web