Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

Filling in cyg_flash_devtab[] array

Altera_Forum
Honored Contributor II
1,970 Views

Does 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

0 Kudos
11 Replies
Altera_Forum
Honored Contributor II
416 Views

It 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.html
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

I 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.
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

Yes, 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_ }
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

TO_BE_DONE

0 Kudos
Altera_Forum
Honored Contributor II
416 Views

no 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_devtab
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

Many 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?
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

Hmm 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);Try to have a look at the symbols in the compiled file. This table is placed in a special link section called .ecos.table.cyg_flashdev, and you should have your p8p_drv_handle symbol in that section. 

Are you sure your driver is linked with the rest of the eCos kernel? 

How did you include it in the eCos configuration? Is your .cdl file correctly included in the ecos.ecc configuration file?
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

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 init 

init: 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>
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

I'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.
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

 

--- Quote Start ---  

Are you sure this is the right platform? Did you install the Nios2eCos package and did you select the Nios2 platform?  

--- Quote End ---  

 

 

I must check it. 

 

 

--- Quote Start ---  

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. 

--- Quote End ---  

 

 

Yes, the problem was in the absence of "whole-archive" option although I linked my driver with the kernel. I believe my predecessor had his reasons to avoid that option; so, I just included empty global function in my driver and called it during booting. No, that is not nice but it may be ok for a while. 

Now, as my driver is linked, I have faced new problem with FIS.
0 Kudos
Altera_Forum
Honored Contributor II
416 Views

It's just that this is an Altera forum, and the eCos section here is more specifically about the Nios II port of eCos. If you are using a PowerPC board you'll probably have more luck on a more generic eCos forum or mailing list, or maybe on a PowerPC forum.

0 Kudos
Reply