[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [microblaze-uclinux] Problem with 2nd stage bootloader (u-boot)

To: <microblaze-uclinux@xxxxxxxxxxxxxx>
Subject: RE: [microblaze-uclinux] Problem with 2nd stage bootloader (u-boot)
From: "Radde, Jarno" <jarno.radde@xxxxxxx>
Date: Wed, 7 Mar 2007 09:35:25 +0100
In-reply-to: <001b01c75f34$0fff5bc0$9ac0a592@xxxxxxxxxxxxx>
Reply-to: microblaze-uclinux@xxxxxxxxxxxxxx
Sender: owner-microblaze-uclinux@xxxxxxxxxxxxxx
Thread-index: Acde03P2K64dh1KQStejywn/FelZmAAXTk7QAFcnhiA=
Thread-topic: [microblaze-uclinux] Problem with 2nd stage bootloader (u-boot)

Hi Kevin!

-----Original Message-----
From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
[mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx] Kevin Somervill

> If I may interject...

> | > U-Boot> md 0x28000000
> | > 28000000: ffff0008 aa99ffff 2000ffff 3000ffff    ........ ...0...
> | > 28000010: 0000ffff 2000ffff 2000ffff 3001ffff    .... ... ...0...
> | > 28000020: 0004ffff 3001ffff 0167ffff 3000ffff    ....0....g..0...
> | > 28000030: 0000ffff 2000ffff 3000ffff 0000ffff    .... ...0.......
> | > 28000040: 3000ffff 0000ffff 2000ffff 2000ffff    0....... ... ...
> | > 28000050: 2000ffff 2000ffff 2000ffff 2000ffff     ... ... ... ...

> This is not what you would read from a failed device.  Two things
stick out:

> 1. the first read has the half-words reversed with the others which is
> indicative some sort of timing problem (goofed up parameters in the
MHS or
> bad constraints in the UCF, most likely the former).

Hm, okay. I have no experience with things like that. I just thought the
reference design or wizard generated things would work "out of the box".
But
Xilinx already showed with the debug module that this is not always the
case.

> 2. for a device failure, I would expect the FFFF to be random junk and
not
> stuck high.

If you mean the first read, then yes. For the other reads the FFFF is 
correct because it is empty. The lower 16 bits always had the correct
values
(I'm not sure about the first read).

> I'm not familiar with your hardware, so I have the following
questions:

Hm, I have some more information from the from the ml401 user guide:

Two 32-Mb linear flash devices (Micron MT28F320J3RG-11 ET) are installed
on 
the board for a total of 8 MB of flash memory. These flash memory chips
are 
Intel StrataFlash compatible. This memory provides non-volatile storage
of 
data, software, or bitstreams. Each flash chip is 16 bits wide and
together
 forms a 32-bit data bus that is shared with SRAM. In conjunction with a

CPLD, the flash memory can also be used to program the FPGA. Note: The
reset
for the AC97 Codec is shared with the reset signal for the flash memory 
chips and is designed to be asserted at power-on or upon system reset.

> 1. Have you ever gotten a reference design to reliably access the
"failing"
> device? (Outside of attempts at uClinux)

No. I tried the design from the Xilinx document xapp730.pdf and the
petalogix 
reference design named Xilinx-ML401-uclinux-ref-edk82. It did not work
with 
both :( In the Xilinx document most parts are automatically generated by
the
Wizard, so they "should" work.

> 2. What are the differences between what you have and the reference
design?

No changes.

> 3. Are the address lines shared between the two flash devices?

Hm, sorry I'm not sure about that. I'm more familiar with software than
with
hardware. Therefore I do not really understand it. I know that it can be
seen
which FPGA pins are connected with with peripheral pin, but I do not
know how
it should be. I copied a part of the UCF file, I hope it is the correct
part:

#-----------------------------------------------------------------------
-------
# IO Pad Location Constraints / Properties for SRAM/FLASH
#-----------------------------------------------------------------------
-------

NET sram_clk            LOC = AF7;
NET sram_clk_fb         LOC = AD17;
NET flash_a23           LOC = T21;
NET sram_flash_addr<22> LOC = U20;
NET sram_flash_addr<21> LOC = T19;
NET sram_flash_addr<20> LOC = AC5;
NET sram_flash_addr<19> LOC = AB5;
NET sram_flash_addr<18> LOC = AC4;
NET sram_flash_addr<17> LOC = AB4;

NET sram_flash_addr<16> LOC = AB3;
NET sram_flash_addr<15> LOC = AA4;
NET sram_flash_addr<14> LOC = AA3;
NET sram_flash_addr<13> LOC = W5;
NET sram_flash_addr<12> LOC = W6;
NET sram_flash_addr<11> LOC = W3;
NET sram_flash_addr<10> LOC = AF3;
NET sram_flash_addr<9>  LOC = AE3;
NET sram_flash_addr<8>  LOC = AD2;
NET sram_flash_addr<7>  LOC = AD1;
NET sram_flash_addr<6>  LOC = AC2;
NET sram_flash_addr<5>  LOC = AC1;
NET sram_flash_addr<4>  LOC = AB2;
NET sram_flash_addr<3>  LOC = AB1;
NET sram_flash_addr<2>  LOC = AA1;
NET sram_flash_addr<1>  LOC = Y2;
NET sram_flash_addr<0>  LOC = Y1;
NET sram_flash_data<31> LOC = F14;
NET sram_flash_data<30> LOC = F13;
NET sram_flash_data<29> LOC = F12;
NET sram_flash_data<28> LOC = F11;
NET sram_flash_data<27> LOC = F16;
NET sram_flash_data<26> LOC = F15;
NET sram_flash_data<25> LOC = D14;
NET sram_flash_data<24> LOC = D13;
NET sram_flash_data<23> LOC = D15;
NET sram_flash_data<22> LOC = E14;
NET sram_flash_data<21> LOC = C11;
NET sram_flash_data<20> LOC = D11;
NET sram_flash_data<19> LOC = D16;
NET sram_flash_data<18> LOC = C16;
NET sram_flash_data<17> LOC = E13;
NET sram_flash_data<16> LOC = D12;
NET sram_flash_data<15> LOC = AA14;
NET sram_flash_data<14> LOC = AB14;
NET sram_flash_data<13> LOC = AC12;
NET sram_flash_data<12> LOC = AC11;
NET sram_flash_data<11> LOC = AA16;
NET sram_flash_data<10> LOC = AA15;
NET sram_flash_data<9>  LOC = AB13;
NET sram_flash_data<8>  LOC = AA13;
NET sram_flash_data<7>  LOC = AC14;
NET sram_flash_data<6>  LOC = AD14;
NET sram_flash_data<5>  LOC = AA12;
NET sram_flash_data<4>  LOC = AA11;
NET sram_flash_data<3>  LOC = AC16;
NET sram_flash_data<2>  LOC = AC15;
NET sram_flash_data<1>  LOC = AC13;
NET sram_flash_data<0>  LOC = AD13;
NET sram_cen            LOC = V7;
NET sram_flash_oe_n     LOC = AC6;
NET sram_flash_we_n     LOC = AB6;
NET sram_bw<3>          LOC = Y3; #Y4; 
NET sram_bw<2>          LOC = Y4; #Y3;
NET sram_bw<1>          LOC = Y5; #Y6;
NET sram_bw<0>          LOC = Y6; #Y5;
NET flash_ce            LOC = W7;
NET sram_adv_ld_n       LOC = W4;
NET sram_mode           LOC = V26;

NET sram_clk           IOSTANDARD = LVCMOS33;
NET sram_clk           DRIVE = 16;
NET sram_clk           SLEW = FAST;
NET sram_clk_fb        IOSTANDARD = LVCMOS33;

NET flash_a23          IOSTANDARD = LVDCI_33;
NET flash_a23  SLEW = FAST;
NET flash_a23  DRIVE = 8;

NET sram_mode          IOSTANDARD = LVDCI_33;
NET sram_mode SLEW = FAST;
NET sram_mode DRIVE = 8;

NET sram_flash_addr<*> IOSTANDARD = LVDCI_33;
NET sram_flash_addr<*>  SLEW = FAST;
NET sram_flash_addr<*>  DRIVE = 8;

NET sram_flash_data<*> IOSTANDARD = LVCMOS33;
NET sram_flash_data<*> DRIVE = 12;
NET sram_flash_data<*> SLEW = FAST;
NET sram_flash_data<*> PULLDOWN;

NET sram_flash_oe_n    IOSTANDARD = LVDCI_33;
NET sram_flash_oe_n SLEW = FAST;
NET sram_flash_oe_n DRIVE = 8;

NET sram_flash_we_n    IOSTANDARD = LVDCI_33;
NET sram_flash_we_n SLEW = FAST;
NET sram_flash_we_n DRIVE = 8;

NET sram_bw<*>         IOSTANDARD = LVDCI_33;
NET sram_bw<*> SLEW = FAST;
NET sram_bw<*> DRIVE = 8;

NET flash_ce           IOSTANDARD = LVDCI_33;
NET flash_ce SLEW = FAST;
NET flash_ce DRIVE = 8;

NET sram_cen           IOSTANDARD = LVDCI_33;
NET sram_cen SLEW = FAST;
NET sram_cen DRIVE = 8;

NET sram_adv_ld_n      IOSTANDARD = LVDCI_33;
NET sram_adv_ld_n SLEW = FAST;
NET sram_adv_ld_n DRIVE = 8;

> 4. Can you reliably access the "working device"?

You mean the lower 16 bits? Except of the first read where I am not
really
sure about my previous results I always got the correct data there.

> 5. What is different between the connectivity of two devices (besides
one
> doesn't work)?  If nothing, maybe that's the problem?

Sorry I do not understand. Where can I find that out?

> 6. Do you have pull-ups on the DQ lines?  Switch them to pull-downs
and see
> if the FFFF got to 0.  This might indicate an failed OE line.

Hm, I really don't know. As mentioned before I don't know much about
hardware.
In the UCF part above there is one line:

NET sram_flash_data<*> PULLDOWN;

If you mean this line it is already set to pulldown.

> A few points to ponder as you sort out your hw.

Thank you! Sorry that I could not answer all of your questions :(

Best regards

Jarno Radde


This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.

If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message.
  
Thank you for your co-operation.



___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/

References:
- RE: [microblaze-uclinux] Problem with 2nd stage bootloader (u-boot)
  - From: Kevin Somervill

Prev by Date: RE: [microblaze-uclinux] SAMBA problem
Next by Date: [microblaze-uclinux] EDK 9.1 - auto-config.in
Previous by thread: RE: [microblaze-uclinux] Problem with 2nd stage bootloader (u-boot)
Next by thread: Re: [microblaze-uclinux] HELP ME¡¡¡ AGAIN
Index(es):
- Date
- Thread