headers
Iztok Zupet | 1 Jul 2002 15:35
Picon

RedBoot from DoC not working quite well

Hi,

 I succsessfuly replaced a DoC millenium firmware with RedBoot using the GRUB 
patch as the base. After

	>>> doc_loadbios /dev/mtd0 redboot_firmware

RedBoot boots fine (int18 or int19). But after formating my DoC with 
nftl_format utility:

	>>> nftl_format /dev/mtd0 128000

which should leave all the RedBoot blocks unchanged, my RedBoot is gone.
The whole redboot_firmware size is 126280.

Can someone tell me why the RedBoot and NFTL blocks interleave, if they do. 

Thanks
iz
Permalink | Reply | 3 comments |
headers
Joakim Tjernlund | 1 Jul 2002 15:35
Picon

FS corruption.

Hi 

I just got a FS crash/corruption a one of our boards. I am running the stable jffs2 branch
from late April. Any idea's what caused this?

 Jocke 

> Setting Target eth0 IP address: a000108.
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> LLC 2.0 by Procom, 1997, Arnaldo C. Melo, 2001
> NET4.0 IEEE 802.2 extended support
> NET4.0 IEEE 802.2 User Interface SAPs, Jay Schulist, 2001
> JFFS2: Total scan time: 5.97 sec
> Eep. Child "S40umountfs" (ino #245) of dir ino #13 doesn't exist!
> Eep. Child "telnet" (ino #568) of dir ino #65 doesn't exist!
> Eep. Child "ansi" (ino #765) of dir ino #78 doesn't exist!
> Eep. Child "ansis" (ino #804) of dir ino #78 doesn't exist!
> Eep. Child "ansi80x60-mono" (ino #778) of dir ino #78 doesn't exist!
> Eep. Child "ansi80x30" (ino #771) of dir ino #78 doesn't exist!
> Eep. Child "ansisysk" (ino #812) of dir ino #78 doesn't exist!
> Eep. Child "ACT" (ino #1206) of dir ino #91 doesn't exist!
> Eep. Child "Yancowinna" (ino #1215) of dir ino #91 doesn't exist!
> Eep. Child "etc" (ino #1594) of dir ino #1560 doesn't exist!
> Eep. Child "liblockfile.so.1.0" (ino #671) of dir ino #66 doesn't exist!
> Eep. Child "crt1.o" (ino #637) of dir ino #66 doesn't exist!
> Eep. Child "libe2p.so.2.3" (ino #622) of dir ino #66 doesn't exist!
> Eep. Child "libpopt.so.0.0.0" (ino #694) of dir ino #66 doesn't exist!
> Eep. Child "alib_swusd" (ino #1629) of dir ino #1561 doesn't exist!
> Eep. Child "date" (ino #175) of dir ino #2 doesn't exist!
> Eep. Child "domainname" (ino #163) of dir ino #2 doesn't exist!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jasmine Strong | 1 Jul 2002 15:41

Re: RedBoot from DoC not working quite well


On Mon, 1 Jul 2002, Iztok Zupet wrote:

> RedBoot boots fine (int18 or int19). But after formating my DoC with
> nftl_format utility:
>
> 	>>> nftl_format /dev/mtd0 128000
>

You can't start a format from that address.  It's not an erase block
boundary.  (Most DoC devices have 8k erase blocks.  THat means 8192 bytes,
not 8000.)

Try erasing from 131072, rather than 128000.

Jas.
Permalink | Reply | 2 comments |
headers
Frederic Gobry | 1 Jul 2002 15:14
Picon

Re: mmap question

I follow-up to my own question: I've managed to use mmap with jffs2
quite successfully, but now I would like to directly use MTD (so that
I can handle the way sectors are erased / written to in order to
ensure good atomicity).

I've seen that the MTD char driver does not provide mmap support. In
order to implement it, I would like to know if I can use the 'point'
function of the mtd_info structure to get the physical address of the
flash device. From the documentation

  "For devices which are entirely memory-mapped and which can be
   mapped directly into user-space page tables, we may support
   execute-in-place (XIP) mapping of data on the flash. The precise
   semantics of this are yet to be defined, so it's probably best just
   not to either implement or attempt to use these two functions right
   at the moment."

So, is it the correct way to go ?

Thanks,

Frédéric
Permalink | Reply | 6 comments |
headers
Iztok Zupet | 1 Jul 2002 16:03
Picon

Re: RedBoot from DoC not working quite well

On Monday 01 July 2002 15:41, Jasmine Strong wrote:
> On Mon, 1 Jul 2002, Iztok Zupet wrote:
> > RedBoot boots fine (int18 or int19). But after formating my DoC with
> >
> > nftl_format utility:
> > 	>>> nftl_format /dev/mtd0 128000
>
> You can't start a format from that address.  It's not an erase block
> boundary.  (Most DoC devices have 8k erase blocks.  THat means 8192 bytes,
> not 8000.)
>
> Try erasing from 131072, rather than 128000.
>
> Jas.

 I tried but it still owerwrites or erases my RedBoot.
Size of my redboot_firmware is exactly 123.2K.

Regards
iz
Permalink | Reply | 1 comment |
headers
David D. McCoach | 1 Jul 2002 20:56
Favicon

MultiMediaCard

Any one doing work with MultiMedia Cards? 

THe are not really flash not nand type devices.

      _/    _/ _/    _/ _/_/_/   David D McCoach
     _/    _/ _/_/_/_/   _/     Woodward McCoach, Inc.
    _/ _/ _/ _/ _/ _/   _/     1180 McDermott Drive
   _/_/_/_/ _/    _/   _/     West Chester, PA 19380
  _/    _/ _/    _/ _/_/_/   610-692-9526 ext.103
Permalink | Reply | 0 comments |
headers
Pete Popov | 2 Jul 2002 01:46

Atmel 49BV1614A parts

I'm having a problem with the above parts which I finally debugged to a
different sector scheme from the older 49BV1614 parts.  The 1614 has 8
8KB sectors, 2 32KB sectors, and 30 64B sectors.  The newer 1614A has 8
8KB sectors, and 31 64KB sectors.  But both parts have the same
manufacturer and device IDs so I don't see any way of differentiating
the two.  Any ideas on how to best handle this?   There is some sort of
"additional" id in the newer part, but the current mtd layer has no
support for this.

I'm not on the list so a direct reply would be appreciated.

Thanks a lot.

Pete
Permalink | Reply | 0 comments |
headers
Joakim Tjernlund | 2 Jul 2002 12:10
Picon

RE: [Fwd: cfi_cmdset_0001.c: do_write_buffer bug]

Hi John

Has Intel responded yet? If yes, do they have a fix?

         Jocke
> 
> 
> On 20 June 2002 13:25 David Woodhouse <dwmw2 <at> infradead.org> wrote:
> 
> > John.Hall <at> optionexist.co.uk said:
> > >  Not yet. We've spoken to Intel and they acknowledge there might be
> > >  a problem, but we're waiting for them to get back to us.
> 
> > OK, I suspect what we want to do is something like...
> > 
> >  Send WriteToBuffer command.
> >  Poll for a little while for chips to become ready.
> >  If neither chip is ready, repeat.
> >  If only one chip is ready, abort the WriteToBuffer. Send a
> >  zero-length (or one-byte) buffer and then something other than a
> >  WriteConfirm command, to abort the write. Clear the resulting
> >  'Invalid Command/ Sequence' error bits which will get set, and start
> >  again.
> 
> Possibly. We're going to wait and see what Intel say, and then submit a
> patch if needed.
> 
> Regards,
> John Hall
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iztok Zupet | 2 Jul 2002 12:28
Picon

Re: RedBoot from DoC not working quite well

On Monday 01 July 2002 16:03, Iztok Zupet wrote:
> On Monday 01 July 2002 15:41, Jasmine Strong wrote:
> > On Mon, 1 Jul 2002, Iztok Zupet wrote:
> > > RedBoot boots fine (int18 or int19). But after formating my DoC with
> > >
> > > nftl_format utility:
> > > 	>>> nftl_format /dev/mtd0 128000
> >
> > You can't start a format from that address.  It's not an erase block
> > boundary.  (Most DoC devices have 8k erase blocks.  THat means 8192
> > bytes, not 8000.)
> >
> > Try erasing from 131072, rather than 128000.
> >
> > Jas.
>
>  I tried but it still owerwrites or erases my RedBoot.
> Size of my redboot_firmware is exactly 123.2K.
>
> Regards
> iz
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

 It OK now . My RedBoot firware was 8K bytes too big, eg it loaded yust a 
little pass the 0x20000 in DoC.

Regards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcos Lois Bermúdez | 2 Jul 2002 13:39
Picon

About MTD layer

I get some trouble using MTD/JFFS/2
At some time my board halts, i use a mbm29lv160 that don't have all the 
sectors of 64Kb, it have some sectors at 8 Kb, 16Kb and 32Kb.
Where i can test if my MTD layes detect this sector layout?

Any help will be apreciated.
Regards.
Permalink | Reply | 0 comments |

Gmane