headers
oliver munz @ s p e a g | 4 Nov 2008 15:46
Picon

What is the reason to...

mark CYGPKG_IO_SPI as HARDWARE?

I think Generic SPI or I2C and so one should be loadable whitout an 
template. Can we change this?

Thanks
Permalink | Reply | 13 comments |
headers
Bart Veer | 4 Nov 2008 19:56
Favicon

Re: What is the reason to...

>>>>> "Oliver" == oliver munz  <at>  s p e a g <munz <at> speag.ch> writes:

    Oliver> mark CYGPKG_IO_SPI as HARDWARE?
    Oliver> I think Generic SPI or I2C and so one should be loadable
    Oliver> whitout an template. Can we change this?

The problem here is that other drivers such as the wallclock or
dataflash are likely to depend on the SPI/I2C bus being available. On
some platforms there may even be platform HAL dependencies on the bus.
Now, by convention you can enable flash support on a given platform
simply by e.g. "ecosconfig add flash" and everything sorts itself out.
If the SPI or I2C bus driver was not automatically part of the
configuration then that would stop working.

If you want the SPI or I2C support to be automatically available when
needed, working within the limitations of current CDL, then the
generic SPI or I2C packages have to be part of the target definition
in ecos.db. That means they have to be hardware packages.

Also, in most cases the expectation is that the generic SPI and I2C
packages will only be usable if the target definition also specifies a
device driver appropriate for the hardware. So if you are adding SPI
or I2C support to a target then you have to edit the ecos.db target
entry anyway, and adding two packages instead of one is no big deal.

Now, both the generic SPI and I2C packages have been carefully
designed to ensure that they add zero overhead to the application if
nothing actually uses the SPI or I2C bus. Any unused functionality
gets eliminated at link-time by linker garbage collection. Hence the
only real overhead is at build-time: ecosconfig or the configtool may
(Continue reading)

Permalink | Reply | 12 comments |
headers
andrew wiggin | 4 Nov 2008 20:28
Picon

REGION TOP and malloc

Hi all,

I am currently working on an AT91-like board for which I have 16MB of
SDRAM. However, not all of the SDRAM can be used, so I added the
support for CYGINT_HAL_ARM_MEM_REAL_REGION_TOP and it seems to work
well in the sense that my hal_arm_mem_real_region_top() function is
called, and the _actual_ TOP is returned.

Though, my problem is that malloc() still continues to return
addresses above my actual heap TOP. I tried to read the code, my
heaps.cxx really seems OK:
 Cyg_Mempool_dlmalloc CYGBLD_ATTRIB_INIT_BEFORE(CYG_INIT_MEMALLOC)
cygmem_pool_heap1 ( (cyg_uint8 *)CYGMEM_SECTION_heap1 ,
    HAL_MEM_REAL_REGION_TOP( (cyg_uint8 *)CYGMEM_SECTION_heap1 +
CYGMEM_SECTION_heap1_SIZE ) - (cyg_uint8 *)CYGMEM_SECTION_heap1 )
        ;
Which really makes the base address and size I have, and according to
the different Malloc implementation (mvarimpl.inl and dlmalloc.cxx),
malloc should either fail or return a valid address (which _is_
possible as I allocate only 800kB out of 8.9MB available).

In order to do the test, I just replaced all my calls to malloc() with:
void* ptr = malloc(size); \
CYG_ASSERT(ptr <= HAL_MEM_REAL_REGION_TOP( (cyg_uint8
*)CYGMEM_SECTION_heap1 + CYGMEM_SECTION_heap1_SIZE ), "malloc returned
an  <at>  out of memory..." )

This assert always fail after a while (but as stated above, mallinfo()
returns 8.9MB free at this point and the size asked for is lower than
800kB). So where did I miss something ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Evgeniy Dushistov | 6 Nov 2008 19:23
Picon

at91sam9263ek

Hi,  

I want to see working ecos on at91sam9263ek board.  
As far as I know, there is no freely available source code of ecos port on  
this hardware, am I right? (I know about ecoscentric, but it is not  
freely available).  

May be anybody is working on such kind of port?  

Right now I'm reading docs about cdl language, and stuck on which
variant to choose: create directory at91sam9 in  
packages/hal/arm/arm9 and write hal package from scratch  
or use packages/hal/arm/at91 stuff, at91sam9263ek is very similar  
to at91sam7s, but  
packages/hal/arm/at91/var/current/cdl/hal_arm_at91.cdl  
contain things like "implements CYGINT_HAL_ARM_ARCH_ARM7",  
may be someone, who has more experience than I (i.e. > 0) with ecos  
configuration framework, could suggest which solution to choose? 

--

-- 
/Evgeniy
Permalink | Reply | 6 comments |
headers
Praveen VS | 7 Nov 2008 05:03

Intel strata flash -redboot


We have a custom board based on imx27 & we want to boot the kernel from 
flash. But the flash we have is Intel Strata P30 ( JS48F4400P0VB00S).  We 
are modifying the redboot which comes with imx27ADS reference board. We want 
to know  which file we need to modify?
Any body has successfully able to boot kernel from this flash using redboot 
on any other board

Thanks in advance
Regards
Praveen
Permalink | Reply | 3 comments |
headers
Andrew Lunn | 7 Nov 2008 07:34
Picon

Re: Intel strata flash -redboot

On Fri, Nov 07, 2008 at 09:33:08AM +0530, Praveen VS wrote:
>
>
> We have a custom board based on imx27 & we want to boot the kernel from  
> flash. But the flash we have is Intel Strata P30 ( JS48F4400P0VB00S).  We 
> are modifying the redboot which comes with imx27ADS reference board. We 
> want to know  which file we need to modify?
> Any body has successfully able to boot kernel from this flash using 
> redboot on any other board

I think the P30 is a bit odd. Take a look at:

http://sourceware.org/ml/ecos-discuss/2007-04/msg00178.html

        Andrew
Permalink | Reply | 2 comments |
headers
Andrew Lunn | 7 Nov 2008 17:14
Picon

Re: i2c driver for at91sam7x

On Fri, Nov 07, 2008 at 08:39:23PM +0530, vibisreenivasan wrote:
> hello,
> 	Is there any one working on i2c bus driver for at91sam7x.

I know eCosCentric have one, but you need to pay for that. 

Other people have mentioned writing i2c drivers as well.

However, you need to be careful. The i2c hardware is broken. The Linux
kernel marks it as such. See:

http://www.at91.com/samphpbb/viewtopic.php?t=4665&sid=1032a7cdc95b571dc784adb204d78d33

From what i understand, if you are doing transfers of 1 byte, it is
O.K, but multiple byte transfers can break.

Writing a GPIO based driver should be reasonably easy as far as i
understand and does not suffer from these problems.

        Andrew
Permalink | Reply | 0 comments |
headers
oliver munz @ s p e a g | 7 Nov 2008 19:20
Picon

Re: What is the reason to...

In this case templates like:

target at91sam7sek {
    alias { "Atmel AT91SAM7SEK evaluation board" at91_at91sam7sek }
    packages { CYGPKG_HAL_ARM
                   CYGPKG_HAL_ARM_AT91
                   CYGPKG_HAL_ARM_AT91SAM7
                   CYGPKG_HAL_ARM_AT91SAM7SEK
                   CYGPKG_IO_SERIAL_ARM_AT91
                   CYGPKG_DEVS_FLASH_AT91
                   CYGPKG_DEVS_SPI_ARM_AT91
                   CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC
                   CYGPKG_DEVS_USB_AT91
        }
        description "
        The at91sam7sek target provides the packages needed to run eCos 
on an
        Atmel AT91SAM7S-EK evaluation board."
}

should be changed?

They are missing the CYGPKG_IO_SPI and so on...

Thanks Oliver

Bart Veer schrieb:
>>>>>> "Oliver" == oliver munz  <at>  s p e a g <munz <at> speag.ch> writes:
>>>>>>             
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
hartleys | 7 Nov 2008 19:33
Favicon

RE: Intel strata flash -redboot

On Thursday, November 06, 2008 11:34 PM, Andrew Lunn wrote:
> On Fri, Nov 07, 2008 at 09:33:08AM +0530, Praveen VS wrote:
>>
>>
>> We have a custom board based on imx27 & we want to boot the kernel 
>> from flash. But the flash we have is Intel Strata P30 ( 
>> JS48F4400P0VB00S).  We are modifying the redboot which comes with 
>> imx27ADS reference board. We want to know  which file we need to
modify?
>> Any body has successfully able to boot kernel from this flash using 
>> redboot on any other board
>
> I think the P30 is a bit odd. Take a look at:
> 
> http://sourceware.org/ml/ecos-discuss/2007-04/msg00178.html

I'm using the same patch on a ep93xx based board using P30 flash. Works
great for me.

The only problem I found in the patch is in flash_hwr_init() the first:

+ 	__strata_info.base1 = (void *)CYGNUM_FLASH_BASE;

Should be removed. The __strata.info is only available #ifndef
CYGOPT_FLASH_IS_BOOTBLOCK. The .base1 is actually set correctly a bit
later in the code.

Regards,
Hartley
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gábor Török | 8 Nov 2008 22:39
Picon

Re: What is the reason to...

I think it is the same issue CYGPKG_IO_USB and CYGPKG_IO_USB_SLAVE,
which are also marked as hadware packages and not included in the
templates.

On Fri, Nov 7, 2008 at 7:20 PM, oliver munz  <at>  s p e a g <munz <at> speag.ch> wrote:
> In this case templates like:
>
> target at91sam7sek {
>   alias { "Atmel AT91SAM7SEK evaluation board" at91_at91sam7sek }
>   packages { CYGPKG_HAL_ARM
>                  CYGPKG_HAL_ARM_AT91
>                  CYGPKG_HAL_ARM_AT91SAM7
>                  CYGPKG_HAL_ARM_AT91SAM7SEK
>                  CYGPKG_IO_SERIAL_ARM_AT91
>                  CYGPKG_DEVS_FLASH_AT91
>                  CYGPKG_DEVS_SPI_ARM_AT91
>                  CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC
>                  CYGPKG_DEVS_USB_AT91
>       }
>       description "
>       The at91sam7sek target provides the packages needed to run eCos on an
>       Atmel AT91SAM7S-EK evaluation board."
> }
>
> should be changed?
>
> They are missing the CYGPKG_IO_SPI and so on...
>
> Thanks Oliver
>
(Continue reading)

Permalink | Reply | 5 comments |

Gmane