- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have spent several days now searching and reading and think I am nearly there... but not quite. I am using the NIOS II core with SOPC builder. I use Quartus II for the FPGA image. This is a project I have inherited which kept the FPGA image in a ECPS64 and the software image in CFI. I have combined the two and keep them in the EPCS64. Works OK. I have been trying to get the remote update controller to work. I have put it into the core via SOPC and can read and write its registers via NIOS. I can also make it do a reconfig but it always seems to use the factory image. Has any one got a working example using the Cyclone III and NIOS II?
I use the following to read 2 of the registers... ParamValue = IORD( REMOTE_UPDATE_CYCLONEIII_0_BASE, 0x4); ParamValue = IORD( REMOTE_UPDATE_CYCLONEIII_0_BASE, 0x0); After power on both registers read 0. After reconfig command, register 0 = 1 and register 4 = 8 Any ideas please? Brain is starting to hurt!Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
:):)
Sorted. Used the settings in my previous post but instead of doing a make on the bootloader did a make CODE_BASE=0x0. Working now. :):) Thanks all for your help.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- You can probably just put the boot code into a user-defined internal memory block, and point the nios reset vector at it. That would remove the problems of the sopc builder repeatedly substituting its own file. After all, I presume that is what happens anyway. It would also let you use TCM for the boot code (probably more useful for the JTAG block though since you are probably copying code to SDRAM and have an instruction cache anyway). --- Quote End --- Dsl, I am following what you suggested. My problem is that the EPCS controller does not give me a transmit ready signal (when I read the status register)and the bootloader gets stuck in the loop waiting for the flash to be ready. If you look at the object file dump, // Wait until controller is ready for a TX-char, then send it. tx_ready_loop: ldwio rf_temp, EPCS_STATUS_OFFSET (r_epcs_base_address) d0: 92400237 ldwio r9,8(r18) andi rf_temp, rf_temp, EPCS_STATUS_TRDY_MASK d4: 4a40100c andi r9,r9,64 beq rf_temp, r_zero, tx_ready_loop d8: 483ffd26 beq r9,zero,d0 <tx_ready_loop> stwio r_epcs_tx_value, EPCS_TXDATA_OFFSET (r_epcs_base_address) dc: 92c00135 stwio r11,4(r18) It is here where I am not able to move forward. I never get reach address 0xdc. Till this point I am fine. This is my flow I keep the bootloader on internal memory and upon finding that the boot is for application image, I load the bootloader to an on-chip ram. I reset the nios control to the bootlader and let it run. When i am debugging the bootloader (i access the on-chip memory and put return instruction at various location to see how far the flow runs), I get stuck in the above loop shown. Any help would be great.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,Cris Could you please tell me how to generate my epcs_controller_boot_rom.hex with customized start address?
I only got *.elf files but not *.hex files by rebuilt boot_loader_sources directory using NIOS II command console tools, and the r_flash_ptr has already been set to my new start addrss.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please take a look at the attached sample. This was for Cyclone III; you may need some changes to make it work on other fpga devices.
- unzip the files in a new directory - open Nios II command shell and go there - change EPCS_SRC_ADDR in boot_loader.h with desired boot address for Nios application - build the custom bootloader, which generates a epcs_controller_boot_rom_A.hex file (simply type 'make') - replace the existing epcs_controller_boot_rom.hex file in your Quartus project with the newly generated one (thus removing _A) - select Quartus Processing menu, then Update Memory Initialization file - select Quartus Processing menu, then Start -> Start Assembler - the generated sof file will boot from the specified epcs address- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Chris,
To boot on the desired address for Nios application, I did exactly what you did but unfortunately when I use your sample and I type 'make' I have the error : "make *** [all] Error 2" ; whereas when I go to my directory where boot_loader.h is defined and I modified the EPCS_SRC_ADDR like superior_100 I have only generation of .elf files, where is the problem ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Chris,
To boot on the desired address for Nios application, I did exactly what you did but unfortunately when I use your sample in typing 'make' I have the error : "make *** [all] Error 2" ; whereas when I go to my directory where boot_loader.h is defined and I modified the EPCS_SRC_ADDR like superior_100 I have only generation of .elf files. Where is the problem ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Julien92,
You may try "make CODE_BASE=0x0". A link is valuble, I think you will get what you want there: 3w.alterawiki.com/wiki/EPCS_bootloaders. Good luck!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you superior_100, it worked.
Just have another problem, when I want to Update Memory Initialization file with Quartus processing menu, it doesn't to update the new Hex : Error: Project contains unresolved partitions Error: Unresolved partition "<Top partition>" Error: Quartus II MIF/HEX Update was unsuccessful. 2 errors, 0 warnings- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok I opened the new epcs_flash_boot_controller.hex file in quartus and
in Quartus process menu -> Update Memory file worked, however to start assembler what do I have to do ? I have none idea !- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Julien_92,
I have already make it follow what Cris72 had said, I copy the steps below, besides, you can may some useful info at alterawiki & search EPCS bootloaders. - unzip the files in a new directory - open Nios II command shell and go there - change EPCS_SRC_ADDR in boot_loader.h with desired boot address for Nios application - build the custom bootloader, which generates a epcs_controller_boot_rom_A.hex file (simply type 'make') - replace the existing epcs_controller_boot_rom.hex file in your Quartus project with the newly generated one (thus removing _A) - select Quartus Processing menu, then Update Memory Initialization file - select Quartus Processing menu, then Start -> Start Assembler - the generated sof file will boot from the specified epcs address- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes I followed these steps and it worked,
however I don't know if I have to open a specific file from my quartus project before to do start assembler or settle a parameter in quartus II ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't know whether this is necessary, but I just do like this:
-rename epcs_controller_boot_rom_A.hex to kernel_epcs_flash_controller_0_boot_rom_synth.hex; -replace the system generated kernel_epcs_flash_controller_0_boot_rom_synth.hex with mine; -copy my kernel_epcs_flash_controller_0_boot_rom_synth.hex to the root direction of my project, and add it to the project; -then Processing->Update Memory Initialization file; -Processing->Start -> Start Assembler; now the .sof file is updated, and it is right file.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just had to remove db and incremental db folders in my quartus project to run fitter without problems and start assembler after.
Thank you- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
just have another question : why after reconfig command register 4(boot adress) = IORD(REMOTE_UPDATE_BASE, 0x04) = 8 ?
while the bootloader in my second sof is pointing to the firmware at 0 if I use the original bootloader code without modification. So my register 4 shouldn't contain the value 0 ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could somebody could explain me please, because I don't really understand what is happening ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Julien
I believe you are missing a point: the boot address in remote update core and the address of bootloader code are unrelated. Remote update boot address ONLY refers to the position of FPGA configuration image. The Nios firmware position is included in this FPGA configuration itself, i.e. it is defined by the bootloader code you assigned to epcs device with the hex memory initialization file. I don't know why you read 8 from the remote update address register; if FPGA reconfigures correctly probably it's only a trivial read error. Anyway, according to what I said above, you should read here the address of the currently loaded fpga image, not that of Nios firmware.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just to be sure I well understand, in the remote update core you've the boot address
(using IORD to read remote update register like 0x04 to read the boot address) that only refers where the address of FPGA configuration image is situated by default 0. Address of FPGA configuration image that can be changed with the bootloader code (EPCS_boot_rom.hex) ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry if I look lost...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Remote update core is something related to FPGA hardware and it doesn't know anything about Nios or whatever is implemented inside FPGA.
You could have implemented another processor instead of Nios, and this would have a different bootloading method: then, the uP bootloader is only a matter of the specific FPGA configuration and remote update core has no effect on it. In the case of the epcs controller for Nios system, the Nios bootloader is embedded in the controller core itself: this means the bootloader is encapsulated in epcs controller hw logic (sort of PROM bits) when the core is generated and fitted into the fpga image. That's why you need to assign the firmware position before generating the fpga image and you can't change it by simply modifying the remote update settings. Please let me know if you got it clearly or if you need futher explanation.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So the remote update only enables to read position of FPGA configuration image and can't change it ! if I well understand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So for my project in the following attachment, the EPCS64 memory is divided in a factory code and an application code,
when I would have modified the EPCS_boot_rom.hex to# define SOFTWARE_OFFSET 0x400000, with the remote update I could read the position of my FPGA config image with IORD(REMOTE_BASE, 0x4) that should be 0x400000 ? I hope I'm right- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page