| |
Hi,
If I compile the LEGO firmware sources with gcc, the code size increases much
beyond the 128 KB (which I think) the IAR compiled sources fits into. That means
that one have to relocate part of the compiled code into the memory areas
between 128KB-256KB. That is ok, but not totally optimal as the files,
filehandles, and file verion info is also in that region making it a puzzle.
Also I think it is hard to download new files if the flash is partly taken for
code purposes.
With the http://nxtgcc.sf.net project (which you need to look into this) I get
these numbers from the make process:
Size after:
m_sched.elf :
section size addr
.text 126176 1048576
.text2 23572 1279744
.data 6180 2097152
.bss 45828 2103332
.comment 2133 0
.debug_aranges 496 0
.debug_pubnames 31 0
.debug_info 2139 0
.debug_abbrev 512 0
.debug_line 2732 0
.debug_frame 216 0
.debug_str 276 0
.debug_loc 353 0
.debug_ranges 48 0
Total 210692
text2 and data is relocated. (See AT91SAM7S256_memory.ldh linker details in the
"common") folder for details. I have tried with a "home-made" toolchain (see
"toolchain" folder and now with the precompiled WinArm toolchain, which produces
tighter code. The GNUARM toolchain did worse than WinARM.
Best,
Rasmus
|
|
| |
Regarrding overwriting the flash system. I encountered the problem of
flash file system overwriting user code as well. It's because it is
hard coded in the code the starting address of the file system.
There's a constant named "STARTOFUSERFLASH" that defines where the
file system ("USERFLASH") begins.
I resolved this to make it a run-time definition and make things much
easier. What I did was add a new segment to the linker file with
command that it is to be located as the last linked section. I'm sure
the IAR linker commands are different for GCC so I won't go into that.
Then I modified the source to change the defines for the "first /
start address for flash file storage" from being a constant to being a
reference to a constant relating to the last address in my dummy
section. Once I got this working, no more problems.
Within the IAR tool chain, enabling/disabling compiler optimization
can make alarge different of 10s of 1K of code size. Make sure that
you've got all the GCC optimizations enabled.
You're right. The IAR tool chain recompiles firmware version 1.04 into
something around 128K.
"nxtmote" <nxtmote@gmail.com> wrote in message
news:JEwGI7.60C@lugnet.com...
> Hi,
>
> If I compile the LEGO firmware sources with gcc, the code size
> increases much
> beyond the 128 KB (which I think) the IAR compiled sources fits
> into. That means
> that one have to relocate part of the compiled code into the memory
> areas
> between 128KB-256KB. That is ok, but not totally optimal as the
> files,
> filehandles, and file verion info is also in that region making it a
> puzzle.
> Also I think it is hard to download new files if the flash is partly
> taken for
> code purposes.
>
> With the http://nxtgcc.sf.net project (which you need to look into
> this) I get
> these numbers from the make process:
>
> Size after:
> m_sched.elf :
> section size addr
> .text 126176 1048576
> .text2 23572 1279744
> .data 6180 2097152
> .bss 45828 2103332
> .comment 2133 0
> .debug_aranges 496 0
> .debug_pubnames 31 0
> .debug_info 2139 0
> .debug_abbrev 512 0
> .debug_line 2732 0
> .debug_frame 216 0
> .debug_str 276 0
> .debug_loc 353 0
> .debug_ranges 48 0
> Total 210692
>
> text2 and data is relocated. (See AT91SAM7S256_memory.ldh linker
> details in the
> "common") folder for details. I have tried with a "home-made"
> toolchain (see
> "toolchain" folder and now with the precompiled WinArm toolchain,
> which produces
> tighter code. The GNUARM toolchain did worse than WinARM.
>
> Best,
> Rasmus
|
|
| |
In lugnet.robotics.nxt.nxthacking, Rasmus Pedersen wrote:
> Hi,
>
> If I compile the LEGO firmware sources with gcc, the code size increases much
> beyond the 128 KB (which I think) the IAR compiled sources fits into. That means
> that one have to relocate part of the compiled code into the memory areas
> between 128KB-256KB. That is ok, but not totally optimal as the files,
> filehandles, and file verion info is also in that region making it a puzzle.
> Also I think it is hard to download new files if the flash is partly taken for
> code purposes.
Are you adjusting these values in d_loader.h?
#define STARTOFFILETABLE (0x13FF00L)
#define STARTOFUSERFLASH (0x11F000L)
#define SIZEOFUSERFLASH (STARTOFFILETABLE - STARTOFUSERFLASH)
I've been told by folks at LEGO that if I grow the size of the firmware by
adding new features that I will need to modify these values. And the boundary
needs to be divisible by 8.
John Hansen
|
|
| |
In lugnet.robotics.nxt.nxthacking, John Hansen wrote:
> In lugnet.robotics.nxt.nxthacking, Rasmus Pedersen wrote:
> > Hi,
> >
> > If I compile the LEGO firmware sources with gcc, the code size increases much
> > beyond the 128 KB (which I think) the IAR compiled sources fits into. That means
> > that one have to relocate part of the compiled code into the memory areas
> > between 128KB-256KB. That is ok, but not totally optimal as the files,
> > filehandles, and file verion info is also in that region making it a puzzle.
> > Also I think it is hard to download new files if the flash is partly taken for
> > code purposes.
>
> Are you adjusting these values in d_loader.h?
>
> #define STARTOFFILETABLE (0x13FF00L)
> #define STARTOFUSERFLASH (0x11F000L)
> #define SIZEOFUSERFLASH (STARTOFFILETABLE - STARTOFUSERFLASH)
>
> I've been told by folks at LEGO that if I grow the size of the firmware by
> adding new features that I will need to modify these values. And the boundary
> needs to be divisible by 8.
More precisely, I was told to increase the STARTOFUSERFLASH value if I increased
the firmware size beyond the current value. The unmodified source code compiles
to 121324 bytes using the current evaluation version of the IAR Embedded
Workbench (4.41.1.201). The STARTOFUSERFLASH is 0x1F000 which is 126976. That
means with IAR we have about 5652 bytes to play with before it will be necessary
to increase the STARTOFUSERFLASH value.
John Hansen
|
|
| |
In lugnet.robotics.nxt.nxthacking, Rasmus Pedersen wrote:
> Hi,
>
> If I compile the LEGO firmware sources with gcc, the code size increases much
> beyond the 128 KB (which I think) the IAR compiled sources fits into. That means
> that one have to relocate part of the compiled code into the memory areas
> between 128KB-256KB. That is ok, but not totally optimal as the files,
> filehandles, and file verion info is also in that region making it a puzzle.
> Also I think it is hard to download new files if the flash is partly taken for
> code purposes.
>
> With the http://nxtgcc.sf.net project (which you need to look into this) I get
> these numbers from the make process:
>
> Size after:
> m_sched.elf :
> section size addr
> .text 126176 1048576
> .text2 23572 1279744
> .data 6180 2097152
> .bss 45828 2103332
> .comment 2133 0
> .debug_aranges 496 0
> .debug_pubnames 31 0
> .debug_info 2139 0
> .debug_abbrev 512 0
> .debug_line 2732 0
> .debug_frame 216 0
> .debug_str 276 0
> .debug_loc 353 0
> .debug_ranges 48 0
> Total 210692
>
> text2 and data is relocated. (See AT91SAM7S256_memory.ldh linker details in the
> "common") folder for details. I have tried with a "home-made" toolchain (see
> "toolchain" folder and now with the precompiled WinArm toolchain, which produces
> tighter code. The GNUARM toolchain did worse than WinARM.
Have you experimented at all with the compiler optimisation flags? I don't know
if all of them are supported for the ARM architecture, and some options cause
problems on other architectures, but there's a bit of a list here:
http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Optimize-Options.html
Also, removing debug information (-s) will reduce the size, but you may not want
to do that while hacking.
ROSCO
|
|
| |
In lugnet.robotics.nxt.nxthacking, John Hansen wrote:
> In lugnet.robotics.nxt.nxthacking, John Hansen wrote:
> > In lugnet.robotics.nxt.nxthacking, Rasmus Pedersen wrote:
> > > Hi,
> > >
> > > If I compile the LEGO firmware sources with gcc, the code size increases much
> > > beyond the 128 KB (which I think) the IAR compiled sources fits into. That means
> > > that one have to relocate part of the compiled code into the memory areas
> > > between 128KB-256KB. That is ok, but not totally optimal as the files,
> > > filehandles, and file verion info is also in that region making it a puzzle.
> > > Also I think it is hard to download new files if the flash is partly taken for
> > > code purposes.
> >
> > Are you adjusting these values in d_loader.h?
I did not do so. The memory map in LEGO_MINDSTORMS_NXT_Firmware_v1.03.bin is
like this for the files:
0x11F000-0x12E99D Actual files like Demo.rxe
0x13FF00-0x13FF37 FILE_HANDLE(s)
0x13FFFC-0c13FFFF FILEVERSION
The nxtgcc stuff compiles to 126176 bytes in the .text segment just fits below
STARTOFUSERFLASH (800 byte margin). The next segment .text2 + .data is 29752
bytes and is linked in at 0x138700. So it ends up pretty close (968 bytes) from
the FILE_HANDLE(s) address.
Anyway, if IAR compiles to 121324 bytes then the converted version of the
sources is 126176+23572+6180 - 121324 = 34604 bytes larger. However, I looked in
LEGO_MINDSTORMS_NXT_Firmware_v1.03.bin and it seems like the firmware code ends
at 0x1E226, which is 123436 bytes. Do you know why there is a difference between
your compiler and the one producing the firmware?
How are the file tables generated with the IAR compiler? Is there a tool for
that? I cut (with a little utility called binsert) the three file related memory
ranges out of LEGO_MINDSTORMS_NXT_Firmware_v1.03.bin and indsert them in the gcc
compiled image:-).
> >
> > #define STARTOFFILETABLE (0x13FF00L)
> > #define STARTOFUSERFLASH (0x11F000L)
> > #define SIZEOFUSERFLASH (STARTOFFILETABLE - STARTOFUSERFLASH)
> >
> > I've been told by folks at LEGO that if I grow the size of the firmware by
> > adding new features that I will need to modify these values. And the boundary
> > needs to be divisible by 8.
>
>
> More precisely, I was told to increase the STARTOFUSERFLASH value if I increased
> the firmware size beyond the current value. The unmodified source code compiles
> to 121324 bytes using the current evaluation version of the IAR Embedded
> Workbench (4.41.1.201). The STARTOFUSERFLASH is 0x1F000 which is 126976. That
> means with IAR we have about 5652 bytes to play with before it will be necessary
> to increase the STARTOFUSERFLASH value.
I should try that one day and see if it can be avoided to split the code into
.text and .text2. Good hint.
Best,
Rasmus
>
> John Hansen
|
|
| |
...
>
> Have you experimented at all with the compiler optimisation flags?
I have not done that. Well, just a little bit:-). The best one (not
surprisingly) is the "-Os" optimization, which does this
"Optimize for size. -Os enables all -O2 optimizations that do not typically
increase code size."
> I don't know
> if all of them are supported for the ARM architecture, and some options cause
> problems on other architectures, but there's a bit of a list here:
> http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Optimize-Options.html • Thanks for the link.
>
> Also, removing debug information (-s) will reduce the size, but you may not want
> to do that while hacking.
I tried that but I think the debug info is used on the host side? It did not
seem to decrease the firmware image.
Thanks for the ideas.
Best,
Rasmus
>
> ROSCO
|
|
| |
In lugnet.robotics.nxt.nxthacking, Rasmus Pedersen wrote:
> Do you know why there is a difference between
> your compiler and the one producing the firmware?
LEGO is using a slightly older version of IAR Embedded Workbench. Maybe that
explains it. Or maybe its a 1.03 vs 1.04 source code difference.
> How are the file tables generated with the IAR compiler? Is there a tool for
> that?
I have been told that the following is the standard operating procedure for
generating the complete firmware image:
1. Compile with IAR Embedded Workbench to .a79 binary file.
2. Reset NXT to SAMBA mode
3. Run ATMEL SAMBA utility and erase entire flash memory
4. Download the .a79 firmware file
5. Start the firmware (Go 0x100000)
6. Download desired files to the NXT using LMS NXT software (BricxCC or NeXTTool
should work as well)
7. Reset NXT to SAMBA mode
8. Run ATMEL SAMBA utility again
9. Download firmware image again (but do not start it)
10. Upload the entire flash memory to a file (Upload 0x40000 bytes)
The resulting file should be a new firmware image like the ones that LEGO
provides.
John Hansen
|
|
| |
In lugnet.robotics.nxt.nxthacking, Dick Swan wrote:
> Regarrding overwriting the flash system. I encountered the problem of
> flash file system overwriting user code as well. It's because it is
> hard coded in the code the starting address of the file system.
> There's a constant named "STARTOFUSERFLASH" that defines where the
> file system ("USERFLASH") begins.
>
> I resolved this to make it a run-time definition and make things much
> easier. What I did was add a new segment to the linker file with
> command that it is to be located as the last linked section. I'm sure
> the IAR linker commands are different for GCC so I won't go into that.
> Then I modified the source to change the defines for the "first /
> start address for flash file storage" from being a constant to being a
> reference to a constant relating to the last address in my dummy
> section. Once I got this working, no more problems.
Hi Dick Swan,
That is a nice flexible way of doing it. I will see if I can figure it out in
gcc. Thanks for the idea.
>
> Within the IAR tool chain, enabling/disabling compiler optimization
> can make alarge different of 10s of 1K of code size. Make sure that
> you've got all the GCC optimizations enabled.
Well...I have -=Os on, which are all size reducing features. The actual
"problem" can also be this packed stuff that we e-mailed about. The is probably
the next thing to investigate in this forum.
>
> You're right. The IAR tool chain recompiles firmware version 1.04 into
> something around 128K.
What is the tightest you can compile it to (text+data)?
Best,
Rasmus
>
>
>
>
> "nxtmote" <nxtmote@gmail.com> wrote in message
> news:JEwGI7.60C@lugnet.com...
> > Hi,
> >
> > If I compile the LEGO firmware sources with gcc, the code size
> > increases much
> > beyond the 128 KB (which I think) the IAR compiled sources fits
> > into. That means
> > that one have to relocate part of the compiled code into the memory
> > areas
> > between 128KB-256KB. That is ok, but not totally optimal as the
> > files,
> > filehandles, and file verion info is also in that region making it a
> > puzzle.
> > Also I think it is hard to download new files if the flash is partly
> > taken for
> > code purposes.
> >
> > With the http://nxtgcc.sf.net project (which you need to look into
> > this) I get
> > these numbers from the make process:
> >
> > Size after:
> > m_sched.elf :
> > section size addr
> > .text 126176 1048576
> > .text2 23572 1279744
> > .data 6180 2097152
> > .bss 45828 2103332
> > .comment 2133 0
> > .debug_aranges 496 0
> > .debug_pubnames 31 0
> > .debug_info 2139 0
> > .debug_abbrev 512 0
> > .debug_line 2732 0
> > .debug_frame 216 0
> > .debug_str 276 0
> > .debug_loc 353 0
> > .debug_ranges 48 0
> > Total 210692
> >
> > text2 and data is relocated. (See AT91SAM7S256_memory.ldh linker
> > details in the
> > "common") folder for details. I have tried with a "home-made"
> > toolchain (see
> > "toolchain" folder and now with the precompiled WinArm toolchain,
> > which produces
> > tighter code. The GNUARM toolchain did worse than WinARM.
> >
> > Best,
> > Rasmus
|
|
| |
In lugnet.robotics.nxt.nxthacking, John Hansen wrote:
> In lugnet.robotics.nxt.nxthacking, Rasmus Pedersen wrote:
> > Do you know why there is a difference between
> > your compiler and the one producing the firmware?
>
> LEGO is using a slightly older version of IAR Embedded Workbench. Maybe that
> explains it. Or maybe its a 1.03 vs 1.04 source code difference.
>
> > How are the file tables generated with the IAR compiler? Is there a tool for
> > that?
>
> I have been told that the following is the standard operating procedure for
> generating the complete firmware image:
>
> 1. Compile with IAR Embedded Workbench to .a79 binary file.
> 2. Reset NXT to SAMBA mode
> 3. Run ATMEL SAMBA utility and erase entire flash memory
> 4. Download the .a79 firmware file
> 5. Start the firmware (Go 0x100000)
> 6. Download desired files to the NXT using LMS NXT software (BricxCC or NeXTTool is nice. I tried it last year.
> should work as well)
> 7. Reset NXT to SAMBA mode
> 8. Run ATMEL SAMBA utility again
> 9. Download firmware image again (but do not start it)
> 10. Upload the entire flash memory to a file (Upload 0x40000 bytes)
>
> The resulting file should be a new firmware image like the ones that LEGO
> provides.
OK. This is good info!!! It is hard to guess that this was the way to do it. It
also makes some sense for LEGO to use their file manager to do this rather than
having a second tool replicate a filemanager on the host and insert it at
compile time. But on the other hand, I kind of think this little utility that I
made which copy pastes the files, filehandles, and fileversion info from a ready
firmware image is ok handy to avoid doing this over and over again.
Best,
Rasmus
>
> John Hansen
|
|
| |
In lugnet.robotics.nxt.nxthacking, Rasmus Pedersen wrote:
> Hi,
>
> If I compile the LEGO firmware sources with gcc, the code size increases much
> beyond the 128 KB (which I think) the IAR compiled sources fits into.
I read a paper that attributed most of the code size increases in gcc generated
code to the printf library - search for AN52-ARM-C-Benchmark.pdf to read the
paper. Out of curiosity I built the firmware using the newlib libc and the gcc
4.1.1 toolchain. The code size was
firmware :
section size addr
.text 158492 1048576
.data 6216 2097152
.bss 46240 2103368
.comment 2052 0
.debug_aranges 7312 0
.debug_pubnames 16026 0
.debug_info 213843 0
.debug_abbrev 42027 0
.debug_line 53237 0
.debug_frame 19336 0
.debug_str 30069 0
.debug_loc 126303 0
.debug_ranges 3744 0
Total 724897
I then built the firmware without linking to libc, and supplied the missing
functions from source ripped out of linux's klibc. I got this for code size
firmware :
section size addr
.text 127080 1048576
.data 5116 2097152
.bss 45752 2102268
.comment 1188 0
.debug_aranges 5912 0
.debug_pubnames 12976 0
.debug_info 92527 0
.debug_abbrev 20705 0
.debug_line 30860 0
.debug_frame 14212 0
.debug_str 22560 0
.debug_loc 75593 0
.debug_ranges 2616 0
Total 457097
I haven't tried the klibc firmware so this could be complete garbage, but it may
be a place to start.
Andrew
|
|
|
