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

Groups > comp.arch.embedded > #32120 > unrolled thread

Patch fixed strings in .hex file

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 1 of 2  [1] 2  Next page →

#32120 — Patch fixed strings in .hex file

In one project I have many quasi-fixed strings that I'd like to keep in 
non volatile memory (Flash) to avoid losing precious RAM space.

static const char s1[] = "/my/very/long/string/of/01020304";
static const char s2[] = "/another/string/01020304";
...

Substring "01020304" is a serial number that changes during production 
with specific device. It has the same length in bytes (it's a simple hex 
representation of a 32-bits integer).

Of course it's too difficult and slow to rebuild the firmware during 
production passing to the compiler the real serial number. I think a 
better solution is to patch the .hex file generated by the compiler.

I'm wondering how to detect the exact positions (addresses) of serial 
numbers to fix.

The build system is gcc, so I could search for s1 in the elf file. Do 
you know of a tool that returns the address of a symbol in the elf or 
map file?

Could you suggest a better approach?

[toc] | [next] | [standalone]

#32121

On 16/01/2024 13:19, pozz wrote:
> In one project I have many quasi-fixed strings that I'd like to keep in 
> non volatile memory (Flash) to avoid losing precious RAM space.
> 
> static const char s1[] = "/my/very/long/string/of/01020304";
> static const char s2[] = "/another/string/01020304";
> ...
> 
> Substring "01020304" is a serial number that changes during production 
> with specific device. It has the same length in bytes (it's a simple hex 
> representation of a 32-bits integer).
> 
> Of course it's too difficult and slow to rebuild the firmware during 
> production passing to the compiler the real serial number. I think a 
> better solution is to patch the .hex file generated by the compiler.
> 
> I'm wondering how to detect the exact positions (addresses) of serial 
> numbers to fix.
> 
> The build system is gcc, so I could search for s1 in the elf file. Do 
> you know of a tool that returns the address of a symbol in the elf or 
> map file?
> 
> Could you suggest a better approach?
> 

In the source code, put the serial number in as "PQRXYZ" or some other 
distinct string of characters.  Generate bin files, not hex (or convert 
with objcopy).  Then do a simple search for the special string to find 
its position and replace it with the serial number using a simple Python 
script or your other favourite tool (awk, sed, perl, whatever).

Oh, and in the source code, don't forget to make the string "volatile".

[toc] | [prev] | [next] | [standalone]

#32123

Il 16/01/2024 13:51, David Brown ha scritto:
> On 16/01/2024 13:19, pozz wrote:
>> In one project I have many quasi-fixed strings that I'd like to keep 
>> in non volatile memory (Flash) to avoid losing precious RAM space.
>>
>> static const char s1[] = "/my/very/long/string/of/01020304";
>> static const char s2[] = "/another/string/01020304";
>> ...
>>
>> Substring "01020304" is a serial number that changes during production 
>> with specific device. It has the same length in bytes (it's a simple 
>> hex representation of a 32-bits integer).
>>
>> Of course it's too difficult and slow to rebuild the firmware during 
>> production passing to the compiler the real serial number. I think a 
>> better solution is to patch the .hex file generated by the compiler.
>>
>> I'm wondering how to detect the exact positions (addresses) of serial 
>> numbers to fix.
>>
>> The build system is gcc, so I could search for s1 in the elf file. Do 
>> you know of a tool that returns the address of a symbol in the elf or 
>> map file?
>>
>> Could you suggest a better approach?
>>
> 
> In the source code, put the serial number in as "PQRXYZ" or some other 
> distinct string of characters.  Generate bin files, not hex (or convert 
> with objcopy).  Then do a simple search for the special string to find 
> its position and replace it with the serial number using a simple Python 
> script or your other favourite tool (awk, sed, perl, whatever).

I thought about this approach, but is it so difficult to have the same 
exact sequence of bytes somewhere else in the output?


> Oh, and in the source code, don't forget to make the string "volatile".

Why?

[toc] | [prev] | [next] | [standalone]

#32126

On 16/01/2024 15:42, pozz wrote:
> Il 16/01/2024 13:51, David Brown ha scritto:
>> On 16/01/2024 13:19, pozz wrote:
>>> In one project I have many quasi-fixed strings that I'd like to keep 
>>> in non volatile memory (Flash) to avoid losing precious RAM space.
>>>
>>> static const char s1[] = "/my/very/long/string/of/01020304";
>>> static const char s2[] = "/another/string/01020304";
>>> ...
>>>
>>> Substring "01020304" is a serial number that changes during 
>>> production with specific device. It has the same length in bytes 
>>> (it's a simple hex representation of a 32-bits integer).
>>>
>>> Of course it's too difficult and slow to rebuild the firmware during 
>>> production passing to the compiler the real serial number. I think a 
>>> better solution is to patch the .hex file generated by the compiler.
>>>
>>> I'm wondering how to detect the exact positions (addresses) of serial 
>>> numbers to fix.
>>>
>>> The build system is gcc, so I could search for s1 in the elf file. Do 
>>> you know of a tool that returns the address of a symbol in the elf or 
>>> map file?
>>>
>>> Could you suggest a better approach?
>>>
>>
>> In the source code, put the serial number in as "PQRXYZ" or some other 
>> distinct string of characters.  Generate bin files, not hex (or 
>> convert with objcopy).  Then do a simple search for the special string 
>> to find its position and replace it with the serial number using a 
>> simple Python script or your other favourite tool (awk, sed, perl, 
>> whatever).
> 
> I thought about this approach, but is it so difficult to have the same 
> exact sequence of bytes somewhere else in the output?

Try it and see.

> 
> 
>> Oh, and in the source code, don't forget to make the string "volatile".
> 
> Why?
> 

If you have :

	static const char s1[] = "PQRXYZ";

and your code later does, say :

	const int last_digit = s1[5] - '0';

the compiler will optimise it to :

	const int last_digit = '*';

i.e., it will calculate 'Z' - '0' at compile time - and if I remember by 
ASCII codes correctly, that matches '*'.

You will be messing with the string behind the compiler's back.  Make it 
volatile.  "volatile const" might be unusual, but it is useful in 
exactly this kind of circumstance.

[toc] | [prev] | [next] | [standalone]

#32130

Il 16/01/2024 16:36, David Brown ha scritto:
> On 16/01/2024 15:42, pozz wrote:
>> Il 16/01/2024 13:51, David Brown ha scritto:
>>> On 16/01/2024 13:19, pozz wrote:
>>>> In one project I have many quasi-fixed strings that I'd like to keep 
>>>> in non volatile memory (Flash) to avoid losing precious RAM space.
>>>>
>>>> static const char s1[] = "/my/very/long/string/of/01020304";
>>>> static const char s2[] = "/another/string/01020304";
>>>> ...
>>>>
>>>> Substring "01020304" is a serial number that changes during 
>>>> production with specific device. It has the same length in bytes 
>>>> (it's a simple hex representation of a 32-bits integer).
>>>>
>>>> Of course it's too difficult and slow to rebuild the firmware during 
>>>> production passing to the compiler the real serial number. I think a 
>>>> better solution is to patch the .hex file generated by the compiler.
>>>>
>>>> I'm wondering how to detect the exact positions (addresses) of 
>>>> serial numbers to fix.
>>>>
>>>> The build system is gcc, so I could search for s1 in the elf file. 
>>>> Do you know of a tool that returns the address of a symbol in the 
>>>> elf or map file?
>>>>
>>>> Could you suggest a better approach?
>>>>
>>>
>>> In the source code, put the serial number in as "PQRXYZ" or some 
>>> other distinct string of characters.  Generate bin files, not hex (or 
>>> convert with objcopy).  Then do a simple search for the special 
>>> string to find its position and replace it with the serial number 
>>> using a simple Python script or your other favourite tool (awk, sed, 
>>> perl, whatever).
>>
>> I thought about this approach, but is it so difficult to have the same 
>> exact sequence of bytes somewhere else in the output?
> 
> Try it and see.
> 
>>
>>
>>> Oh, and in the source code, don't forget to make the string "volatile".
>>
>> Why?
>>
> 
> If you have :
> 
>      static const char s1[] = "PQRXYZ";
> 
> and your code later does, say :
> 
>      const int last_digit = s1[5] - '0';
> 
> the compiler will optimise it to :
> 
>      const int last_digit = '*';
> 
> i.e., it will calculate 'Z' - '0' at compile time - and if I remember by 
> ASCII codes correctly, that matches '*'.
> 
> You will be messing with the string behind the compiler's back.  Make it 
> volatile.  "volatile const" might be unusual, but it is useful in 
> exactly this kind of circumstance.

Oh yes, I got the point now.

[toc] | [prev] | [next] | [standalone]

#32129

Un bel giorno pozz digitò:

>> In the source code, put the serial number in as "PQRXYZ" or some other 
>> distinct string of characters.  Generate bin files, not hex (or convert 
>> with objcopy).  Then do a simple search for the special string to find 
>> its position and replace it with the serial number using a simple Python 
>> script or your other favourite tool (awk, sed, perl, whatever).
> 
> I thought about this approach, but is it so difficult to have the same 
> exact sequence of bytes somewhere else in the output?

Extremely unlikely, especially since you use text strings and therefore you
actually use 64 bits (eigth ASCII characters) to represent a 32 bit number.
Besides, you don't need to use an ASCII string as the placeholder, you can
use any 64 bit number.

If for example your binary file is 1 MB, there is one chance over 2.2
trillion to have the same number duplicated somewhere else.

>> Oh, and in the source code, don't forget to make the string "volatile".
> 
> Why?

To avoid that the compiler will optimize the code and "obfuscate" your
string. I don't think it is very likely, but it is not impossible,
especially if you use a very aggressive optimization level.

-- 
Fletto i muscoli e sono nel vuoto.

[toc] | [prev] | [next] | [standalone]

#32133

On 16/01/2024 16:47, dalai lamah wrote:
> Un bel giorno pozz digitò:
> 
>>> In the source code, put the serial number in as "PQRXYZ" or some other
>>> distinct string of characters.  Generate bin files, not hex (or convert
>>> with objcopy).  Then do a simple search for the special string to find
>>> its position and replace it with the serial number using a simple Python
>>> script or your other favourite tool (awk, sed, perl, whatever).
>>
>> I thought about this approach, but is it so difficult to have the same
>> exact sequence of bytes somewhere else in the output?
> 
> Extremely unlikely, especially since you use text strings and therefore you
> actually use 64 bits (eigth ASCII characters) to represent a 32 bit number.
> Besides, you don't need to use an ASCII string as the placeholder, you can
> use any 64 bit number.
> 
> If for example your binary file is 1 MB, there is one chance over 2.2
> trillion to have the same number duplicated somewhere else.
> 
>>> Oh, and in the source code, don't forget to make the string "volatile".
>>
>> Why?
> 
> To avoid that the compiler will optimize the code and "obfuscate" your
> string. I don't think it is very likely, but it is not impossible,
> especially if you use a very aggressive optimization level.
> 

Actually, this sort of thing really does happen in practice.  In one of 
my current projects, I have some data that is filled in by 
post-processing the binary file, and I had to use volatile accesses to 
read the data or the compiler would optimise based on its knowledge of 
the contents it saw at compile time.  This is not just theoretical.

(To be fair, it is a bit more likely if - like in my case - the source 
file uses null characters rather than a pseudo-random string of characters.)

[toc] | [prev] | [next] | [standalone]

#32122

On 16.01.2024 13:19, pozz wrote:
> In one project I have many quasi-fixed strings that I'd like to keep in
> non volatile memory (Flash) to avoid losing precious RAM space.
> 
> static const char s1[] = "/my/very/long/string/of/01020304";
> static const char s2[] = "/another/string/01020304";
> ...
> 
> Substring "01020304" is a serial number that changes during production
> with specific device. It has the same length in bytes (it's a simple hex
> representation of a 32-bits integer).
> 
> Of course it's too difficult and slow to rebuild the firmware during
> production passing to the compiler the real serial number. I think a
> better solution is to patch the .hex file generated by the compiler.
> 
> I'm wondering how to detect the exact positions (addresses) of serial
> numbers to fix.

Generate two binaries with different substrings and then do
a binary file compare to find the position.

[toc] | [prev] | [next] | [standalone]

#32124

Il 16/01/2024 15:07, Herbert Kleebauer ha scritto:
> On 16.01.2024 13:19, pozz wrote:
>> In one project I have many quasi-fixed strings that I'd like to keep in
>> non volatile memory (Flash) to avoid losing precious RAM space.
>>
>> static const char s1[] = "/my/very/long/string/of/01020304";
>> static const char s2[] = "/another/string/01020304";
>> ...
>>
>> Substring "01020304" is a serial number that changes during production
>> with specific device. It has the same length in bytes (it's a simple hex
>> representation of a 32-bits integer).
>>
>> Of course it's too difficult and slow to rebuild the firmware during
>> production passing to the compiler the real serial number. I think a
>> better solution is to patch the .hex file generated by the compiler.
>>
>> I'm wondering how to detect the exact positions (addresses) of serial
>> numbers to fix.
> 
> Generate two binaries with different substrings and then do
> a binary file compare to find the position.

Thank you for this?

[toc] | [prev] | [next] | [standalone]

#32125

On 2024-01-16, pozz <pozzugno@gmail.com> wrote:

> I'm wondering how to detect the exact positions (addresses) of serial 
> numbers to fix.

Assuming there's a symbol associated with the address, the link map
will tell you what the address is.

--
Grant

[toc] | [prev] | [next] | [standalone]

#32127

On 16/01/2024 16:24, Grant Edwards wrote:
> On 2024-01-16, pozz <pozzugno@gmail.com> wrote:
> 
>> I'm wondering how to detect the exact positions (addresses) of serial
>> numbers to fix.
> 
> Assuming there's a symbol associated with the address, the link map
> will tell you what the address is.
> 

Making the symbol extern linkage (remove the "static") would help with that!

[toc] | [prev] | [next] | [standalone]

#32134

On 2024-01-16, David Brown <david.brown@hesbynett.no> wrote:
> On 16/01/2024 16:24, Grant Edwards wrote:
>> On 2024-01-16, pozz <pozzugno@gmail.com> wrote:
>> 
>>> I'm wondering how to detect the exact positions (addresses) of serial
>>> numbers to fix.
>> 
>> Assuming there's a symbol associated with the address, the link map
>> will tell you what the address is.
>> 
>
> Making the symbol extern linkage (remove the "static") would help with that!

IIRC, if you're using gcc/binutils, there are ways to get even static
symbols to show up in the link map (e.g. --fdata-sections), but making
the symbol global is smplest.

--
Grant

[toc] | [prev] | [next] | [standalone]

#32131

Il 16/01/2024 16:24, Grant Edwards ha scritto:
> On 2024-01-16, pozz <pozzugno@gmail.com> wrote:
> 
>> I'm wondering how to detect the exact positions (addresses) of serial
>> numbers to fix.
> 
> Assuming there's a symbol associated with the address, the link map
> will tell you what the address is.

The map file is simple to read by human, but I think it's better to use 
some tool (readelf or objdump) that access elf file.

Even if I weren't able to create a command line for this task.

[toc] | [prev] | [next] | [standalone]

#32128

On 16/01/2024 13:19, pozz wrote:
> In one project I have many quasi-fixed strings that I'd like to keep in 
> non volatile memory (Flash) to avoid losing precious RAM space.
> 
> static const char s1[] = "/my/very/long/string/of/01020304";
> static const char s2[] = "/another/string/01020304";
> ...
> 
> Substring "01020304" is a serial number that changes during production 
> with specific device. It has the same length in bytes (it's a simple hex 
> representation of a 32-bits integer).
> 
> Of course it's too difficult and slow to rebuild the firmware during 
> production passing to the compiler the real serial number. I think a 
> better solution is to patch the .hex file generated by the compiler.
> 
> I'm wondering how to detect the exact positions (addresses) of serial 
> numbers to fix.
> 
> The build system is gcc, so I could search for s1 in the elf file. Do 
> you know of a tool that returns the address of a symbol in the elf or 
> map file?
> 
> Could you suggest a better approach?
> 

Another - perhaps more reliable - method would be to put the string in 
its own section with __attribute__((section('serial_number'))), and then 
have a linker file entry to fix it at a specific known address.

[toc] | [prev] | [next] | [standalone]

#32147

On 16.1.2024 17.39, David Brown wrote:
> On 16/01/2024 13:19, pozz wrote:
>> In one project I have many quasi-fixed strings that I'd like to keep 
>> in non volatile memory (Flash) to avoid losing precious RAM space.
>>
>> static const char s1[] = "/my/very/long/string/of/01020304";
>> static const char s2[] = "/another/string/01020304";
>> ...
>>
>> Substring "01020304" is a serial number that changes during production 
>> with specific device. It has the same length in bytes (it's a simple 
>> hex representation of a 32-bits integer).
>>
>> Of course it's too difficult and slow to rebuild the firmware during 
>> production passing to the compiler the real serial number. I think a 
>> better solution is to patch the .hex file generated by the compiler.
>>
>> I'm wondering how to detect the exact positions (addresses) of serial 
>> numbers to fix.
>>
>> The build system is gcc, so I could search for s1 in the elf file. Do 
>> you know of a tool that returns the address of a symbol in the elf or 
>> map file?
>>
>> Could you suggest a better approach?
>>
> 
> Another - perhaps more reliable - method would be to put the string in 
> its own section with __attribute__((section('serial_number'))), and then 
> have a linker file entry to fix it at a specific known address.
> 

My vote for this.

If there are many strings, they could be set into
a const volatile struct which then is located into
a known place.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#32132

Am 16.01.2024 um 13:19 schrieb pozz:
> The build system is gcc, so I could search for s1 in the elf file. Do
> you know of a tool that returns the address of a symbol in the elf or
> map file?

Last time I needed that, I hacked it up myself; at least back in 32-bit
times, ELF was not that hard (but I had to do that anyway to convert ELF
into something the controller could boot).

> Could you suggest a better approach?

Define your memory allocations explicitly. Instead of building a binary
and hacking the strings, place the strings at a fixed address and
regenerate the ELF or .hex file containing them from scratch. Whether
you then give the fixed addresses a name using linker magic, or just
cast pointers, is a matter of taste.


  Stefan

[toc] | [prev] | [next] | [standalone]

#32136

On 2024-01-16, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 16.01.2024 um 13:19 schrieb pozz:
>> The build system is gcc, so I could search for s1 in the elf file. Do
>> you know of a tool that returns the address of a symbol in the elf or
>> map file?
>
> Last time I needed that, I hacked it up myself; at least back in 32-bit
> times, ELF was not that hard (but I had to do that anyway to convert ELF
> into something the controller could boot).

I think scanelf from pax-utils will do it.

https://github.com/gentoo/pax-utils

[toc] | [prev] | [next] | [standalone]

#32137

On 2024-01-16, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 16.01.2024 um 13:19 schrieb pozz:
>> The build system is gcc, so I could search for s1 in the elf file. Do
>> you know of a tool that returns the address of a symbol in the elf or
>> map file?
>
> Last time I needed that, I hacked it up myself; at least back in 32-bit
> times, ELF was not that hard (but I had to do that anyway to convert ELF
> into something the controller could boot).

libelf should help.

The requirements sound similar to "we need to patch the checksum in the
vector table so that a LPC MCU will boot":

https://github.com/imi415/lpchecksum

It should be easy to modify that to patch serial numbers.

> Define your memory allocations explicitly. Instead of building a binary
> and hacking the strings, place the strings at a fixed address and
> regenerate the ELF or .hex file containing them from scratch. Whether
> you then give the fixed addresses a name using linker magic, or just
> cast pointers, is a matter of taste.

Yes.  Placing the string in a special section via the linker script will
make it easier for the patch tool to locate the string.

cu
Michael
-- 
Some people have no respect of age unless it is bottled.

[toc] | [prev] | [next] | [standalone]

#32135

Am 16.01.2024 um 13:19 schrieb pozz:

> I'm wondering how to detect the exact positions (addresses) of serial 
> numbers to fix.

You do not.

Instead, you set up linker scripts, linker options and/or add 
__attribute(()) to the variables' definitions to _place_ them at a 
predetermined, fixed, known-useful location.

And do yourself one favour: have only _one_ instance of that number in 
your code.  Use concatenation or similar to output it where needed.

Then you can use tools like srecord GNU binutils to stamp your desired 
number into that fixed location in the hex file.  Professional-grade 
chip flashing tools for production environments can usually do that by 
themselves, so you don't even have to edit your "official" files.

Details will obviously vary by tool chain.

[toc] | [prev] | [next] | [standalone]

#32138

Il 16/01/2024 19:35, Hans-Bernhard Bröker ha scritto:
> Am 16.01.2024 um 13:19 schrieb pozz:
> 
>> I'm wondering how to detect the exact positions (addresses) of serial 
>> numbers to fix.
> 
> You do not.
> 
> Instead, you set up linker scripts, linker options and/or add 
> __attribute(()) to the variables' definitions to _place_ them at a 
> predetermined, fixed, known-useful location.

Do you mean to choose by yourself the exact address of *each* string? 
And where would you put them, at the beginning, in the middle or at the 
end of the Flash? You need to calculate the address of the next string 
from the address *and length* of the previous string. It seems to me a 
tedious and error-prone job that could be done easily by the linker.


> And do yourself one favour: have only _one_ instance of that number in 
> your code.  Use concatenation or similar to output it where needed.
> 
> Then you can use tools like srecord GNU binutils to stamp your desired 
> number into that fixed location in the hex file.  Professional-grade 
> chip flashing tools for production environments can usually do that by 
> themselves, so you don't even have to edit your "official" files.
> 
> Details will obviously vary by tool chain.
> 

Patching the .hex or .bin file replacing 8 bytes starting from a known 
address is simple. I would write a Python script or would use one of 
srecord[1] tools.

[1] https://srecord.sourceforge.net/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web