- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
We have a board that uses 2 SST39VF160 sticks of flash. These are both 1 Meg by 16-bits. They have been configured as 1 Meg by 32-bits for a total of 4 MBytes of flash capacity.
I have managed to write some drivers that allow my Nios core to read, write, and clear the flash. In my main routine, I can make the calls something like this. # include "sst_flash.h" alt_flash_fd *fd; fd = alt_flash_open_dev(FLASH_NAME); // as defined in system.h by SOPC builder if(fd) { sst_flash_erase_block(fd, offset); sst_flash_write(fd, offset, data, length); sst_flash_read(fd, offset, data_rb, length); } // end if else return -1; // just bail if the open fails. All is happy in the main routine. I have loops that run through and verify the flash contents. I have already made my own flash-programming design for this board. My flash programmer seems to download and work just fine. It seems to hang up when it tries to open the flash device. I get the following failure, see below. Feb 8, 2005 3:53:43 PM - (SEVERE) nios2-flash-programmer: Error opening target hardware Feb 8, 2005 3:53:43 PM - (SEVERE) nios2-flash-programmer: Unable to open flash-device after successfully communicating with target. I changed my alt_sys_init.c file so that it creates an instance, and initiates the flash. How do I get the system to use my flash drivers?링크가 복사됨
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Your question asks how do you integrate your flash into the HAL. However you seem to think that this will solve your flash programmer issue. It won't all it will do is give you access to the HAL flash API.
If you wish to have access to the HAL API you should look in the file altera_avalon_cfi_flash_table.c in the function alt_set_flash_algorithm_func, this of course assumes that your flash is CFI compliant.- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Perhaps I am asking the wrong question. I was thinking that the flash programmer used the HAL API to program the on-board flash.
If I am successful in integrating my CFI compliant flash dirvers into the HAL, will I be able to get the flash programmer to call my routines to program the flash?- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
No sorry, you will be able to program your flash from your program, which you can already do. However the flash_programmer does not use the HAL APIs
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
If the flash programmer fails to communicate with the flash on our board, am I toast?
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
You don't really need to rely on the Nios II's IDE to program the FLASH. It just means that you have more work to do. The easiest option is to make a program that does know how to write to your FLASH device, put the code/data you want flashed in the program as an array (c initializer) then download your program to RAM through the JTAG interface and have your code FLASH the data from the array into the FLASH.
This requires two big steps. Getting your code/data into a binary format and getting that binary data into a c initializer. objcopy is very useful for getting the code into a binray format and I find that perl (or other scripting languages) are easy to use to create a c-initializer of the binary data.- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
This can be done, and I have already loaded the Linux kernel into the SRAM. I had similar thoughts of moving the kernel from RAM to flash; However, the flash becomes an issue when I try to load the file system. The only way I know how to load the file system is through the flash-programmer.
I'm going to try to reconfigure my Nios core. I currently have two 16-bit wide sticks of flash configured as one 32-bit wide flash. I'm going to separate them in SOPC builder and write some VHDL code to do the address decoding. I did something similar for the SRAM, and it works just fine. I'm hoping this will work for the flash as well. I'll post a success or failure when I'm done. I don't think I'm going to get back on this again until tomorrow.- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
CFI interface does not mean CFI compliant. The SST flash has a CFI interface, but it does not follow the CFI guidlines developed by Intel, AMD, Sharp, and Fujitsu. I have only read Intel and AMD versions.
For example, to do a CFI Query a device should send the following address and data values. Address: 0x55, Data: 0x98 in one write cycle. The SST CFI Query is done with Address: 0x5555, DATA 0xAA Address: 0x2AAA, Data 0x55 Address: 0x5555, Data 0x98 in three write cycles. In order to get the SST flash to enter query mode, I had to write VHDL driver that decoded the single write cycle used by CFI compliant flash devices and generate the SST query command. Pay attention to the data sheet, this is much easier.