Author Topic: mtd sees flash  (Read 28553 times)

0 Members and 1 Guest are viewing this topic.

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
mtd sees flash
« on: July 15, 2005, 05:30:10 am »
Code: [Select]
mtd: Giving out device 0 to NOR flash on EDB7312
EDB7312-NOR:using static partition definition
Creating 3 MTD partitions on "NOR flash on EDB7312":
0x00000000-0x00040000 : "ARMboot"
mtd: Giving out device 1 to ARMboot
0x00040000-0x00240000 : "Kernel"
mtd: Giving out device 2 to Kernel
0x00240000-0x01000000 : "RootFS"
mtd: Giving out device 3 to RootFS


Now I just need to figure out if mtd will let me write to it once I find the proper commands....  I can read it via /dev/mtdblock1 fine (verified that it's actually the flash)

Offline judb

  • Administrator
  • Veteran.
  • *****
  • Posts: 1329
  • ph4t l3wtz
Re: mtd sees flash
« Reply #1 on: July 15, 2005, 12:27:33 pm »
thats great news!  Is this using your custom kernel loading via the serial port or what?

Also, are there really three partitions in the flash like it mentions or is that a default flash layout its using?

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #2 on: July 15, 2005, 08:47:19 pm »
I havent tried reading from any other partitions, I wasn't much interested in anything but ARMBoot --- the driver doesn't support writing, so we still need to make that...  the specs say how to unlock the flash but I'm not quite sure how to impliment ;)

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #3 on: July 15, 2005, 08:48:26 pm »
Quote
thats great news!  Is this using your custom kernel loading via the serial port or what?


the custom kernel isnt being loaded via serial port, the firmware is being changed on the fly to not check sigs via the serial port btw

Offline judb

  • Administrator
  • Veteran.
  • *****
  • Posts: 1329
  • ph4t l3wtz
Re: mtd sees flash
« Reply #4 on: July 16, 2005, 05:26:34 am »
oh okay i see now.  im out of it right now due to pain killers.. I just had surgery this morning.  doh!

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #5 on: July 17, 2005, 08:05:41 am »
I got the drivers working, but I think perhaps the memory is protected?  Unlock seems to work, and it can write but only if it's the SAME data that was there.  Could it be that the blocks are protected?  

It thinks there are 2 chips, but that seems to be the only way it works right... couple other things I can try but this is annoying heh

Sam

Code: [Select]
physmap flash device: 80000 at 70000000
Found: ST M29W200BB
phys_mapped_flash: Found 2 x16 devices at 0x0 in 16-bit bank
number of JEDEC chips: 1


Code: [Select]

# dd if=/dev/mtd0 of=test bs=1024 count=10
MTD_open
MTD_read
MTD_read
MTD_read
MTD_read
MTD_read
MTD_read
MTD_read
MTD_read
MTD_read
MTD_read
10+0 records in
10+0 records out
MTD_close
# dd of=/dev/mtd0 if=test bs=1024 count=10
MTD_open
MTD_write
MTD_write
MTD_write
MTD_write
MTD_write
MTD_write
MTD_write
MTD_write
MTD_write
MTD_write
10+0 records in
10+0 records out
MTD_close
#

Offline judb

  • Administrator
  • Veteran.
  • *****
  • Posts: 1329
  • ph4t l3wtz
Re: mtd sees flash
« Reply #6 on: July 17, 2005, 02:20:36 pm »
Hmmm.. i think the write protection is a posibility but bushing was saying he has some amd flash chip and that its specs dont include a write protect pin like the chip I have does.

Curious...

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #7 on: July 18, 2005, 03:03:09 am »
judb or somebody who knows this stuff come help me out in irc would ya heh... I got flash_and_burn to see the chip but I'm not sure how to go about enabling the writing on it...

I had to write the unlock codes to addr 0x5555,0x2AAA,0x5555 and it works reading from offsets 0x0 and 0x04 for the MfrID andChipID -- mfr ID is also at 0x02 and ChipID is at 0x06 as well then


Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #8 on: July 18, 2005, 03:12:55 am »
could also write them at the addresses 0xAAA, 0x555, 0xAAA shifted left one bit and it worked the same...

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #9 on: July 18, 2005, 05:41:20 am »
lol, well... I THINK this is progress but I managed to erase my flash :b

Now I need to write something that will keep the 8051 alive during an initial boot ... what I have only works if it's booted up once before

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #10 on: July 18, 2005, 09:31:40 am »
FYI: I managed to write out the (modified) bootloader code over the serial port and boot up the box, so it's up with erased flash heh.... now just need to get writing working, and we should all be able to reflash our chips and use and hard drives we feel like :)

Offline judb

  • Administrator
  • Veteran.
  • *****
  • Posts: 1329
  • ph4t l3wtz
Re: mtd sees flash
« Reply #11 on: July 18, 2005, 01:52:01 pm »
Will this require everyone to have a serial connection working to get it up and running?  Also, I did a slight poke but not too hard, what are you using for your serial port rig again?

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #12 on: July 18, 2005, 05:44:08 pm »
Quote
Will this require everyone to have a serial connection working to get it up and running?  Also, I did a slight poke but not too hard, what are you using for your serial port rig again?


naw anybody could erase their flash right now :b  and if we get this working anybody can reflash w/o serial...

look at http://wiki.phathack.com/Access_Serial_Port for my serial setup

Offline judb

  • Administrator
  • Veteran.
  • *****
  • Posts: 1329
  • ph4t l3wtz
Re: mtd sees flash
« Reply #13 on: July 18, 2005, 07:37:08 pm »
Yeah I found that after I asked.  hehe :)  Thanks for the info.. the radio shack around the corner has them for 10 bucks too. sweet.


Quote

w00t!  If you can erase it that means at least some of the PBs don't have the Flash write protected, and that with the appropriate black magic you'll be able to write.  Which brand/part is your flash chip, incidentally?  :)


VVVVVVVVVVVVVVVVVVVVVVVVVV

You know, I think that means that all phatboxes will not have the flash write protected.. at least the 1.1 and older boxes.. my flash chip has write protect capability but it doesnt appear to be wired up for it.  bushing has an AMD flash chip that apparently doesnt support it at all.. so I think we may dodge that bullet.
« Last Edit: July 18, 2005, 11:03:21 pm by judb »

Offline RobM

  • Senior Member
  • A few posts under my belt.
  • *****
  • Posts: 48
Re: mtd sees flash
« Reply #14 on: July 18, 2005, 10:37:27 pm »
Quote

naw anybody could erase their flash right now :b  and if we get this working anybody can reflash w/o serial...

look at http://wiki.phathack.com/Access_Serial_Port for my serial setup


w00t!  If you can erase it that means at least some of the PBs don't have the Flash write protected, and that with the appropriate black magic you'll be able to write.  Which brand/part is your flash chip, incidentally?  :)

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #15 on: July 19, 2005, 01:23:53 am »
Quote

w00t!  If you can erase it that means at least some of the PBs don't have the Flash write protected, and that with the appropriate black magic you'll be able to write.  Which brand/part is your flash chip, incidentally?  :)


Mine is the ST M29W200BB (Like it said in the output from the flash program I posted ;) )
« Last Edit: July 19, 2005, 01:24:46 am by sbingner »

Offline bushing

  • Senior Member
  • Needs to get outside.
  • *****
  • Posts: 119
  • props to my peeps
Re: mtd sees flash
« Reply #16 on: July 20, 2005, 12:03:45 am »
It was rmini who had the AMD chip, BTW -- I have the ST Micro.  But yeah, as far as we can tell, the two chips should be treated identically.

I'd really like to play more with this myself, but I'm juggling daggers right now over here :( so let me see if I can at least provide some insightful commentary.

I believe the device should be in 16-bit mode, so the chip id code should be 555, 2AA, 555 according to the datasheet ... that works out to

0101 0101 0101
0010 1010 1010
0101 0101 0101

You said you sent 0x5555, 0x2AAA, 0x5555? that's

0101 0101 0101 0101
0010 1010 1010 1010
0101 0101 0101 0101

Now, the datasheet says that it only looks at A0-A10 for the command interface (so, the rightmost 11 bits)

so it would see
x101 0101 0101
x010 1010 1010
x101 0101 0101

You also said that AAA, 555, AAA shifted left by 1 bit worked, so that's

1010 1010 1010 -> 0101 0101 0100
0101 0101 0101 -> 1010 1010 1010
1010 1010 1010 -> 0101 0101 0100

Soo... that kinda looks like A2 of the processor is connected to A0 of the flash rom -- ie it's throwing away the right two bits of the address. interesting.

That would explain why the chip id bytes are at 0x00 and 0x04 -- because those become 0x00 and 0x01 when you shift them right by 2.  They are also at 0x02 and 0x06 because those also turn into 0x00 and 0x04.

(Apologies if this was already obvious -- I'm just trying to reason this out for myself.)

It would seem like the processor would not like that and that you would see stuff doubled in memory when you tried (or it tried) to read the rom to boot off it, or whatever, but I must not be understanding the way the processor handles 16-bit accesses.

So, in theory, if one wanted to erase the last block, #6 (64k from 0x18000 to 0x1ffff), you would do something like

Code: [Select]

unsigned short *flash_base; // should be 16 bit wide
flash_base=mmap(blah blah blah);

#define WRITE_FLASH(x,y) flash_base[(x)<<1]=y // only shift by 1 because we're doing 16 bits at a time

WRITE_FLASH(0x555,0xAA);
WRITE_FLASH(0x2AA,0x55);
WRITE_FLASH(0x555,0x80);
WRITE_FLASH(0x555,0xAA);
WRITE_FLASH(0x2AA,0x55);
WRITE_FLASH(0x1FFFF,0x30);   // this can be any address inside the block


And then 50 ns later it would perform that erase operation.

writing a single 16-bit word would be:

Code: [Select]

WRITE_FLASH(0x555,0xAA);
WRITE_FLASH(0x2AA,0x55);
WRITE_FLASH(0x555,0xA0);
WRITE_FLASH(address,(16-bits of data));


You might be able to read the protection status of the blocks by doing the same sequence as you'd use for reading the id of the chip, but instead of reading 0x00 or 0x04, you might read (0x0002, 0x1002, 0x2002, 0x3002) << 2  -- and i think those should show up as 0 for unprotected blocks and 1 for protected blocks.

That having been said ... if you managed to erase your chip, that should mean it's unprotected :/

-b

Offline RobM

  • Senior Member
  • A few posts under my belt.
  • *****
  • Posts: 48
Re: mtd sees flash
« Reply #17 on: July 20, 2005, 01:06:08 am »
Yeah, I've got the AMD in my VW/Audi PB.  I'm going to trace the addr pins, but it's possible that the low bits of the CPU are wired to the high bits of the flash chip.

Offline RobM

  • Senior Member
  • A few posts under my belt.
  • *****
  • Posts: 48
Re: mtd sees flash
« Reply #18 on: July 20, 2005, 01:32:45 am »
A[2:16] of the CPU are connected to A[0:14] of the flash chip.  Pin A[1] of the CPU is connected to A[15] of the flash, and A[16] of the flash appears to be unconnected.

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: mtd sees flash
« Reply #19 on: July 20, 2005, 10:39:01 am »
No, I sent 0x5555=AA, 0xAAAA=55, 0xAAAA=90

Also, strangely enough when I wrote to 0x02 it showed up on both 0x02 and 0x03 (I wrote 0xa0 and I read 0x02=0xa0,0x03=0xa0)

It also ends up locking up my kernel whenever I write a block other than 0x00 eg. 5555=aa AAAA=55 AAAA=a0 02=a0
<KERNEL CRASH>

I don't understand why it said virtual address 0x02 tho, I've gott boot_rom so I'm actually opening 0x70000000 and that would be real address 0x70000002 -- if it's not in write mode it doesn't crash
Code: [Select]

Unable to handle kernel NULL pointer dereference at virtual address 00000002
pgd = c0034000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: ffffffff
CPU: 0
pc : [<c004af74>]    lr : [<c00ea2a4>]    Not tainted
sp : c0c3803c  ip : c0c38068  fp : c0c38064
r10: c00f6000  r9 : c01088a0  r8 : c00f8540
r7 : c00f99b4  r6 : c00ebd68  r5 : 00000028  r4 : c0c38000
r3 : 0000e51c  r2 : c0c3803c  r1 : c0c38000  r0 : 00000002
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  Segment kernel
Control: 217D  Table: C0C34015  DAC: 00000015
Process  (pid: 0, stackpage=c0c37000)