Honored ContributorDoes anybody know when and how cyg_flash_devtab[] array is filled in? I see &(syg_flashdevtab[0]) == &syg_flashdevtab_end and syg_flashdevtab[0].num_block_infos < 0 whereas SYGHWR_IO_FLASH_DEVICE == 1
Honored ContributorIt is automatically filled in using the DEVTAB_ENTRY macro.
I suggest reading this chapter (and the ones around it) about writing drivers for eCos: http://www.ecoscentric.com/ecospro/doc/html/ref/io-how-to-write-a-driver.htmlHonored ContributorI am afraid your link is a copy of http://ecos.sourceware.org/docs-3.0/ref/io-how-to-write-a-driver.html and there seems to be an error in DEVIO_TABLE calling: seeing devtab.h, it should be DEVIO_TABLE(l, write, read, select, get_config, set_config), they omitted select. I wrote
DEVIO_TABLE( p8p_handlers, p8p_write, p8p_read, p8p_select, p8p_get_config, p8p_set_config, p8p_close ); DEVTAB_ENTRY( p8p_label, p8p_name, 0, //does not depend upon a lower level interface &p8p_handlers, p8p_init, p8p_lookup, p8p_priv ); and cdl_package CYGPKG_DEVS_FLASH_P8P { display "P8P FLASHlike memory support" parent CYGPKG_IO_FLASH description "FLASHlike memory device support for P8P" implements CYGHWR_IO_FLASH_DEVICE hardware compile p8p.c } in .cdl. It is built alright but cyg_flash_devtab does not seem to be filled in.Honored ContributorYes, the DEVTAB_ENTRY macro will only fill in the generic devtab, which holds any kind of driver accessible with the generic API. eCos also has specific device tables for special kind of peripherals, such as for example cyg_flashdevtab for flash devices. Those tables need dedicated macros to be filled correctly.
In that case if you can't find the documentation, it is a good idea to check the include files of the generic package. For example in your case, in the CYGPKG_IO_FLASH package, you'll find with the following macros in packages/io/flash/current/include/flash_dev.h (on my old version of eCos, so yours my differ a little):// Macros for instantiating the above structures.
# ifdef CYGHWR_IO_FLASH_BLOCK_LOCKING
# define CYG_FLASH_FUNS(_funs_, _init_, _query_ , _erase_, _prog_ , _read_, _lock_, _unlock_)
struct cyg_flash_dev_funs _funs_ =
{
.flash_init = _init_,
.flash_query = _query_,
.flash_erase_block = _erase_,
.flash_program = _prog_,
.flash_read = _read_,
.flash_block_lock = _lock_,
.flash_block_unlock = _unlock_
}
# else
# define CYG_FLASH_FUNS(_funs_, _init_, _query_ , _erase_, _prog_ , _read_, _lock_, _unlock_)
struct cyg_flash_dev_funs _funs_ =
{
.flash_init = _init_,
.flash_query = _query_,
.flash_erase_block = _erase_,
.flash_program = _prog_,
.flash_read = _read_
}
# endif
// We assume HAL tables are placed into RAM.
# define CYG_FLASH_DRIVER(_name_, _funs_, _flags_, _start_, _end_, _num_block_infos_, _block_info_, _priv_)
struct cyg_flash_dev _name_ CYG_HAL_TABLE_ENTRY(cyg_flashdev) =
{
.funs = _funs_,
.flags = _flags_,
.start = _start_,
.end = _end_,
.num_block_infos = _num_block_infos_,
.block_info = _block_info_,
.priv = _priv_
}
TO_BE_DONE
Honored Contributorno this should be enough... are you sure that your custom driver is included in the eCos configuration? Could there be a# ifdef somewhere that prevents those macros from running?
An easy way I have to find out if a specific part of the source code is compiled, is to voluntarily introduce a syntax error just before of after those macros. If you can still compile eCos without any errors, then it means that your code isn't compiled, or ignored. AFAIK the CYG_FLASH_DRIVER inserts an element statically in the code, during compile time, so there is no reason why the table wouldn't be populated. Are you looking at the correct table? From what I'm seeing, the table used by those macros is cyg_flashdev, not cyg_flash_devtabHonored ContributorMany thanks for so quick reply.
--- Quote Start --- are you sure that your custom driver is included in the eCos configuration? Could there be a# ifdef somewhere that prevents those macros from running? An easy way I have to find out if a specific part of the source code is compiled, is to voluntarily introduce a syntax error just before of after those macros... Are you looking at the correct table? From what I'm seeing, the table used by those macros is cyg_flashdev, not cyg_flash_devtab --- Quote End --- Yes, the driver is included. I made syntax errors involuntary and it took me about ten attempts to compile the code. I don't look at the table directly; I see that, in cyg_flash_init function, I have got &(cyg_flasdevhtab[0]) == &cyg_flashdevtab_end (I made debug output) that results in returning SYG_FLASH_INVALID and the message "FLASH: driver init failed: Invalid FLASH address". Any advice?Honored ContributorHmm this is very strange... this table is defined here:
// This array contains entries for all flash devices that are
// installed in the system.
__externC struct cyg_flash_dev cyg_flashdevtab;
CYG_HAL_TABLE_BEGIN(cyg_flashdevtab, cyg_flashdev);
// end of the flashdev table
__externC struct cyg_flash_dev cyg_flashdevtab_end;
CYG_HAL_TABLE_END(cyg_flashdevtab_end, cyg_flashdev);Thanks a lot, the problem seems to have been in linking. I ensured linking and just now I saw such a message after start:
flash dev fun initinit: 0xeff13a4c
flash inited ok
sorry, flash config exceeds available space in fis directory
redboot(tm) bootstrap and debug environment [rom]
non-certified release, version unknown - built 16:23:08, dec 18 2013
copyright (c) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
free software foundation, inc.
redboot is free software, covered by the ecos license, derived from the
gnu general public license. you are welcome to change it and/or distribute
copies of it under certain conditions. under the license terms, redboot's
source code and full license terms must have been made available to you.
redboot comes with absolutely no warranty.
platform: ar4080 (powerpc p4080) ist board
ram: 0x00000000-0x80000000 [0x00100000-0x7fffc000 available]
flash: 0x00000000-0x007fffff, 4 x 0x100 blocks, 130 x 0x1000 blocks
redboot>
Honored ContributorI'm sorry I have never used that kind of flash so I can't help you a lot more on this issue. The only flash I'm using is the EPCS. One strange thing though is this line:
--- Quote Start --- Platform: AR4080 (PowerPC P4080) IST board --- Quote End --- Are you sure this is the right platform? Did you install the Nios2eCos package and did you select the Nios2 platform? As for the link process, when using the eCos HAL tables it is important that the driver code is linked with the kernel in the main archive. If it is linked later (with the application, for example) without the -Wl,--whole-archive option, then gcc can strip some symbols that seem unused and will remove your structure from the table. But as long as your driver's cdl file is correctly read by the eCos build system, the driver should be linked with the kernel so this is a problem you aren't supposed to see.Honored Contributor
