[U-Boot] Unexpected effects/problems porting code to u-boot SPL

[U-Boot] Unexpected effects/problems porting code to u-boot SPL

[bin4ry]

I want to extend the u-boot SPL code with some fuzzy extractor logic by
adding code into
`{u-boot_sources}/arch/arm/cpu/armv7/omap-common/hwinit-common.c`.
U-boot shall be used on a PandaBoard ES (omap4460 SoC).

Thus, first I successfully implemented the code on my x86 pc and I am
porting it to the ARM-based PandaBoard. The complete code can be found
here (as a side note the "main" function is s_init()):

http://pastebin.com/iaz13Yn9

However, I am expecting dozens of unexptected effects, which results in
either stopping during the execution of the code, stopping u-boot after
reading u-boot.img or not sending output (and thus not booting) at all.

For example, I want to call two functions (`computeSyndrome`,
`decodeErrors`) inside a `for`-loop, which is part of another function
`golayDecode`.

For my first problem please ignore the code below the multiline comment
starting with `/*        >>>> These lines of code below totally break
u-boot`. Also only the function `computeSyndrome` in conjunction with
the calling function `golayDecode` is important.

The issue: If comment out both functions `computeSyndrome` and
`decodeErrors` everything works fine and the OS (Android) is booting.
However, if `computeSyndrome` is not commented out and thus gets
processed, u-boot stucks after displaying `reading u-boot.img`.
The funny thing about it: even if I replace `computeSyndrome` with a
bogus function which does not but iterating a values or displaying
stuff, u-boot stucks as well.

Furthermore, if I remove the multiline comment furhter below to also
include the residual code, u-boot doesn't display ony character. *

I am a beginner regarding microprocessor programming but I can not
figure out a possible error in these 12 lines of the computeSyndrome
function or the general behaviour of u-boot at all. **

Does anyone have a clue what I am missing?

Thanks,
P.

* I am using minicom to display the output of u-boot, which I receive
over serial-usb-converter.  
** I am using the following compiler flags to make sure there are no
errors at compile time: `-Wall -Wstrict-prototypes
-Wdisabled-optimization -W -pedantic`


    void golayDecode(volatile int x[12], volatile int y[12], volatile
unsigned int golayEncodedSecret[30], volatile unsigned int s, volatile
unsigned char repetitionDecodedSecretBits[360]){
    
    printf("\n[I] - Performing Golay decoding\r\n");
    volatile unsigned char secret[22] = {0};
    volatile unsigned char currentByte = 0, tmpByte = 0;
    volatile unsigned int golayDecodedSecret[30] ={0};
    volatile int twelveBitCounter = 0;//, j = 0, k = 0, q = 0, aux = 0,
found = 0, bitCounter = 0, i_2 = 7, currentSecretEncByte = 0x00;
    volatile int c_hat[2] = {0}, e[2] = {0};
    e[0] = s;
    e[1] = 0;

    for(twelveBitCounter = 0; twelveBitCounter < 30; twelveBitCounter+=2){
        printf("Computing syndrome and decoding errors for bytes %03x &
%03x\n", golayEncodedSecret[twelveBitCounter],
golayEncodedSecret[twelveBitCounter+1]);
          computeSyndrome(golayEncodedSecret[twelveBitCounter],
golayEncodedSecret[twelveBitCounter+1], x, y, s);
          decodeErrors(golayEncodedSecret[i], golayEncodedSecret[i+1],
x, y, s);
    }
    
    printf("\n[D] - Reconstructing secret bytes\r\n");

    
    /*        >>>> These lines of code below totally break u-boot
    for(i = 0; i < 30; i+=2){
        currentSecretEncByte = golayDecodedSecret[i];
        volatile int j = 11;

        // Access each source bit        
        for(; 0<=j; j--){            
            volatile int currentSourceBit = (currentSecretEncByte >> j)
& 0x01;    
        
            repetitionDecodedSecretBits[bitCounter] = currentSourceBit;
            bitCounter++;
        }
    }
    
    k = 0;
    for(i = 0; i<176; i++){
        tmpByte =  repetitionDecodedSecretBits[i] << i_2;
        currentByte = currentByte | tmpByte;
        i_2--;
        if(i_2==0){    // We collected 8 bits and created a byte
            secret[k] = currentByte;
            i_2 = 7;
            tmpByte = 0x00;
            currentByte = 0x00;
            k++;
        }        
    }

    SHA256_CTX ctx;
    unsigned char hash[32];

    printf("\n[I] - Generating secret key K\n");
    sha256_init(&ctx);
    sha256_update(&ctx,secret,strlen((const char*)secret));
    sha256_final(&ctx,hash);

    printf("\n[I] - This is our secret key
K\n\t==================================\n\t");
    print_hash(hash);
    printf("\t==================================\n");
    */
    }


    /* Function for syndrome computation */
    void computeSyndrome(int r0, int r1, volatile int x[12], volatile
int y[12], volatile unsigned int s){
    unsigned int syndromeBitCounter, syndromeMatrixCounter, syndromeAux;

    s = 0;
    for(syndromeMatrixCounter=0; syndromeMatrixCounter<12;
syndromeMatrixCounter++){
        syndromeAux = 0;
        
        for(syndromeBitCounter=0; syndromeBitCounter<12;
syndromeBitCounter++){
            syndromeAux =
syndromeAux^((x[syndromeMatrixCounter]&r0)>>syndromeBitCounter &0x01);
        }
        for(syndromeBitCounter=0; syndromeBitCounter<12;
syndromeBitCounter++){
            syndromeAux =
syndromeAux^((y[syndromeMatrixCounter]&r1)>>syndromeBitCounter &0x01);
        }
        s = (s<<1)^syndromeAux;
        
    }
    }



    /* Funcion to recover original byte */
    void decodeErrors(int r0, int r1, volatile int x[12], volatile int
y[12], volatile unsigned int s){
    //printf("\n[D] - Starting to decode errors for %3x | %3x\n", r0, r1);
    volatile unsigned int c_hat[2] = {0xaa}, e[2] = {0xaa};
    volatile unsigned int q;
    unsigned int i, j, aux, found;

    //printf("Step 2\n");
    if(weight(s)<=3){
        e[0] = s;
        e[1] = 0;
    }else{
        /******* STEP 3 */
        //printf("Step 3\n");
        i = 0;
        found = 0;
        do{
            if (weight(s^y[i]) <=2){
                     e[0] = s^y[i];
                     e[1] = x[i];
                     found = 1;
                printf("\ntest 2\n");
               }
             i++;
            }while ((i<12) && (!found));

            if (( i==12 ) && (!found)){
               /******* STEP 4 */
              //printf("Step 4\n");
               q = 0;
               for (j=0; j<12; j++){
                      aux = 0;
                       for (i=0; i<12; i++)
                     aux = aux ^ ( (y[j]&s)>>i & 0x01 );
                       q = (q<<1) ^ aux;
                 }

               /******* STEP 5 */
               //printf("Step 5\n");
               if (weight(q) <=3){
                       e[0] = 0;
                       e[1] = q;
                }else{
                       /******* STEP 6 */
                       //printf("Step 6\n");
                       i = 0;
                       found = 0;
                       do{
                     if (weight(q^y[i]) <=2){
                             e[0] = x[i];
                             e[1] = q^y[i];
                             found = 1;
                       }
                     i++;
                }while((i<12) && (!found));
           
                       if ((i==12) && (!found)){
                       /******* STEP 7 */
                       printf("\n[E] - uncorrectable error pattern! (%3x
| %3x)\n", r0, r1);
                       /* You can raise a flag here, or output the
vector as is */
                       //exit(1);
                }
            }
         }
    }

    c_hat[0] = r0^e[0];
    c_hat[1] = r1^e[1];
    //printf("\t\tEstimated codeword = %x%x\n", c_hat[0], c_hat[1]);
    }

[U-Boot] Unexpected effects/problems porting code to u-boot SPL

[Andreas Bießmann]

Dear bin4ry,

On 08/28/2013 03:30 PM, bin4ry wrote:
> I want to extend the u-boot SPL code with some fuzzy extractor logic by
> adding code into
> `{u-boot_sources}/arch/arm/cpu/armv7/omap-common/hwinit-common.c`.
> U-boot shall be used on a PandaBoard ES (omap4460 SoC).
> 
> Thus, first I successfully implemented the code on my x86 pc and I am
> porting it to the ARM-based PandaBoard. The complete code can be found
> here (as a side note the "main" function is s_init()):
> 
> http://pastebin.com/iaz13Yn9
> 
> However, I am expecting dozens of unexptected effects, which results in
> either stopping during the execution of the code, stopping u-boot after
> reading u-boot.img or not sending output (and thus not booting) at all.
> 
> For example, I want to call two functions (`computeSyndrome`,
> `decodeErrors`) inside a `for`-loop, which is part of another function
> `golayDecode`.
> 
> For my first problem please ignore the code below the multiline comment
> starting with `/*        >>>> These lines of code below totally break
> u-boot`. Also only the function `computeSyndrome` in conjunction with
> the calling function `golayDecode` is important.
> 
> The issue: If comment out both functions `computeSyndrome` and
> `decodeErrors` everything works fine and the OS (Android) is booting.
> However, if `computeSyndrome` is not commented out and thus gets
> processed, u-boot stucks after displaying `reading u-boot.img`.
> The funny thing about it: even if I replace `computeSyndrome` with a
> bogus function which does not but iterating a values or displaying
> stuff, u-boot stucks as well.
> 
> Furthermore, if I remove the multiline comment furhter below to also
> include the residual code, u-boot doesn't display ony character. *
> 
> I am a beginner regarding microprocessor programming but I can not
> figure out a possible error in these 12 lines of the computeSyndrome
> function or the general behaviour of u-boot at all. **
> 
> Does anyone have a clue what I am missing?

<snip code>

I'll not dive in your code but just a few comments. In s_init you do
_not_ have a full CRT! The BSS is not initialized there and writing data
in BSS will likely corrupt code, at least in the 'normal' u-boot mode
before relocation. In the SPL case for omap it's a bit different (BSS
lays in SDRAM which will be initialized at end of s_init .. and I dunno
if it is zeroed out correctly as required by full CRT ;).

Another issue could be that you have only a small, temporary stack
there. I feel the s_init() is just the wrong place to call your code.
AFAIR was a discussion regarding s_init and correct placement in the
call chain. This would maybe solve the two mentioned problems but will
also move your code to another place (maybe after some decission you'll
feed with your code's output?).

It would be the easiest solution if you could move your code to another
place. Maybe inject it in board_init_f?
If not you'll need to setup CRT by initializing BSS correctly for your
needs _and_ verify you'll not blow up your minimal stack there. That
could be a quite expensive task.
Verifying the stack usage is advised in any case, see doc/README.SPL how
to do so.

Best regards

Andreas Bie?mann

[U-Boot] Unexpected effects/problems porting code to u-boot SPL

[Andreas Bießmann]

Dear 0xbin4ry,

please keep the list in cc.

On 28.08.13 19:17, 0xbin4ry wrote:
> Am 28.08.13 16:58, schrieb Andreas Bie?mann:
>> In s_init you do
>> _not_ have a full CRT! The BSS is not initialized there and writing data
>> in BSS will likely corrupt code, at least in the 'normal' u-boot mode
>> before relocation. In the SPL case for omap it's a bit different (BSS
>> lays in SDRAM which will be initialized at end of s_init .. and I dunno
>> if it is zeroed out correctly as required by full CRT ;).
>
> Ah  ok. Thanks for clarification. I did not know about the partial CRT.
>
>> Another issue could be that you have only a small, temporary stack
>> there. I feel the s_init() is just the wrong place to call your code.
>> AFAIR was a discussion regarding s_init and correct placement in the
>> call chain. This would maybe solve the two mentioned problems but will
>> also move your code to another place (maybe after some decission you'll
>> feed with your code's output?).
>
> The reason why I put my code at such an early place is because I want to
> extract the "untouched" first ~30 kByte of the on-chip ram (Starting at
> 0x040300000).

ouch, 30kB? How big is the SRAM of omap4? How big is your code and how
many stack space is reserved? Are these 30kB part of your SPL binary?

> This is a rather simple algorithm which already works
> flawlessly. I could store the data in an array and pass it to the more
> complex algorithm, which I could put into board_init_f, you suggested.
> Do you know a "best practice" to pass such a data structure between both
> functions?

You'll need to wait until sdram_init() is run, then you can use the
SDRAM and place your stuff there. If the BLOB is part of your SPL, why
don't just use the symbols later on?

> However, the code must still be part oft the SPL and must be executed
> before the actual u-boot.img gets loaded. But I guess board_init_f is
> still part of the SPL (I did not work with this function, yet and
> currently do not have the code at hand)?

Yes it is part of SPL an it's used to run board specific stuff. The _f
indicates that it is run 'in place' before relocation. This is an
leftover from NOR flash days where the very first code is run form NOR
in place. The _r part will run later, but this is omitted in SPL case.

Best regards

Andreas Bie?mann