RE: [ECOS] Redboot run issues when HAL_MMU_OFF is issued

RE: [ECOS] Redboot run issues when HAL_MMU_OFF is issued

[Chris Zimman]

> I am trying to do a rom update to update the redboot  and in the
> process, i need to do a run.
> But "run"'s getting stuck as you saw.
> 
> What is  " _heap1" with reference to the linker script.  How does the
> "start address" in the  line "RAM: 0x00000000-0x0ff00000,
> [0x00014020-0x0fed1000] available" get populated. In my case it points
> to _heap1. My golden working redboot image had a different  "start
> address" and it worked fine without issues.

Hi Joe

Without seeing the sources, I can't really say too much more, but I can tell
you in principle that you're making this way too hard if all you're trying to
do is update Redboot.

Freescale tends to do their own versions of Redboot, and (no offense
Freescale folks) they aren't the cleanest ports.

I don't really have cycles to dig through their tree right now unfortunately.
You may consider talking to eCosCentric if you want a supported port to the
iMX31.

--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 issues when HAL_MMU_OFF is issued

[Chris Zimman]

> The issue looks like when 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?
> 
> I had previously been successful in loading another version of redboot
> but the only difference i notice on the serial console is in the
> following line:
> RAM: 0x00000000-0x0ff00000, [0x00014020-0x0fed1000] available
> 
> The start address 0x00014020 which refers to "heap1" in the redboot
> code seems to be different. Any one has an idea on as to how do i
> trace this start address of RAM?
> 
> 
> 
> void launchRunImg(unsigned long addr)
> {
>   asm volatile ("mov r12, r0;");
>   HAL_CLEAN_INVALIDATE_L2();
>   HAL_DISABLE_L2();
>   HAL_MMU_OFF();

If you're turning off the MMU and the code is in remapped space that's not
1-1 (eg. phys addr == virt addr), this isn't going to work.

I still don't understand overall what it is that you're trying to do.

--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 issues when HAL_MMU_OFF is issued

[Chris Zimman]

> The issue looks like when 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?
> 
> I had previously been successful in loading another version of redboot
> but the only difference i notice on the serial console is in the
> following line:
> RAM: 0x00000000-0x0ff00000, [0x00014020-0x0fed1000] available
> 
> The start address 0x00014020 which refers to "heap1" in the redboot
> code seems to be different. Any one has an idea on as to how do i
> trace this start address of RAM?
> 
> 
> 
> void launchRunImg(unsigned long addr)
> {
>   asm volatile ("mov r12, r0;");
>   HAL_CLEAN_INVALIDATE_L2();
>   HAL_DISABLE_L2();
>   HAL_MMU_OFF();

If you're turning off the MMU and the code is in remapped space that's not
1-1 (eg. phys addr == virt addr), this isn't going to work.

I still don't understand overall what it is that you're trying to do.

--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 issues when HAL_MMU_OFF is issued

[Gary Thomas]

joseph biswal wrote:
> Hi All:
> 
> The issue looks like when 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?
> 
> I had previously been successful in loading another version of redboot
> but the only difference i notice on the serial console is in the
> following line:
> RAM: 0x00000000-0x0ff00000, [0x00014020-0x0fed1000] available
> 
> The start address 0x00014020 which refers to "heap1" in the redboot
> code seems to be different. Any one has an idea on as to how do i
> trace this start address of RAM?
> 
> 
> 
> void launchRunImg(unsigned long addr)
> {
>   asm volatile ("mov r12, r0;");
>   HAL_CLEAN_INVALIDATE_L2();
>   HAL_DISABLE_L2();
>   HAL_MMU_OFF();
> 
> 
> 
> Here's a snapshot of my redboot prompt:
> 
> Reading Flash ID...
> 
> NAND part info: 0xaa2c, 0x1580, 0x0050, 0x0000
> Searching for BBT table in the flash ...
> .
> Found version 5 Bbt0 at block 2047 (0xffe0000)
> Total bad blocks: 0
> ... 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 := 0x40004
> LAN92XX: Starting status := 0x40004
> ... waiting for BOOTP information
> Ethernet eth0: MAC address 00:22:33:44:55:66
> IP: 206.44.17.132/255.255.255.0, Gateway: 206.44.17.254
> Default server: 0.0.0.0
> 
> Clock input is 26 MHz
> RedBoot(tm) bootstrap and debug environment [ROMRAM]
> Non-certified release, version FSL 200814 - built 00:22:10, Mar  2 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.
> 
> RAM: 0x00000000-0x0ff00000, [0x00014020-0x0fed1000] available
> FLASH: 0x00000000 - 0x10000000, 2048 blocks of 0x00020000 bytes each.
> RedBoot>
> RedBoot>
> RedBoot> 14020^C
> RedBoot> load -r -b 0x100000 ^C
> RedBoot> ip -l 206.44.17.239/24 -h 206.44.17.89
> IP: 206.44.17.239/255.255.255.0, Gateway: 206.44.17.254
> Default server: 206.44.17.89
> RedBoot> load -r -b 0x100000 redboot.bin_paragon
> Using default protocol (TFTP)
> Raw file loaded 0x00100000-0x0012b35b, assumed entry at 0x00100000
> RedBoot> run 0x100000
> load entry_address=0x100000
> virt_addr=0x100000
> phys_addr=0x80100000
> Launchrunimg called
> 
> 
> 
> Thanks in Advance!
> -Munro.
> 

Since this port isn't in the public tree, it's pretty hard to say much.

However, _most_ ARM devices don't have RAM mapped 1-1 (i.e. the physical
address of RAM is not the same as the logical address).  When you turn
off the MMU, everything changes and depending on the code, it will probably
just die...

Why are you using 'run' and not 'go'?  I think that 'run' (which is
specific to ARM ports) is not the correct choice for running an
eCos application from RedBoot (which another RedBoot qualifies as)


-- 
------------------------------------------------------------
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

[ECOS] Redboot run issues when HAL_MMU_OFF is issued

[joseph biswal]

Hi All:

The issue looks like when 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?

I had previously been successful in loading another version of redboot
but the only difference i notice on the serial console is in the
following line:
RAM: 0x00000000-0x0ff00000, [0x00014020-0x0fed1000] available

The start address 0x00014020 which refers to "heap1" in the redboot
code seems to be different. Any one has an idea on as to how do i
trace this start address of RAM?



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



Here's a snapshot of my redboot prompt:

Reading Flash ID...

NAND part info: 0xaa2c, 0x1580, 0x0050, 0x0000
Searching for BBT table in the flash ...
.
Found version 5 Bbt0 at block 2047 (0xffe0000)
Total bad blocks: 0
... 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 := 0x40004
LAN92XX: Starting status := 0x40004
... waiting for BOOTP information
Ethernet eth0: MAC address 00:22:33:44:55:66
IP: 206.44.17.132/255.255.255.0, Gateway: 206.44.17.254
Default server: 0.0.0.0

Clock input is 26 MHz
RedBoot(tm) bootstrap and debug environment [ROMRAM]
Non-certified release, version FSL 200814 - built 00:22:10, Mar  2 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.

RAM: 0x00000000-0x0ff00000, [0x00014020-0x0fed1000] available
FLASH: 0x00000000 - 0x10000000, 2048 blocks of 0x00020000 bytes each.
RedBoot>
RedBoot>
RedBoot> 14020^C
RedBoot> load -r -b 0x100000 ^C
RedBoot> ip -l 206.44.17.239/24 -h 206.44.17.89
IP: 206.44.17.239/255.255.255.0, Gateway: 206.44.17.254
Default server: 206.44.17.89
RedBoot> load -r -b 0x100000 redboot.bin_paragon
Using default protocol (TFTP)
Raw file loaded 0x00100000-0x0012b35b, assumed entry at 0x00100000
RedBoot> run 0x100000
load entry_address=0x100000
virt_addr=0x100000
phys_addr=0x80100000
Launchrunimg called



Thanks in Advance!
-Munro.

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

[ECOS] Redboot run issues when HAL_MMU_OFF is issued

[joseph biswal]

Hi All:

The issue looks like when 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?

I had previously been successful in loading another version of redboot
but the only difference i notice on the serial console is in the
following line:
RAM: 0x00000000-0x0ff00000, [0x00014020-0x0fed1000] available

The start address 0x00014020 which refers to "heap1" in the redboot
code seems to be different. Any one has an idea on as to how do i
trace this start address of RAM?



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



Here's a snapshot of my redboot prompt:

Reading Flash ID...

NAND part info: 0xaa2c, 0x1580, 0x0050, 0x0000
Searching for BBT table in the flash ...
.
Found version 5 Bbt0 at block 2047 (0xffe0000)
Total bad blocks: 0
... 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 := 0x40004
LAN92XX: Starting status := 0x40004
... waiting for BOOTP information
Ethernet eth0: MAC address 00:22:33:44:55:66
IP: 206.44.17.132/255.255.255.0, Gateway: 206.44.17.254
Default server: 0.0.0.0

Clock input is 26 MHz
RedBoot(tm) bootstrap and debug environment [ROMRAM]
Non-certified release, version FSL 200814 - built 00:22:10, Mar  2 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.

RAM: 0x00000000-0x0ff00000, [0x00014020-0x0fed1000] available
FLASH: 0x00000000 - 0x10000000, 2048 blocks of 0x00020000 bytes each.
RedBoot>
RedBoot>
RedBoot> 14020^C
RedBoot> load -r -b 0x100000 ^C
RedBoot> ip -l 206.44.17.239/24 -h 206.44.17.89
IP: 206.44.17.239/255.255.255.0, Gateway: 206.44.17.254
Default server: 206.44.17.89
RedBoot> load -r -b 0x100000 redboot.bin_paragon
Using default protocol (TFTP)
Raw file loaded 0x00100000-0x0012b35b, assumed entry at 0x00100000
RedBoot> run 0x100000
load entry_address=0x100000
virt_addr=0x100000
phys_addr=0x80100000
Launchrunimg called



Thanks in Advance!
-Munro.

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