[Bug 1000693] flash.c assertion failure

[Bug 1000693] flash.c assertion failure

[bugzilla-daemon]

http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000693





--- Comment #1 from Andrew Lunn <andrew.lunn@ascom.ch>  2009-03-02 22:21:18 ---
The problem with flash3 is that the test case itself instansiates a new flash
driver instance at compile time. There is then an incosistancy between the
number of flash devices known by CDL in CYGHWR_IO_FLASH_DEVICE and the number
of entries in the HAL table cyg_flashdevtab[].

The current design does not allow "user space" flash drivers. All drivers have
to be in the eCos tree where they have access to CDL and can set
CYGHWR_IO_FLASH_DEVICE correctly. 

I'm not sure how to resolve this issue. 

Remove flash3?
Add a CDL option CYGHWR_IO_FLASH_DEVICE_USERSPACE which implements 
CYGHWR_IO_FLASH_DEVICE twice and disables the assert?

Bart: What do you think?


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Issue 1000693] flash.c assertion failure

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
https://bugzilla.ecoscentric.com/show_bug.cgi?id=1000693

Mark Mumford <markthetyke@4dv.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markthetyke@4dv.net

--- Comment #7 from Mark Mumford <markthetyke@4dv.net> 2010-07-17 05:54:46 BST ---
I get the same error when trying to use the SST flash driver. I am porting the
smdk2410 to a mini2440 board which uses a s3c2440a micro with NAND and NOR
flash. Other than that it seems to be a copy of the samsung board. The NOR
flash being a SST 39VF1601 chip. This is the FriendlyARM mini2440 board which
seems fairly popular in some circles.
The comments say that CYGHWR_IO_FLASH_DEVICE is calculated but I cannot see
where this happens. This is a platform issue and the chip is hardwired onto the
board not on an extension board.

-- 
Configure issuemail: https://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the issue.

[Issue 1000693] flash.c assertion failure

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000693





--- Comment #3 from Bart Veer <bartv@ecoscentric.com>  2009-03-03 14:59:42 ---
Adding a flash driver in user space is not a common requirement, but
the synthetic target can be rather more dynamic than a physical board.
I can think of other scenarios where it might be desirable, for
example a board with the SPI signals on an expansion connector and
hooked up to an external dataflash. Some people may prefer to instantiate
the dataflash device in application space rather than update the platform
HAL and the target definition.

So, adding CYGHWR_IO_FLASH_DEVICE_USERSPACE is probably the sensible
way to go. The flash3.c test would then need a #ifdef on that option.
Unfortunately that means the test won't actually be run very often -
only when the application developer has explicitly enabled that
option.

I am not sure why you think _USERSPACE should implement
CYGHWR_IO_FLASH_DEVICE twice? Are you worried about the case where
there are zero flash devices in the target definition and >=2 flash
devices in user space? If so, having two implements properties would
indeed be the safe solution.

Bart


-- 
Configure issuemail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the issue.