[ECOS] RedBoot for Assabet (strongarm) problem

[ECOS] RedBoot for Assabet (strongarm) problem

[todd.kallam]

Hi,

This looks like a similar problem that I had with the reset vector being
initiailized
to the wrong address.  You can tell by looking at the third line of your hex
dump.
The first entry shows the address of the the reset_vector and should be 0040
instead of 0060.

You can search the archives for more info about reset_vector and UNMAPPED_PRT
to find out more about this problem, but here are three solutions from Chris
Lesiak:

        1. Add the following to your hal_platform_setup.h file:
                #define CYGHWR_HAL_ROM_VADDR 0x50000000
        2. Change your binutils.  Binutils-011002 does not have this problem .
        3. Define CYGSEM_HAL_ROM_RESET_USES_JUMP (I haven't tried this myself.)

I used method 1 to fix my problem.

Todd

> Hi Jesper,
>
> Yes the flash is 32 bits width but I don't think this is the problem :
> I've got a running binary of redboot and mine non working binary.
>
> I've checked with hexdump and the bytes seems to be properly ordered in both
files :
> working redboot.bin :
> 0000000 f018 e59f f018 e59f f018 e59f f018 e59f
> 0000010 f018 e59f 0000 0000 f018 e59f f018 e59f
> 0000020 0060 0000 037c 5000 0400 5000 0438 5000
>
> non-working redboot.bin :
> 0000000 f018 e59f f018 e59f f018 e59f f018 e59f
> 0000010 f018 e59f 0000 0000 f018 e59f f018 e59f
> 0000020 0040 0002 0128 0002 01ac 0002 01e4 0002
>
> Thanks
> Eric

Re: [ECOS] RedBoot for Assabet (strongarm) problem

[Jordi Colomer]

> You can search the archives for more info about reset_vector and UNMAPPED_PRT
> to find out more about this problem, but here are three solutions from Chris
> Lesiak:
> 
>         1. Add the following to your hal_platform_setup.h file:
>                 #define CYGHWR_HAL_ROM_VADDR 0x50000000
>         2. Change your binutils.  Binutils-011002 does not have this problem .
>         3. Define CYGSEM_HAL_ROM_RESET_USES_JUMP (I haven't tried this myself.)
> 

FYI:
I have tried method #3 and it works.

-- 
Jordi Colomer

[ECOS] Building ecos

[RolandKane]

I am having a problem with Ecosconfig locating the rules.mak file. It is in
the path it is looking for. Also I mount the C: drive like instructed.
     bash-2.05$ mount -f c:/ /c

*** Process 492 created "make -j1"
make -r -C hal/i386/arch/v1_3_1 headers
make[1]: Entering directory `/home/RKane/first_build/hal/i386/arch/v1_3_1'
makefile:92: //C/PROGRA~1/REDHAT~1/eCos/packages/pkgconf/rules.mak: No such
host or network path
make[1]: stat://C/PROGRA~1/REDHAT~1/eCos/packages/pkgconf/rules.mak: No such
host or network path
make[1]: *** No rule to make target
`//C/PROGRA~1/REDHAT~1/eCos/packages/pkgconf/rules.mak'.  Stop.
make[1]: Leaving directory `/home/RKane/first_build/hal/i386/arch/v1_3_1'
make: *** [headers] Error 2

*** Process 492 terminated (rc=2)
*** Killing process 492 (TerminateProcess)


Windows 2000, Ecos Config 1.3.1
Thanks,
Roland Kane

Re: [ECOS] Building ecos

[Julian Smart]

It could be that you're using a newer version of Cygwin that no longer recognises the //c notation. Please try the newer version of ecosconfig which can be found on the ftp site, inside the archive containing the updated Windows-only Configuration Tool. Sorry, I'm having trouble accessing the eCos pages right now so I can't give the exact URL.

Regards,

Julian

At 07:09 AM 11/24/01 -0600, RolandKane wrote:
 >I am having a problem with Ecosconfig locating the rules.mak file. It is in
 >the path it is looking for. Also I mount the C: drive like instructed.
 >     bash-2.05$ mount -f c:/ /c
 >
 >*** Process 492 created "make -j1"
 >make -r -C hal/i386/arch/v1_3_1 headers
 >make[1]: Entering directory `/home/RKane/first_build/hal/i386/arch/v1_3_1'
 >makefile:92: //C/PROGRA~1/REDHAT~1/eCos/packages/pkgconf/rules.mak: No such
 >host or network path
 >make[1]: stat://C/PROGRA~1/REDHAT~1/eCos/packages/pkgconf/rules.mak: No such
 >host or network path
 >make[1]: *** No rule to make target
 >`//C/PROGRA~1/REDHAT~1/eCos/packages/pkgconf/rules.mak'.  Stop.
 >make[1]: Leaving directory `/home/RKane/first_build/hal/i386/arch/v1_3_1'
 >make: *** [headers] Error 2
 >
 >*** Process 492 terminated (rc=2)
 >*** Killing process 492 (TerminateProcess)
 >
 >
 >Windows 2000, Ecos Config 1.3.1
 >Thanks,
 >Roland Kane

-- 
Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1 7EG Tel: +44 (1223) 271063

Re: [ECOS] RedBoot for Assabet (strongarm) problem

[Eric BENARD / FREE]

OK (2) should be the reason it's now working for me.

Last problem : it's no more possible to execute Linux kernel :
RedBoot> fis load "Linux kernel"
RedBoot> exec -b 0x100000 -l 0xc0000

and nothing more ...

I'll try to add debug log when I have time to see where it's blocking.

Eric


Tim Michals wrote:

> Used 3 to fix this issue.
> -----Original Message-----
> From: todd.kallam@acterna.com [mailto:todd.kallam@acterna.com]
> Sent: Monday, November 19, 2001 3:30 PM
> To: ebenard@free.fr
> Cc: ecos-discuss@sources.redhat.com
> Subject: [ECOS] RedBoot for Assabet (strongarm) problem
> 
> 
> 
> 
> 
> Hi,
> 
> This looks like a similar problem that I had with the reset vector being
> initiailized
> to the wrong address.  You can tell by looking at the third line of your hex
> dump.
> The first entry shows the address of the the reset_vector and should be 0040
> instead of 0060.
> 
> You can search the archives for more info about reset_vector and
> UNMAPPED_PRT
> to find out more about this problem, but here are three solutions from Chris
> Lesiak:
> 
>         1. Add the following to your hal_platform_setup.h file:
>                 #define CYGHWR_HAL_ROM_VADDR 0x50000000
>         2. Change your binutils.  Binutils-011002 does not have this problem
> .
>         3. Define CYGSEM_HAL_ROM_RESET_USES_JUMP (I haven't tried this
> myself.)
> 
> I used method 1 to fix my problem.
> 
> Todd
> 

RE: [ECOS] RedBoot for Assabet (strongarm) problem

[Tim Michals]

Used 3 to fix this issue.
-----Original Message-----
From: todd.kallam@acterna.com [mailto:todd.kallam@acterna.com]
Sent: Monday, November 19, 2001 3:30 PM
To: ebenard@free.fr
Cc: ecos-discuss@sources.redhat.com
Subject: [ECOS] RedBoot for Assabet (strongarm) problem





Hi,

This looks like a similar problem that I had with the reset vector being
initiailized
to the wrong address.  You can tell by looking at the third line of your hex
dump.
The first entry shows the address of the the reset_vector and should be 0040
instead of 0060.

You can search the archives for more info about reset_vector and
UNMAPPED_PRT
to find out more about this problem, but here are three solutions from Chris
Lesiak:

        1. Add the following to your hal_platform_setup.h file:
                #define CYGHWR_HAL_ROM_VADDR 0x50000000
        2. Change your binutils.  Binutils-011002 does not have this problem
.
        3. Define CYGSEM_HAL_ROM_RESET_USES_JUMP (I haven't tried this
myself.)

I used method 1 to fix my problem.

Todd

> Hi Jesper,
>
> Yes the flash is 32 bits width but I don't think this is the problem :
> I've got a running binary of redboot and mine non working binary.
>
> I've checked with hexdump and the bytes seems to be properly ordered in
both
files :
> working redboot.bin :
> 0000000 f018 e59f f018 e59f f018 e59f f018 e59f
> 0000010 f018 e59f 0000 0000 f018 e59f f018 e59f
> 0000020 0060 0000 037c 5000 0400 5000 0438 5000
>
> non-working redboot.bin :
> 0000000 f018 e59f f018 e59f f018 e59f f018 e59f
> 0000010 f018 e59f 0000 0000 f018 e59f f018 e59f
> 0000020 0040 0002 0128 0002 01ac 0002 01e4 0002
>
> Thanks
> Eric

Re: [ECOS] RedBoot for Assabet (strongarm) problem

[Eric BENARD / FREE]

OK, I've compiled a brand new arm-elf 3.0.2 toolchain and it's working.

Don't know what was wrong the first time ...

Eric

Jesper Skov wrote:

>>>>>>"Eric" == Eric BENARD / FREE <ebenard@free.fr> writes:
>>>>>>
> 
> Eric> Hi Jesper, Yes the flash is 32 bits width but I don't think this
> Eric> is the problem : I've got a running binary of redboot and mine
> Eric> non working binary.
> 
> Sorry, no idea then.
> 
> Jesper
> 
> 
> 

Re: [ECOS] RedBoot for Assabet (strongarm) problem

[Jesper Skov]

>>>>> "Eric" == Eric BENARD / FREE <ebenard@free.fr> writes:

Eric> Hi Jesper, Yes the flash is 32 bits width but I don't think this
Eric> is the problem : I've got a running binary of redboot and mine
Eric> non working binary.

Sorry, no idea then.

Jesper

Re: [ECOS] RedBoot for Assabet (strongarm) problem

[Eric BENARD / FREE]

Hi Jesper,

Yes the flash is 32 bits width but I don't think this is the problem :
I've got a running binary of redboot and mine non working binary.

I've checked with hexdump and the bytes seems to be properly ordered in both files :
working redboot.bin :
0000000 f018 e59f f018 e59f f018 e59f f018 e59f
0000010 f018 e59f 0000 0000 f018 e59f f018 e59f
0000020 0060 0000 037c 5000 0400 5000 0438 5000

non-working redboot.bin :
0000000 f018 e59f f018 e59f f018 e59f f018 e59f
0000010 f018 e59f 0000 0000 f018 e59f f018 e59f
0000020 0040 0002 0128 0002 01ac 0002 01e4 0002

Thanks
Eric

Jesper Skov wrote:

>>>>>>"Eric" == Eric BENARD / FREE <ebenard@free.fr> writes:
>>>>>>
> 
> Eric> I tried to flash redboot.bin to my Assabet board using JFlash.
> Eric> It flashs properly but nothing happens on the serial port even
> Eric> after reseting the board.
> 
> I don't know the Assabet board, but if the flash is 16/32 bit wide,
> this could be due to an endian issue (if so, there's probably an
> option in the flash software to swap bytes before programming them
> into the flash).
> 
> Jesper
> 
> 
> 

Re: [ECOS] RedBoot for Assabet (strongarm) problem

[Jesper Skov]

>>>>> "Eric" == Eric BENARD / FREE <ebenard@free.fr> writes:

Eric> I tried to flash redboot.bin to my Assabet board using JFlash.
Eric> It flashs properly but nothing happens on the serial port even
Eric> after reseting the board.

I don't know the Assabet board, but if the flash is 16/32 bit wide,
this could be due to an endian issue (if so, there's probably an
option in the flash software to swap bytes before programming them
into the flash).

Jesper

[ECOS] RedBoot for Assabet (strongarm) problem

[Eric BENARD / FREE]

Hi,

I compiled lastest RedBoot from cvs using a freshly built arm-elf-gcc 3.0.2 :
Reading specs from /usr/local/arm/3.0.2/lib/gcc-lib/arm-elf/3.0.2/specs
Configured with: ../gcc-3.0.2/configure --target=arm-elf 
--prefix=/usr/local/arm/3.0.2 --with-gnu-as --with-gnu-ld --enable-languages=c,c++
Thread model: single
gcc version 3.0.2

I did :
# ./tools/configtool/standalone/common/ecosconfig new assabet redboot
# ./tools/configtool/standalone/common/ecosconfig import 
../redboot/ecos/packages/hal/arm/sa11x0/assabet/current/misc/redboot_ROM.ecm
# ./tools/configtool/standalone/common/ecosconfig tree
# make

I get the following binaries :
-rwxr-xr-x    1 root     root        99760 nov 19 03:50 redboot.bin
-rwxr-xr-x    1 root     root       640434 nov 19 03:50 redboot.elf
-rwxr-xr-x    1 root     root       159144 nov 19 03:50 redboot.img
-rwxr-xr-x    1 root     root       286930 nov 19 03:50 redboot.srec

I tried to flash redboot.bin to my Assabet board using JFlash.
It flashs properly but nothing happens on the serial port even after reseting 
the board.

Are there known issues with cvs redboot for strongarm ?

If so, which is the good cvs tag to checkout to have a running redboot for assabet ?

Many thanks

Eric