Unexpected effects/problems porting code to u-boot SPL
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()):
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]);
}Dear bin4ry,
Quoted 32 lines · 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()):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 afor-loop, which is part of another functiongolayDecode.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 functioncomputeSyndromein conjunction with the calling functiongolayDecode` is important.The issue: If comment out both functions
computeSyndromeanddecodeErrorseverything works fine and the OS (Android) is booting. However, ifcomputeSyndromeis not commented out and thus gets processed, u-boot stucks after displayingreading u-boot.img. The funny thing about it: even if I replacecomputeSyndromewith a bogus function which does not but iterating a values or displaying stuff, u-boot stucks as well.
Quoted 8 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Dear 0xbin4ry,
please keep the list in cc.
Quoted 17 lines · On 28.08.13 19:17, 0xbin4ry wrote:
Am 28.08.13 16:58, schrieb Andreas Bie?mann:
Quoted 6 lines
In
s_inityou 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 ofs_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.
Quoted 6 lines
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 regardings_initand 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?).
Quoted 3 lines
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?
Quoted 5 lines
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?
Quoted 4 lines
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_fis 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