headers
David Woodhouse | 1 Jun 2000 02:49
Favicon

MTD CVS update: 'mtd/grub doc_stage1.S'

Update of /home/cvs/mtd/grub
In directory infradead.org:/tmp/cvs-serv17114

Modified Files:
	doc_stage1.S 
Log Message:
Fix the setup of the INT 19h handler so we are no longer using the
previously initialised %es register as the segment address of the vector.

Also fix the segment registers in the actual copy, so that we put the 
right stuff in place, rather than starting our copy at 0000:0000.

I can hardly believe that this has ever worked. It seems that by an
amazing coincidence, the IPL ROM sets %es to 0x2000 before jumping to
the code - so even though we were using an uninitialised segment
address pointer, and our copy of the IRQ handler to the _intended_
location went AWOL, we ended up with the INT 19h handler pointing at
the location in memory at which the IPL ROM loads the SPL, before the
SPL relocates itself into the reserved area.

So as long as nothing touched that memory later in the startup sequence,
it would still be there when the BIOS got round to calling INT 19h to
boot. This is why it worked on simple machines like my 386 testbed, but
nothing else.

I hereby declare myself to be Today's Official Mr F*** All Good.

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Woodhouse | 1 Jun 2000 03:00
Favicon

Re: MTD CVS update: 'mtd/grub doc_stage1.S'


dwmw2 <at> infradead.org said:
>  Also fix the segment registers in the actual copy, so that we put the
>  right stuff in place, rather than starting our copy at 0000:0000. 

It seems I lied about this one - that was right in the previous version, 
but I removed a 'push cs; pop ds' pair with some debugging cruft and didn't 
remember that fact when I later noticed that they ought to be there for 
other reasons. The perils of asm hacking at 2am :)

So I'm not _quite_ as stupid as I thought. Close, though. It _was_ 
copying the handler to the right place, but just pointing the IRQ vector at 
the old location.

Oh well, it ought to work now. Now we just need to finish hacking Grub so 
it can boot a kernel off the NFTL. So far, it finds the hardware and scans 
if for an NFTL Media Header. The rest should be simple.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Jun 2000 17:12
Favicon

MTD CVS update: 'mtd/kernel Config.in'

Update of /home/cvs/mtd/kernel
In directory infradead.org:/tmp/cvs-serv25081

Modified Files:
	Config.in 
Log Message:
Fix typo in Config.in

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Jun 2000 17:18
Favicon

MTD CVS update: 'mtd/kernel Makefile'

Update of /home/cvs/mtd/kernel
In directory infradead.org:/tmp/cvs-serv25173

Modified Files:
	Makefile 
Log Message:
PMC551_DRAM_BUG only needs to be defined for pmc551.o, not for the whole
directory.

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Jun 2000 18:04
Favicon

MTD CVS update: 'mtd/kernel mtdcore.c'

Update of /home/cvs/mtd/kernel
In directory infradead.org:/tmp/cvs-serv25669

Modified Files:
	mtdcore.c 
Log Message:
Export the symbols which we are supposed to provide to other modules

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Jun 2000 18:25
Favicon

JFFS - ready for submission into 2.[34]?

I'm fairly happy with the current state of the MTD code - my remaining
niggles are lack of certain functionality rather than stupidities in the
code, so I'm submitting it to Alan in the hope that he'll include it into
his 2.4.0-test1-ac kernels - after all, it's "only new drivers."

If I get away with that, it would be nice to get JFFS in too - Alex, is the 
code in our CVS ready for that or should we hold off for a while longer?

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 12 comments |
headers
Alexander Larsson | 1 Jun 2000 19:13
Picon

Re: JFFS - ready for submission into 2.[34]?

On Thu, 1 Jun 2000, David Woodhouse wrote:

> I'm fairly happy with the current state of the MTD code - my remaining
> niggles are lack of certain functionality rather than stupidities in the
> code, so I'm submitting it to Alan in the hope that he'll include it into
> his 2.4.0-test1-ac kernels - after all, it's "only new drivers."
 Yes! Yes!

> If I get away with that, it would be nice to get JFFS in too - Alex, is the 
> code in our CVS ready for that or should we hold off for a while longer?

I will look at it tomorrow at work (Haven't had time before). All
functionallity should be implemented and work. I haven't done any larger
scale testing yet though, so it's definitely experimental. There is a bug
in the mkfs.jffs program though. It generates too big nodes (which the
jffs code can't handle) for files that are larger than 64k.

/ Alex

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 9 comments |
headers
Alexander Larsson | 2 Jun 2000 10:04
Picon

Re: JFFS - ready for submission into 2.[34]?

On Fri, 2 Jun 2000, David Woodhouse wrote:

> 
> alex <at> cendio.se said:
> > Possibly. But i suppose the real reason is that the current way would
> > be the way you normally use it in embedded systems (like those axis
> > are doing). You generate your root fs on the build machine, create a
> > jffs image and download it into the flash memory of the target system.
> 
> Yeah, but it's still not imperative to create the image in one go from mkfs.
Actually I'm not sure jffs needs a special mkfs at all. An empty flash
should work just as well. It will just creates a root node at mount time.

> We create our Linux (and even NT) workstations by just taking a dump of the
> filesystem after installation, and dd'ing that onto the target. That would
> work just as well for JFFS.
That doesn't work well in a factory producing thousands of cameras a
week.

> Either way - once we get it working on NAND flash, and having to map round 
> bad blocks, we're going to have difficulties with just dumping an image on
> to the flash anyway. 

Well. The bad block remapping can certainly be problematic since the
journal won't be linear anymore. I suppose the lower layer mtd driver does
the remapping automatically?

/ Alex

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Woodhouse | 2 Jun 2000 10:21
Favicon

Re: JFFS - ready for submission into 2.[34]?


alex <at> cendio.se said:
>  I will look at it tomorrow at work (Haven't had time before). All
> functionallity should be implemented and work. I haven't done any
> larger scale testing yet though, so it's definitely experimental.

Fine. We all know how to get larger scale testing :)

> There is a bug in the mkfs.jffs program though. It generates too big
> nodes (which the jffs code can't handle) for files that are larger
> than 64k.

I saw the dicussion about this, and was wondering why mkfs.jffs actually 
populates the filesystem at all. Is it because it's more space-efficient to 
do it all at once than it would be to mkfs, mount and populate it?

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 8 comments |
headers
Alexander Larsson | 2 Jun 2000 10:24
Favicon

MTD CVS update: 'mtd/fs/jffs inode.c intrep.c'

Update of /home/cvs/mtd/fs/jffs
In directory infradead.org:/tmp/cvs-serv1341

Modified Files:
	inode.c intrep.c 
Log Message:
Update to 2.4.0-test1-ac7 (any other ac version probably works too.)

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org
Permalink | Reply | 0 comments |

Gmane