Flashing u-boot over serial (OMAPL138)

Hi Laszio papp,

For custom boards, please go through the needed modifications (for re-building the tool) listed at

http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138#Modifications_for_Custom_Boards

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

Sorry, but forgot to mention that we had already discussed it here:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/293890.aspx?pi209567=2

Is there any reason why TI has not provided a configuration file interface rather than source level in which case end users need to rebuild the code?

Also, I have just configured the uart, ddr2/mddr and pll, but the sfh.exe is still stuck with reading the BOOTUBL string from the serial line. What more can I do?

Hi Laszlo,

I would suggest looking at these posts:

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/47/p/107883/380855.aspx#380855

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/103862/383437.aspx#383437

Best,

Andrew

Andrew,

thank you for your answer. Unfortunately, I am not planning to use AIS format because if I understood correctly, that is unnecessary to get u-boot flashed. I need to get the bundled SFT second-stage bootloader running on the board which initializes the DDR memory. Then, u-boot is loaded, and flashed into the NOR flash memory.

That is my understanding of the workflow, and has been confirmed in this thread: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/293890/1026767.aspx#1026767

Did you get this boot sequence working without UBL, just SFT on its own with the sfh.exe. It looks this causes an awkward amount of pain for the end users. I have read several "magical" threads about it, but none of the ideas (when they were present) helped me! One of those people even tried to replace the cable... :-)

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/94876/1031029.aspx#1031029

I wish there was a more active forum than this. Is there a quicker way to reach out? I am kinda blocked by basic stuff at the moment... Any help would be warmly appreciated. Thanks!

Hi Laszlo,

Which model are you trying to implement?

For a typical Linux application, the old flow looked something like this:

• UBL (sets up DDR, PSC, and copies U-Boot to memory)
• U-Boot (loads Linux and file system)
• Linux

The flow for the OMAP-L138 would look like this:

• AIS-signed U-boot (sets up DDR, PSC, and loads Linux and file system)
• Linux

I've personally done work on AM1705/1707/OMAPL137 booting.  In all cases, I have used the "old flow".  It is straightforward and well documented in the threads that I referenced.  If you are stuck on the "waiting for SFT..." string, it is likely that you have something incorrect in the SFT image. 

The SFT image is small enough that it can run in the internal RAM of the OMAPL138, if you have code composer studio, and a JTAG, you could run the target directly to see where you are stuck.  Again, the threads I referred to discuss the most likely culprits of customization.  Until you understand how the SFT needs to be customized, I'm afraid you are not going to get any further with booting from serial.

If you can't get past these issues, look in to the "spi-flash-writer" tool available from TI.  You would be required to run this from JTAG though... 

Best of Luck,

Andrew

Andrew,

have you read the thread I linked?

First, I am not using UBL. Second, I am not using AIS. Third, I do not have problem with the memory, but even the UART communication (getting BOOTUBL back).

See the following thread about CCS discussion.

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/295838/1031489.aspx#1031489

It is quite frustrating that pretty much everything is broken on Linux by TI.

Fwiw, once I get it working, I will try to release a Qt based open source and a bit better loved tool for the public for free. That should have no TI proprietary issues. It will use u-boot SPL. I will not require .NET on Linux either, nor recompilation for configuration settings.

For the present, here you can find the changes I made to the source based on the following site:

http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138#Modifications_for_Custom_Boards

1) UART

OMAP-L138/Common/include/device_uart.h (We use UART-1 for the serial port loading and flashing where the BOOTME and BOOTUBL messages are expected)

#define DEVICE_UART_TIMEOUT (10240)
#define DEVICE_UART_PERIPHNUM (1)

1) PLL Settings (for non 24 MHz input clocks)

OMAP-L138/Common/src/device.c

// System PLL Setup
if (status == E_PASS)
{
#if defined(AM1808)
    // CPU(s) at 456 MHz
    status |= DEVICE_PLL0Init(0, 18, 0, 0, 0, 18, 8); 
#else
    // CPU(s) at 300 MHz
    // status |= DEVICE_PLL0Init(0, 24, 0, 1, 0, 11, 5);
    status |= DEVICE_PLL0Init(0, 30, 0, 1, 0, 11, 7); 
#endif 
}

if (status == E_PASS)
{
    // mDDR @ 150MHz
    // status |= DEVICE_PLL1Init(24, 1, 0, 1, 2);
    status |= DEVICE_PLL1Init(24, 1, 0, 1, 5); 
}

OMAP-L138/Common/src/device_uart.c (unchanged because we use 300 MHz as well)

const UART_ConfigObj DEVICE_UART_config = 
{
    UART_OSM_X16, // osm
    UART_PARITY_NONE, // parity
    UART_STOP_BITS_1, // stopBits
    8, // charLen
#if defined(AM1808) 
    123 // divider = 456MHz/(2*16*115200)
#elif defined(AM1810) // divider = 300MHz/(2*16*115200)
    81 
#else
    81 // divider = 300MHz/(2*16*115200)
#endif
};

I began to debug the issue with an xds100v2 JTAG, and this is the register value (PINMUX4) when printing that out by gdb:

(gdb) p/x *0x01C14130
$3 = 0x00220000
(gdb)

That looks alright to me when trying to get UART1 working which is the expected port for all this. If I set DEVICE_UART_PERIPHNUM to 2, then I am getting the following:

(gdb) p/x *0x01C14130
$3 = 0x22220000
(gdb)

I have just read out the PLL related register values as well, but those also all look fine and are inline with the gel file that we have been using for emulation with CCS. Here you can see the content for those:

PLLC0:

PLLCTL: 0x49
PLLM: 0x1e
PREDIV: 0x8000
POSTDIV: 0x8001
DIV1: 0x8000
DIV3: 0800b
DIV7: 0x8007

PLLC1:

PLLCTL: 0x49
PLLM: 0x18
POSTDIV: 0x8001
DIV1: 0x8000
DIV2: 0x8001
DIV3: 0x8005

I do not see any issues in here, so why am I not getting the expected BOOTUBL over serial port?

Just in case, I have tried two different usb-serial dongles, but I cannot get it working with either of those:

Bus 002 Device 009: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]

and

Bus 002 Device 010: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

I realized that the BOOTCFG register has the value of 0x17 (0x0001 0001) while debugging with JTAG. That means no boot mode based on the serial flasher codebase.

I wonder why I am not getting the UART1 boot mode in there instead? This may very well explain certain issues, but why that register is not latched properly is beyond my league for now... got a clue in there?

After a bit of JTAG debugging, it seems that the second stage boot loader is awaiting the "  START" sequence which the host is supposed to send over... It seems the SFT is not getting that for some reason? Any clue why that could even happen?