headers
Rene Nielsen | 2 Mar 2009 12:01

Making support for different flash sizes.

Hi,

Suppose you have created a HAL Variant named "abc". And suppose that it supports a range of different 16
MByte flash devices, and that these devices are specified in .../devs/flash/≤arch>/abc/current/cdl/flash_abc.cdl.

Now suppose that your sales organization says: Hey, please squeeze your code into an 8 MByte flash device,
so that we can save some bucks.

For reasons other than the flash-size issue, I'd like to create a new redboot_ROMRAM.cdl file for the board
equipped with the 8MByte flash. Let's call this redboot_ROMRAM_8MB_flash.ecm and place it next to the
original redboot_ROMRAM.ecm file.

The original redboot_ROMRAM.ecm file contains a line like the following:
  package -hardware CYGPKG_DEVS_FLASH_≤ARCH>_ABC current ;

I would perfer *not* to list both the 8 and 16 MByte flash devices in the same flash_abc.cdl file. So my
question is:

Is it possible to create a new file next to flash_abc.cdl called e.g. flash_abc_8mb_flash.cdl and point
that out from redboot_ROMRAM_8MB_flash.ecm, or will I have to create a completely new
/devs/flash/≤arch>/abc_XXX branch? Or is there a better way to handle this?

Thanks,
René Schipp von Branitz Nielsen 
Vitesse Semiconductors

--

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

Permalink | Reply | 2 comments |
headers
Jürgen Lambrecht | 2 Mar 2009 12:42
Favicon

Re: Interrupt stack on ARM arch.

Hello Martin,

I also just read your previous mail on ecos-devel.
Each 12us an IRQ is indeed fast!
Using the FIQ is a good idea, but you should then not use eCos (in 
vectors.S). Just write all FIQ handling code yourself in assembly then. 
I have had problems with the ARM FIQ 
(http://sourceware.org/ml/ecos-discuss/2007-09/msg00099.html).
Also search the mailing list for "FIQ", there are some interesting mails.

Martin Laabs wrote:
> Hi,
>
> I've been looking in vectors.S in ecos/packages/hal/arm because I
> get a trap when disableing the CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK
> option.
> There you find the following:
>
>
> IRQ:
>         // Note: I use this exception stack while saving the context because
>         // the current SP does not seem to be always valid in this CPU mode.
>         ldr     sp,.__exception_stack   // get good stack
>         stmfd   sp!,{r0-r5}             // save some supervisor regs
>         sub     r0,lr,#4                // PC at time of interrupt
>         mrs     r1,spsr
>         mov     r2,#CYGNUM_HAL_VECTOR_IRQ
>         mov     r3,sp
> [...]
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
joseph biswal | 2 Mar 2009 17:27
Picon

Redboot run issues when HAL_MMU_OFF is issued

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:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gary Thomas | 2 Mar 2009 17:32
Favicon

Re: Redboot run issues when HAL_MMU_OFF is issued

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();
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Zimman | 2 Mar 2009 17:34
Favicon

RE: Redboot run issues when HAL_MMU_OFF is issued

> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tarmo Kuuse | 2 Mar 2009 17:36
Picon
Favicon

Re: Avoiding memcpy in ethernet drivers

Edgar Grimberg wrote:
> Having to write a driver for an ethernet device, I noticed that there
> are 2 memcpy()s in most of the drivers, one when sending and one when
> receiving. This usually happens from and to the sg_list passed from
> the hardware independent ethernet driver. Now, is this really
> necessary?
> For my case, I have one ring of buffers for each send and receive. I
> would like to craft the driver as such to point the buffers to the
> buffer in sg_list, but I can set up the rings only when the device is
> stopped. This excludes ad-hoc setting when receiving/sending.
> My idea was to create the sg_list-s (one for send and one for receive)
> so they can be available to the init function from the NETDEVTAB_ENTRY
> macro. In this way, a driver will need to take care of the pointers
> to/from the sg_list-s.
> Any comments/advices on this ?

Just pointing out that some ethernet HW requires aligned buffers. E.g. 
FEC in newer ColdFire devices needs data to be aligned to 4 bytes.

--
Kind regards,
Tarmo Kuuse

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 1 comment |
headers
Edgar Grimberg | 2 Mar 2009 17:51

Re: Re: Avoiding memcpy in ethernet drivers

Tarmo Kuuse wrote:
> Edgar Grimberg wrote:
>> Having to write a driver for an ethernet device, I noticed that there
>> are 2 memcpy()s in most of the drivers, one when sending and one when
>> receiving. This usually happens from and to the sg_list passed from
>> the hardware independent ethernet driver. Now, is this really
>> necessary?
>> For my case, I have one ring of buffers for each send and receive. I
>> would like to craft the driver as such to point the buffers to the
>> buffer in sg_list, but I can set up the rings only when the device is
>> stopped. This excludes ad-hoc setting when receiving/sending.
>> My idea was to create the sg_list-s (one for send and one for receive)
>> so they can be available to the init function from the NETDEVTAB_ENTRY
>> macro. In this way, a driver will need to take care of the pointers
>> to/from the sg_list-s.
>> Any comments/advices on this ?
>
> Just pointing out that some ethernet HW requires aligned buffers. E.g. 
> FEC in newer ColdFire devices needs data to be aligned to 4 bytes.
>
Thanks for pointing that out. I'd say to align them at cache line, this 
will make it easier to debug in case there are some problems with caches 
and manual flushing and invalidation is needed. For my driver (eTSEC), 
the requirements are a bit unbalanced:
"Receive buffer pointer, written by the user. The receive buffer 
pointer, which always points to the first location of the associated 
data buffer, must be 8-byte aligned. The buffer must reside in memory 
external to the eTSEC."
and
"The transmit buffer pointer contains the address of the associated data
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Zimman | 2 Mar 2009 18:08
Favicon

RE: Redboot run issues when HAL_MMU_OFF is issued

> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bart Veer | 3 Mar 2009 19:22
Favicon

Re: Avoiding memcpy in ethernet drivers

>>>>> "Edgar" == Edgar Grimberg <edgar.grimberg <at> gmail.com> writes:

    Edgar> Having to write a driver for an ethernet device, I noticed
    Edgar> that there are 2 memcpy()s in most of the drivers, one when
    Edgar> sending and one when receiving. This usually happens from
    Edgar> and to the sg_list passed from the hardware independent
    Edgar> ethernet driver. Now, is this really necessary?

Ethernet hardware varies widely, but there are two main categories:
fifo vs. DMA.

With a fifo-based device the driver just puts an outgoing packet into
a transmit fifo, possibly an int at a time, possibly a byte at a time.
Similarly incoming packets are read out of a receive fifo. So there
has to be a copy operation between the sg_list and the fifo.

With DMA, ideally there would be no need for a copy operation - if the
hardware was designed just right, and if higher-level code like the
BSD, RedBoot or LWIP TCP/IP stacks did the right thing. Unfortunately
neither assumption is safe.

For outgoing packets the DMA engine typically imposes some
limitations. For example the start of a DMA buffer may have to be
aligned to an integer boundary, or to a cacheline boundary (typically
but not always 16-bytes). If an outgoing packet is split over multiple
buffers then the DMA engine may require that every buffer except the
last one is a multiple of the cacheline size. Currently there is no
mechanism for ethernet drivers to indicate such restrictions to
higher-level code, and the sg_list's provided by higher-level code may
provide buffers with arbitrary alignments and lengths.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Grant Edwards | 3 Mar 2009 20:23
Favicon

Re: Avoiding memcpy in ethernet drivers

On 2009-03-03, Bart Veer <bartv <at> ecoscentric.com> wrote:
>>>>>> "Edgar" == Edgar Grimberg <edgar.grimberg <at> gmail.com> writes:
>
>> Having to write a driver for an ethernet device, I noticed
>> that there are 2 memcpy()s in most of the drivers, one when
>> sending and one when receiving. This usually happens from and
>> to the sg_list passed from the hardware independent ethernet
>> driver. Now, is this really necessary?
>
> Ethernet hardware varies widely, but there are two main
> categories: fifo vs. DMA.
[...]
> With DMA, ideally there would be no need for a copy operation
> - if the hardware was designed just right, and if higher-level
> code like the BSD, RedBoot or LWIP TCP/IP stacks did the right
> thing. Unfortunately neither assumption is safe.
>
> For outgoing packets the DMA engine typically imposes some
> limitations. For example the start of a DMA buffer may have to
> be aligned to an integer boundary, or to a cacheline boundary
> (typically but not always 16-bytes). If an outgoing packet is
> split over multiple buffers then the DMA engine may require
> that every buffer except the last one is a multiple of the
> cacheline size.

My experience is somewhat limited, but I've yet to see a uC
Ethernet controller with a DMA engine that supported splitting
frames in any manner at all (inbound or outbound).  If the
network stack requires that packets be split into various
chunks, then there's simply no avoiding the copy operation.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane