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

nios2-download Verify Failed

Altera_Forum
Honored Contributor II
2,081 Views

Thanks in advance. 

 

We are finally getting a chance to migrate to the mmu branch. Our goal is to use the TSE and Marvell. We've seen in the wiki that we will need to do some adds to the *.dts, etc. 

 

This is a joint effort so I haven't done all the environment setup myself. I see we are using the "trunk" branch when I do a "git branch -l" on both "uClinux-dist" and "linux-2.6.x" 

 

I'm using the Cyclone III 3c120 Evaluation Board 

We got a good *.sopcinfo file and *.sof 

 

We successfully got a *.dts file using the Wiki pages and we built an image. 

 

In the "make menuconfig" we selected "dts" and set the path.  

 

WE've Tried VARIOUS things for the DTB at physical address - which from what 

I found should be used and 0xC0000000 

But we still get the same Verify Failed error on nios2-download and it always starts 

loading at the 0xC0000000 

************************************************************** 

------------------------------------------------ 

Altera Nios2 Command Shell [GCC 3] 

 

Version 10.1, Built Tue Nov 30 02:10:00 PST 2010 

------------------------------------------------ 

 

[NiosII EDS]$ nios2-download -g linux.initramfs.gz 

Using cable "USB-Blaster [USB-0]", device 1, instance 0x00 

Pausing target processor: OK 

Initializing CPU cache (if present) 

OK 

Downloaded 4912KB in 84.6s (58.0KB/s) 

Verifying C0000000 ( 0%) 

Verify failed between address 0xC0000000 and 0xC000FFFF 

Leaving target processor paused 

/cygdrive/c/altera/10.1/quartus/qdesigns/Work/Cyclone3c120/cycloneIII_3c120_nios 

II_standardMMU/uClinux 

[NiosII EDS]$ 

****************************************** 

 

What are we missing? I feel very close. Do we need to modify something in the *.dts?
0 Kudos
9 Replies
Altera_Forum
Honored Contributor II
604 Views

You have to set the "Memory base address" to the address of your main RAM, not including the MMU kernel area offset (0xC0000000). For example, I have 0x04000000 for DDR. 

 

For the simple case -- you should uncheck "DTB at physical address" and instead check "Compile and link device tree into kernel image" and put the path to your DTS file there. 

 

The fancier alternative, which I haven't tried -- 

IF you are: 

  • building your device tree into your FPGA image (onchip ROM) 

  • OR loading it through u-boot 

  • OR storing it in flash 

 

you need to compile your DTS (source) to a DTB (binary) manually (I don't know the tool/command) and use the latter. Uncheck "Compile and link device tree into kernel image". Check "DTB at physical address" and put in the address of the onchip ROM or flash or wherever u-boot puts the DTB in RAM. 

 

If this clarifies it for you, please add the missing information to the wiki pages you used.
0 Kudos
Altera_Forum
Honored Contributor II
604 Views

Thanks. I'll let you know how it goes. That will be next week sometime.

0 Kudos
Altera_Forum
Honored Contributor II
604 Views

TO_BE_DONE

0 Kudos
Altera_Forum
Honored Contributor II
604 Views

O.K. Got it to load at 0xD0000000 

 

In make menuconfig I needed - in Processor type and features: 

 

(0x10000000) Link address offset for booting  

 

Hangs when booting so now time to check the hardware design. 

 

0 Kudos
Altera_Forum
Honored Contributor II
604 Views

That's not right -- that's the value you should put in "Memory base address". The "Link address offset for booting" is an *offset* in your RAM, so it needs to be smaller than the size of your RAM. It's where the image gets loaded before bing uncompressed into the beginning of RAM, so memory size minus approximate size of image minus some leg room gets you a reasonable offset. 2/3 the size of your RAM is also a good rule of thumb. 

 

The download should then start at kernel virtual offset + "Memory base address" + "Link address offset for booting". So in your case, something like 0xD2000000.
0 Kudos
Altera_Forum
Honored Contributor II
604 Views

Thanks for explaining that. I will try (probably this weekend) and post.

0 Kudos
Altera_Forum
Honored Contributor II
604 Views

I'm having the very same problem. How does one set the memory base address? 

 

Thanks
0 Kudos
Altera_Forum
Honored Contributor II
604 Views

 

--- Quote Start ---  

I'm having the very same problem. How does one set the memory base address? 

 

Thanks 

--- Quote End ---  

 

I see this as the first option under "Platform options"
0 Kudos
Altera_Forum
Honored Contributor II
604 Views

Thanks in Advance.  

 

I had to leave this and work on another project. Now that I'm back to it I decided to to use the example from the website for the 3C120 Eval board. So I'm starting with that sopc to create the *.dts and then *.dtb and with the *.dtb the zImage. 

 

I'm doing what is says on the Altera Wiki Devicetree and clarified by ykozlov and the zImage downloads but I still hang at boot. 

 

When I make the *.dts I get the following messages: 

Waring decriptor memory connected through a bridge. I'll probably mess things up trying to gues what memory I'm connected to... 

Component pll_master of class dummy_master is unknown 

but I do get my *.dts. 

 

 

Originally I DID miss the big step of manually getting a *.dtb from the *.dts.  

 

With the non mmu I used to build the zImage and download with nios2-download -g and then use the nios2-terminal. 

 

So, the only way I can get it to load and verified is by having the link address offset = 0x12000000 – and the DTB can be anything.  

 

But the nios2-terminal hangs.
0 Kudos
Reply