2008-04-08 20:25:32     initcode -- early debug via serial

Document created by Aaronwu Employee on Sep 17, 2013
Version 1Show Document
  • View in full screen mode

2008-04-08 20:25:32     initcode -- early debug via serial

Kris Dickie (CANADA)

Message: 53864    I have a custom BF548 board and I am currently trying to get u-boot running properly.

 

u-boot resides in SPI flash, and is at least getting to initcode() alright, and I am just trying to understand something strange that is occurring. I don't think the problem will affect the rest of u-boot from loading but I am wondering why this may occur and if it can be solved.

 

u-boot is loaded via JTAG onto the SPI flash, as no UART is available on the board for UART boot mode, and yes, loading SPI flash via JTAG is extremely slow (ie. > 1 hour for a 100K u-boot LDR). I have a trick, which is to load only a portion of the LDR  that will run the initcode, which obviously won't get me very far, but at least let's me see what's going on in the early stages.

 

void initcode() {

    old_baud = fncall() /* returns 57600, which is set in BCF */

    ...

    serial_putc('S');

    ...

    serial_putc('B');

    ...

    serial_putc('L');

    bfin_write_PLL_LOCKCNT(CONFIG_PLL_LOCKCNT_VAL);

    serial_putc('A');

    ...

 

    /* Only reprogram when needed to avoid triggering unnecessary

     * PLL relock sequences.

     */

    if (bfin_read_VR_CTL() != CONFIG_VR_CTL_VAL) {

        serial_putc('!');

        bfin_write_VR_CTL(CONFIG_VR_CTL_VAL);

        asm("idle;");

    }

       

    serial_putc('C');

    bfin_write_PLL_DIV(CONFIG_PLL_DIV_VAL);

       

    serial_putc('K');

 

    /* Only reprogram when needed to avoid triggering unnecessary

     * PLL relock sequences.

     */

    if (bfin_read_PLL_CTL() != CONFIG_PLL_CTL_VAL) {

        serial_putc('!');

        bfin_write_PLL_CTL(CONFIG_PLL_CTL_VAL);

        asm("idle;");

    }

 

    /* Since we've changed the SCLK above, we may need to update

     * the UART divisors (UART baud rates are based on SCLK).

     */

    serial_reset_baud(old_baud);

 

    serial_putc('F');

    ...

}

 

Anyhow, what I see on my terminal is "SBLA!CEdT??jR?", when I plan to eventually see "SBLA!CK!FIN>"

So when I write to PLL DIV, something is changing the UART output. I have measured on a scope, and the baud actually does change. Initially I measure ~45700 baud, after PLL_DIV, I measure ~115200 baud, and then after the call to serial_reset_baud, I measure 57600, which is what I expect. But everything is garbage after the PLL_DIV write.

 

In my board configuration file, when I set VCO multiplier and SCLK divider to the default PLL register reset values (VCO=10, SCLKDIV=5) then I actually get the text expected. The  values I want to test are VCO=8, SCLKDIV=4, which would actually yield the same SCLK value, and just changing the register values.

 

Does anyone have an idea of what could be affecting the output like this?

Thanks

QuoteReplyEditDelete

 

 

2008-04-08 23:43:20     Re: initcode -- early debug via serial

Mike Frysinger (UNITED STATES)

Message: 53869    it's all in the HRM ... the UART divisor is based on SCLK, and SCLK is determined by PLL_DIV.

 

you'll probably need to add a call to serial_reset_baud(old_baud) right after the PLL_DIV write.

    bfin_write_PLL_DIV(CONFIG_PLL_DIV_VAL);

    serial_reset_baud(old_baud);

    serial_putc('K');

 

it works with the other settings as those probably result in the same SCLK value as the reset state.

QuoteReplyEditDelete

 

 

2008-04-11 18:30:56     Re: initcode -- early debug via serial

Mike Frysinger (UNITED STATES)

Message: 54129    did that suggestion help out ?  just wondering so i know if it needs to be added to svn

QuoteReplyEditDelete

 

 

2008-04-14 14:02:49     Re: initcode -- early debug via serial

Kris Dickie (CANADA)

Message: 54204    sorry, no it didn't. once the baud changes, it never seems to output within initcode(), no matter where serial_reset_baud() is called. not a big deal as output is correct after initcode() finishes, maybe not a bad idea to include in svn in any case, could be my board that is acting up.

 

 

Follow-up [12:51 PM]:

 

Actually, the original error may have been coming from somewhere else, as I am receiving good output now without any change in the code maybe timings or something else. Not a big deal at this point, I know initcode() executes.

Attachments

    Outcomes