RE: [ECOS] Booting from Flash in a AT91M55800A based platform

RE: [ECOS] Booting from Flash in a AT91M55800A based platform

[Lambrecht Jürgen]

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Frank Pagliughi
> Sent: vrijdag 1 augustus 2008 21:34
> To: Pazos Escudero Nuria
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] Booting from Flash in a AT91M55800A based platform
> 
> Pazos Escudero Nuria wrote:
> 
> >Hi,
> >
> >I've ported eCos and RedBoot for a proprietary platform comprising the
> >AT91M55800A processor a SRAM and three S29AL016D90TFI02 flash modules.
> >The RAM version works fine and I can communicate with the RedBoot
> >console through the serial port, but I have not yet managed to make
Can you access the flash from redboot? (fis init; fconfig -I; ..)

Are the flash things OK? You can use the arm/at91/eb55 port as starting point. You need also flash code in devs/flash/arm/eb55 and devs/flash/amd/am29xxxxx -> I just checked devs/flash/amd/am29xxxxx/current/include/flash_am29xxxxx_parts.inl, and there is no S29AL part in the list.
Just add it. You can start from the CYGHWR_DEVS_FLASH_AMD_S29GL128N part, and check your datasheet for changes.
(mark: the eb55 board uses an atmel flash of course, so the part used (' #define CYGHWR_DEVS_FLASH_ATMEL_AT49BV1604A ') is in devs\flash\atmel\at49xxxx\current\include\ flash_at49xxxx_parts.inl)

You could also have problems because of the 3 flash chips. Start with using only 1.
If you want to use the 3 flashes separately, I think you need then the flash_v2 drivers - check the mailing list for it.

> the
> >platform boot from the flash (after copying the ROM version of the
> >ported RedBoot on the flash address pointed by the chip select 0). I
> >don't know whether the problem comes from the platform porting or from
> >the fact that eCos does not recognize the used flash chips from
> >Spansion. Could you provide me any hint?
> >
> >Thanks in advance!
> >Nuria
> >
> >
> >
> If you're programming the Flash chips with a JTAG, then the lack of
> eCos
> drivers doesn't matter at this stage.
> - Does the JTAG software claim that the "program and verify" worked
> properly?
> - Are the Flash chips properly wired on the board?
> - Did you set up the "_InitMemory" table in "hal_platform_setup.h" for
> the Flash chip(s). You need to set the base address, # wait states,
> etc.
> Plus the base address for each CS line must be different, even if the
> CS
> is disabled.
Indeed.

I have a 64MB S29GL512, and use 4 chip-selects for it.
Here is my "_InitMemory" code:

        .long   0x1000352D  //NCS0 flash-1 , 16MB, 2 cycles after transfer, 16-bit, 4 wait state
        .long   0x1100352D  //NCS1 flash-2 , 16MB, 2 cycles after transfer, 16-bit, 4 wait state
        .long   0x1200352D  //NCS2 flash-3 , 16MB, 2 cycles after transfer, 16-bit, 4 wait state
        .long   0x1300352D  //NCS3 flash-4 , 16MB, 2 cycles after transfer, 16-bit, 4 wait state
        .long   0x06002121  //NCS4 IDT SRAM, 16MB, 0 cycles after transfer, 16-bit, 1 wait state

Starting from the eb55 port, I first used addresses 0x0100, 0x0200, 0x0300 and 0x0400. But this did not work very well! I still don't know why. The addresses 0x1000, 0x1100, .. worked, so I stopped my effort there.

> - You should be able to reset the CPU and single step through the first
> few instructions, using the JTAG and/or gdb. Remember that the chip
> starts with the first Flash (CS0) mapped to address zero. You can
> single
> step up to the point where the chip select registers are loaded and
> make
> sure that the values are being loaded properly.  But note that you
> can't
> step over the remap command since the debugger messes with the
> pipeline.
> - One of the first things that the assembly startup does is set the
> master clock (and maybe the PLL) running faster. If you set them
> running
> faster than the external board can support, the board may lock up.
> 
> 
> Whatever you're using to load the RAM debug code onto the board is
> initializing it properly (a JTAG initialization file?). Use that as a
> starting point. The only thing it isn't doing is setting up the Flash
> chip select registers in the EBI, so pay careful attention to that.
> 
> Frank
> 
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


--
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] Thread safe memory allocations

[Stefan Sommerfeld]

Hello,

I use Doug Lea's memory allocation and enabled "Make thread safe", but for me it 
looks like it doesn't do any locking. There's a MALLOC_LOCK macro which is 
empty. I have sometimes a crash getting mallinfo, that's why I searched for a 
lock inside getStatus().

Is the thread safe implementation really working?

Bye...

BTW: I released a memory leak checker on the devel mailing list.


-- 
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] Thread safe memory allocations

[Andrew Lunn]

On Thu, Aug 07, 2008 at 01:42:22PM +0200, Stefan Sommerfeld wrote:
> Hello,
>
> I use Doug Lea's memory allocation and enabled "Make thread safe", but 
> for me it looks like it doesn't do any locking. There's a MALLOC_LOCK 
> macro which is empty. I have sometimes a crash getting mallinfo, that's 
> why I searched for a lock inside getStatus().
>
> Is the thread safe implementation really working?

The locking should be happening at a higher level. All allocations
should be going through the code in
packages/services/memalloc/common/current/include/mempolt2.inl
although being a humble C programmer all this C++ classes and
templates stuff gets me confused. This template code uses scheduler
locking to make it thread safe.

        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] Booting from Flash in a AT91M55800A based platform

[Frank Pagliughi]

Pazos Escudero Nuria wrote:

>Hi,
>
>I've ported eCos and RedBoot for a proprietary platform comprising the
>AT91M55800A processor a SRAM and three S29AL016D90TFI02 flash modules.
>The RAM version works fine and I can communicate with the RedBoot
>console through the serial port, but I have not yet managed to make the
>platform boot from the flash (after copying the ROM version of the
>ported RedBoot on the flash address pointed by the chip select 0). I
>don't know whether the problem comes from the platform porting or from
>the fact that eCos does not recognize the used flash chips from
>Spansion. Could you provide me any hint?
>
>Thanks in advance!
>Nuria
>
>  
>
If you're programming the Flash chips with a JTAG, then the lack of eCos 
drivers doesn't matter at this stage.
- Does the JTAG software claim that the "program and verify" worked 
properly?
- Are the Flash chips properly wired on the board?
- Did you set up the "_InitMemory" table in "hal_platform_setup.h" for 
the Flash chip(s). You need to set the base address, # wait states, etc. 
Plus the base address for each CS line must be different, even if the CS 
is disabled.
- You should be able to reset the CPU and single step through the first 
few instructions, using the JTAG and/or gdb. Remember that the chip 
starts with the first Flash (CS0) mapped to address zero. You can single 
step up to the point where the chip select registers are loaded and make 
sure that the values are being loaded properly.  But note that you can't 
step over the remap command since the debugger messes with the pipeline.
- One of the first things that the assembly startup does is set the 
master clock (and maybe the PLL) running faster. If you set them running 
faster than the external board can support, the board may lock up.


Whatever you're using to load the RAM debug code onto the board is 
initializing it properly (a JTAG initialization file?). Use that as a 
starting point. The only thing it isn't doing is setting up the Flash 
chip select registers in the EBI, so pay careful attention to that.

Frank

-- 
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] Booting from Flash in a AT91M55800A based platform

[Pazos Escudero Nuria]

Hi,

I've ported eCos and RedBoot for a proprietary platform comprising the
AT91M55800A processor a SRAM and three S29AL016D90TFI02 flash modules.
The RAM version works fine and I can communicate with the RedBoot
console through the serial port, but I have not yet managed to make the
platform boot from the flash (after copying the ROM version of the
ported RedBoot on the flash address pointed by the chip select 0). I
don't know whether the problem comes from the platform porting or from
the fact that eCos does not recognize the used flash chips from
Spansion. Could you provide me any hint?

Thanks in advance!
Nuria

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