[ECOS] Porting eCos / Redboot / Memory map modifications / E7T

[ECOS] Porting eCos / Redboot / Memory map modifications / E7T

[Ali Sina]

Hello,

we are trying to get our code to run on our own hardware, which for all 
practical reasons can be described as an E7T platform with double the RAM.

The setup is as follows:
Redboot (ROM startup mode) is resident on the board and upon power on loads 
the image of the code (RAM startup) from FLASH into RAM, where the code then 
gets executed.
As a control and starting point, the same Redboot and the compiled code run 
fine on both E7T and our HW, of course not using the extra RAM.

From this list, Massa's book and other sources I understand that what is 
needed in order to use the extra RAM is to modify the memory layout, 
specified in the mlt_arm_e7t_rom/mlt_arm_e7t_ram.h and .ldi files. 
Particularly, I have changed the RAM size to double (from 0x80000 to 
0x100000) and modified the heap size accordingly.

Is this sufficient? The code will compile but does not work when using the 
extra RAM (for now I use a static array to control the RAM requirement of 
the code)
I can provide more detail if necessary, but possibly I am missing something 
even more basic.

Thanks for any help,


Ali

_________________________________________________________________
DonÂ’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


-- 
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] Porting eCos / Redboot / Memory map modifications / E7T

[Andrew Lunn]

On Wed, Sep 28, 2005 at 08:15:10AM +0000, Ali Sina wrote:
> Hello,
> 
> we are trying to get our code to run on our own hardware, which for all 
> practical reasons can be described as an E7T platform with double the RAM.
> 
> The setup is as follows:
> Redboot (ROM startup mode) is resident on the board and upon power on loads 
> the image of the code (RAM startup) from FLASH into RAM, where the code 
> then gets executed.
> As a control and starting point, the same Redboot and the compiled code run 
> fine on both E7T and our HW, of course not using the extra RAM.
> 
> >From this list, Massa's book and other sources I understand that what is 
> needed in order to use the extra RAM is to modify the memory layout, 
> specified in the mlt_arm_e7t_rom/mlt_arm_e7t_ram.h and .ldi files. 
> Particularly, I have changed the RAM size to double (from 0x80000 to 
> 0x100000) and modified the heap size accordingly.
> 
> Is this sufficient?

IT might be worth reading the data sheet about the memory
controller. Does it need setting up differently when there is double
the amount of RAM.

packages/hal/arm/e7t/current/include/hal_platform_setup.h looks
to be doing something with a memory controller and timings.

        Andrew

-- 
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] Porting eCos / Redboot / Memory map modifications / E7T

[Ali Sina]

Thanks Andrew,
we finally got the memory recognized by properly modifying the 3 files.
Indeed, modification of hal_platform_setup.h was necessary.

Now the next two questions arise:

1. I would like to make Redboot the only bootloader on the system and get 
rid of the ARM BSL. Can this be done reasonably easy on the E7T?
I understand that Redboot needs to be told to start at 0x01800000 instead of 
0x01820000. I have proceeded along the instructions provided here-> 
http://www.kozio.com/technology/tech_briefs/ChangingRedBootsStartingAddress/
and put the RB binary in the flash via Wiggler, but the image will not boot. 
Am I missing something?

2. It seems that upon start Redboot is doing _something_ on UART0 of the E7T 
platform - which is the user UART, while UART1 is used for console 
communication /debug. This is a problem because the application assumes 
external equipment to be attached to UART0 and whatever is send out of UART0 
by Redboot causes the external equipment (which we cannot change or control) 
to crash.
Also, UART1 is assumed to be used for communication purposes, and the roles 
cannot be switched because of the way our hardware is built.
After some investigation I concluded that this _something_ might be Redboot 
trying to find a channel to use for console communication. Looking briefly 
at the RB source I did not see anything right away. Any ideas of how to fix 
this?

Regards,

Ali



>From: Andrew Lunn <andrew@lunn.ch>
>To: Ali Sina <replay688@hotmail.com>
>CC: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] Porting eCos / Redboot / Memory map modifications / E7T
>Date: Wed, 28 Sep 2005 10:58:27 +0200
>
>On Wed, Sep 28, 2005 at 08:15:10AM +0000, Ali Sina wrote:
> > Hello,
> >
> > we are trying to get our code to run on our own hardware, which for all
> > practical reasons can be described as an E7T platform with double the 
>RAM.
> >
> > The setup is as follows:
> > Redboot (ROM startup mode) is resident on the board and upon power on 
>loads
> > the image of the code (RAM startup) from FLASH into RAM, where the code
> > then gets executed.
> > As a control and starting point, the same Redboot and the compiled code 
>run
> > fine on both E7T and our HW, of course not using the extra RAM.
> >
> > >From this list, Massa's book and other sources I understand that what 
>is
> > needed in order to use the extra RAM is to modify the memory layout,
> > specified in the mlt_arm_e7t_rom/mlt_arm_e7t_ram.h and .ldi files.
> > Particularly, I have changed the RAM size to double (from 0x80000 to
> > 0x100000) and modified the heap size accordingly.
> >
> > Is this sufficient?
>
>IT might be worth reading the data sheet about the memory
>controller. Does it need setting up differently when there is double
>the amount of RAM.
>
>packages/hal/arm/e7t/current/include/hal_platform_setup.h looks
>to be doing something with a memory controller and timings.
>
>         Andrew

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


-- 
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] Porting eCos / Redboot / Memory map modifications / E7T

[Andrew Lunn]

On Sun, Oct 16, 2005 at 08:46:53PM +0000, Ali Sina wrote:
> Thanks Andrew,
> we finally got the memory recognized by properly modifying the 3 files.
> Indeed, modification of hal_platform_setup.h was necessary.
> 
> Now the next two questions arise:
> 
> 1. I would like to make Redboot the only bootloader on the system and get 
> rid of the ARM BSL. Can this be done reasonably easy on the E7T?
> I understand that Redboot needs to be told to start at 0x01800000 instead 
> of 0x01820000. I have proceeded along the instructions provided here-> 
> http://www.kozio.com/technology/tech_briefs/ChangingRedBootsStartingAddress/
> and put the RB binary in the flash via Wiggler, but the image will not 
> boot. Am I missing something?

The code for the eCos E7T in the repository has RedBoot as the only
boot loader. So you might want to compare your code with the E7T code
and see what is different....

 
> 2. It seems that upon start Redboot is doing _something_ on UART0 of the 
> E7T platform - which is the user UART, while UART1 is used for console 
> communication /debug. This is a problem because the application assumes 
> external equipment to be attached to UART0 and whatever is send out of 
> UART0 by Redboot causes the external equipment (which we cannot change or 
> control) to crash.
> Also, UART1 is assumed to be used for communication purposes, and the roles 
> cannot be switched because of the way our hardware is built.
> After some investigation I concluded that this _something_ might be Redboot 
> trying to find a channel to use for console communication. Looking briefly 
> at the RB source I did not see anything right away. Any ideas of how to fix 
> this?

If you look in packages/hal/arm/e7t/current/src/hal_diag.c you will
see it defines two e7t_ser_channels. One is for UART0 and the other is
for UART1. Try disabling UART0. 

        Andrew

-- 
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] Porting eCos / Redboot / Memory map modifications / E7T

[Ali Sina]

Andrew, thanks again- both problems solved, following your advice below:
- took the redoobot repository code and worked from there
- disabled the init of UART0 in hal_diag.c

Now one small thing is left regarding the redboot start address 
modification:

- I have noticed that upon hardware reset everything works fine.
However, when calling "reset" from within redboot, it seems that the
flash is somehow not properly seen. See output below:

----
RedBoot> reset
... Resetting.
+FLASH: driver init failed: Driver does not support device
Sorry, FLASH config exceeds available space in FIS directory

RedBoot(tm) bootstrap and debug environment [ROM]
---

Subsequent hardware reset will not show any issues with the flash.

This is currently not a major issue, but what I am afraid of
is that this wants to tell me that something else will break
later on down the road.

Am I to worry about this?

Cheers,

Ali


>From: Andrew Lunn <andrew@lunn.ch>
>To: Ali Sina <replay688@hotmail.com>
>CC: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] Porting eCos / Redboot / Memory map modifications / E7T
>Date: Sun, 16 Oct 2005 23:17:51 +0200
>
>On Sun, Oct 16, 2005 at 08:46:53PM +0000, Ali Sina wrote:
> > Thanks Andrew,
> > we finally got the memory recognized by properly modifying the 3 files.
> > Indeed, modification of hal_platform_setup.h was necessary.
> >
> > Now the next two questions arise:
> >
> > 1. I would like to make Redboot the only bootloader on the system and 
>get
> > rid of the ARM BSL. Can this be done reasonably easy on the E7T?
> > I understand that Redboot needs to be told to start at 0x01800000 
>instead
> > of 0x01820000. I have proceeded along the instructions provided here->
> > 
>http://www.kozio.com/technology/tech_briefs/ChangingRedBootsStartingAddress/
> > and put the RB binary in the flash via Wiggler, but the image will not
> > boot. Am I missing something?
>
>The code for the eCos E7T in the repository has RedBoot as the only
>boot loader. So you might want to compare your code with the E7T code
>and see what is different....
>
>
> > 2. It seems that upon start Redboot is doing _something_ on UART0 of the
> > E7T platform - which is the user UART, while UART1 is used for console
> > communication /debug. This is a problem because the application assumes
> > external equipment to be attached to UART0 and whatever is send out of
> > UART0 by Redboot causes the external equipment (which we cannot change 
>or
> > control) to crash.
> > Also, UART1 is assumed to be used for communication purposes, and the 
>roles
> > cannot be switched because of the way our hardware is built.
> > After some investigation I concluded that this _something_ might be 
>Redboot
> > trying to find a channel to use for console communication. Looking 
>briefly
> > at the RB source I did not see anything right away. Any ideas of how to 
>fix
> > this?
>
>If you look in packages/hal/arm/e7t/current/src/hal_diag.c you will
>see it defines two e7t_ser_channels. One is for UART0 and the other is
>for UART1. Try disabling UART0.
>
>         Andrew

_________________________________________________________________
DonÂ’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


-- 
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] Porting eCos / Redboot / Memory map modifications / E7T

[Andrew Lunn]

On Sun, Oct 23, 2005 at 10:10:45AM +0000, Ali Sina wrote:
> Andrew, thanks again- both problems solved, following your advice below:
> - took the redoobot repository code and worked from there
> - disabled the init of UART0 in hal_diag.c
> 
> Now one small thing is left regarding the redboot start address 
> modification:
> 
> - I have noticed that upon hardware reset everything works fine.
> However, when calling "reset" from within redboot, it seems that the
> flash is somehow not properly seen. See output below:
> 
> ----
> RedBoot> reset
> ... Resetting.
> +FLASH: driver init failed: Driver does not support device

This is strange. Normally warm reset and flash problems means the
system hangs solid. The normal problem is that a flash erase/write
operation is active when the warm reset happens. Two things can then
happen:

The warm-reset causes the reset CPU pin to be active and the flash is
connected to this, so gets reset back into read mode.

The flash is not connected to the reset pin so stays in erase/write
mode. All subsequent reads result in the flash returning status
information, not contents of the flash. So the CPU has only junk to
execute and crashs imeadietly.

You seem to have something else happening. It is booting so the flash
must be readable. Yet the flash is not responding correctly to the ID
request. You might want to print out the ID information. Take a look
at the flash_query() function for the flash driver you are using. Does
the values it is returning look like an ID? Does it look like status
information?

This is probably something you want to fix before going into
production. The watchdog code uses the same process to reboot the
system. So the watchdog is not going to work. There is also a
posibility this is a hardware problem with the flash resets. So you
might want to get your hardware people to take a look just to make
sure everything is as it is supposed to be.

        Andrew

-- 
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] Porting eCos / Redboot / Memory map modifications / E7T

[Andrew Lunn]

On Sun, Oct 23, 2005 at 01:10:37PM +0200, Andrew Lunn wrote:
> On Sun, Oct 23, 2005 at 10:10:45AM +0000, Ali Sina wrote:
> > Andrew, thanks again- both problems solved, following your advice below:
> > - took the redoobot repository code and worked from there
> > - disabled the init of UART0 in hal_diag.c
> > 
> > Now one small thing is left regarding the redboot start address 
> > modification:
> > 
> > - I have noticed that upon hardware reset everything works fine.
> > However, when calling "reset" from within redboot, it seems that the
> > flash is somehow not properly seen. See output below:
> > 
> > ----
> > RedBoot> reset
> > ... Resetting.
> > +FLASH: driver init failed: Driver does not support device
> 
> This is strange. Normally warm reset and flash problems means the
> system hangs solid. The normal problem is that a flash erase/write
> operation is active when the warm reset happens. Two things can then
> happen:
> 
> The warm-reset causes the reset CPU pin to be active and the flash is
> connected to this, so gets reset back into read mode.
> 
> The flash is not connected to the reset pin so stays in erase/write
> mode. All subsequent reads result in the flash returning status
> information, not contents of the flash. So the CPU has only junk to
> execute and crashs imeadietly.
> 
> You seem to have something else happening. It is booting so the flash
> must be readable. Yet the flash is not responding correctly to the ID
> request. You might want to print out the ID information. Take a look
> at the flash_query() function for the flash driver you are using. Does
> the values it is returning look like an ID? Does it look like status
> information?
> 
> This is probably something you want to fix before going into
> production. The watchdog code uses the same process to reboot the
> system. So the watchdog is not going to work. There is also a
> posibility this is a hardware problem with the flash resets. So you
> might want to get your hardware people to take a look just to make
> sure everything is as it is supposed to be.

Something else thought about last night. It could be a cache
issue. When doing something other than reading from the FLASH you need
the cache disabled. It could be that something is enabling caching on
the memory region the FLASH uses. A warm restart may not to disabling
the caches. So when the flash driver tries to access the flash after
the warm start it fails. This might be easy to prove. Getting the ID
of the flash generally means writing a command and then reading back
the result. If what you read back is the same as the command you have
just written you know you have a cache problem.

        Andrew

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