On 9/4/07, Ben Warren bwarren@qstreams.com wrote:

David Hawkins wrote:

...

Hi Robert,

...

The big problem we have now: is this a hardware issue or a bdi config issue? Aside from the flash we have 1GigaByte of DDR ram. Can anyone help us track our flash issues down to be hardware, config file, or some combination? The hardware guys think the board is fine.

Have you checked that the Flash is getting accessed?

Very good point. I know you've made many changes since your initial setup Robert. Did any of them make the chip select strobe?

We now see the CE on the flash chip going from 3.3v to 0 on reset of the 8548. We also see the same behavior when issuing a mdh command on the bdi - however, we cannot see any activity whatsoever on the Ax pins on the spansion flash chip when trying read via the bdi and mdh.

Getting deep into 8548, the "pin strapping" I believe is controlled by the POR Boot Mode Status Register (PORBMSR) in "20.4.1.2" in:

http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf

Reading the register PORBMSR we get: 0x86370000 which I'm reading as:

1 0000 110 00 11 0 11 100 00000000000000

0 BCFG = 1 The CPU is allowed to start fetching boot code. 1-4 reserved 5-7 ROM_LOC = 110 Local bus GPCM:16-bit (our local bus is 16bit) 8-9 reserved 10-11 BSCFG = 11 Boot sequencer disabled 12 reserved 13-15 Host/agent = PCI1/PCI-X and Serial RapidIO agent mode 16-31 reserved.

Our flash is 128MB and we think we set the LAW correctly in the bdi config file as F8000000 . In 4.3.1.3 however, it defaults to FF80000 and says:

"If translation is to be performed to a page outside the default boot ROM address range defined in the MPC8548E (8 Mbytes at 0x0_FF80_0000 to 0x0_FFFF_FFFF as defined in Section 4.4.3.3, "Boot ROM Location"), the external host or boot sequencer must then also set up a local access window to define the routing of the boot code fetch to the target interface that contains the boot code, because the BPTR defines only the address translation, not the target interface."

Perhaps we're not doing that right?

...

I'm working with an 83xx based board, so the 85xx will be slightly different, but here's what I'd look for. When the processor boots, it reads a hardware configuration word (HCW) that tells it where to boot from. The pin strapping can be set to tell it to use Flash. Assuming the HCW is read correctly, you should be able to see the CE# line on the Flash assert when the processor boots.

Also, on the 83xx you can set the RCW values directly from the BDI-2000, using an entry like the following in the TARGET section:

RCW 0x8060a000 0x04230000

I did see RCW while googling, but that appears not to be present on the 85xx as I couldn't find it in the 85xx bdi manual or the freescale manual. Anyone know the equivalent?

Thanks all! Robert

We now see the CE on the flash chip going from 3.3v to 0 on reset of the 8548. We also see the same behavior when issuing a mdh command on the bdi

Great. Thats encouraging :)

however, we cannot see any activity whatsoever on the Ax pins on the spansion flash chip when trying read via the bdi and mdh.

What about when the processor boots?

http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf

p233 of the PDF:

When the e500 core comes out of reset, its MMU has one 4-Kbyte page defined at 0x0_FFFF_Fnnn. The core begins execution with the instruction at effective address 0x0_FFFF_FFFC. To get this instruction, the core’s first instruction fetch is a burst read of boot code from effective address 0x0_FFFF_FFE0.

So the address bus LSBs should be changing during this burst, whereas the MSBs would be high.

I did see RCW while googling, but that appears not to be present on the 85xx as I couldn't find it in the 85xx bdi manual or the freescale manual. Anyone know the equivalent?

It looks like the 85xx ditches the RCW method in favor of the boot sequencer, which the 83xx also supports. As far as I understand the processor comes out of reset, holds the core in reset, reads register settings from an I2C EEPROM, programs the registers, and then releases the core. Basically you can override any (some?) default register settings.

p233 states: the default boot ROM address range defined in the MPC8548E (8 Mbytes at 0x0_FF80_0000 to 0x0_FFFF_FFFF

which is the same as one of the defaults for the MPC8349.

I'm pretty sure that you should be able to power up the processor, and the BDI-2000 can play in this default address-space, i.e., accesses between 0xFF800000 and the end of 4GB space should decode to the Flash.

Do you have a Freescale evaluation board for comparison tests?

Cheers, Dave

Hi Robert,

...

...

however, we cannot see any activity whatsoever on the Ax pins on the spansion flash chip when trying read via the bdi and mdh.

What about when the processor boots?

...

http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf

p233 of the PDF:

When the e500 core comes out of reset, its MMU has one 4-Kbyte page defined at 0x0_FFFF_Fnnn. The core begins execution with the instruction at effective address 0x0_FFFF_FFFC. To get this instruction, the core's first instruction fetch is a burst read of boot code from effective address 0x0_FFFF_FFE0.

So the address bus LSBs should be changing during this burst, whereas the MSBs would be high.

Excellent idea - can I please clarify it? On the spansion flash chip we have LBA5 to LBA30 - where LBA30 is the LSB. On reset, should we be seeing changes on these LSB's while the MSB's remain high?

Here's some notes I wrote a while back

http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf

Figure 5, p33, shows LA[27:31] toggling during boot from Flash. Note that the asynchronous memory interface (GPCM) changes address pins LA[27:31] during byte-wise access *not* the LAD[27:31] multiplexed address/data bus that. So if the board design connects up the wrong pins to the Flash, it won't work. In your case, since you talk about LBA30 as being your LSB, it sound like you have 16-bit Flash. The same comment applies though; LA[27:30] are the bits that should be connected to the Flash for booting.

From the block diagram in Ch 13 of the 8548 reference manual, it looks like the local bus controller setup is the same.

Note: if your Flash is connected to the wrong address pins, it might be possible using the boot sequencer to change the boot address to a UPM controlled area, and then use the UPM to read the flash. But of course that requires having the I2C EEPROM on the board to enable the boot sequencer.

...

I'm pretty sure that you should be able to power up the processor, and the BDI-2000 can play in this default address-space, i.e., accesses between 0xFF800000 and the end of 4GB space should decode to the Flash.

We tried doing an mdh on 0xff800000 but still see bad data, even after setting:

But the Flash chip-select asserts, OE# asserts, and data is driven out of the Flash? How about the address pins?

WM32 0xe0005000 0xff801001 ;BR0 WM32 0xe0005004 0xff806e65 ;OR0

Yeah, I wouldn't both changing registers until you get the default state working.

One more question please, since 83xx is the same here. What's the register that needs to be changed to move the boot location from FF800000 to F8000000 ? I've been getting deep into the boot sequencer and PORBMSR, but I'm having a hard time determining what and where to change the boot location address. We don't have an I2C eeprom, but the hardware guys tell me we can strap the pins to set the register once we know which one it is.

If your hardware guy knows of the pin strapping, then he should know the register setting :)

p233 says that it is the boot sequencer that can be used to change the boot address.

However, I wouldn't bother with trying to change the boot address until you've got the flash working.

Any particular reason you want to change the address range? It really isn't that important what the memory map is during boot versus running u-boot. For example, the 83xx u-boot code first used the high-boot address, and then switched to low-boot (which is nice as it puts the boot code at the start of Flash). The Flash itself can be viewed after boot at a user-defined address. See the document notes at the link above.

Cheers, Dave

Hi Robert,

...

Here's some notes I wrote a while back

http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf

Figure 5, p33, shows LA[27:31] toggling during boot from Flash. Note that the asynchronous memory interface (GPCM) changes address pins LA[27:31] during byte-wise access *not* the LAD[27:31] multiplexed address/data bus that. So if the board design connects up the wrong pins to the Flash, it won't work. In your case, since you talk about LBA30 as being your LSB, it sound like you have 16-bit Flash. The same comment applies though; LA[27:30] are the bits that should be connected to the Flash for booting.

Bingo! Excellent notes as it seems to describe our exact problem. The way you describe it must be done - using pins LA[27:30] in our case - is _not_ how our board is. It was that way in the prototype phase but had a spurious signal on the bus so the hardware guys say. So it was changed to the way you say it can't be done - via LAD[27:30] multiplexed address/data bus.

I'm glad we've found your problem, but I'm sorry to hear the cause. Life now becomes more difficult for you :(

...

Note: if your Flash is connected to the wrong address pins, it might be possible using the boot sequencer to change the boot address to a UPM controlled area, and then use the UPM to read the flash. But of course that requires having the I2C EEPROM on the board to enable the boot sequencer.

We don't have an I2C EEPROM, so its jumper wire time.

Its worth trying. My assumption would be that if you use the I2C boot sequencer to setup the boot address (however that is done), and then setup the memory controller that decodes that address to trigger the use of a UPM, where the UPM is setup correctly to read the Flash, then it will boot correctly. Of course I've never done this, or heard of a board that does it, so let us know how you go :)

This is really a side issue now, but since I asked it I might as well finish up on it. The two 8548 boards I've looked at - EP8548 and CDS - both have 8MB of flash starting at FF800000. What relation does that have to the 8548 boot rom location of FF800000 ?

Read the explanation on p31 for the 83xx http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf

The thing to get your head around is that (for an 83xx);

On reset the processor setups up a basic memory map where the processor boots from either 0xFFF00100 or 0x00000100, i.e., it boots from 1MB lower than the highest 32-bit address or it boots from address 0.

The processor sets up an 8MB memory window that decodes to that Flash, eg. 0xFF800000 is the default base address of that Flash, or 0x0000000 is the default. (Assuming of course the config words say to boot from local bus flash).

When you have an 8MB flash, either boot base-address works fine. However, when you have a larger flash, high-boot requires the boot code reside about 8MB into your Flash. Thats a bummer, as it splits your useable Flash in two, so using low-boot works nicer.

Regardless of which boot method is used, once u-boot code runs, it sets up the decode region for the flash to be whereever it wants to be. In some boards, I am sure the Flash just gets left where it is, with perhaps the memory window being opened wider if there was a larger flash. In that case, the u-boot code for a high-boot image would still be found about 8MB into that decode region (for high-boot).

Basically, shortly after the processor boots you setup the memory map as you'd like to see it.

Since I have 128MB of flash starting at F8000000 in my or0 / br0 registers and LAW's in my u-boot code, do I not need to change the boot rom location? Does this effect the location to load the u-boot.bin file, 0xFFF80000 in the two 8548 examples?

It depends :)

If your processor boot sequence depended on the default FF800000 window, and high-booted, then u-boot would live about 8MB into your 128MB Flash, and without changing the or0/br0, you'd only see the lower 8MB of the Flash. U-Boot would be linked with the FF800000 base address (or whatever U-boot needs regarding addresses). Once U-boot executes, and I think has setup the DDR and moved over to run from DDR, its no longer executing from Flash, so the location of the Flash can be moved. In that case, you'd change the base address to be F8000000 and viola, you can access all 128MB.

If however you use the I2C boot sequencer to setup the 128MB flash as 128MB starting at F8000000, and boot that way, the u-boot image will sit about 1MB from the end of the 128MB Flash, not 8MB from the start of the flash. However, the processor reset vector, and hence u-boot code, will execute from FFFF0100 in either case.

I haven't looked at the 85xx manual in enough detail to see if all this applies, but thats the basics :)

If you can get the 85xx to boot from 00000000, then it won't matter if you setup an 8MB window or 128MB window, just so long as the window starts at address 00000000 after reset. Then you can move it to F8000000 after boot. Then you'll only have code at the start of Flash, not starting 8MB into it (or 1MB from the end).

Cheers, Dave

Hi Luiz,

Luiz Neto wrote:

Hi David,

This is Luiz and I'm working with Robert in this project. Actually, I'm a hardware guy. I read your messages and it seems you're right. However, before introducing these changes on the board, we decided to verify all flash circuitry and we noticed the following:

CE# is OK! WE# is OK! OE# is OK!

We verified it using a scope and triggering CE# pin. After that, we tried to write to flash through BDI2000 using "mm" command. Again with a scope we checked each address line and apparently everything is fine with the address. We also checked the data being written, and it's ok too. After that, in order to validate the written, we read the same address we had just written. But we got a different value. Therefore we are not writing correctly to flash.

Ok, after all, we fixed our board following your tips. We connected LA[27:30] to A[3:0] and A[4:25] to LBA[26:5]. But we got the same bad result. I mean we read a wrong data.

After, we changed flash access time, decreasing it. And the problem persisted. We changed flash chip and nothing happened.

Actually I'm afraid because I can't see what else we can verify on hardware.

My opinion is we have mistakes on configuration file. I'm not sure if we are configuring all registers correctly.

Do you think it would be helpful if I send you our flash schematic and our configuration file?

Thanks in advance! Luiz.

I'm not sure if this has been mentioned or not. You should be able to read/write the flash from the BDI-2000, regardless of whether you connect the LA or LBA address bits. The difference comes into play when you want to boot from the flash chip. During the very early boot process, only the special LSbits toggle. On one spin of our board we missed this as well, and had to do some funny business with an I2C EEPROM to boot the board. Thankfully it was easy with our CPU (MPC8349) because it only involved programming a couple of configuration words and no UPM programming like Dave H. has suggested. It looks like it may not be as simple for you. :-(

If you're able to white-wire the LA bits, that's cool because ultimately you'll need that to boot the board. You're right that something else is screwy.

Have you tried asking Freescale for help through their website? I've found their tech support in these matters to be responsive and useful. You can send me your schematic & config if you want, although I can't guarantee to be of much use.

regards, Ben

Hi Luiz,

This is Luiz and I'm working with Robert in this project.

Glad to hear he's got someone to grow grey hairs with ... if it hasn't fallen out yet.

Actually, I'm a hardware guy.

So am I ... this week :)

I read your messages and it seems you're right. However, before introducing these changes on the board, we decided to verify all flash circuitry and we noticed the following:

CE# is OK! WE# is OK! OE# is OK!

We verified it using a scope and triggering CE# pin. After that, we tried to write to flash through BDI2000 using "mm" command. Again with a scope we checked each address line and apparently everything is fine with the address.

I think that after the processor boots LAD[0:31] activate for each address access, its only during boot that LAD[27:31] do not toggle, and you have to use LA[27:31]. So its that confirmation of the address toggles in this case just confirms that the LAD[27:31] bits toggle.

On the bright-side, it sounds like you have the bit ordering correct ([27:30])... just not the right bits (LAD vs LA).

We also checked the data being written, and it's ok too. After that, in order to validate the written, we read the same address we had just written. But we got a different value. Therefore we are not writing correctly to flash.

Have you tried using simple CFI flash commands; read the manufacturer ID, read the device ID, read the sector protection? Don't bother with BDI Flash commands just yet, just use memory read/write commands.

Ok, after all, we fixed our board following your tips. We connected LA[27:30] to A[3:0] and A[4:25] to LBA[26:5]. But we got the same bad result. I mean we read a wrong data.

After, we changed flash access time, decreasing it. And the problem persisted. We changed flash chip and nothing happened.

Actually I'm afraid because I can't see what else we can verify on hardware.

My opinion is we have mistakes on configuration file. I'm not sure if we are configuring all registers correctly.

Do you think it would be helpful if I send you our flash schematic and our configuration file?

Sure, no guarantees, you can send me a copy, or send a link to the group. I'm not too knowledgeable on BDI config files yet, as I don't have my custom hardware. However, I have looked at a few hardware designs, so perhaps I'll spot something on the schematic. The peripherals seem to be pretty similar between the PowerQUICCs, so I'll dig up a working configuration file, and look at the difference in register settings.

What is your Flash? Eg. if its say a Spansion device, do you have WP# tied high, BYTE# tied low/high, etc? Are there any address pins left floating?

Do you have a logic analyzer available? If you did, you'd be able to look at the flash controls and write-data and convince yourself that your Flash programming sequence was correct.

The best advice at the moment, is to access your Flash configuration using manual read/write sequences.

Cheers, Dave

Hi Luiz,

First of all, thanks for helping us!!! You are amazing guys!

There is a saying 'what goes around, comes around ...'.

So by helping you now, I hope someone helps me later :)

Yes, we want to boot from flash. But firstly, we want to validate our hardware :)

Always helps to walk before running :)

So, let me see if I understood you synchronizing some points:

1- In order to validate my flash circuitry, I don't need LA pins. I'm able to validate it using just simple FCI commands. Am I right?

Yes.

0. Scope out the pins and check the chip-select and write pulse timing matches that specified by the Flash.

1. Try reading the manufacturer info.

I'm not familiar with these command. Probably Robert knows it. But he is out of the office until tuesday. Can you please give some examples?

Its in the data sheet. See comments below.

2- LA pins are necessary just in case I want to boot from flash. Is it?

Yes. LA[27:31] need to be connected to the boot Flash.

3- Our flash is a S29GL01GP MirrorBit. I'm send you our flash schematic and datasheet. There you can see that WP# is tied high, BYTE# is tied high, RESET# is high (a FPGA controls this pin) and that there is no address pin floating.

Ok. I plan to use the same part.

Download the data sheet; eg. I seem to have a copy called s29gl-p_00_a5_e.pdf

Look near the end of the document for the 'Memory Array Command Definitions' table, x16.

Eg. to read the manufacturer ID perform the following sequence, where wm.b means write memory byte, but you'll need to replace this with the BDI2000 equivalent, which I can't recall at the moment :) (and the 0x might be optional too). The point is this will help you understand how to use the table:

wm.b 0x555 0xAA wm.b 0x2AA 0x55 wm.b 0x555 0x90 wm.b 0x000 0x01

and then read say 8 bytes from the flash

md.b 8

Somewhere in the data sheet it'll tell you what the Spansion manufacturer ID is supposed to be.

The 0x555 0xAA 0x2AA 0x55 is called the unlock sequence, the remaining bytes are then command codes.

If you get the low-level routines to give you valid results, then you can try higher-level Flash commands to see where you get differing results.

You can use this method to program Flash bytes too.

Cheers, Dave

Hi Robert,

Thanks all for the help so far. I'm going to jump back in the discussion at this part in the thread. We ran out of S29GL01GP chips so we temporarily moved to the S29GL512P 64MB chip, with a chip size of 4000000. The good news is after jumpering the board to the correct addresses we can do a "mdf 0xfc000000" and get all F's . We can also do a "erase 0xfc000000 CHIP" and the command completes successfully.

When we do a "prog 0xfc000000 uboot.bin bin" however, we get ""Programming flash memory failed" . Our questions at this point are:

Before assuming an address that reads 0xFFFFFFFF is really your flash, you did double-check that the Flash CE# and OE# signals are active for those accesses correct?

1. If we can do an erase as shown above does that mean our unlocking

sequence has been performed correctly?

As I have commented before; if you're unsure, *do it manually*, read the manufacturer ID first, and sector protection, or whatever.

What's confusing us here is that the "0x555 0xAA 0x2AA 0x55" sequence seems to be the same for our current S29GL512P, the S29GL01GP, Ben's S29GL064M, and the MPC8548CDS chip , the AM29LV641D. Maybe some CFI standard thing?

Don't be confused; read the data sheet :)

Yes, its a CFI thing. However, non-CFI JEDEC flash has something similar.

Anyways. Ben's sequence and an example I found for the CDS board is this:

; Enable flash programming WM16 0xfe000000 0x0060 ;clear flash lock-bits WM16 0xfe000000 0x00d0 DELAY 1000 WM16 0xfe000000 0xffff

I don't see an unlock sequence here though. Perhaps there is an unlock-bypass command earlier on.

In our case 0xfe000000 becomes 0xfc000000. We found a 8540ads with the same code. In the 8548cds case they seem to use the equivalent for 0xFF800000 with WM32. In all these examples where not sure where these addresses come from as they don't seem to be clearly from the respective manuals.

I explained earlier the fact that the processor starts off with a default memory map that you can then override. So 0xFF800000 is the default map with an 8MB window at the top of memory, while 0xFE000000 is a 32MB window setup by writes to the local bus registers (OR/BR or whatever they're called).

We also can execute the unlock command successfully, with this entry in our config files:

ERASE 0xFc000000 CHIP; Erase whole Chip

If the chip started out with 0xFFFFFFFF, then you can't really say you've had success :)

2. Any other ideas on why we can read and erase but not write our flash?

Thanks all, been quite a ride but I think we're almost ready to get into debugging our u-boot code.

Go back to basics first;

1. Confirm that accesses to the addresses you believe the Flash are located generate CE# and OE#

(I'm sure you did this, but you didn't re-state it)

2. Use memory commands to read the manufacturer ID

3. Use memory commands to write a word

4. Use memory commands to erase that sector

5. Repeat 3

6. Use memory commands to erase the chip

Then try the software equivalents. Then try programming U-boot.

Cheers, Dave

Hi Jerry,

David missed three steps here: 2. Read the flash data sheets, especially the command interface 3. ReRead the flash data sheets, especially the command interface 4. ReReRead the flash data sheets, especially the command interface

Robert's statement "Maybe some CFI standard thing?" betrays him.

Yeah, I guess I was being too kind.

Thanks for having my back Jerry.

:)

David Hawkins wrote:

One other thing:

...

...

Then try the software equivalents. Then try programming U-boot.

Don't even bother trying to boot U-boot until you know your SDRAM is setup correctly.

But thats another set of data sheets, and processor reference manual chapters ....

:)

Should we tell him how much simpler flash configuration is than SDRAM?

Designated curmudgeon of the day, ;-) gvb

On 9/12/07, David Hawkins dwh@ovro.caltech.edu wrote:

...

Should we tell him how much simpler flash configuration is than SDRAM?

Again, I was trying to be kind ;)

OK guys I have a sense of humour and you all have indeed been very kind in your help. Everyone was a newbie at one point of course. David has already identified a hardware problem for us in which we are quite grateful. I've been reading almost every patch and email on this list for several months trying to understand it all. All I can do in return is say thanks and supply patches once we finally get our board up. That and help those like myself someday - which I do often on the topics I know something about.

In the meantime we'll be spending quality with our manuals. We have OE and CE toggling on our erase, mm, and prog commands but we cannot read the values we write with mm. We cannot read the manufactorer id on oxfc000000. Beyond that the magic numbers are for the first and second unlock cycles and for autoselect, we cannot understand why bdi configs use 0x0600 and 0x00d0 for their magic numbers - which are not the same magic numbers in the manuals best as we can tell. We tried writing the same magic numbers in the manuals directly via the bdi to seemingly no effect.

That all being said, our knowledge is slowly getting there - and it would have exponentially slower without the help so far.

Cheers, Robert

David Hawkins wrote:

Hi Robert,

...

OK guys I have a sense of humour

Its a pre-requisite; that, and tough skin ;)

[snip]

...

Beyond that the magic numbers are for the first and second unlock cycles and for autoselect, we cannot understand why bdi configs use 0x0600 and 0x00d0 for their magic numbers - which are not the same magic numbers in the manuals best as we can tell.

It depends on how the Flash is wired. As far as data wires go, Flash[15:0] can connect to Processor[15:0] or Processor[0:15]. Whatever the processor writes, it'll read back.

However, the Flash command codes expect the bit pattern as defined in the command codes table on Flash[15:0].

So you've got lots of board specific cases;

• bits reversed
• bytes swapped
• bits in bytes reversed

and so on ...

If the command code was 0x0006, and the BDI config you copied shows 0x0600, then they've got bytes swapped. If the code was 0x0060, and the bus is reversed then you'll get 0x0600.

When you copy someone elses design without understanding it, you can end up copying their mistakes.

In your case, you hooked up your Flash correctly, but you're trying to interpret someone else's design in the context of your design.

Rather than that, just look at the data sheets and your specific design. You've gained an understanding of what the BDI configuration file should contain, now toss away anyone elses configs ... or look at them with a 'grain of salt'.

Cheers, Dave

I have limited CFI experience, but my flash experience is that the flash chips ignore extra bytes in the data lanes when you send commands. Assuming your flash isn't bit-swapped, you should be able to write the magic bytes down all four byte lanes and have it work for byte-wide, 16-bit-wide, and 32-bit-wide chips or paralleled 8-bit or 16-bit wide chips. This neatly solves the byte swap issue as well.

The other critical part is the address you use. Depending on the width of your chip(s) and if more than one paralleled on the bus, you will have to add zero "0" bits to the magic 55 / AA addresses in the manual.

For the translation of byte-wide to 16 bit wide: 55 (0101_0101) becomes 0AA (0_1010_1010) AA (1010_1010) becomes 254 (1_0101_0100) ^ added '0' bit

For the translation of byte-wide to 32 bit wide: 55 (0101_0101) becomes 154 (01_0101_0100) AA (1010_1010) becomes 2A8 (10_1010_1000) ^^ two added '0' bits

Best regards, gvb

David Hawkins wrote:

Hi Jerry,

...

I have limited CFI experience, but my flash experience is that the flash chips ignore extra bytes in the data lanes when you send commands. Assuming your flash isn't bit-swapped, you should be able to write the magic bytes down all four byte lanes and have it work for byte-wide, 16-bit-wide, and 32-bit-wide chips or paralleled 8-bit or 16-bit wide chips. This neatly solves the byte swap issue as well.

Nice to know, thanks.

...

The other critical part is the address you use. Depending on the width of your chip(s) and if more than one paralleled on the bus, you will have to add zero "0" bits to the magic 55 / AA addresses in the manual.

For the translation of byte-wide to 16 bit wide: 55 (0101_0101) becomes 0AA (0_1010_1010) AA (1010_1010) becomes 254 (1_0101_0100) ^ added '0' bit

For the translation of byte-wide to 32 bit wide: 55 (0101_0101) becomes 154 (01_0101_0100) AA (1010_1010) becomes 2A8 (10_1010_1000) ^^ two added '0' bits

Ooh, thats a sneaky one.

I think (hope) the Spansion chips are 'smarter' than that. They have a BYTE# pin that configures it to operate in 8-bit (low) versus 16-bit (high), and in byte mode DQ15 become A-1 (address bit minus -1). I'm pretty sure the Spansion data sheet describes the commands in terms of byte addresses, so there is no ambiguity of byte versus 'word' (which has so many meanings ...) addresses in the command codes.

Robert has correctly connected the Flash address and data signals, so he shouldn't have to massage the address/data relative to the data sheet command codes.

I'm pretty sure the Altera FPGA boards that I ran some tests on used Spansion Flash, and I didn't have to shift the address part of the Flash command.

Nice info though, thanks. Dave

The address shifting happens when the hardware guys put down (2) 8-bit flash chips to be 16 bits wide, (4) 8-bit flash chips to be 32 bits wide, or (2) 16-bit flash chips to be 32 bits wide. Size, timing, availability, and cost reasons usually drive this (and the first three are weighted very low).

Back when we had to subtract two '1' bits to make '0's, flashes (actully, EEPROMs to really show my age) only came in 8 bit wide packages so the address shifting phenomena happened quite often.

gvb

On 9/12/07, David Hawkins dwh@ovro.caltech.edu wrote:

Don't move onto anything until you can read the manufacturer ID, you've found a problem, so you need to figure it out here first.

After a few days with the docs, we've had some limited success. We moved back to 128MB of ram and a base address of F8000000 . We think we may have some timimg issues. To read the manufactor id the docs say:

*( (UINT16 *)base_addr + 0x555 ) = 0x00AA; /* write unlock cycle 1 */ *( (UINT16 *)base_addr + 0x2AA ) = 0x0055; /* write unlock cycle 2 */ *( (UINT16 *)base_addr + 0x555 ) = 0x0090; /* write autoselect command */ manuf_id = *( (UINT16 *)base_addr + 0x000 ); /* read manuf. id */

So in our case we start with LAD30, so we need to do a shift left:

AAA = 555 << 1; 554 = 2AA << 1;

In the bdi, we executed:

ATUM>mmh 0xf8000AAA 0x00AA ATUM>mmh 0xf8000554 0x0055 ATUM>mmh 0xf8000AAA 0x0090 ATUM>mmh 0xf8000AAA 0x0090 ATUM>mdh 0xf8000000 1

At which point we got the manufactor id and everything else. Unfortunately the next day we weren't able to repeat it - can the manufactor id be erased?

Anyways, we were able to write a word:

ATUM>mmh 0xf8000AAA 0x00AA ATUM>mmh 0xf8000554 0x0055 ATUM>mmh 0xf8000AAA 0x00A0 ATUM>mmh 0xf8000F00 0xCAFE ATUM>mdh 0xf8000F00 1 0_f8000f00 : 0xcafe -13570

We have yet to be able to repeat that feat at any other address. We can read 0xCAFE from 0xf8000F00 , but only after about a minute after a bdi boot. We cannot overwrite 0xf8000F00 , nor can we erase the entire chip via the documented sequence. As I said we think we have timing issues. Any suggestions? More RTFM? We do have a logic analyzer.

Thanks all, Robert

robert lazarski wrote:

On 9/12/07, David Hawkins dwh@ovro.caltech.edu wrote:

...

Don't move onto anything until you can read the manufacturer ID, you've found a problem, so you need to figure it out here first.

<snip>

We have yet to be able to repeat that feat at any other address. We can read 0xCAFE from 0xf8000F00 , but only after about a minute after a bdi boot. We cannot overwrite 0xf8000F00 , nor can we erase the entire chip via the documented sequence. As I said we think we have timing issues. Any suggestions? More RTFM? We do have a logic analyzer.

Nice progress! Since you have a logic analyzer, you should definitely get a sense of the timing, which may or may not reveal anything. You have this chip select really slowed down, and it's asynchronous, so something would have to really be out of whack.

I'd be more tempted to look elsewhere. What else do you have on the local bus? Are other devices isolated via buffers in the same way that the Freescale eval boards are? Is the flash VCC looking good? Is the reset signal solid?

regards, Ben

On 9/14/07, David Hawkins dwh@ovro.caltech.edu wrote:

Hi Robert,

...

After a few days with the docs, we've had some limited success. We moved back to 128MB of ram and a base address of F8000000 . We think we may have some timimg issues. To read the manufactor id the docs say:

*( (UINT16 *)base_addr + 0x555 ) = 0x00AA; /* write unlock cycle 1 */ *( (UINT16 *)base_addr + 0x2AA ) = 0x0055; /* write unlock cycle 2 */ *( (UINT16 *)base_addr + 0x555 ) = 0x0090; /* write autoselect command */ manuf_id = *( (UINT16 *)base_addr + 0x000 ); /* read manuf. id */

So in our case we start with LAD30, so we need to do a shift left:

AAA = 555 << 1; 554 = 2AA << 1;

Do you really? I would have thought that the address code was a byte-address, and therefore invariant for this part. In 16-bit mode the device doesn't see the last bit. Double-check :)

OK guys, its working!!!! YEAH!!!! Last problem turned out to be an open resistor / bad solder joint on the address bus! We can now erase the flash chip entirely. I also did the prog command to upload uboot.bin and can see the uboot version at the base address - so this stage is now completed!!!! Thanks so much for all the help guys, I doubt we would have gotten so far without this community and we are most grateful! I feel so much smarter now ;-) .

Last question before I get into my code finally - and I'll start a new thread when I start debugging: The bdi docs in the uboot manual seem to stop at the 'go' command. When I type 'info' I get a running state. Can I now just power on and attach a terminal via the serial port to get the uboot shell? To get to that point is the next dragon to slay?

Thanks!!! Robert

We are using BDI3000 to Burn u-boot.bin to Flash memory. The flash we are using is Spansion S29GL512S.

As per the flash datasheet we tried programming 4 bytes( using telnet mmb command) write buffer programming cycle. We succeeded.

But when we tried programming a binary file ( u-boot.bin) ,it was failing. Even though the log shows Flash programming passed but in the location when we do a mdh there is no u-boot data.

Please find the log captured below.

IMX6#0> - TARGET: processing reset request - TARGET: BDI executes scan chain init string IMX6#0> IMX6#0> - TARGET: Bypass check 0x00000001 => 0x00000004 - TARGET: JTAG exists check passed - Core#0: ID code is 0x4BA00477 - Core#0: DP-CSW is 0xF0000000 - Core#0: DBG-AP at 0x82150000 - Core#0: DIDR is 0x3513702A - TARGET: Reset sequence passed - TARGET: resetting target passed - TARGET: processing target startup .... - TARGET: processing target startup passed IMX6#0> IMX6#0> IMX6#0>

*********************Flash Erase successful************************** IMX6#0>mmh 0x08000aaa 0xaaaa IMX6#0>mmh 0x08000554 0x5555 IMX6#0>mmh 0x08000aaa 0x8080 IMX6#0>mmh 0x08000aaa 0xaaaa IMX6#0>mmh 0x08000554 0x5555 IMX6#0>mmh 0x08000aaa 0x1010 IMX6#0>erase 0x08000000 chip Erasing flash at 0x08000000 Erasing flash passed

*********************Write to buffer Flash Programming successful************************** IMX6#0>mmb 0x08000aaa 0xaa IMX6#0>mmb 0x08000555 0x55 IMX6#0>mmb 0x08000000 0x25 IMX6#0>mmb 0x08000000 3 IMX6#0>mmb 0x08000000 0x12 IMX6#0>mmb 0x08000001 0x34 IMX6#0>mmb 0x08000002 0x56 IMX6#0>mmb 0x08000003 0x78 IMX6#0>mmb 0x08000000 0x29 IMX6#0>mdb 0x08000000 08000000 : 12 34 56 78 ff ff ff ff .4Vx.... 08000008 : ff ff ff ff ff ff ff ff ........ 08000010 : ff ff ff ff ff ff ff ff ........ 08000018 : ff ff ff ff ff ff ff ff ........ 08000020 : ff ff ff ff ff ff ff ff ........ 08000028 : ff ff ff ff ff ff ff ff ........ 08000030 : ff ff ff ff ff ff ff ff ........ 08000038 : ff ff ff ff ff ff ff ff ........ 08000040 : ff ff ff ff ff ff ff ff ........ 08000048 : ff ff ff ff ff ff ff ff ........ 08000050 : ff ff ff ff ff ff ff ff ........ 08000058 : ff ff ff ff ff ff ff ff ........ 08000060 : ff ff ff ff ff ff ff ff ........ 08000068 : ff ff ff ff ff ff ff ff ........ 08000070 : ff ff ff ff ff ff ff ff ........ 08000078 : ff ff ff ff ff ff ff ff ........ IMX6#0> IMX6#0>mmh 0x08000000 0x00f0 IMX6#0>mmh 0x08000aaa 0x7070 IMX6#0>mmh 0x08000aaa 0x7171 IMX6#0>mmh 0x08000aaa 0xaaaa IMX6#0>mmh 0x08000554 0x5555 IMX6#0>mmh 0x08000000 0x3030 IMX6#0>mmh 0x08000aaa 0x1010 IMX6#0>erase 0x08000000 chip Erasing flash at 0x08000000 Erasing flash passed

********************U-boot Programming with Prog command Failure************************** IMX6#0>mmh 0x08000aaa 0xaaaa IMX6#0>mmh 0x08000554 0x5555 IMX6#0>mmh 0x08000000 0x0025 IMX6#0> IMX6#0>prog 0x08000000 u-boot.bin bin Programming u-boot.bin , please wait .... Programming flash passed IMX6#0>mmh 0x08000000 0x0029 IMX6#0>mdh 0x08000000 08000000 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000010 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000020 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000030 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000040 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000050 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000060 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000070 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000080 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 08000090 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 080000a0 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 080000b0 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 080000c0 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 080000d0 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 080000e0 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. 080000f0 : 000a 004a 000a 004a 000a 004a 000a 004a ..J...J...J...J. IMX6#0>

I was able to read the manufacturer ID also .

The Prog command shows it is successful but nothing is written on the base address if i give the prog command directly without any write to buffer programming commands or word programming commands

Kindly help me resolving this issue.

-- View this message in context: http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-t... Sent from the U-Boot mailing list archive at Nabble.com.

Hi Fabio,

The CPU is imx6 customed processor.

The Prog command shows it passed but the u-boot.bin is not uploaded.

Regards, Monica.S

From: Fabio Estevam-2 [via U-Boot] [mailto:ml-node+s10912n155717h46@n7.nabble.com] Sent: Monday, May 27, 2013 7:08 PM To: Monica Sampathkumar Subject: Re: minimum bdi config to read flash on 85xx

Hi Monica,

On Mon, May 27, 2013 at 10:01 AM, Monica <[hidden email]</user/SendEmail.jtp?type=node&node=155717&i=0>> wrote:

We are using BDI3000 to Burn u-boot.bin to Flash memory. The flash we are using is Spansion S29GL512S.

As per the flash datasheet we tried programming 4 bytes( using telnet mmb command) write buffer programming cycle. We succeeded.

But when we tried programming a binary file ( u-boot.bin) ,it was failing. Even though the log shows Flash programming passed but in the location when we do a mdh there is no u-boot data.

Please find the log captured below.

IMX6#0>

Your email subject mentions 85xx, but the prompt above says mx6.

Which CPU does your board have? _______________________________________________ U-Boot mailing list [hidden email]</user/SendEmail.jtp?type=node&node=155717&i=1> http://lists.denx.de/mailman/listinfo/u-boot

________________________________ If you reply to this email, your message will be added to the discussion below: http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-t... To unsubscribe from minimum bdi config to read flash on 85xx, click herehttp://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=23684&code=bW9uaWNhX3NAaGNsLmNvbXwyMzY4NHw3MDA1NTgxNTM=. NAMLhttp://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml

::DISCLAIMER:: ----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.

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

-- View this message in context: http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-t... Sent from the U-Boot mailing list archive at Nabble.com.

Hello,

On 9/14/07, Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:

robert lazarski wrote:

...

OK guys, its working!!!! YEAH!!!! Last problem turned out to be an

OK, now, here at our labs we have two rules:

1) when you smoke your hardware, you treat the lab with candy/icecream/cookies/... 2) when a board-bring-up is succesfull, you treat the lab with candy/icecream/cookies/...

Regards,

Hi Robert,

OK guys, its working!!!! YEAH!!!! Last problem turned out to be an open resistor / bad solder joint on the address bus!

This raises another debugging rule:

'one is never enough'

=> Have multiple copies of the same hardware.

And then Murphy's Law comes into play:

'the first one you debug will be the bad one'

=> Every damn time too ;)

Glad to hear you've got passed that problem. Dave