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

[Gary Thomas <gary at mlbassoc dot com>]

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