[Bug 1000693] New: flash.c assertion failure

[Bug 1000693] New: flash.c assertion failure

[bugzilla-daemon]

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

           Summary: flash.c assertion failure
           Product: eCos
           Version: 3.0beta1
          Platform: linux (Linux synthetic target)
        OS/Version: Other
            Status: NEW
          Severity: normal
          Priority: normal
         Component: Flash driver
        AssignedTo: gary@mlbassoc.com
        ReportedBy: andrew.lunn@ascom.ch
         QAContact: ecos-bugs@ecos.sourceware.org
             Class: ---


synth target, template all.

/home/lunn/eCos/work/install/tests/devs/flash/synthv2/current/tests/flash3
ASSERT FAIL: <1>flash.c[228]cyg_flash_init() incorrect number of flash devices 
ASSERT FAIL: <1>flash.c             [ 228] cyg_flash_init()                    
                                                                incorrect
number of flash devices

Some of the other flash test cases are also failing....


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

[Bug 1000693] flash.c assertion failure

[bugzilla-daemon]

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


John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bartv@ecoscentric.com




--- Comment #2 from John Dallaway <john@dallaway.org.uk>  2009-03-03 13:16:09 ---
Adding Bart Veer to the CC list for comment.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/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]

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.

[Bug 1000693] flash.c assertion failure

[bugzilla-daemon]

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





--- Comment #4 from John Dallaway <john@dallaway.org.uk>  2009-03-19 11:20:30 ---
Andrew, are you able to sort this out for eCos 3.0 or should we push it out to
be fixed at some later time?


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

[Bug 1000693] flash.c assertion failure

[bugzilla-daemon]

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


Andrew Lunn <andrew.lunn@ascom.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Flag|                            |Blocking_3.0-




--- Comment #5 from Andrew Lunn <andrew.lunn@ascom.ch>  2009-03-20 20:27:53 ---
It is a corner case which will not affect many users, only those with pluggable
flash devices, eg DataFlash. So i suggest we don't have this as a blocker for
3.0.


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

[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.