[ECOS] Redboot run image issues

[ECOS] Redboot run image issues

[joseph biswal]

Hi ALl;
I am working on the MX31 platform wijht ARM 11 core.
When i run  the image from RAM from another image, its stops after
printing this :
load entry_address=0x100000
virt_addr=0x100000
phys_addr=0x80100000

Heres a  snapshot.

RedBoot> load -r -b 0x100000 /redboot.0220
Using default protocol (TFTP)
Raw file loaded 0x00100000-0x0012bc13, assumed entry at 0x00100000
RedBoot> run 0x100000
load entry_address=0x100000
virt_addr=0x100000
phys_addr=0x80100000


Would it be something to do with the image size or linker script?
I have ensured that my target.ld and mlt_romram.h are correct for the
ROM addresses
Thansks in advance for your help.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot run image issues

[Gary Thomas]

joseph biswal wrote:
> Hi ALl;
> I am working on the MX31 platform wijht ARM 11 core.
> When i run  the image from RAM from another image, its stops after
> printing this :
> load entry_address=0x100000
> virt_addr=0x100000
> phys_addr=0x80100000
> 
> Heres a  snapshot.
> 
> RedBoot> load -r -b 0x100000 /redboot.0220
> Using default protocol (TFTP)
> Raw file loaded 0x00100000-0x0012bc13, assumed entry at 0x00100000
> RedBoot> run 0x100000
> load entry_address=0x100000
> virt_addr=0x100000
> phys_addr=0x80100000
> 
> 
> Would it be something to do with the image size or linker script?
> I have ensured that my target.ld and mlt_romram.h are correct for the
> ROM addresses
> Thansks in advance for your help.
> 

What sort of an image is 'redboot.0220'?  Most times, the
files we load to execute are either ELF binary images, or
Motorola S-record files.  In both of these cases, the '-r'
option should *not* be used.

My [first] guess is that you've loaded some sort of structured
file (ELF, S-record) using '-r' which will not get the correct
instructions in the correct location, hence not run.

Try it without '-r'


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot run image issues

[joseph biswal]

Hi Gary:

If i run the same image by loading it to ram from a JTAG(BDI3000), it
works just fine.
I am not able to understand what is the difference when i run the same
image from JTAG and when i do a "run" from a already running image.

Thanks.

On Sat, Feb 21, 2009 at 6:15 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> joseph biswal wrote:
>> Hi ALl;
>> I am working on the MX31 platform wijht ARM 11 core.
>> When i run  the image from RAM from another image, its stops after
>> printing this :
>> load entry_address=0x100000
>> virt_addr=0x100000
>> phys_addr=0x80100000
>>
>> Heres a  snapshot.
>>
>> RedBoot> load -r -b 0x100000 /redboot.0220
>> Using default protocol (TFTP)
>> Raw file loaded 0x00100000-0x0012bc13, assumed entry at 0x00100000
>> RedBoot> run 0x100000
>> load entry_address=0x100000
>> virt_addr=0x100000
>> phys_addr=0x80100000
>>
>>
>> Would it be something to do with the image size or linker script?
>> I have ensured that my target.ld and mlt_romram.h are correct for the
>> ROM addresses
>> Thansks in advance for your help.
>>
>
> What sort of an image is 'redboot.0220'?  Most times, the
> files we load to execute are either ELF binary images, or
> Motorola S-record files.  In both of these cases, the '-r'
> option should *not* be used.
>
> My [first] guess is that you've loaded some sort of structured
> file (ELF, S-record) using '-r' which will not get the correct
> instructions in the correct location, hence not run.
>
> Try it without '-r'
>
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Redboot run image issues

[Chris Zimman]

> If i run the same image by loading it to ram from a JTAG(BDI3000), it
> works just fine.
> I am not able to understand what is the difference when i run the same
> image from JTAG and when i do a "run" from a already running image.

You need to provide more information on *what* it is that you're loading.
What Gary was asking is if it's an ELF file, SREC, etc. that you're loading
versus a flat binary image.  If you're not aware of which type it is, running
'file' on it will tell you.

Can you post the exact command you're giving the BDI to load the image?
For the avoidance of doubt, I'm not asking for 'load' or 'load image', but
rather 'load [mem address] image [bin | elf | srec]' -- like the full line.

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot run image issues

[joseph biswal]

Hi Chris;
As i stated in my earlier email, i am using a raw binary image version
i.e redboot.bin. I hope "-r" would not be a problem in that case.
I am using the rom_ram versions of the redboot image as defined by  my
cdl configuration.

When i load the image using BDI, i issue the following command:

BDI> load 0x8ff00000 redboot.bin

BDI>rm pc 0x8ff00000

BDI>go
Then on the  serial console, i get the messges for a working image boot.
Following is a snapshot from the hyperterminal O/P.
NAND part info: 0xaa2c, 0x1580, 0x0050, 0xb476
flash_hwr_init(g_bbt=0x00014208)
Searching for BBT table in the flash ...

Found version 1 Bbt0 at block 2047 (0xffe0000)
Total bad blocks: 1
... Read from 0x0fee0000-0x0ff00000 at 0x00080000: .
... Read from 0x0fed3000-0x0fed4000 at 0x0009f000: .
PMIC ID: 0x0000009d [Rev: 3.5]

LAN92xx Driver version 1.1
SMSC LAN9217: ID = 0x117a REV = 0x0
LAN92XX: Waiting to get all clear.
LAN92XX: Starting status := 0x40000
LAN92XX: Starting status := 0x40000
Ethernet eth0: MAC address 92:92:92:12:12:16
IP: 172.20.102.116/255.255.0.0, Gateway: 172.20.0.1
Default server: 172.20.16.36

Clock input is 26 MHz
RedBoot(tm) bootstrap and debug environment [ROMRAM]
Non-certified release, version FSL 200814 - built 12:49:42, Feb 22 2009

Platform: Freescale (i.MX) MX31 3-Stack (Freescale i.MX31 based) PASS 2.0 [x32 D
DR]
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Copyright (C) 2003, 2004, 2005, 2006 eCosCentric Limited

RAM: 0x00000000-0x0ff00000, [0x00014200-0x0fed1000] available
FLASH: 0x00000000 - 0x10000000, 2048 blocks of 0x00020000 bytes each.



Whereas, when i load and runthe same redboot.bin from an existing
working version of "redboot.bin " in RAM, i get the following
: It gets stuck after printing "phys_addr=0x80100000" on the serial
console. I am guessing something somewhere is wrong in the memory
location but i am not sure where to start with. Would it be a problem
with the linker script, mlt file or something else?
ARe there other files in the HAL i need to look into? WHat actuallly
happens when "LaunchRunIMage" in the redboot code  is invoked??


ion FSL 200814 - built 14:08:19, Oct  6 2008

Platform: Freescale (i.MX) MX31 3-Stack (Freescale i.MX31 based) PASS 2.0 [x32 D
DR]
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

RAM: 0x00000000-0x0ff00000, [0x000141c0-0x0fed1000] available
FLASH: 0x00000000 - 0x10000000, 2048 blocks of 0x00020000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort
^C
RedBoot> ^C
RedBoot> ip -l 206.44.17.239/24 -h 206.44.17.89
IP: 206.44.17.239/255.255.255.0, Gateway: 172.20.0.1
Default server: 206.44.17.89
RedBoot> load -v -r -b 0x100000 redboot.bin_paragon
Using default protocol (TFTP)
|
Raw file loaded 0x00100000-0x00144a5b, assumed entry at 0x00100000
RedBoot> run 0x100000
load entry_address=0x100000
virt_addr=0x100000
phys_addr=0x80100000



On Sun, Feb 22, 2009 at 3:19 PM, Chris Zimman <czimman@bloomberg.com> wrote:
>> If i run the same image by loading it to ram from a JTAG(BDI3000), it
>> works just fine.
>> I am not able to understand what is the difference when i run the same
>> image from JTAG and when i do a "run" from a already running image.
>
> You need to provide more information on *what* it is that you're loading.
> What Gary was asking is if it's an ELF file, SREC, etc. that you're loading
> versus a flat binary image.  If you're not aware of which type it is, running
> 'file' on it will tell you.
>
> Can you post the exact command you're giving the BDI to load the image?
> For the avoidance of doubt, I'm not asking for 'load' or 'load image', but
> rather 'load [mem address] image [bin | elf | srec]' -- like the full line.
>
> --Chris
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Redboot run image issues

[Chris Zimman]

> Whereas, when i load and runthe same redboot.bin from an existing
> working version of "redboot.bin " in RAM, i get the following
> : It gets stuck after printing "phys_addr=0x80100000" on the serial
> console. I am guessing something somewhere is wrong in the memory
> location but i am not sure where to start with. Would it be a problem
> with the linker script, mlt file or something else?
> ARe there other files in the HAL i need to look into? WHat actuallly
> happens when "LaunchRunIMage" in the redboot code  is invoked??

That's not going to work because the Redboot code isn't relocatable like
that.  Like you can't just load it and launch it from any location.  If I
understood you right, you're trying to launch a ROM or ROMRAM image from
within Redboot.  This is probably not what you want.

You can configure a Redboot image to be launched from RAM, but this is
generally not necessary unless you're doing special things (eg. replacing a
Reboot ROM mode image, etc.)

Beyond that, without seeing what's going on in the HAL setup
(hal_platform_setup.h), it's difficult to guess which of any number of things
it may be tromping over that could cause it to hang.

I'm still missing what it is that you're ultimately trying to do here.

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot run image issues

[joseph biswal]

My final intent is to get my redboot port to boot from the NAND flash.
I am trying to run this image  from NAND flash but it gets stuck even
before spitting anything on the console. Hence i turn to the BDI
debugger where i try running the image from RAM and see if it works.

I am running on a MX31 based board with Freescale PDK1.4.

On Sun, Feb 22, 2009 at 9:30 PM, Chris Zimman <czimman@bloomberg.com> wrote:
>> Whereas, when i load and runthe same redboot.bin from an existing
>> working version of "redboot.bin " in RAM, i get the following
>> : It gets stuck after printing "phys_addr=0x80100000" on the serial
>> console. I am guessing something somewhere is wrong in the memory
>> location but i am not sure where to start with. Would it be a problem
>> with the linker script, mlt file or something else?
>> ARe there other files in the HAL i need to look into? WHat actuallly
>> happens when "LaunchRunIMage" in the redboot code  is invoked??
>
> That's not going to work because the Redboot code isn't relocatable like
> that.  Like you can't just load it and launch it from any location.  If I
> understood you right, you're trying to launch a ROM or ROMRAM image from
> within Redboot.  This is probably not what you want.
>
> You can configure a Redboot image to be launched from RAM, but this is
> generally not necessary unless you're doing special things (eg. replacing a
> Reboot ROM mode image, etc.)
>
> Beyond that, without seeing what's going on in the HAL setup
> (hal_platform_setup.h), it's difficult to guess which of any number of things
> it may be tromping over that could cause it to hang.
>
> I'm still missing what it is that you're ultimately trying to do here.
>
> --Chris
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Redboot run image issues

[Chris Zimman]

> My final intent is to get my redboot port to boot from the NAND flash.
> I am trying to run this image  from NAND flash but it gets stuck even
> before spitting anything on the console. Hence i turn to the BDI
> debugger where i try running the image from RAM and see if it works.

Without having seen your code, I don't know exactly what you're doing at
startup, but booting from flash vs. starting from memory *typically* will use
a different code path as far as the startup is concerned.  

Because NAND isn't linearly addressable, in a typical NAND boot scenario, it
usually copies a very small amount of code from the NAND into a local buffer
and starts executing from there.  That code is responsible for getting the
rest of the code out of NAND and into memory.  Just taking a quick look at
the Freescale site, it appears that for at least some version of Redboot,
they've made the necessary change to copy the Redboot image from NAND into
SDRAM.

See:

http://www.freescale.com/files/dsp/doc/app_note/AN3672.pdf?fpsp=1&WT_TYPE=App
lication%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentatio
n

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot run image issues

[Rutger Hofman]

You may be aware that NAND flash requires a different type of driver 
than NOR flash. I have written an eCos NAND flash package that is in a 
pre-beta stage. It can be downloaded from
http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/ and I welcome 
other testers. Since NAND flash requires a controller, chances are that 
you will have to write the bottom half of an NFC (NAND Flash Controller) 
device driver yourself. Hopefully the procedures to do that are outlined 
clearly in the documentation I provide.

However, I didn't attempt yet to support booting from the NAND. If it is 
supported at all, this is usually a two-step procedure: NFCs can 
sometimes be configured to load the first page(s) at boot time using 
some h/w procedure and run that code; these page(s) must contain code to 
load the rest of the bootstrap routines from following NAND flash pages. 
This is necessary because NAND flash cannot be randomly accessed, but 
can only be read a page at a time. The very first bootstrap page(s) will 
have to contain the code to read from NAND; and methinks it will not be 
easy to squeeze that code into one 2KB page, although it has been done 
of course.

Rutger Hofman
VU Amsterdam

joseph biswal wrote:
> My final intent is to get my redboot port to boot from the NAND flash.
> I am trying to run this image  from NAND flash but it gets stuck even
> before spitting anything on the console. Hence i turn to the BDI
> debugger where i try running the image from RAM and see if it works.
> 
> I am running on a MX31 based board with Freescale PDK1.4.
> 
> On Sun, Feb 22, 2009 at 9:30 PM, Chris Zimman <czimman@bloomberg.com> wrote:
>>> Whereas, when i load and runthe same redboot.bin from an existing
>>> working version of "redboot.bin " in RAM, i get the following
>>> : It gets stuck after printing "phys_addr=0x80100000" on the serial
>>> console. I am guessing something somewhere is wrong in the memory
>>> location but i am not sure where to start with. Would it be a problem
>>> with the linker script, mlt file or something else?
>>> ARe there other files in the HAL i need to look into? WHat actuallly
>>> happens when "LaunchRunIMage" in the redboot code  is invoked??
>> That's not going to work because the Redboot code isn't relocatable like
>> that.  Like you can't just load it and launch it from any location.  If I
>> understood you right, you're trying to launch a ROM or ROMRAM image from
>> within Redboot.  This is probably not what you want.
>>
>> You can configure a Redboot image to be launched from RAM, but this is
>> generally not necessary unless you're doing special things (eg. replacing a
>> Reboot ROM mode image, etc.)
>>
>> Beyond that, without seeing what's going on in the HAL setup
>> (hal_platform_setup.h), it's difficult to guess which of any number of things
>> it may be tromping over that could cause it to hang.
>>
>> I'm still missing what it is that you're ultimately trying to do here.
>>
>> --Chris
>>
> 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Redboot run image issues

[joseph biswal]

Hi Chris/GAry:

My NAND boot works fine with this particular image. The issue looks
like whe i do a "RUN" of this same working piece of image out of RAM,
it seems to get stuck.

I debugged using BDI breakpoints as well as "diag_printfs" and looks
like it does not go beyond  HAL_MMU_OFF in
packages/hal/arm/mx31/ads/current/src/redboot_cmds.c. I don't
understand the flow in LaunchrunImage()  since it falls on the thin
line of swtching the MMU on and off. Any hints?

Would it be related to any of the relocations

void launchRunImg(unsigned long addr)
{
    asm volatile ("mov r12, r0;");
    HAL_CLEAN_INVALIDATE_L2();
    HAL_DISABLE_L2();
    HAL_MMU_OFF();


Thanks in Advance!
-Munro.



On Mon, Feb 23, 2009 at 3:42 AM, Chris Zimman <czimman@bloomberg.com> wrote:
>> My final intent is to get my redboot port to boot from the NAND flash.
>> I am trying to run this image  from NAND flash but it gets stuck even
>> before spitting anything on the console. Hence i turn to the BDI
>> debugger where i try running the image from RAM and see if it works.
>
> Without having seen your code, I don't know exactly what you're doing at
> startup, but booting from flash vs. starting from memory *typically* will use
> a different code path as far as the startup is concerned.
>
> Because NAND isn't linearly addressable, in a typical NAND boot scenario, it
> usually copies a very small amount of code from the NAND into a local buffer
> and starts executing from there.  That code is responsible for getting the
> rest of the code out of NAND and into memory.  Just taking a quick look at
> the Freescale site, it appears that for at least some version of Redboot,
> they've made the necessary change to copy the Redboot image from NAND into
> SDRAM.
>
> See:
>
> http://www.freescale.com/files/dsp/doc/app_note/AN3672.pdf?fpsp=1&WT_TYPE=App
> lication%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentatio
> n
>
> --Chris
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss