UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor honeywelldev
Visitor
8,688 Views
Registered: ‎06-05-2014

Totally dead card

A flash program went bad or something and we are getting nothing from our board.

 

Is it possible, via the jtag connection.. to load the fsbl, bit, uboot, uImage, ramdisk etc all in to memory manually.. then set the PC and say "run"

 

For example I ahve each of those as seperate images, but I also have a prebuilt boot.bin... however since our flash is corrupted we can't even get to a uboot prompt to reprogram it so our only fall back is the JTAG.

 

Is there a way to load the boot.bin into memory, then erase the flash and write it from memory into flash all via XMD?

0 Kudos
24 Replies
Visitor honeywelldev
Visitor
8,686 Views
Registered: ‎06-05-2014

Re: Totally dead card

Btw we ahve tried this sequence

 

connect arm hw
stop
fpga -f download.bit
dow u-boot.elf
run

 

And we do get the "done" light on the FPGA to light up and the uboot serial console shows the first few lines but it freezes after "press any key" with a count of 0, and won't accept any inputs.  btw it doesn't count down from N->0 it starts at zero.  And I know this uboot/bit/etc are all good we kept them as archive working versions.

0 Kudos
Xilinx Employee
Xilinx Employee
8,680 Views
Registered: ‎03-13-2012

Re: Totally dead card

That should basically work, but you have to run the FSBL before running U-Boot.

I.e:

 

connect arm hw
dow fsbl.elf
run
<wait a bit here>
stop
dow u-boot.elf
run

 

The bitstream is probably not even needed at this point.

To fix the boot.bin you should be able to add

dow -data boot.bin <address>

 before downloading U-Boot.

 

Then, once in U-Boot, it should be possible to write the boot.bin to the flash using U-Boot's sf commands.

0 Kudos
Visitor honeywelldev
Visitor
8,657 Views
Registered: ‎06-05-2014

Re: Totally dead card

Yes but what address do I load the boot.bin to? or do I just do it to some high memory region then in uboot flash it to the flash?

 

Because uboot is hanging up on the serial console after the first few lines it does the "press any key" thing with  count of 0 and gives you a uboot> prompt but won't accept any keyboard inputs.

0 Kudos
Xilinx Employee
Xilinx Employee
8,655 Views
Registered: ‎03-13-2012

Re: Totally dead card

The address should not matter unless it collides with an area U-Boot needs to execute. It should be safe to use one of the addresses that is usually used to load uImage or ramdisk to (e.g. 0x3000000). And the use U-Boot to write it into flash, yes.

 

Does U-Boot still hang when you run the FSBL before?

0 Kudos
Visitor honeywelldev
Visitor
8,628 Views
Registered: ‎06-05-2014

Re: Totally dead card

Yeah if I don't do the fpga  load uboot doesn't even show up.. but with the fpga load I get this

 

****** Xilinx Microprocessor Debugger (XMD) Engine
****** XMD v2014.2 (64-bit)
  **** SW Build 932637 on Wed Jun 11 13:31:38 MDT 2014
    ** Copyright 1986-2014 Xilinx, Inc. All Rights Reserved.


XMD%
XMD% connect arm hw

JTAG chain configuration
--------------------------------------------------
Device   ID Code        IR Length    Part Name
 1       4ba00477           4        arm_dap
 2       03731093           6        xc7z045

--------------------------------------------------
Enabling extended memory access checks for Zynq.
Writes to reserved memory are not permitted and reads return 0.
To disable this feature, run "debugconfig -memory_access_check disable".

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

CortexA9 Processor Configuration
-------------------------------------
Version.............................0x00000003
User ID.............................0x00000000
No of PC Breakpoints................6
No of Addr/Data Watchpoints.........4

Connected to "arm" target. id = 64
Starting GDB server for "arm" target (id = 64) at TCP port no 1234
XMD% dow fsbl.elf
Processor Reset .... DONE
Downloading Program -- fsbl.elf
        section, .text: 0x00000000-0x0000aebb
        section, .handoff: 0x0000aebc-0x0000af07
        section, .init: 0x0000af08-0x0000af1f
        section, .fini: 0x0000af20-0x0000af37
        section, .rodata&colon; 0x0000af38-0x0000b1d7
        section, .data&colon; 0x0000b1d8-0x0000debb
        section, .eh_frame: 0x0000debc-0x0000debf
        section, .mmu_tbl: 0x00010000-0x00013fff
        section, .ARM.exidx: 0x00014000-0x00014007
        section, .init_array: 0x00014008-0x0001400f
        section, .fini_array: 0x00014010-0x00014013
        section, .rsa_ac: 0x00014014-0x0001503f
        section, .bss: 0x00015040-0x0001c34b
        section, .heap: 0x0001c34c-0x0001e34f
        section, .stack: 0xffff0000-0xffffd3ff
Download Progress..10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x00000000
XMD% run
Processor started. Type "stop" to stop processor

RUNNING> 0
XMD% stop
Processor stopped

XMD% User Interrupt, Processor Stopped at 0x000041b4

XMD% fpga -f download.bit
Configuring Device 2 (xc7z045) with Bitstream -- download.bit
........10.......20.......30.......40.......50.......60.......70.......80......
90.......Done
Successfully downloaded bit file.

JTAG chain configuration
--------------------------------------------------
Device   ID Code        IR Length    Part Name
 1       4ba00477           4        arm_dap
 2       03731093           6        xc7z045

0
XMD% dow u-boot.elf
Processor Reset .... DONE
Downloading Program -- u-boot.elf
        section, .text: 0x04000000-0x0403e043
        section, .rodata&colon; 0x0403e048-0x0404cfb8
        section, .hash: 0x0404cfbc-0x0404cfe7
        section, .data&colon; 0x0404cfe8-0x0405437f
        section, .got.plt: 0x04054380-0x0405438b
        section, .u_boot_list: 0x0405438c-0x04054bcf
        section, .rel.dyn: 0x04054bd0-0x0405d0c7
        section, .bss: 0x04054bd0-0x040a9af7
Download Progress..10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x04000000
XMD% run
Processor started. Type "stop" to stop processor

RUNNING> 0
XMD%

 

And then on the serial console I get this

 

▒▒▒

U-Boot 2014.01 (Jul 30 2014 - 15:37:27)

I2C:   ready
Memory: ECC disabled
DRAM:  1 GiB
NAND:  512 MiB
In:    serial
Out:   serial
Err:   serial
Net:   Gem.e000b000
Hit any key to stop autoboot:  0
u-boot>

 

But nothing happens.. it just sits there and I can't  "type" into the window it rejects any typing

0 Kudos
Visitor honeywelldev
Visitor
8,625 Views
Registered: ‎06-05-2014

Re: Totally dead card

Here is doing your sequence exactly but we get nothing on the serial at all

XMD% rst
System reset successfully

0
XMD% Processor Stopped on Reset

XMD% state
--------------------------------------------------------
System(1) - Hardware System on FPGA(Device 1) Targets:
--------------------------------------------------------
Stopped         Target(64) - Cortex-A9(1) Hardware Debug Target*


XMD% dow fsbl.elf
Processor Reset .... DONE
Downloading Program -- fsbl.elf
        section, .text: 0x00000000-0x0000aebb
        section, .handoff: 0x0000aebc-0x0000af07
        section, .init: 0x0000af08-0x0000af1f
        section, .fini: 0x0000af20-0x0000af37
        section, .rodata&colon; 0x0000af38-0x0000b1d7
        section, .data&colon; 0x0000b1d8-0x0000debb
        section, .eh_frame: 0x0000debc-0x0000debf
        section, .mmu_tbl: 0x00010000-0x00013fff
        section, .ARM.exidx: 0x00014000-0x00014007
        section, .init_array: 0x00014008-0x0001400f
        section, .fini_array: 0x00014010-0x00014013
        section, .rsa_ac: 0x00014014-0x0001503f
        section, .bss: 0x00015040-0x0001c34b
        section, .heap: 0x0001c34c-0x0001e34f
        section, .stack: 0xffff0000-0xffffd3ff
Download Progress..10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x00000000
XMD% run
Processor started. Type "stop" to stop processor

RUNNING> 0
XMD% stop
Processor stopped

XMD% User Interrupt, Processor Stopped at 0x00006a38

XMD% dow u-boot.elf
Processor Reset .... DONE
Downloading Program -- u-boot.elf
        section, .text: 0x04000000-0x0403e043
        section, .rodata&colon; 0x0403e048-0x0404cfb8
        section, .hash: 0x0404cfbc-0x0404cfe7
        section, .data&colon; 0x0404cfe8-0x0405437f
        section, .got.plt: 0x04054380-0x0405438b
        section, .u_boot_list: 0x0405438c-0x04054bcf
        section, .rel.dyn: 0x04054bd0-0x0405d0c7
        section, .bss: 0x04054bd0-0x040a9af7
Download Progress..10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x04000000
XMD% run
Processor started. Type "stop" to stop processor

RUNNING> 0
XMD% state
--------------------------------------------------------
System(1) - Hardware System on FPGA(Device 1) Targets:
--------------------------------------------------------
Running         Target(64) - Cortex-A9(1) Hardware Debug Target*


XMD%

 

0 Kudos
Xilinx Employee
Xilinx Employee
8,620 Views
Registered: ‎03-13-2012

Re: Totally dead card

Hard to say what's going wrong. Looks like something is depending on the bitstream being loaded for some reason. But why U-Boot is not reacting is weird.

Is that a custom board or one of the Xilinx development boards?

 

For the Xilinx boards there are binaries available in the wiki (http://www.wiki.xilinx.com/Zynq+Releases) which should work for the flow I proposed above.

 

If it's a custom board, it may be helpful to create an FSBL and U-Boot that don't expect any PL configuration and try to get into a working U-Boot with those.

 

Also, I think SDK can write flash memory, but I'm not familiar with how to do that and whether that might limited to Xilinx boards or not.

0 Kudos
Visitor honeywelldev
Visitor
8,618 Views
Registered: ‎06-05-2014

Re: Totally dead card

Is there anyway to extract a uboot image from a boot.bin ?  I want to make sure the uboot i have matches the boot.bin we know works.

 

I did a verify on the uboot elf after a power cycle (ie after its loaded it from flash but is "dead") and it is saying it doesn't match... but that could be from the flash config issue we have.  

 

XMD% elf_verify u-boot.elf
Data=0xf41e7d5e, Expected=0xea000013
ERROR: Elf Verify failed at Address:
        0x04000000

 

All we did is a "saveenv" and restarted (changed the bootargs variable) and now the whole card seems to be rendered useless.  All I can think is that the flash program failed or corrupted it in some way.

 

Any yeah its custom HW so those default images don't work unfortunately.

0 Kudos
Visitor honeywelldev
Visitor
8,617 Views
Registered: ‎06-05-2014

Re: Totally dead card

Btw, if we stop it after we get that uboot screen that freezes in XMD we get this

 

XMD% stop
Processor stopped

XMD% User Interrupt, Processor Stopped at 0x3ff6c238

 

That address is WAY outside the bounds of the uboot code.. so does it seem like the uboot isn't correct that we have? (hence why I was asking if there was a way to extract it from the boot.bin and compare)

0 Kudos
Xilinx Employee
Xilinx Employee
8,767 Views
Registered: ‎03-13-2012

Re: Totally dead card

U-Boot relocates itself - usually close to the end of the available DRAM. So, that looks correct to me at first glance. (http://www.denx.de/wiki/view/DULG/DebuggingUBoot)

0 Kudos
Visitor honeywelldev
Visitor
8,758 Views
Registered: ‎06-05-2014

Re: Totally dead card

I can't get to that link btw.  Is there anyway of knowing "where" its hung? What code its stuck on.. etc in the uboot? I can poke around in memory with the jtag is there anything we could learn about why uboot is freezing? Is there any other method for pushing it through?

0 Kudos
Xilinx Employee
Xilinx Employee
8,755 Views
Registered: ‎03-13-2012

Re: Totally dead card

That's what the link above is about. You may have to remove the closing ')' which isn't supposed to be part of the link, the forum messed that up.

0 Kudos
Visitor honeywelldev
Visitor
8,739 Views
Registered: ‎06-05-2014

Re: Totally dead card

Ha didn't even notice that extra ")", frustrated at this point I guess.  Yes I can get to that link now, I will read through it. Thanks!

0 Kudos
Visitor honeywelldev
Visitor
8,733 Views
Registered: ‎06-05-2014

Re: Totally dead card

So decoding the elf I can see the symbol table with all the functions etc.. so I f I knew the offset i was at I coudl say what function it was it at least maybe.  But since its already relocated, the base+offset won't work.  Is there a symbol in the elf that says where the relocation address is?

 

I see

reclocate_done

env_relocate_spec (Function)

relocate_code (Function)

env_relocate (Function)

boot_relocate_fdt (Function)

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
8,730 Views
Registered: ‎03-13-2012

Re: Totally dead card

IIRC, the link gives the config symbol/#define that specifies the offset. I usually just print that from U-Boot. Then I don't have to trace through all the #defines and re-definitions to figure out what it ends up being.

0 Kudos
Visitor honeywelldev
Visitor
8,722 Views
Registered: ‎06-05-2014

Re: Totally dead card

Yeah but I can't even seem to connect

 

XMD% arm-xilinx-linux-gnueabi-gdb.exe u-boot.elf
GNU gdb (Sourcery CodeBench Lite 2013.11-53) 7.6.50.20130726-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-mingw32 --target=arm-xilinx-linux-gnueab
i".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://sourcery.mentor.com/GNUToolchain/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from c:\u-boot.elf...done.
(gdb) target remote
To open a remote debug connection, you need to specify what
serial device is attached to the remote system
(e.g. /dev/ttyS0, /dev/ttya, COM1, etc.).
(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Bogus trace status reply from target: timeout
(gdb) b cpu_init_f
Function "cpu_init_f" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)

 

 

 

If I follow the instructions in that it says to remote connect to bdi:2001

 

Is that trying to cnnect over UDP/Ethernet? because our board won't even come up besides if uboot isn't even running who is servicing the NIC?

0 Kudos
Visitor honeywelldev
Visitor
8,721 Views
Registered: ‎06-05-2014

Re: Totally dead card

This doesn't work either

 

XMD% dow u-boot.elf
Processor Reset .... DONE
Downloading Program -- u-boot.elf
        section, .text: 0x04000000-0x0403e043
        section, .rodata&colon; 0x0403e048-0x0404cfb8
        section, .hash: 0x0404cfbc-0x0404cfe7
        section, .data&colon; 0x0404cfe8-0x0405437f
        section, .got.plt: 0x04054380-0x0405438b
        section, .u_boot_list: 0x0405438c-0x04054bcf
        section, .rel.dyn: 0x04054bd0-0x0405d0c7
        section, .bss: 0x04054bd0-0x040a9af7
Download Progress..10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x04000000
XMD% arm-xilinx-linux-gnueabi-gdb.exe u-boot.elf
GNU gdb (Sourcery CodeBench Lite 2013.11-53) 7.6.50.20130726-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-mingw32 --target=arm-xilinx-linux-gnueab
i".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://sourcery.mentor.com/GNUToolchain/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from c:\u-boot.elf...done.
(gdb) target remote :1234
Remote debugging using :1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Bogus trace status reply from target: timeout

 

0 Kudos
Xilinx Employee
Xilinx Employee
8,719 Views
Registered: ‎03-13-2012

Re: Totally dead card

You should be able to connect gdb to the xmd instance. When connecting to the processor it usually prints something like "gdb server listening on port 1234". Then you simply connect to that gdbserver with target remote :1234 (assuming you run xmd and gdb on the same machine, if they run on different machines you'd also need to specify the hostname and make sure there is no firewall in between blocking the connection).

0 Kudos
Visitor honeywelldev
Visitor
8,714 Views
Registered: ‎06-05-2014

Re: Totally dead card

I tried that, its in my comments above but here it is again

 

Here is the connection...

XMD% connect arm hw

JTAG chain configuration
--------------------------------------------------
Device   ID Code        IR Length    Part Name
 1       4ba00477           4        arm_dap
 2       03731093           6        xc7z045

--------------------------------------------------
Enabling extended memory access checks for Zynq.
Writes to reserved memory are not permitted and reads return 0.
To disable this feature, run "debugconfig -memory_access_check disable".

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

CortexA9 Processor Configuration
-------------------------------------
Version.............................0x00000003
User ID.............................0x00000000
No of PC Breakpoints................6
No of Addr/Data Watchpoints.........4

Connected to "arm" target. id = 64
Starting GDB server for "arm" target (id = 64) at TCP port no 1234
XMD%

 

Now we need to flash the fsbl, bit, and uboot before we can start (btw how loing does the fsbl take? even if I give it several minutes it never finishes on the same location)

XMD% dow fsbl.elf
Processor Reset .... DONE
Downloading Program -- fsbl.elf
        section, .text: 0x00000000-0x0000aebb
        section, .handoff: 0x0000aebc-0x0000af07
        section, .init: 0x0000af08-0x0000af1f
        section, .fini: 0x0000af20-0x0000af37
        section, .rodata&colon; 0x0000af38-0x0000b1d7
        section, .data&colon; 0x0000b1d8-0x0000debb
        section, .eh_frame: 0x0000debc-0x0000debf
        section, .mmu_tbl: 0x00010000-0x00013fff
        section, .ARM.exidx: 0x00014000-0x00014007
        section, .init_array: 0x00014008-0x0001400f
        section, .fini_array: 0x00014010-0x00014013
        section, .rsa_ac: 0x00014014-0x0001503f
        section, .bss: 0x00015040-0x0001c34b
        section, .heap: 0x0001c34c-0x0001e34f
        section, .stack: 0xffff0000-0xffffd3ff
Download Progress..10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x00000000
XMD% run
Processor started. Type "stop" to stop processor

RUNNING> 0
XMD% stop
Processor stopped

XMD% User Interrupt, Processor Stopped at 0x00006a54

XMD% fpga -f download.bit
Configuring Device 2 (xc7z045) with Bitstream -- download.bit
........10.......20.......30.......40.......50.......60.......70.......80.......
90.......Done
Successfully downloaded bit file.

JTAG chain configuration
--------------------------------------------------
Device   ID Code        IR Length    Part Name
 1       4ba00477           4        arm_dap
 2       03731093           6        xc7z045

0
XMD% dow u-boot.elf
Processor Reset .... DONE
Downloading Program -- u-boot.elf
        section, .text: 0x04000000-0x0403e043
        section, .rodata&colon; 0x0403e048-0x0404cfb8
        section, .hash: 0x0404cfbc-0x0404cfe7
        section, .data&colon; 0x0404cfe8-0x0405437f
        section, .got.plt: 0x04054380-0x0405438b
        section, .u_boot_list: 0x0405438c-0x04054bcf
        section, .rel.dyn: 0x04054bd0-0x0405d0c7
        section, .bss: 0x04054bd0-0x040a9af7
Download Progress..10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x04000000

 

So now e should be ready to "debug" uboot.

Seems to load the elf properly and intialize

XMD% arm-xilinx-linux-gnueabi-gdb.exe u-boot.elf
GNU gdb (Sourcery CodeBench Lite 2013.11-53) 7.6.50.20130726-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-mingw32 --target=arm-xilinx-linux-gnueab
i".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://sourcery.mentor.com/GNUToolchain/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from c:\u-boot.elf...done.

 

But when I try and connect like you said using target remote :1234 (remember I am debugging uboot so not sure the NIC would even work at this poitn nor would I know what IP it is etc)

(gdb) target remote :1234
Remote debugging using :1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Bogus trace status reply from target: timeout

 

If I list a symbol for example like this it seems to work so gdb knows my elf properly just can't seem to connect

(gdb) info function main
All functions matching regular expression "main":

File cache_v7.c:
static void v7_dcache_maint_range(u32, u32, u32);
static void v7_maint_dcache_all(u32);

File cache-cp15.c:
void arm_init_domains(void);

File main.c:
void main_loop(void);
(gdb) b main_loop
Breakpoint 1 at 0x4015ef0: file main.c, line 417.

 

But this wont work because I am not connected

(gdb) c
The program is not being run.

 

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
6,319 Views
Registered: ‎03-13-2012

Re: Totally dead card

The NIC is not involved at all. XMD inplements the gdbserver. So, gdb connects to the local xmd instance and all debug operations go through XMD/JTAG.

 

Your FSBL not stopping at the same location every time sounds wrong to me. Especially in JTAG mode, it should at some point just sit in an infinit loop and/or wfi. So, there should be no great variation, if any, IMHO. Did you check where/what the FSBL is executing when you stop it?

 

I don't know what's going wrong once you get connected. I haven't seen those errors yet. So, far it usually worked for me.

0 Kudos
Visitor honeywelldev
Visitor
6,315 Views
Registered: ‎06-05-2014

Re: Totally dead card

FSBL stops "close" withing a few words I think usually. My guess the assembly is just looping maybe there are some timer or watchdog massaging things going on so its skidding a bit on the stop depending on where i happen to catch it...

 

 

As for the gdb connect yeah I read i shoudl be able to do the ":1234" thing in other places as well.  Should I open a webcase on it you think? kinda a dead end and its holding up all my development unfortunately.

0 Kudos
Xilinx Employee
Xilinx Employee
6,310 Views
Registered: ‎03-13-2012

Re: Totally dead card

Well, it's definitely hard to debug from this perspective here.

 

What I'd do:

1. Create minimal FSBL and U-Boot that don't need any bitstream and eliminate that one from the flow for now

2. Modify FSBL/Create standalone app to blow away the saved U-Boot environment (you said you did saveenv and afterwards things didn't work anymore).

0 Kudos
Visitor honeywelldev
Visitor
6,268 Views
Registered: ‎06-05-2014

Re: Totally dead card

For anyone reading this looking for a solution, I wanted to update the post.  We weren't able to get anywhere and had to have the manufature of the card create a custom FSBL that allowed for flash programming via the jtag.  Once we did that, we erased and reflashed everything on the NAND.  Whatever "event" happen messed up the flash to the point where we couldn't even boot out of RAM normally.  That shouldn't happen, yet that is the conclusion we were left with.  Once we erased and reflashed via the SDK (using the modified FSBL) the card is back up and running.

0 Kudos
Explorer
Explorer
6,262 Views
Registered: ‎08-19-2014

Re: Totally dead card

I noticed you mentioned saving your uboot environment at one point earlier in the thread. I was booting from SD on a ZC706 platform recently and in uboot, I made some environment changes and then saved. Uboot did not save these changes to the SD, but instead to the on board QSPI. Maybe this is what corrupted your flash. There may be a setting or build option in uboot to determine where that environment is saved, and by default, it's set to QSPI.

-Jordan
This signature intentionally left blank.
0 Kudos