AnsweredAssumed Answered

Errors in SDK 1.8 Linux deployment documentation for B4860QDS board?

Question asked by Ken Lauffenburger on Jul 20, 2015
Latest reply on Jul 24, 2015 by Yiping Wang

According to the Freescale Information Center document, in the section "Ramdisk Deployment from Flash" for the B4860QDS board, Step 3 "Programming Ramdisk to NOR Flash", the steps are:

     3.     Programming Ramdisk to NOR Flash

The ramdisk should be downloaded to the RAM then copied to the flash address <ramdisk_start_addr>. At the U-Boot prompt, use the following commands to program the ramdisk to flash:

=>tftp 2000000 fsl-image-core-<platform>.ext2.gz.u-boot
=>protect off <ramdisk_start_addr> +$fielsize
=>erase <ramdisk_start_addr> +$filesize
=>cp.b 2000000 <ramdisk_start_addr> $filesize
=>protect on <ramdisk_start_addr> +$filesize

I take the address specification <ramdisk_start_addr> to be one of the Rootfs addresses 0xEF300000 (alternate bank) or 0xED300000 (current bank) listed in Table 1 of the section "Flash Bank Usage" found in the same document for the same board a few sections earlier.  According to the table, the space allocated for the image at either of these addresses is 12 MBytes.

 

But this is the result when I attempt to execute the above listed commands:

tftp 2000000 fsl-image-core-b4860qds-64b-20150613235020.rootfs.ext2.gz.u-boot

...

Bytes transferred = 38711773 (24eb1dd hex)

=> protect off ef300000 +$filesize

Error: end address (0xf17eb1dc) not in flash!

Bad address format

 

The above image is a pre-built image from the SDK 1.8 package.  The apparent problem is that the image is over 38.7 MBytes in size.

 

What am I doing wrong here?  Did I interpret the document wrong?  Am I trying to write the image to the wrong address, or do I have the wrong image?  Is the documentation wrong?

 

Also, according to the hardware documentation for the board (B4860QDSRM), there are 128 MBytes of NOR flash provided on the board.  But in the Information Center document, the NOR flash address space listed in the above referenced Table 1 spans the address range 0xEC000000 to 0xEFFFFFFF, which, if my arithmatic is correct, is 64 MBytes, not 128 MBytes.

 

What gives here?

 

I'm at a dead stop here.  Thanks for any help anyone can provide.

 

--ken

Outcomes