6 replies to this topic

[pascal06]

Hello,

I try to find a good procedure to compile firmware with GCC.
Each time we need to add some firmeware code, we need to modify memory layout.
After some reading on the web and the Porting Kit documentation, it's not very clear for me.

When I cannot build because my firmware doesn't fit the allocated memory, I need to change two files :
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR>scatterfile_tinyclr_gcc.xml
and
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\DeviceCode\Blockstorage\Sam7X_blockstorage

For the first, it's simple, if I understand correctly :

If I need x bytes (compiler give this value), I just need to add x to previous existing value in Deploy_BaseAddress properties.

<?xml version="1.0"?>
<ScatterFile xmlns="http://schemas.microsoft.com/netmf/ScatterfileSchema.xsd">

    <!-- SAM7X512 has 128KB of RAM at 0x00000000, 512KB FLASH at 0x00100000  -->

    <Set Name="Valid" Value="false"/>

    <!-- ################################################################################ -->
    <!-- 16KB Stack and 16KB Heap -->
    <Set Name="Heap_Begin"      Value="0x00010000"/>
    <Set Name="Heap_End"        Value="0x00017FF8"/>
    <Set Name="Stack_Bottom"    Value="0x00018000"/>
    <Set Name="Stack_Top"       Value="0x0001FFF8"/>

    <If Name="TARGETLOCATION" In="FLASH">
        <Set Name="Code_BaseAddress"    Value="0x0011e000"/>
        <Set Name="Deploy_BaseAddress"  Value="0x00172000"/> <!-- here -->
        <Set Name="Code_Size"           Value="%Deploy_BaseAddress - Code_BaseAddress%"/>
        <Set Name="Config_BaseAddress"  Value="0x0017E000"/>    
        <Set Name="Config_Size"         Value="0x00002000"/>
        <Set Name="Valid"               Value="true"/>
    </If>

With this modification, the compile phase should works. But, the deployement phase can be unsuccessful in case of not enought room in blockstorage.
So, we need to change values in this structure also.

const BlockRange g_SAM7X_BS_BlockRange[] =
{
    //
    { BlockRange::BLOCKTYPE_BOOTSTRAP       ,  0,  5 },
    { MEMORY_BLOCKTYPE_GCC_SPECIAL_BOOTSTRAP,  6, 14 },
    { BlockRange::BLOCKTYPE_CODE            , 15, 44 },
    { MEMORY_BLOCKTYPE_GCC_SPECIAL_CODE     , 45, 46 },
    { BlockRange::BLOCKTYPE_DEPLOYMENT      , 47, 60 },
    { BlockRange::BLOCKTYPE_STORAGE_A       , 61, 61 },
    { BlockRange::BLOCKTYPE_STORAGE_B       , 62, 62 },
    { BlockRange::BLOCKTYPE_CONFIG          , 63, 63 }
};

Anybody may explain how to modify this file with a easy to understand way. How to know the size of each block ?
Is it related to PortBooter.bin, TinyBooter.bin, TinyBooterDecompressor.bin files size (one block = 8k) ...

Any help appreciate,
/pascal

[Chris Walker]

Anybody may explain how to modify this file with a easy to understand way. How to know the size of each block ?
Is it related to PortBooter.bin, TinyBooter.bin, TinyBooterDecompressor.bin files size (one block = 8k) ...

Yes, each block is 8KB. There are 64 blocks total (8KB * 64KB = 512KB).

Does that help at all? It sounds like you had already figured that out though...

When making firmware modifications, we typically compile the image--and then measure the size of TinyBooter (using SAM-BA) and the size of TinyCLR (using MFDeploy). Then we re-adjust the block layout, recompile (with /t:rebuild), and reflash.

Chris

[pascal06]

Yes, each block is 8KB. There are 64 blocks total (8KB * 64KB = 512KB).

Does that help at all? It sounds like you had already figured that out though...

When making firmware modifications, we typically compile the image--and then measure the size of TinyBooter (using SAM-BA) and the size of TinyCLR (using MFDeploy). Then we re-adjust the block layout, recompile (with /t:rebuild), and reflash.

Chris

Thanks Chris,

And :
BLOCKTYPE_BOOTSTRAP = TinyBooter size
BLOCKTYPE_CODE = TinyCLR size
BLOCKTYPE_DEPLOYEMENT = Free memory for managed code size

But what's both *GCC_SPECIAL* blocks ? Do I need to change his size, and if yes, based on what ?

Many thanks,
Pascal

[Chris Walker]

But what's both *GCC_SPECIAL* blocks ? Do I need to change his size, and if yes, based on what ?

GCC creates "bigger" code than RVDS. These are a sort of conditional-compilation to allow for that bigger code. Just make sure that the total of the GCC_SPECIAL and non-special blocks for that chunk of space (TinyBooter, TinyCLR, code, config, EWR, etc.) add up to the amount you need. If you have access to RVDS, you can adjust the non-special blocks to fit the RVDS-compiled firmware and then adjust the GCC_SPECIAL blocks to make extra room for the GCC-compiled code.

You're going to be taking space out of the C# code deployment area (or getting rid of the "unused" 16KB EWR area) to make room for the GCC expansion blocks.

Also, you can just get rid of the GCC_SPECIAL blocks if you'd like and just use one set of blocks. The reason to have both sets is so that you get extra space for C# code when using an RVDS/MDK toolchain.

Chris

[CW2]

With this modification, the compile phase should works. But, the deployement phase can be unsuccessful in case of not enought room in blockstorage.

Please have a look at the following post which contains updated blockrange for GCC 4.4. The *GCC_SPECIAL* symbols are used to differentiate the block range layout between GCC and the other compilers - when compiling with GCC, there is more blocks for bootstrap, because the generated code is twice as big.

[pascal06]

Please have a look at the following post which contains updated blockrange for GCC 4.4. The *GCC_SPECIAL* symbols are used to differentiate the block range layout between GCC and the other compilers - when compiling with GCC, there is more blocks for bootstrap, because the generated code is twice as big.

Many thanks,

I'm finally successful with a firmware and TinyBooterDecompressor compiled with GCC 4.2.
And a simple blink led application works. For some of you, it's not a huge step, but for me, it was a long way.

But I have only 32k for C# project Without any new firmware feature.
And, I don't know why, the device capabilities function on MFDeploy reply Not Supported (any idea ?),
When I will have time, I will write a little document with my experience, because my feeling is that we don't have enought document about that, it's not realy trivial. Perhaps a little tools to manipulate both files needed to modify would be useful.

Thanks again,
/pascal

[pascal06]

And, I don't know why, the device capabilities function on MFDeploy reply Not Supported (any idea ?),

Forget this remark, I have tested this function with TinyBooterDecompressor only , with no firmware,
It works know,
Pascal