DiskOnChip for PowerPC embedded system.

DiskOnChip for PowerPC embedded system.

[Brendan J Simon]

I wish to use a DiskOnChip2000 device for PowerPC embedded system
running Linux, but have a few questions.

1) Do I need to reprogram the firmware on the DOC device or is the Linux
driver software all I need ?

2) Can I use the firmware/ROM space to put own bootloader code ?  How
big is it ?

3) Is there an FAQ for DOCs that aren't Intetl PC specific ?

Thanks,
Brendan Simon.




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

Re: DiskOnChip for PowerPC embedded system.

[David Woodhouse]

Brendan.Simon@ctam.com.au said:
>  1) Do I need to reprogram the firmware on the DOC device or is the
> Linux driver software all I need ?

Some kind of firmware is required to get the machine booting off the 
DiskOnChip, but the normal firmware doesn't work very happily with LILO or 
grub. Apparently it works OK with syslinux though.

I'd like to add code to grub to drive the DiskOnChip directly and replace the 
standard firmware. But I want to get the Linux drivers working first.

> 2) Can I use the firmware/ROM space to put own bootloader code ?  How
> big is it ?

48K by default IIRC. You can use that as a first stage and load more though.

> 3) Is there an FAQ for DOCs that aren't Intetl PC specific ? 

None of the stuff I've done so far is ia32-specific. The DiskOnChip Linux 
driver has been tested on Alpha, and although I don't have a big-endian box 
with an ISA slot I can fit the eval board in, I believe it should also work.

Booting's a different problem - but I haven't addressed that yet.

The firmware is _only_ required for booting the kernel. In DOS, it also 
provides INT 13h (Disk BIOS) services to access the DiskOnChip as a normal
DASD, but under Linux we don't need that because we drive the hardware 
directly.


--
dwmw2




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

Re: DiskOnChip for PowerPC embedded system.

[Brendan J Simon]

David Woodhouse wrote:

> Brendan.Simon@ctam.com.au said:
> >  1) Do I need to reprogram the firmware on the DOC device or is the
> > Linux driver software all I need ?
>
> Some kind of firmware is required to get the machine booting off the
> DiskOnChip, but the normal firmware doesn't work very happily with LILO or
> grub. Apparently it works OK with syslinux though.

I'm using a PowerPC embedded system.  There is no floppy and it is obviously
non-Intel.  From what I know, lilo, grub and syslinux are Intel specific.
I can currently run a linux kernel out of a linear flash SIMM.  If this kernel
has the DOC drivers compiled in then I should be able to use the DOC without
having to touch the firmware.  Is this correct ?
I would have to write the low-end driver for the DOC I assume.


> I'd like to add code to grub to drive the DiskOnChip directly and replace the
> standard firmware. But I want to get the Linux drivers working first.

I thought they were working ?
Is it useable for a production system ?
What else needs to be done ?
I'm using kernel 2.2.5 at the moment.  Is this OK ?


> > 2) Can I use the firmware/ROM space to put own bootloader code ?  How
> > big is it ?
>
> 48K by default IIRC. You can use that as a first stage and load more though.

This could be handy :)


> > 3) Is there an FAQ for DOCs that aren't Intetl PC specific ?
>
> None of the stuff I've done so far is ia32-specific. The DiskOnChip Linux
> driver has been tested on Alpha, and although I don't have a big-endian box
> with an ISA slot I can fit the eval board in, I believe it should also work.
>
> Booting's a different problem - but I haven't addressed that yet.

I guess I could write some simple boot code that could read ext2 filesystem and
load the kernel into memory from the DOC, then boot the kernel.  I'm not sure
how much work is involved in that though.  M-Systems have on OS Adaption Kit
which has ANSI source for the TrueFFS, FAT FS, etc.  This may be worth
considering but I imagine it might be expensive, but I guess there is no harm in
enquiring.


> The firmware is _only_ required for booting the kernel. In DOS, it also
> provides INT 13h (Disk BIOS) services to access the DiskOnChip as a normal
> DASD, but under Linux we don't need that because we drive the hardware
> directly.

When you say the "firmware is _only_ required for booting the kernel", I take it
you mean only required when boot a kernel that is actually stored on the DOC
itself.  Sorry if this sounds like a dumb question.

Brendan Simon.




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

Re: DiskOnChip for PowerPC embedded system.

[David Woodhouse]

Brendan.Simon@ctam.com.au said:
> I can currently run a linux kernel out of a linear flash SIMM.  If
> this kernel has the DOC drivers compiled in then I should be able to
> use the DOC without having to touch the firmware.  Is this correct ?

Correct.

> I would have to write the low-end driver for the DOC I assume.

If it's not memory-mapped you'd have to write some code. If it's memory
-mapped, my existing code should work fine.


Brendan.Simon@ctam.com.au said:
> I thought they were working ? 

M-Systems released code for Intel systems which is working. They may recompile 
it for PPC if you ask nicely. They may also let you have their code to 
recompile it yourself, if you sign a strict NDA. 

My code is working, but it's not 100% reliable yet - it doesn't deal with bad 
blocks on the flash, and there are other reports of strange behaviour where it 
leaves the media in a state which the 'official' driver can't recognise.

I haven't been able to reproduce any of these problems recently, which is why 
it's not been fixed yet.

> Is it useable for a production system ?

If you use M-Systems' code in a production system (i.e. something you 
distribute) you mustn't compile it into your kernel - that would violate the 
GPL.

My code isn't ready for production use. It's fine in read-only mode, but still 
sometimes gets confused when it's allowed to write to the device.

> What else needs to be done ? 

Mostly bugfixes and cleaning up. I'm going to be snowed under till around 
March now, but after that I'll have lots of time to finish this off. But if 
you're willing to sign an NDA, I can provide you with some specs for the 
DiskOnChip and NFTL, so that you can help out with the development.

> I'm using kernel 2.2.5 at the moment.  Is this OK ?

That's fine. I started developing on 2.2, then ported to 2.3. Currently, it 
should compile with either. I'm intending to backport to 2.0 as soon as it's 
ready, too.


Brendan.Simon@ctam.com.au said:
> I guess I could write some simple boot code that could read ext2
> filesystem and load the kernel into memory from the DOC, then boot the
> kernel.  I'm not sure how much work is involved in that though.

Grub is fairly much like that. I don't know how much is written in i386 asm, 
or how easy it'd be to port it. It reads ext2 and sets up the kernel for boot. 
It should be fairly easy to add DiskOnChip and NFTL read-only support.

> M-Systems have on OS Adaption Kit which has ANSI source for the
> TrueFFS, FAT FS, etc.  This may be worth considering but I imagine it
> might be expensive, but I guess there is no harm in enquiring.

Under a very strict NDA. For a bootloader that's not as much of a problem as 
it is for the kernel driver, but it would still be useful to be able to 
release the bootloader code. If you base it on the OSAK, you can't.


> When you say the "firmware is _only_ required for booting the kernel",
> I take it you mean only required when boot a kernel that is actually
> stored on the DOC itself. 

Sorry, yes - only required if you need to boot a kernel from the device.

--
dwmw2




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

Re: DiskOnChip for PowerPC embedded system.

[Brendan J Simon]

Stuart Lynne wrote:

> On Wed, Jan 05, 2000 at 09:09:35AM +0000, David Woodhouse wrote:
>
> > If you use M-Systems' code in a production system (i.e. something you
> > distribute) you mustn't compile it into your kernel - that would violate the
> > GPL.
>
> It is trivial to compile their code as a module and use from an initrd file.

I thought that the linux kernel didn't support modules for ppc, at least not for
the 2.2.5 kernel which I got from the linuxppc.org site.  It is the
embedded-2.2.5 kernel put together by Dan Malek.

I assume that the newer version do support modules.  Is this true.
Would this be true of all ppc targets such as 860, 8260, etc or is it just for
common workstations like PowerMacs, etc ?

What kernel versions support modules on ppc ?

Brendan Simon.




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

Re: DiskOnChip for PowerPC embedded system.

[Brendan J Simon]

David Woodhouse wrote:

> > 2) Can I use the firmware/ROM space to put own bootloader code ?  How
> > big is it ?
>
> 48K by default IIRC. You can use that as a first stage and load more though.

I just noticed something.  48KB of linear ROM space would require a minimum of
16 address lines.  As far as I can see, the DOC2000 only has 13 address lines
(ie. 8KB address space).  I'm a bit confused here.

How does the DOC distinguish between accesses to the linear ROM and accesses to
the NAND-Flash ?

Thanks,
Brendan Simon.




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

Re: DiskOnChip for PowerPC embedded system.

[David Woodhouse]

Brendan.Simon@ctam.com.au said:
> I just noticed something.  48KB of linear ROM space would require a
> minimum of 16 address lines.  As far as I can see, the DOC2000 only
> has 13 address lines (ie. 8KB address space).  I'm a bit confused
> here.

> How does the DOC distinguish between accesses to the linear ROM and
> accesses to the NAND-Flash ? 

The 48Kb of firmware is actually on the flash, before the NFTL starts. You can 
expand that as much as you like, although I'm not sure if M-Systems' drivers 
will be happy with the NFTL starting in a different place. My drivers scan the 
whole of the flash to find it, though.

The 'linear rom' is only about 32 bytes (or 64?) repeated throughout the first 
half of the device's (externally-visible) address space. The second half of 
the address space holds the registers through which you control and access the 
flash.

On ia32, the linear rom holds just enough code to read the next 48Kb off the 
flash into memory, then jump to it.



--
dwmw2




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