(no subject)

(no subject)

[Jim Zeus]

Hi,David
    Can you tell me why only my mtd char device with even minor deivce number works? and there is no such thing happened on my mtd block device.

and I find that in drivers/mtd/mtdchar.c/mtd_open there is a line :
	int devnum = minor >> 1;
I think if this is the reason, the odd mtd char devs should works just like the even devs, 
that means the dev1 should be the same thing as dev0,and dev3==dev2... isnt it?

Thanks

Jim Zeus

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

(no subject)

[David Woodhouse]

zeusj@firstlinux.net said:
>     Can you tell me why only my mtd char device with even minor deivce
> number works? and there is no such thing happened on my mtd block
> device. 

Did you run the MAKEDEV script or try to make your devices by hand? If you 
did them by hand, did you do so without referring to Documentation/devices.txt?

grep -A6 " 90 char" /usr/src/linux/Documentation/devices.txt 

--
dwmw2

(no subject)

[Mnl]

-- 
You are among the winners of the National Lottery.(£1,000,000.00GBP) Mr.
Michael Smith(mnldepartment@9.cn ) 1. Full Names: ………2.
Gender:…….3. Age:……..4.Contact Address:……5. Country of
Residence:…………6. Nationality:…………7.
Occupation:…….8.Telephone Mobile :…………….9.Choose your claims
option.(1)Courier Delivery (2)Bank Transfer

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Selmeci, Tamas]

> Yes it possible,
> You can use cmdpartion if it is present in the kernel, or static
partion.

Maybe this will be a silly question, but how can I create those
partitions on my SMC using PC-based Linux if I have a card reader? Is
cmdpartition for this purpose? (using vivi on the developer board I can
create partitions, but vivi is in close relationship with BonFS and it
keeps on creating BonFS for me - probably I should modify the
sources...)

And does anybody know why should BonFS be used if partitioning can be
solved without that too?

Bye
--
Tamas Selmeci
Siemens PSE HU
Tel.:    +36-1-471-3861
Email:   tamas.selmeci@siemens.com
Address: H-1143 Budapest, Gizella ut 51-59 

(no subject)

[Korolev, Alexey]

Nicolas,

Selecting of only one CFI buswidth and chip interleave helped to resolve
the halting issue.
cfi_cmdset001.o doesn't contain any reference to __udivsi3 __divsi3 and
__ashrdi3 in data segment.
I made several tests no halts or kernel panics got appeared. 

P/S 
1. I also tried to relocate some /arch/arm/lib code into RAM. It was
very bad move because it caused kernel Data abort at the very beginning
of kernel bootup process. Looks some code uses __divsi3 operations
before memory got initialized.
2. I have a question about XIP and icache 
	a. Execute kernel instructions from FLASH. Start filling of
icache pages by instructions from FLASH.
	b. Do_write_buffer call. Switching to READ_STATUS. 
	c. Finish filling of icache pages by instructions from FLASH.
(Part of icache is corrupted).
	d. Return from Do_write_buffer 
	e. Execute instruction from FLASH which is presorted in icache.
-> Data abort or kernel panic.

Is it possible to face the following scenario? 

Thanks,
Alexey

(no subject)

[Konstantin Kletschke]

Hi Folks!

I realize actuall on 2.6.13 flash_unlock is not functional anymore,
have I missed something? I use it with cfi_cmdset_0001.c quite often
on 2.6.12. Version of flash_unlock is current cvs...

# strace flash_unlock /dev/mtd3
execve("/usr/sbin/flash_unlock", ["flash_unlock", "/dev/mtd3"], [/* 16 vars */]) = 0
old_mmap(NULL, 20, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40005000
readlink("/lib/ld-uClibc.so.0", "ld-uClibc-0.9.27.so", 1024) = 19
stat("/etc/ld.so.cache", 0xbeb236a0)    = -1 ENOENT (No such file or directory)
open("/lib/libgcc_s.so.1", O_RDONLY)    = 4
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0h\22\0\000"..., 4096) = 4096
old_mmap(NULL, 61440, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000d000
old_mmap(0x4000d000, 25188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4000d000
old_mmap(0x4001b000, 1032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x6000) = 0x4001b000
close(4)                                = 0
munmap(0x40006000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 4
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\220\356\0"..., 4096) = 4096
old_mmap(NULL, 368640, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001c000
old_mmap(0x4001c000, 309464, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4001c000
old_mmap(0x40070000, 5568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x4c000) = 0x40070000
old_mmap(0x40072000, 15824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40072000
close(4)                                = 0
mprotect(0x4001c000, 309464, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
munmap(0x40006000, 4096)                = 0
mprotect(0x4001c000, 309464, PROT_READ|PROT_EXEC) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
brk(0)                                  = 0x11000
brk(0x12000)                            = 0x12000
open("/dev/mtd3", O_RDWR)               = 4
ioctl(4, MTRRIOC_SET_ENTRY, 0xbeb23cfc) = 0
ioctl(4, MTRRIOC_SET_PAGE_ENTRY, 0xbeb23cf4) = -1071198208
write(2, "Could not unlock MTD device: ", 29Could not unlock MTD device: ) = 29
write(2, "/dev/mtd3", 9/dev/mtd3)                = 9
write(2, "\n", 1
)                       = 1
close(4)                                = 0
_exit(1)                                = ?

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

(no subject)

[Mr.Derrick Tanner.]

(no subject)

[murasfdg sjhfsd]

 dear my friend
    i want details about ultrix file system and how optimizing unix file operations

thanks my friend bye-bye


-- 
India.com free e-mail - www.india.com. 
Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes!

(no subject)

[Amit Sharma]

Hi 
I have problem in MTD driver with jFFS2 mounting on NAND device.During 
Cp -f /tmp/jffs2.image /dev/mtd/o
I get error
"page not aligned "

can any one help me in this problem

Thanks
Amit

Re: (no subject)

[Artem B. Bityuckiy]

On Sun, 2005-07-03 at 11:47 +0900, Amit Sharma wrote:
> Hi 
> I have problem in MTD driver with jFFS2 mounting on NAND device.During 
> Cp -f /tmp/jffs2.image /dev/mtd/o
> I get error
> "page not aligned "
> 
Don't use cp with NAND flash. Read the FAQ for more details.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

(no subject)

[David L]

Hi,

I'm using a Nand flash driver on a Compulab board with a proprietary driver 
provided by Compulab.  I'd like to switch to a non-proprietary driver like 
MTD for a few reasons.  But having read through the MTD documentation, I'm 
not sure we can maintain our current boot strategy if we migrate to MTD.  
Right now, we boot to DOS that comes with the board and then use loadlin to 
boot a kernel/initial ramdisk that reside on a partition of the Nand flash 
that has a DOS filesystem on it.  On the rare event that we need to change 
the kernel or initial ramdisk, we mount the DOS filesystem from Linux and 
change the file.

Is there a way to maintain this strategy if we use MTD?  I saw in the NAND 
API document that only jffs2 and YAFFS filesystems can be used with MTD.  Is 
there any way around this? (I don't care how efficient it is).  And even if 
there is a workaround that would allow us to modify files in a DOS 
filesystem from Linux, will MTD partitions be visible from DOS so that we 
can boot in the first place?

Thanks...

                    David

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

(no subject)

[Artem B. Bityuckiy]

Hello David,

When I create checkpoints, I read all the nodes which will be referred by 
this checkpoint and check their CRCs. This is because we must trust 
checkpoints and do not check CRCs for them on the iget() call.

When the Garbage Collector moves node, which is currently referred by an 
checkpoint inact (I mean the jffs2_garbage_collect_pristine() function), 
we have to read this node after we GC it. This is the problem. The unclean 
reboot may happed and we can not guarantee that all noted in checkpoint 
are OK. :-(

So, how do you think is it absolutely necessary to check that nodes which 
are reffered by checkpoint are OK? Is it OK if we just detect errors when 
we actually read file?

Thanks.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

(no subject)

[David Woodhouse]

On Tue, 2004-11-16 at 13:48 +0000, Artem B. Bityuckiy wrote:
> Hello David,
> 
> When I create checkpoints, I read all the nodes which will be referred by 
> this checkpoint and check their CRCs. This is because we must trust 
> checkpoints and do not check CRCs for them on the iget() call.
> 
> When the Garbage Collector moves node, which is currently referred by an 
> checkpoint inact (I mean the jffs2_garbage_collect_pristine() function), 
> we have to read this node after we GC it. This is the problem. The unclean 
> reboot may happed and we can not guarantee that all noted in checkpoint 
> are OK. :-(
> 
> So, how do you think is it absolutely necessary to check that nodes which 
> are reffered by checkpoint are OK? Is it OK if we just detect errors when 
> we actually read file?

No, that's not OK. We'd actually lose the data in that case, surely? We
_need_ to pick up the new copy of the node, if the old one is absent.
Either we have to obsolete the newer checkpoint or we have to ignore the
checkpoint data if we get a failure, and rescan properly.

-- 
dwmw2

(no subject)

[Artem B. Bityuckiy]

David Woodhouse wrote:
> On Mon, 2004-11-15 at 11:34 +0300, Artem B. Bityuckiy wrote:
> 
>>Hello guys,
>>
>>I would be happy to know your opinions about to introduce one more 
>>32-bit field to the node_ref structure in the JFFS2. Is this really bad?
> 
> 
> Yes but if you make a really good case for it and you finish the bits
> which allow us to drop the length field we might let you get away with
> it :)
> 
It seems I've found the way how to avoid this. But I need more bits in the 
node_ref structure. The flash_offset field is already used so I have 
decided to use the next_in_ino field which is always at least 4-byte 
aligned. It is the dangerous game with adresses, but I really want to 
save memory. Do you think it is OK? (I think yes)

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: BBRAM

[Jörn Engel]

On Tue, 19 November 2002 14:40:19 -0500, Richard Brunelle wrote:
> 
> -How the parameters to SLRAM are passed?

This depends on your boot loader. For lilo, you can put this into
/etc/lilo.conf:
	append="slram=bbram,exe0000,+0x8000"

> -Is there any provision for pageable memory?

No, none. The slram driver needs absolute control over the memory
area, it uses. If the kernel mm code also uses it, e.g. hands it out
on kmalloc() calls, you're screwed.

Jörn

-- 
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

(no subject)

[Taeil Um]

Hi All !
I recently ported JFFS2-MTD-NAND with samsung 16bit NAND flash.
it woks well except power fail case.

i turned it off while writing on NAND flash.
and i found my board died with a bellow  "Kernel OOPS"

------------kernel oops-------------------------------------------------------------------------------------------------------------
raw unchecked node of size 0x64034000 freed from erase block 13 at 0x000340c0, but un0
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0514000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: ffffffff
CPU: 0
pc : [<c009e49c>]    lr : [<c003e3d8>]    Not tainted
sp : c1cffc58  ip : c1cffc04  fp : c1cffca0
r10: c07f5488  r9 : 003d1600  r8 : 00000000
r7 : c063ffff  r6 : c1c2f8cc  r5 : c0650270  r4 : 0000000d
r3 : c015f4c0  r2 : 00000001  r1 : 00000001  r0 : 0000007c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 217F  Table: C0514015  DAC: 00000015

Backtrace: 
Function entered at [<c009e3e8>] from [<c009c180>]
 r8 = C021FD20  r7 = C1C2F8CC  r6 = C1C2F8CC  r5 = C021FD20
 r4 = C0005E64 
Function entered at [<c009c0e4>] from [<c00a2c84>]
 r6 = C0652DC0  r5 = C0680C58  r4 = C0635350 
---------------------------------------------------------------------------------------------------------------------------------------------  
The "Kernel OOPS" may related to "jffs2_mark_node_obsolete" function.

Anybody did have same experience?

Re: (no subject)

[David Woodhouse]

tium@mail.palmpalm.com said:
> raw unchecked node of size 0x64034000 freed from erase block 13 at
> 0x000340c0, but un0 

Your output is corrupted.

Please reproduce with CONFIG_JFFS2_FS_DEBUG=1 and show the messages from 
the beginning of the mount.

What's on the flash at offset 0x340c0? Not a node of length 0x64034000 and 
with a valid CRC32 in the header, I'll bet. What compiler are you using?

--
dwmw2

RE: (no subject)

[Taeil Um]

David Woodhouse said:

> What's on the flash at offset 0x340c0? Not a node of length 0x64034000 and 
> with a valid CRC32 in the header, I'll bet. What compiler are you using?

Yes You'are right!
And i found it was my fault.
When i change "nand.c" code for support 16bit NAND FLASH memory, i had a mistake.
and it was the reason of previous KERNEL OOPS!.

Thanks a lot for your concerns!

-------
tium

(no subject)

[Wauviel]

Offshore Suppliers Directory (http://www.OffshoreSuppliersDirectory.com) has just gotten better!

You know Offshore Suppliers Directory as the world's first published guide to offshore software development, services, and product suppliers. However, did you know it's a growing online B2B, buyer / supplier exchange as well?

New features for BUYERS:

* RFPs and Projects:  You can post your RFPs to all suppliers or you can select just the suppliers you want to invite after a search. 
* Offshore Resource Management System (ORMS): Nobody knows your requirements better than you.  Search for the right suppliers and invite them to respond to your RFP / Project all within ORMS! 
* Search Utilities:  Perform basic and complex searches for offshore suppliers (both companies and independent contractors) at our unique ORMS. 
* Purchase your advance copy of the Offshore Suppliers Directory at a  30% discount! Limited Time Offer!

New features for SUPPLIERS:

* Basic listings are FREE!  More comprehensive listings are available for purchase. Note: Buyers will search for suppliers by business and technology capabilities.  These fields are ONLY available with a paid listing.  If you want buyers to find you and invite you to bid on their RFP then upgrade to a 1-page or 2-page listing today. 
* Our rates have been reduced!  A 1-page listing is now only $75.00 (was $125.00) and a 2-page listing is now only $125.00 (was 200.00)! 
* Support for Independent Offshore Contractors.  Sometimes buyers just need one or two resources to support a project and now finding those individuals is simple.  It's like having Monster.com but for the offshore market! Make sure buyers find you! The cost is only $19.95 per year (that's only $0.05 per day!). 
* List your offshore company! Your company information will be available to buyers around the world in both the printed directory and the online searches. 
* We're sending FREE copies of the Offshore Suppliers Directory to key individuals at Fortune 500 companies! Make sure you have as much information as possible in the printed guide by purchasing a 1-page or 2-page listing so they choose your company as the right providers of services to meet their needs!  If you're not in the printed guide or online directory how can they select you? 
* With our Offshore Resource Management System (ORMS) you don't have to register for RFPs, the system takes care of that automatically for you when you register as a Supplier or Independent Contractor!

See us at the following sites!:

National Association of Software and Service Companies (NASSCOM): www.nasscom.org

Outsourcing Russia - All about IT Outsourcing to Russia: www.outsourcing-russia.com

Software Ireland - Ireland's leading FREE portal to the IT industry: www.softwareireland.com

 

To Your Success,

Offshore Suppliers Directory

http://www.OffshoreSuppliersDirectory.com

YOUR NAME WAS SELECTED AS A PERSON OR ORGANIZATION INVOLVED WITH TECHNOLOGY. 
WE APOLOGIZE IF THIS EMAIL IS NOT APPLICABLE TO YOU. 
THIS IS A ONE TIME SUBMISSION.  
YOU DO NOT NEED TO SUBMIT A REMOVAL REQUEST.

(no subject)

[Valls Pellicer,Joan]

On Mon, 17 Sep 2001, Herman Oosthuysen wrote: 
> Howdy, 
>
> Well, it would be horribly slow when system logs etc in /var are written
to
> flash, but in practice you can write to Flash an incredible number of
times 
> before it will become unreliable. In my experience the first thing 
> that happens with age is that the erase cycles become slower and may
increase 
> from around 500ms to as much as 15s, but the device will still work
reliably. 
> This aging happens quite quickly actually - a few hundred erase cycles and
the 
> device will be significantly slower than when new. (I have seen and fixed
many 
> erase algorithms that do not allow sufficient erase time for old parts!). 
I've been looking for this agging problem in M-Systems (like system
integrator), Toshiba and Samsung (like Flash memory manufacturers) Web pages
and I can't find any information. Only in Samsung flash FAQs I've find the
following question (and answer):
Q2. Is program/erase time deteriorated with the increase of program/erase
cycles? 
 <<...OLE_Obj...>> 
A : Samsung's NAND Flash goes through an internal qualification process with
endurance up to 1M cycles. Since NAND Flash has superior endurance to other
Flash technology, the closing of cell threshold is not noticeable until 1M
cycles. The erase time does not change at all, regardless of endurance up to
1M cycles. The program time could take a little longer or does not change. 
 <<...OLE_Obj...>> 
Samsung says that their erasing cycle typical is 2 mseg. and maximal is 3
mseg., which differs a lot of your measurements. When you said 500 mseg.,
were you talking about format operations?
Do you know if this agging problems still occurs? Does it happen with a
specific vendor or product?

Joan Valls
jvp-sice-barcelona@dragados.com

(no subject)

[Roy Lauer]

I'm using DOC 2000, and the latest mtd sw from the
CVS.

Following is what I get a boot time (I do NOT yet boot
from the flash):

> Using configured DiskOnChip probe address 0xf0400000
> DiskOnChip 2000 found at address 0xF0400000
> Flash chip found: Manufacturer ID: 98, Chip ID: 73
(Toshiba TH58V128DC)
> 4 flash chips found. Total DiskOnChip size: 64 MiB
> mtd: Giving out device 0 to DiskOnChip 2000
> NFTL driver: nftlcore.c $Revision: 1.86 $,
nftlmount.c $Revision: 1.28 $
> NFTL_notify_add for DiskOnChip 2000
> NFTL_setup
> NFTL: UnitSizeFactor 0x00 detected. This violates
the spec but we think we know what it means...
> Cannot calculate an NFTL geometry to match size of
0x1ed20.
> Using C:986 H:16 S:8 (== 0x1ed00 sects)
> Partition check:
>  nftla: nftla1

The main problem (which cannot be seen above) is a
delay of about 90 seconds after 
"Flash chip found: ...". The system seems to stuck and
only after a timeout 0f 90 seconds it continues 
with "4 flash chips found...". What can be the reason
for that?

Other problems are UnitSizeFactor=0x00 and the size of
0x1ed20. The driver seems to manage with that. Is this
ok?

Any help will be apreciated.

Roy


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

(no subject)

[Áº²¨]

Hi,everybody
I would like to use mkfs.jffs to create a flash image I can burn into flash.

but the question is I don't know how to boot from this image.

the kernel of our system is 2.4.18 and the platform is ppc 8xx_io
series(ppc823)

How to setup jffs/mtd as the root filesystem/dev for our system?

Thanks,

   -- nielsen


 
 





--http://www.eyou.com
--Îȶ¨¿É¿¿µÄÃâ·Ñµç×ÓÐÅÏä  ÓïÒôÓʼþ  Òƶ¯ÊéÇ©  ÈÕÀú·þÎñ  ÍøÂç´æ´¢...ÒÚÓÊδ¾¡

(no subject)

[victor.martin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Thanks Charles, i think an IDE flash disk should have the same behaviour than 
an IDE disk, but one of them i think it works like a flash card, without 
internal journalling, so it makes incompatible with IDE spec. because of 
accessing times to the disk. 

The problem is that i can install blkmtd module with a device

insmod blkmtd device=/dev/fd0 for example

I can see it in /proc as mtd0

I have a mtdblock 0 with major -minor 31, 0

but when i try to use it, i can't use mtd0 and mtdblock0 and i don't know what 
is wrong.

I have tried to use /dev filesystem but when i use it my kernel doesn't boot

¿What can i do?


---------------------------------------------
Sent using Endymion MailMan.

(no subject)

[Jim Zeus]

Hi ,folks 
 
I am reading MTD code now , and I meet some problem

in the /drivers/mtd/chips/cfi_probe.c 

	/* Check each previous chip to see if it's an alias */
	for (i=0; i<cfi->numchips; i++) {
		/* This chip should be in read mode if it's one
		   we've already touched. */
		if (qry_present(map,chips[i].start,cfi)) {
			/* Eep. This chip also had the QRY marker. 
			 * Is it an alias for the new one? */
			cfi_send_gen_cmd(0xF0, 0, chips[i].start, map, cfi, cfi->device_type, NULL);

			/* If the QRY marker goes away, it's an alias */
			if (!qry_present(map, chips[i].start, cfi)) {
				printk(KERN_DEBUG "%s: Found an alias at 0x%x for the chip at 0x%lx\n",
				       map->name, base, chips[i].start);
				return 0;

/*******I have no idea that the following query command for*******/
/**********I think it will never happen*******************/}
			/* Yes, it's actually got QRY for data. Most 
			 * unfortunate. Stick the new chip in read mode
			 * too and if it's the same, assume it's an alias. */
			/* FIXME: Use other modes to do a proper check */
			cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL);
			
			if (qry_present(map, base, cfi)) {
				printk(KERN_DEBUG "%s: Found an alias at 0x%x for the chip at 0x%lx\n",
				       map->name, base, chips[i].start);
				return 0;
			} 
		}
	}
	


from the code I deduce that 
1. if send the query command twice , the "QRY" will disappear.
2. if send the query command onec, the "QRY" will always be there even you read it many times.
Is my conclusion right?
I know its a stupid question to hardware engineer, but I am a software engineer:<

Any help will be appreciated.


_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

(no subject)

[swimming_fisher]

Hi,
I make a image using mkfs.jffs2 v1.17 for i386,and burn it into my Assabet under redboot.But I fail to mount it using  "mount -t jffs2 /dev/mtdblock3 /mnt".It suggests:
 "jffs2_scan_empty():Empty block at 0xxxxxxx"
 "jffs2_scan_eraseblock():Magic bitmask not found at 0xxxxxxx"

Why?Please give me some advice!

(no subject)

[Jim Zeus]

Hi, David

I try hard but still cant find the reason why there is something wrong with my jffs2, which shows the following message:

jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020018: 0x734d instead

there are many of those when boot the kernel.

I divde the 2 flash chips(intel strataflash 28F128J3A, 16M) into 4 partition:

0x00000000-0x00020000 : "Bootloader"
0x00020000-0x00800000 : "Kernel"
0x00800000-0x01000000 : "Rootfs"
0x01000000-0x02000000 : "JFFS2"

and I erase all the 32M flash before kernel up, then burn the bootloader into "Bootloader",burn the kernel image into "Kernel",burn the jffs2.image into "Rootfs",and "JFFS2" is reserved so I can use it after the kernel is up.

I am confused by the message , because it is OK when I use jffs, is this a bug of jffs2?

Thank you for your help

Jim Zeus

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: (no subject)

[Jim Zeus]

thanks!  David, I have solved the problem! Ola, Ola ,Ola ......^O^

--- David Woodhouse <dwmw2@infradead.org> wrote:
>it'll be controlled by a GPIO pin somewhere. That would be board-specific.

it doesnt controlled by a GPIO,but just like that, its be controlled by a TC(traffic controller), no introduction about it in the document. 
But finally I beat the problem.

thank you for your help very much!

Jim Zeus(survivor from the problem)

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: (no subject)

[Jim Zeus]

--- David Woodhouse <dwmw2@infradead.org> wrote:
>
>zeusj@firstlinux.net said:
>> >I note you don't have a set_vpp() method. Do you need one?
>>  Sure, thanks! 
>
>Does that mean adding one actually makes it work?

aha! no , it doesnt means that, 
since I am not familiar to the intel strata flash 28f128, 
I thought you have a set_vpp() method for it and it can be transmitted to me for my file.
I think I misunderstood what you mean :)
but... I check all the doc I can find but they are all about the hardware:(so many pins...) ,do u have a set_vpp() method for 28f128? If it does, can u show me?

(disheartened)Jim Zeus 


_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: (no subject)

[David Woodhouse]

zeusj@firstlinux.net said:
> since I am not familiar to the intel strata flash 28f128,  I thought
> you have a set_vpp() method for it and it can be transmitted to me for
> my file. I think I misunderstood what you mean :) but... I check all
> the doc I can find but they are all about the hardware:(so many
> pins...) ,do u have a set_vpp() method for 28f128? If it does, can u
> show me? 

Vpp is the programming voltage pin of the flash chip. You have to put a
high voltage on this pin to allow programming - otherwise the chip will be 
in read only mode. Newer chips don't need such high voltages any more, but 
still have a Vpen (program enable) line which has much the same effect.

If the Vpen line to your flash chips isn't just hardwired to be on, then 
it'll be controlled by a GPIO pin somewhere. That would be board-specific.

--
dwmw2

Re: (no subject)

[Jim Zeus]

>Do you have the correct voltage applied to the Vpen line of the flash chip? 
>I note you don't have a set_vpp() method. Do you need one?

Sure, thanks!

>'insurance'? I expect JFFS2 to be more reliable than JFFS at this point. 
>That was, after all, most of the point in doing a complete rewrite :)

OK, I'll try it:)

and why the message show me that "Invalid ioctl 5401 (MEMGETINFO = 80204d01)
"? I find it is in the method mtd_ioctl , and its in the case "default".





_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: (no subject)

[David Woodhouse]

zeusj@firstlinux.net said:
> >I note you don't have a set_vpp() method. Do you need one?
>  Sure, thanks! 

Does that mean adding one actually makes it work?

> and why the message show me that "Invalid ioctl 5401 (MEMGETINFO = 80204d01)

It's a debugging message. I think the ioctl changed at some point in the 
distant past, and it was added so we could tell when people were using old 
tools. Someone (usually cat) did an ioctl on the mtdchar device to see 
whether it was a tty. It wasn't. 

--
dwmw2

Re: (no subject)

[Jim Zeus]

Hi, David
>Show me.

#include <linux/module.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <asm/io.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/map.h>
#include <linux/mtd/partitions.h>


#define WINDOW_ADDR 0x00000000
#define WINDOW_SIZE 0x01000000
#define BUSWIDTH 2

static struct mtd_info *mymtd;


static __u8 perseus_read8(struct map_info *map,unsigned long ofs)
{
	return __raw_readb(map->map_priv_1 + ofs);
}

static __u16 perseus_read16(struct map_info *map,unsigned long ofs)
{
	return __raw_readw(map->map_priv_1 + ofs);
}

static __u32 perseus_read32(struct map_info *map, unsigned long ofs)
{
	return __raw_readl(map->map_priv_1 + ofs);
}

static void perseus_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
{
	memcpy(to, (void *)(map->map_priv_1 + from), len);
}

static void perseus_write8(struct map_info *map, __u8 d, unsigned long adr)
{
	*(__u8 *)(map->map_priv_1 + adr) = d;
}

static void perseus_write16(struct map_info *map, __u16 d, unsigned long adr)
{
	*(__u16 *)(map->map_priv_1 + adr) = d;
}

static void perseus_write32(struct map_info *map, __u32 d, unsigned long adr)
{
	*(__u32 *)(map->map_priv_1 + adr) = d;
}

static void perseus_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len)
{
	memcpy((void *)(map->map_priv_1 + to), from, len);
}


static struct mtd_partition perseus_partition[]={
    { 
	    name: "Perseus Bootloader", 
	    offset: 0, 
	    size:   0x20000,
    },
    {
	   name:"Perseus Kernel",
	   offset:0x20000,
	   size:0x7e0000,
    },
    { 
	    name: "Perseus RamDisk", /////
	    offset: 0x800000,
	    size:0x800000, 
    }
};

#define NUM_PARTITIONS (sizeof(perseus_partition)/sizeof(perseus_partition[0]))


struct map_info perseus_map = {
	name: "Perseus StrataFlash map",
	size: WINDOW_SIZE,
	buswidth: BUSWIDTH,
	read8: perseus_read8,
	read16: perseus_read16,
	read32: perseus_read32,
	copy_from: perseus_copy_from,
	write8: perseus_write8,
	write16: perseus_write16,
	write32: perseus_write32,
	copy_to: perseus_copy_to,
};


static  int __init init_perseus(void)
{
	printk(KERN_NOTICE "Perseus Strataflash mapping:size %x at %x\n", WINDOW_SIZE, WINDOW_ADDR);
	perseus_map.map_priv_1 = (unsigned long)ioremap(WINDOW_ADDR, WINDOW_SIZE);
	printk("ZEUS:perseus_map.map_priv_1=%x\n",perseus_map.map_priv_1);
	if (!perseus_map.map_priv_1) {
		printk("Failed to ioremap\n");
		return -EIO;
	}
	
	mymtd = do_map_probe("cfi_probe", &perseus_map);
	if (mymtd) {
		mymtd->module = THIS_MODULE;
		add_mtd_partitions( mymtd, perseus_partition, NUM_PARTITIONS );

		add_mtd_device(mymtd);
		printk("ZEUS:right end of init_perseus(I mean flash)\n");
		return 0;
	}
	
	iounmap((void *)perseus_map.map_priv_1);
	printk("ZEUS:so its the wrong end of init_perseus(flash)\n");
	return -ENXIO;

}

mod_exit_t cleanup_perseus(void)
{
	if (mymtd) {
		del_mtd_device(mymtd);
		map_destroy(mymtd);
	}
	if (perseus_map.map_priv_1) {
		iounmap((void *)perseus_map.map_priv_1);
		perseus_map.map_priv_1 = 0;
	}
}

module_init(init_perseus);
module_exit(cleanup_perseus);

>Why JFFS not JFFS2?
sure I can use jffs2 too, but for more insurance , I use jffs:)

AND, after some modification, the phenomena I showed you in last mail has been disappeared . 
now, if i use "cp somefile /dev/mtd0", it said£º

MTD_open

MTD_ioctl

Invalid ioctl 5401 (MEMGETINFO = 80204d01)

MTD_write

Chip not ready for buffer write. Xstatus = 18, status = 98

cp: write: Input/output error

MTD_close

I think I have make the mtd up,but why I cant write?
and if I "mount /dev/mtdblock0 /jffs -t jffs",the kernel tell me mount failed and  said"Invalid argument"

BTW:
in my opinion, the "mtd_info" struct should be to describe a mtd device.
the "map_info" struct should be to describe a mapping area in memory which mapping to the mtd device(?) and WINDOW_ADDR is the PA of the mtd device(in my file) and map_info.map_priv_1 is a pointer to the VA of the mtd device.
Is that right? to be honest , I am really confused by these.I cant find any documentation to explain it . 

thank you for your help!

Jim Zeus


_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: (no subject)

[David Woodhouse]

zeusj@firstlinux.net said:
>  Chip not ready for buffer write. Xstatus = 18, status = 98

Do you have the correct voltage applied to the Vpen line of the flash chip? 
I note you don't have a set_vpp() method. Do you need one?

> sure I can use jffs2 too, but for more insurance , I use jffs:) 

'insurance'? I expect JFFS2 to be more reliable than JFFS at this point. 
That was, after all, most of the point in doing a complete rewrite :)

> BTW: in my opinion, the "mtd_info" struct should be to describe a mtd
> device.

Yes. 

> the "map_info" struct should be to describe a mapping area in
> memory which mapping to the mtd device(?)

The map_info struct is used just by the generic flash chip drivers, to 
access the memory bus on which the flash chip resides. 

> and WINDOW_ADDR is the PA of the mtd device(in my file) and 
> map_info.map_priv_1 is a pointer to the VA of the mtd device. 

Those are private information which are specific to your map driver. All 
that matters is that the read16 call reads a word from the correct offset 
on the flash chip. But yes, almost all the map drivers are mostly the same 
code, and this is how they do it.

> Is that right? to be honest , I am really
> confused by these.I cant find any documentation to explain it .  

Occasionally I try to write some documentation. Generally I look at it and 
think the code explains stuff better, so abandon it.

--
dwmw2

(no subject)

[Jim Zeus]

hello, David, thank you for answer my question before
now I've got other 2 questions

I've defined the CONFIG_MTD_BLOCK by choosing "Caching block device access to MTD device".I divided the flash (16 M)into 3 partitions: bootloader, kernel and jffs. and I have create several device file mtd0-mtd4(with major device number 80) and mtdblock0-mtdblock4(with major device number 31). 
now , the first problem appears
1. if I use "cat /proc/mtd" I just can find only one mtd device which is the first partition.

so I modify the file /drivers/mtd/maps/perseus-flash.c to divide the flash into only one partition : jffs (start: the start of flash size:8M) after the kernel up. I mount the mtdblock0 as jffs onto /jffs with command "mount -t jffs /dev/mtdblock0 /jffs". I didnt erase the flash or copy jffs image to mtd because I think mount can create the filesystem format automatically .
then the second problem appears 
2. after enter command mount , lots of meesage appear in the screen (which really scare me:-).and the kernel......died.

I guess maybe the mtd never up , so I reboot and cp some file to /dev/mtd0 , it said "cant open /dev/mtd0 : No such device",but when I try to cp the same file to /dev/mtdblock0 , the message look like what showed when I mount appears
and here is the message:

# mount /dev/mtdblock0 jffs -t jffs

mtdblock_open

ok

JFFS: Trying to mount device 1f:00.

jffs_build_fs()

jffs_create_control()

jffs_build_begin()

  fmc->flash_size = 8388608 bytes

jffs_scan_flash(): start pos = 0x0, end = 0x800000

check_partly_erased_sector():checking sector which contains offset 0x0 for flipp
ing bits..

flash_safe_read(c001a160, 00000000, c0b15000, 00001000)

Unable to handle kernel NULL pointer dereference at virtual address 00000000

pgd = c0b78000

*pgd = 10b9d001, *pmd = 10b9d001, *pte = 00000000, *ppte = 00000000

Internal error: Oops: 0

CPU: 0

pc : [<00000000>]    lr : [<c00b590c>]    Not tainted

sp : c0b7fc34  ip : fffffffe  fp : c0140528

r10: c001b6dc  r9 : 00000080  r8 : c0b7e000

r7 : c001b6a0  r6 : 00000000  r5 : c0135850  r4 : c0b7fc54

r3 : 00001000  r2 : 00000000  r1 : c0b15000  r0 : c0135850

Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  Segment user

Control: 3177  Table: 10B78000  DAC: 00000015

Process mount (pid: 16, stackpage=c0b7f000)

Stack:
>>....here is many address and value 


Backtrace: frame pointer underflow

Function entered at [<fffffff1>] from [<00000000>]

Backtrace aborted due to bad frame pointer <c0140528>

Code: bad PC value.

Kernel panic: Aiee, killing interrupt handler!

In interrupt handler - not syncing



I am just a poor programmer who want to mount a file system, cant u help me?
your help was and will be appreciated .

Jim Zeus(really confused)



_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: (no subject)

[David Woodhouse]

zeusj@firstlinux.net said:
> so I modify the file /drivers/mtd/maps/perseus-flash.c 

Show me.

>  # mount /dev/mtdblock0 jffs -t jffs 

Why JFFS not JFFS2?

--
dwmw2

Re: (no subject)

[Allen Curtis]

We had the same problem where the /dev/ entries where not included in the
JFFS image. In our case I ran MAKEDEV to recreate the missing devices.

The version of JFFS we are using came with HHL Professional 2.0. Based on
the CVS versions, it looks like it is the original code release.

(no subject)

[Sheela Kashyap]

Hi,

I am relatively new to Linux and definitely new to MTD/JFFS. We have
a motorola 8xx board, the boot loader used is ppcboot. We are
currently using NFS as the root file system.  The kernel has been
compiled with the right JFFS and MTD options. I am able to erase the
MTD device, copy the file system on to it and mount and umount
multiple times without any problems. The kernel is in the flash.  We
are using Dhcp to figure out its IP address. 

When I set the bootargs in ppcboot to "root=/dev/mtdblock1 rw" or
"root=/dev/mtdblock1 rw ip=10.100.4.44" and try booting the kernel,
everything is fine till it comes time to mount the root FS.It still
seems to try and go out on the net. This is the trace I see. I have
cut out some parts to reduce the clutter. 

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


Initializing...
  CPU:   XPC860xxZPnnD4 at 80 MHz: 16 kB I-Cache 8 kB D-Cache FEC
present
  Board:   DRAM:  About to program UPMB... finished programming UPMB
Setting value for MPTPR to 400
Run precharge command for each chip-select used
<snip...>

cas latensies supported          3  2    
<snip...>

ppcboot->printenv
bootdelay=10
baudrate=19200
ipaddr=10.0.0.77
serverip=10.0.0.128
bootcmd=bootm 28080000
stdin=serial
stdout=serial
stderr=serial
bootargs=root=/dev/mtdblock1 rw ip=10.100.4.44 

SWSE(bootrom)->bootm 28080000
## Booting Linux kernel at 28080000 ...
   Image Name:   HHL 2.0 for SWSE version 0.005
   Created:      2001-12-06   5:07:40
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    550042 Bytes = 537 kB = 0 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Transferring control to Linux (at address 00000000) ...
Linux version 2.4.2_hhl20 (rick@localhost.localdomain) (gcc version
2.95.3 20010
315 (release/MontaVista)) #6 Wed Dec 5 21:03:08 PST 2001  
On node 0 totalpages: 65536
zone(0): 65536 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock1 rw ip=10.100.4.44 
Decrementer Frequency = 300000000/60 

<snip....>

JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
loop: loaded (max 8 devices)
physmap flash device: 1780000 at 28880000
Physically mapped flash: Found 2 x16 CFI devices at location 0 in 16
bit mode
JEDEC ID: 89 18
cstm_cfi_jedec flash device: 1780000 at 28880000
MTD flash: Found 2 x16 CFI devices at location 0 in 16 bit mode
JEDEC ID: 89 18
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
Sending BOOTP requests............. timed out!
IP-Config: Auto-configuration of network failed.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
request_module[block-major-2]: Root fs not mounted
VFS: Cannot open root device "mtdblock1" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
Rebooting in 180 seconds..                         

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

The "Sending BOOTP requests" line is what I don't understand. The
kernel obviously does not figure out that the root filesystem to be
used is 'jffs'. How can I get it to do that? Do I need to make
changes to some kernel files? Or is it that I need to change the
kernel so that it detects the MTD block device first and figures out
the filesystem?

Any help is greatly appreciated. 

Thanks,
Sheela.

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: (no subject)

[David Woodhouse]

sheela_kashyap@yahoo.com said:
> everything is fine till it comes time to mount the root FS.It still
> seems to try and go out on the net. This is the trace I see. I have
> cut out some parts to reduce the clutter.  

A kernel that old doesn't have 'mtdblock' in the root_dev_names array in 
init/main.c. Add it.

--
dwmw2

Re: (no subject)

[Sheela Kashyap]

Thank you. I was the missing the root dev as you rightly guessed. I
am now successfully booting off mtd/jffs.

While creating the jffs image using mkfs.jffs, I noticed that it did
not create all the /dev entries for me. I had to use 'mknod' and
create it manually on the target. What is the easiest way for me to
create a target image with all the /dev files?

Thanks,
Sheela.

--- David Woodhouse <dwmw2@infradead.org> wrote:
> 
> sheela_kashyap@yahoo.com said:
> > everything is fine till it comes time to mount the root FS.It
> still
> > seems to try and go out on the net. This is the trace I see. I
> have
> > cut out some parts to reduce the clutter.  
> 
> A kernel that old doesn't have 'mtdblock' in the root_dev_names
> array in 
> init/main.c. Add it.
> 
> --
> dwmw2
> 
> 


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: (no subject)

[David Woodhouse]

sheela_kashyap@yahoo.com said:
>  While creating the jffs image using mkfs.jffs, I noticed that it did
> not create all the /dev entries for me. I had to use 'mknod' and
> create it manually on the target. What is the easiest way for me to
> create a target image with all the /dev files? 

Er, not sure - mkfs.jffs ought to work. Why are you using jffs not jffs2?

--
dwmw2

Re: (no subject)

[Sheela Kashyap]

Hmm... I will try mkfs.jffs again in that case. 

Well, by the time I was involved with the project, there had been
some work done on using jffs. But we'll be moving to Jffs2 in a short
while.

Thank you for your help.

Sheela.

--- David Woodhouse <dwmw2@infradead.org> wrote:
> 
> sheela_kashyap@yahoo.com said:
> >  While creating the jffs image using mkfs.jffs, I noticed that it
> did
> > not create all the /dev entries for me. I had to use 'mknod' and
> > create it manually on the target. What is the easiest way for me
> to
> > create a target image with all the /dev files? 
> 
> Er, not sure - mkfs.jffs ought to work. Why are you using jffs not
> jffs2?
> 
> --
> dwmw2
> 
> 


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: (no subject)

[David Woodhouse]

sheela_kashyap@yahoo.com said:
> Hmm... I will try mkfs.jffs again in that case.  

If it fails, can you cut down the directory tree you're putting into the
JFFS image to the smallest testcase that shows the problem (like the /dev
directory and a single device node), then send me both a tarball and the
JFFS image of it?

Where did you get your mkfs.jffs from? 

--
dwmw2

Re: (no subject)

[Sheela Kashyap]

The utilities had already been downloaded by someone else. I am not
sure where they got the package from. I will download the mtd-utils
package again and build the image. 

The 'Id' string in the mkfs.jffs.c file is as follows:

$Id: mkfs.jffs.c,v 1.11 2001/03/11 11:44:42 dwmw2 Exp $

Sheela.

--- David Woodhouse <dwmw2@infradead.org> wrote:
> 
> sheela_kashyap@yahoo.com said:
> > Hmm... I will try mkfs.jffs again in that case.  
> 
> If it fails, can you cut down the directory tree you're putting
> into the
> JFFS image to the smallest testcase that shows the problem (like
> the /dev
> directory and a single device node), then send me both a tarball
> and the
> JFFS image of it?
> 
> Where did you get your mkfs.jffs from? 
> 
> --
> dwmw2
> 
> 


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

(no subject)

[ilatypov]

There are two concerns as I see:

1. I don't know too much about the FTL layer.  The patch to the GRUB boot
loader for booting off DiskOnChip will recognize NFTL block device access
layer only.  The corresponding format command is
   nftl_format /dev/mtd0 98304
provided that the bootloader itself takes the first 12 * 8K bytes.  Make
sure that the nftl drivers were not loaded or activated before issuing
this command.  The device names corresponding to the partitions of
DiskOnChip are /dev/nftla*, of course.

2. The GRUB firmware might not include the DiskOnChip patch.  I suppose
you copied the pre_stage2 file from the GRUB tree to the MTD tree and ran
the make command to generate the grub_firmawre file.  I also understand
that the firmware was stored onto DiskOnChip by launching this command:
    doc_loadbios /dev/mtd0 grub_firmware

Thank you,

Ilguiz

On Wed, 19 Dec 2001, dharmendra.t bavale wrote:

>   I tried all mke2fs /dev/flta1.
[..]
> grub>root (dc0,1)
> The selected disk does not exist
[..]

RE: (no subject)

[Siders, Keith]

-> Why do you want to write the compressed version to the 
-> filesystem? Just so 
-> that you can use gzip -9 and get better compression?
-> 
-> --
-> dwmw2
-> 

In my application I will receive the image already zlib compressed. I was
hoping to skip having to take up memory with both compressed and
uncompressed images prior to writing to JFFS2. But alas, since it's
necessary, I shall malloc(new_space), uncompress(new_space, old_space) ,
free(old_space), fwrite(new_space), and finally free(new_space).

ks

(no subject)

[Siders, Keith]

I have a requirement to store compressed binary images with the intent that
they will be uncompressed when loaded into memory. Can JFFS2 store data
without compression, in this case previously compressed data, and still
automatically uncompress it when retrieved from the filesystem?

Keith Siders
Software Engineer
 Toshiba America Consumer Products, Inc.
Advanced Television Technology Center
801 Royal Parkway, Suite 100
Nashville, Tennessee 37214
Phone: (615) 257-4050
Fax:   (615) 453-7880

Re: (no subject)

[David Woodhouse]

keith_siders@toshibatv.com said:
> I have a requirement to store compressed binary images with the intent
> that they will be uncompressed when loaded into memory. Can JFFS2
> store data without compression, in this case previously compressed
> data, and still automatically uncompress it when retrieved from the
> filesystem?

No, if you want JFFS2 to decompress it, you have to let JFFS2 compress it - 
by putting the uncompressed version into the filesystem instead of the 
compressed version.

Why do you want to write the compressed version to the filesystem? Just so 
that you can use gzip -9 and get better compression?

--
dwmw2

(no subject)

[zud sdf]

subscribe mtd

(no subject)

[zud sdf]

subscribe mtd

(no subject)

[zud sdf]

subscribe

Re: (no subject)

[David Woodhouse]

zydlaula@hotmail.com said:
>  subscribe

Where did you find details of this list?

I thought that all references to it were clearly marked in capital letters
'DO NOT SEND SUBSCRIPTION REQUESTS TO THE LIST'. 

If you have found a reference to the list which is not clearly marked as 
such, please could you let me know where it is so that I can fix it?


--
dwmw2

(no subject)

[Zydla Tsui]

subscribe

(No Subject)

[simon.munton]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: Type: text/plain, Size: 2038 bytes --]

Back in January, I posted a similar question about the unlock bypass mode.

Unfortunately, I've been busy on other things since then, so I've not been able to follow up on it.

The chip needs to be locked before going into the unlock bypass mode and unlocked when it comes out of this mode. It would probably be best to have a couple of helper functions to enter and exit bypass mode. 

Also, in do_write_oneword, it should skip the wait for the chip to be ready and not set the state back to ready if fast is set true.

I've also noticed that CFI_DEVICETYPE_X8 is used in several places, where it seems that cfi->device_type should be used instead (one instance is in issuing the enter bypass mode commands).

Something along the lines of the attached diff (haven't even tried compiling it, so it may be buggy)

Simon

> -----Original Message-----
> From: Brenk, Rudger van [mailto:rudger.van.brenk@intersil.com]
> Sent: 23 April 2001 2:56 pm
> To: 'mtd@infradead.org'
> Subject: Problems using fast write in cfi_cmdset_0002.c
> 
> 
> While building a uClinux environment using MTD and JFFS on an 
> AMD AM29DL323
> device (Kernel 2.0.38). I encountered some problems using the 
> cfi_cmdset_0002.c,
> when ever the fast write option is used the flash is put in a 
> 'unlock bypass
> mode' and starts writing bytes to flash. 
> 
> This is OK but in between byte writes the chip state is set 
> back to FL_READY,
> and available for other threads to access. If an other 
> threads accesses the
> flash chip it's still in 'unlock bypass mode' and will not 
> accept other
> commands/or even worse when this thread schedules out the 
> byte write program
> will continue when the device isn't anymore in 'unlock bypass mode'!!
> 
> Is there anybody else experiencing problems like this?
> 
> Thanks,
> 
> Rudger 
> 
> 
> Rudger.van.Brenk@intersil.com
> 
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
> 




--------------------
talk21 your FREE portable and private address on the net at http://www.talk21.com

[-- Attachment #3: cfi_cmdset_0002.c.diff --]
[-- Type: text/plain, Size: 7140 bytes --]

--- cfi_cmdset_0002.c	Tue Apr 17 15:13:54 2001
+++ C:\TEMP/cfi_cmdset_0002.c	Tue Apr 24 10:46:22 2001
@@ -304,7 +304,7 @@
  retry:
 	cfi_spin_lock(chip->mutex);
 
-	if (chip->state != FL_READY){
+	if (!fast && chip->state != FL_READY){
 	        printk("Waiting for chip to write, status = %d\n", chip->state);
 		set_current_state(TASK_UNINTERRUPTIBLE);
 		add_wait_queue(&chip->wq, &wait);
@@ -331,9 +331,9 @@
 		cfi_send_gen_cmd(0xA0, 0, chip->start, map, cfi->interleave, cfi->device_type, NULL);
 	}
 	else {
-	        cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-	        cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-	        cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	        cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
+	        cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, cfi->device_type, NULL);
+	        cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
 	}
 
 	cfi_write(map, datum, adr);
@@ -365,13 +365,79 @@
 		ret = -EIO;
 	}       
 	DISABLE_VPP(map);
-	chip->state = FL_READY;
-	wake_up(&chip->wq);
+        if (!fast) {
+	        chip->state = FL_READY;
+	        wake_up(&chip->wq);
+        }
 	cfi_spin_unlock(chip->mutex);
 	
 	return ret;
 }
 
+static void cfi_enter_bypass_mode (struct mtd_info *mtd, int chipnum)
+{
+	struct map_info *map = mtd->priv;
+	struct cfi_private *cfi = map->fldrv_priv;
+        unsigned long chipstart;
+        struct flchip *chip = &cfi->chips[chipnum];
+	unsigned long timeo = jiffies + HZ;
+	DECLARE_WAITQUEUE(wait, current);
+
+ retry:
+	cfi_spin_lock(chip->mutex);
+
+	if (chip->state != FL_READY){
+	        printk("Waiting for chip to write, status = %d\n", chip->state);
+		set_current_state(TASK_UNINTERRUPTIBLE);
+		add_wait_queue(&chip->wq, &wait);
+                
+		cfi_spin_unlock(chip->mutex);
+
+		schedule();
+		remove_wait_queue(&chip->wq, &wait);
+		printk("Wake up to write:\n");
+#if 0
+		if(signal_pending(current))
+			return -EINTR;
+#endif
+		timeo = jiffies + HZ;
+
+		goto retry;
+	}	
+
+	chip->state = FL_WRITING;
+
+        chipstart = cfi->chips[chipnum].start;
+
+	/* Go into unlock bypass mode */
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x20, cfi->addr_unlock1, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+
+	cfi_spin_unlock(chip->mutex);
+}
+
+static void cfi_exit_bypass_mode (struct mtd_info *mtd, int chipnum)
+{
+	struct map_info *map = mtd->priv;
+	struct cfi_private *cfi = map->fldrv_priv;
+        unsigned long chipstart;
+        struct flchip *chip = &cfi->chips[chipnum];
+
+	chipstart = cfi->chips[chipnum].start;
+
+	cfi_spin_lock(chip->mutex);
+
+	/* Come out of bypass mode */
+	cfi_send_gen_cmd(0x90, 0, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x00, 0, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+
+	chip->state = FL_READY;
+	wake_up(&chip->wq);
+
+        cfi_spin_unlock(chip->mutex);
+}
+
 static int cfi_amdstd_write (struct mtd_info *mtd, loff_t to , size_t len, size_t *retlen, const u_char *buf)
 {
 	struct map_info *map = mtd->priv;
@@ -425,10 +491,10 @@
 		}
 	}
 	
-	/* Go into unlock bypass mode */
-	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-	cfi_send_gen_cmd(0x20, cfi->addr_unlock1, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+        if (cfi->fast_prog) {
+  	        /* Go into unlock bypass mode */
+                cfi_enter_bypass_mode (mtd, chipnum);
+        }
 
 	/* We are now aligned, write as much as possible */
 	while(len >= CFIDEV_BUSWIDTH) {
@@ -448,8 +514,7 @@
 		if (ret) {
 			if (cfi->fast_prog){
 				/* Get out of unlock bypass mode */
-				cfi_send_gen_cmd(0x90, 0, chipstart, map, cfi->interleave, cfi->device_type, NULL);
-				cfi_send_gen_cmd(0x00, 0, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+                                cfi_exit_bypass_mode (mtd, chipnum);
 			}
 			return ret;
 		}
@@ -462,8 +527,7 @@
 		if (ofs >> cfi->chipshift) {
 			if (cfi->fast_prog){
 				/* Get out of unlock bypass mode */
-				cfi_send_gen_cmd(0x90, 0, chipstart, map, cfi->interleave, cfi->device_type, NULL);
-				cfi_send_gen_cmd(0x00, 0, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+                                cfi_exit_bypass_mode (mtd, chipnum);
 			}
 
 			chipnum ++; 
@@ -473,17 +537,14 @@
 			chipstart = cfi->chips[chipnum].start;
 			if (cfi->fast_prog){
 				/* Go into unlock bypass mode for next set of chips */
-				cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-				cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-				cfi_send_gen_cmd(0x20, cfi->addr_unlock1, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+                                cfi_enter_bypass_mode (mtd, chipnum);
 			}
 		}
 	}
 
 	if (cfi->fast_prog){
 		/* Get out of unlock bypass mode */
-		cfi_send_gen_cmd(0x90, 0, chipstart, map, cfi->interleave, cfi->device_type, NULL);
-		cfi_send_gen_cmd(0x00, 0, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+                cfi_exit_bypass_mode (mtd, chipnum);
 	}
 
 	if (len & (CFIDEV_BUSWIDTH-1)) {
@@ -546,11 +607,11 @@
 
 	adr += chip->start;
 	ENABLE_VPP(map);
-	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-	cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
-	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, cfi->device_type, NULL);
 	cfi_write(map, CMD(0x30), adr);
 	
 	timeo = jiffies + (HZ*20);

Re: (No Subject)

[David Woodhouse]

simon.munton@talk21.com said:
> Back in January, I posted a similar question about the unlock bypass
> mode.

> Unfortunately, I've been busy on other things since then, so I've not
> been able to follow up on it.

Yes, it's currently broken. It should probably be disabled unless someone 
cares sufficiently to fix it, and can show that it's actually an advantage to 
disable interrupts in return for the (probably minimal) speedup.



simon.munton@talk21.com said:
>  I've also noticed that CFI_DEVICETYPE_X8 is used in several places,
> where it seems that cfi->device_type should be used instead (one
> instance is in issuing the enter bypass mode commands).

The unlock addresses are set with that fact taken into consideration. The 
reason is that some devices with DEVICETYPE_16 need unlock addresses which 
are odd, for which the 'multiply by two' doesn't help us much :)


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: (No Subject)

[Masami Komiya]

David Woodhouse wrote:
> 
> simon.munton@talk21.com said:
> >  I've also noticed that CFI_DEVICETYPE_X8 is used in several places,
> > where it seems that cfi->device_type should be used instead (one
> > instance is in issuing the enter bypass mode commands).
> 
> The unlock addresses are set with that fact taken into consideration. The
> reason is that some devices with DEVICETYPE_16 need unlock addresses which
> are odd, for which the 'multiply by two' doesn't help us much :)

Our hardware has one flash memory in 16bit mode. CPU is SH4 of Hitachi.
That is 32bit type CPU and can connect the device in 16bit mode.
In this case, interleave is 1 and bus width is 2.

Before using  cfi->device_type instead of CFI_DEVICETYPE_X8
MTD driver cannot calculate the address of the CFI command correctly.

Masami Komiya


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: (No Subject)

[David Woodhouse]

mkomiya@crossnet.co.jp said:
>  Our hardware has one flash memory in 16bit mode. CPU is SH4 of
> Hitachi. That is 32bit type CPU and can connect the device in 16bit
> mode. In this case, interleave is 1 and bus width is 2.

> Before using  cfi->device_type instead of CFI_DEVICETYPE_X8 MTD driver
> cannot calculate the address of the CFI command correctly.

Which CFI command is being sent to the wrong address? The unlock commands?

The cfi_cmdset_0002 code passes CFI_DEVICETYPE_X8 to the cfi_send_gen_cmd 
function when doing the unlock cycles, instead of cfi->device_type, because 
the unlock addresses (cfi->addr_unlock[12]) are supposed to have been 
pre-calculated so they don't need shifting.

I think that cfi_probe.c calculates the correct addresses for 8-bit chips 
and for 16-bit chips in 8-bit mode. I suspect that we may be calculating 
the wrong unlock addresses for 16-bit chips which are actually in 16-bit 
mode.

Your patch changes 8-bit devices to use (0xaaa,0x555) and changes _all_ 
16-bit devices to use (0x555,0x2aa). I suspect that you should be changing 
only the 16-bit devices _in 16-bit mode_ to use 0x555, 0x2aa, while leaving 
the 16-bit devices in 8-bit mode as they were.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: (No Subject)

[Masami Komiya]

David Woodhouse wrote:
> 
> mkomiya@crossnet.co.jp said:
> >  Our hardware has one flash memory in 16bit mode. CPU is SH4 of
> > Hitachi. That is 32bit type CPU and can connect the device in 16bit
> > mode. In this case, interleave is 1 and bus width is 2.
> 
> > Before using  cfi->device_type instead of CFI_DEVICETYPE_X8 MTD driver
> > cannot calculate the address of the CFI command correctly.
> 
> Which CFI command is being sent to the wrong address? The unlock commands?

Yes, unlock command in do_write_oneword() when the unalined data
is written.
 
> The cfi_cmdset_0002 code passes CFI_DEVICETYPE_X8 to the cfi_send_gen_cmd
> function when doing the unlock cycles, instead of cfi->device_type, because
> the unlock addresses (cfi->addr_unlock[12]) are supposed to have been
> pre-calculated so they don't need shifting.
> 
> I think that cfi_probe.c calculates the correct addresses for 8-bit chips
> and for 16-bit chips in 8-bit mode. I suspect that we may be calculating
> the wrong unlock addresses for 16-bit chips which are actually in 16-bit
> mode.

When the unalined data is written in 16-bit mode,
word mode command is needed with 1bit shift for one interleave.

> Your patch changes 8-bit devices to use (0xaaa,0x555) and changes _all_
> 16-bit devices to use (0x555,0x2aa). I suspect that you should be changing
> only the 16-bit devices _in 16-bit mode_ to use 0x555, 0x2aa, while leaving
> the 16-bit devices in 8-bit mode as they were.

I was misunderstanding about the definitions in cfi_probe_chip().
Attached patch is for cfi_cmdset_0002.c applied simon's patch.


*** cfi_probe.c.org	Wed Apr 18 17:26:35 2001
--- cfi_probe.c	Wed Apr 25 20:52:03 2001
***************
*** 202,209 ****
  		cfi->addr_unlock2=0x2aa; 
  		break;
  	case CFI_DEVICETYPE_X16:
! 		cfi->addr_unlock1=0xaaa; 
! 		cfi->addr_unlock2=0x555; 
  		break;
  	case CFI_DEVICETYPE_X32:
  		cfi->addr_unlock1=0x1555; 
--- 202,215 ----
  		cfi->addr_unlock2=0x2aa; 
  		break;
  	case CFI_DEVICETYPE_X16:
! 		if (map->buswidth == 2) {
! 			cfi->addr_unlock1=0x555; 
! 			cfi->addr_unlock2=0x2aa; 
! 		}
! 		else {
! 			cfi->addr_unlock1=0xaaa; 
! 			cfi->addr_unlock2=0x555; 
! 		}
  		break;
  	case CFI_DEVICETYPE_X32:
  		cfi->addr_unlock1=0x1555;


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: (No Subject)

[David Woodhouse]

mkomiya@crossnet.co.jp said:
>  I was misunderstanding about the definitions in cfi_probe_chip().
> Attached patch is for cfi_cmdset_0002.c applied simon's patch. 

Looks like you mean it's for cfi_cmdset_0002.c _without_ Simon's patch. It 
looks fine to me - I'll give it a day or so for people to object before I 
apply it though :)

Thanks.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: (No Subject)

[Masami Komiya]

David Woodhouse wrote:
> 
> mkomiya@crossnet.co.jp said:
> >  I was misunderstanding about the definitions in cfi_probe_chip().
> > Attached patch is for cfi_cmdset_0002.c applied simon's patch.
> 
> Looks like you mean it's for cfi_cmdset_0002.c _without_ Simon's patch. It
> looks fine to me - I'll give it a day or so for people to object before I
> apply it though :)

Last patch needs Simon's patch. If you does not want to change
CFI_DEVICETYPE_X8 to cfi->device_type, please use following.

(twice 0x2aa is equal to 0x554 :-)

*** cfi_probe.c.org	Wed Apr 18 17:26:35 2001
--- cfi_probe.c	Wed Apr 25 21:39:23 2001
***************
*** 202,209 ****
  		cfi->addr_unlock2=0x2aa; 
  		break;
  	case CFI_DEVICETYPE_X16:
! 		cfi->addr_unlock1=0xaaa; 
! 		cfi->addr_unlock2=0x555; 
  		break;
  	case CFI_DEVICETYPE_X32:
  		cfi->addr_unlock1=0x1555; 
--- 202,214 ----
  		cfi->addr_unlock2=0x2aa; 
  		break;
  	case CFI_DEVICETYPE_X16:
! 		cfi->addr_unlock1=0xaaa;
! 		if (map->buswidth == 2) {
! 			cfi->addr_unlock2=0x554; 
! 		}
! 		else {
! 			cfi->addr_unlock2=0x555; 
! 		}
  		break;
  	case CFI_DEVICETYPE_X32:
  		cfi->addr_unlock1=0x1555;


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: (No Subject)

[David Woodhouse]

mkomiya@crossnet.co.jp said:
! 		if (map->buswidth == 2) {
! 			cfi->addr_unlock2=0x554; 
! 		}
! 		else {
! 			cfi->addr_unlock2=0x555; 
! 		}

Aha. Yes, it all seems to make sense now.... I think :)

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org