Re: 48meg DOC

Re: 48meg DOC

[Mateo Anderson]

Hi Leland

Thanks for the reply.

>But it sounds like you are getting further than i am... 

I wish I could get to the end.

>here is what i know... 
>
>I am using:
> 2.4.18 kernel

I am using 2.4.7-10 (from RH 7.2)

> 22.2 lilo

I am using mtd pacthed 21 version of lilo.

I was thinking to try the version 22.
I'll try this tonight, and I'll let you know if I
get any further.


>...***...
>The latest revision (as of Jan 2002) of the M-Systems DOC firmware is version 
>5.0.  
>This newest version is currently incompatible with the open source MTD 
>drivers.  The 
>previous version (4.2) seems to work fine.
>...***...

Yep. On mine is written 4.2 (But I'll double chek it agian tonight
on the boot screen).

>   LI   The first stage boot loader was able to load the second stage boot 
>    loader, but has failed to execute it. This can either be caused by a 
>    geometry mismatch or by moving /boot/boot.b without running the map 
>    installer. 

I am not sure, what is map installer?
I think I should have a map= line in the lilo.conf.
Is this correct?
What is in this map file?

>hope this helps... and let me know if you can think of anything that i 
>might be doing wrong... 

Are you using the version 5 of the M-Sys firmware?
Maybe this is the problem?

Regards,
Mateo


_____________________________________________________________
Brezplacen E-mail - http://email.star.si
Brezplacen prostor 100 MB,lastna domena - http://www.slohosting.com

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag

Re: 48meg DOC

[Henrik Nordstrom]

Have been playing with a 24megs DOC2000 lately, and soon gave up on the stock 
Linux drivers. Haven't had time to test the CVS version of the MTD drivers 
yet.

What I have ended up doing for the time beeing until I have more time is the 
simplest possible path.. M-Systems 5.1.2 firmware, a single DOS partition 
covering the whole DOC drive, and a normal GRUB as boot loader loaded in the 
normal manners via MBR (not the DOC enabled GRUB firmware).

GRUB loads the kernel and a compressed romfs root image from the DOS partition 
and starts the system. To access the DOC from within Linux for configuration 
data storage and upgrades the 5.0.0 Linux driver from M-Systems is used.

My final goal is to be able to partition the DOC in five pieces and to not 
having to depend on binary only drivers (is a hassle to have to use a initrd 
to be able to boot)..  1 binary flash partition for boot loader (GRUB), plus 
4 partitions for system (ro) and configuration (rw), two of each.

Boot area (GRUB in the binary flash partition)

System image (RO while running, compressed)

Primary configuration database (RW)

+ secondary system image and configuration database.

The configuration databases should preferably be journaled and flash friendly, 
but the write frequency is very low with small amounts of data so it is not 
critical.

But I have not yet figured out how to do this in a stable manner. GRUB does 
not like my DOC chips complaining about a UnitSizeFactor parameter in the 
NFTL header (perhaps because of them being formatted by the new firmware? I 
do not know. Was not aware there was firmware related problems), and if I 
partition the DOC in more than one partition using fdisk then it seems the 
M-Systems firmware craps out and I get all kinds of wierd results and the 
system cannot be booted from DOC. (once booted however it seems to be fine 
when accessed using the 5.0.0 version Linux driver, but I have occationally 
lost the flash disk partition when playing with this so I am not sure...)


> I am not sure, what is map installer?

The LILO map installer is /sbin/lilo. This creates the boot map in /boot/map. 
The boot map contains the block numbers of /boot/boot.b and your kernels or 
initrd images.

Regards
Henrik

Re: 48meg DOC

[Mark Meade]

The UnitSizeFactor problem will go away if you reformat the DoC with the 4.2 
version of the M-Sys DFORMAT utility.  This version is still available at 
www.m-sys.com.

After reformatting with 4.2, you should be able to use Grub for booting, and 
also have multiple partitions on the DoC.

Mark

Henrik Nordstrom wrote:
> But I have not yet figured out how to do this in a stable manner. GRUB does
> not like my DOC chips complaining about a UnitSizeFactor parameter in the
> NFTL header (perhaps because of them being formatted by the new firmware? 

Re: 48meg DOC

[Henrik Nordström]

Great! Will try first thing on Monday. Really dislikes the current ugly
solution with one single partition and the binary m-sys driver for many
reasons.

Do I have to use the GRUB DOC firmware to support multiple partitions, or 
will it also work if using the M-Sys DOS driver firmware and loading GRUB 
via MBR?

Not yet sure if I will go for the GRUB firmware or booting GRUB via the
MBR and the M-Sys DOS driver, but having multiple partitions is a definite
win!

If I use the GRUB firmware, is there any difference if I install it using 
the M-Sys DFORMAT utility or by using the doc_loadbios Linux command? 
Would be great if DFORMAT could be used for the initial install, and 
doc_loadbios for field upgrades.

Do the Linux NFTL driver support any forms of wear level hinting like the 
M-Sys driver does for FAT partitions to avoid copying of unused blocks?

Regards
Henrik


On Sun, 1 Sep 2002, Mark Meade wrote:

> The UnitSizeFactor problem will go away if you reformat the DoC with the 4.2 
> version of the M-Sys DFORMAT utility.  This version is still available at 
> www.m-sys.com.
> 
> After reformatting with 4.2, you should be able to use Grub for booting, and 
> also have multiple partitions on the DoC.
> 
> Mark
> 
> Henrik Nordstrom wrote:
> > But I have not yet figured out how to do this in a stable manner. GRUB does
> > not like my DOC chips complaining about a UnitSizeFactor parameter in the
> > NFTL header (perhaps because of them being formatted by the new firmware? 
> 

Re: 48meg DOC

[Mateo Anderson]

Leland,

>> > 22.2 lilo
>> 
>> I am using mtd pacthed 21 version of lilo.
>> 
>> I was thinking to try the version 22.
>> I'll try this tonight, and I'll let you know if I
>> get any further.

Yesterday I tried with the lilo 22.3.2.
No success :((

I got L 40 40...

I found on this list, that somebody else had this problems and I tried 
with the solution he proposed, but it still did not work (lilo did
not accept those 3D before the numbers).

Now I have tried with the:
- lilo as is on the RH 7.2 system
- patched lilo from M-sys
- patched lilo from mtd
- latest version of lilo

What else should I try??

Is there any HOW-TO about lilo and DOC?
Do I have to use GRUB? Or maybe no boot loader (like a floppy)?

>this project has been interesting to say the least... 

>From the beginig it was interesting, but now I 
don't know any more :((

Regards,
Mateo

_____________________________________________________________
Brezplacen E-mail - http://email.star.si
Brezplacen prostor 100 MB,lastna domena - http://www.slohosting.com

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag

Re: 48meg DOC

[David Woodhouse]

mateo@posta.star.si said:
>  I found on this list, that somebody else had this problems and I
> tried  with the solution he proposed, but it still did not work (lilo
> did not accept those 3D before the numbers). 

Er, that sounds like the mail just got eaten by quoted-unreadable encoding. 

Substitute '=' for '=3D'. 

--
dwmw2

Re: 48meg DOC

[Mateo Anderson]

Hi David

>mateo@posta.star.si said:
>>  I found on this list, that somebody else had this problems and I
>> tried  with the solution he proposed, but it still did not work (lilo
>> did not accept those 3D before the numbers). 
>
>Er, that sounds like the mail just got eaten by quoted-unreadable encoding. 
>
>Substitute '=' for '=3D'. 

Yes, I thought that was the case.
But I saw somebody talking something about 3D sector (or something
like that), so I thought maybe this has something to do with it.

As you know, I tried a lot of possibilities, so I tried that
one too, but it still does NOT WORK!!!

Any ideas?

Regards,
Mateo

_____________________________________________________________
Brezplacen E-mail - http://email.star.si
Brezplacen prostor 100 MB,lastna domena - http://www.slohosting.com

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag

Re: 48meg DOC

[Mark Meade]

Henrik Nordström wrote:
> Do I have to use the GRUB DOC firmware to support multiple partitions, or
> will it also work if using the M-Sys DOS driver firmware and loading GRUB
> via MBR?

You shouldn't need to have GRUB on the DoC to support multiple partitions.  
Grub is simply the bootloader -- the MTD/DoC stuff should work the same 
regardless of the presence of GRUB/LILO/whatever.  

> Not yet sure if I will go for the GRUB firmware or booting GRUB via the
> MBR and the M-Sys DOS driver, but having multiple partitions is a definite
> win!

Use the GRUB firmware if the DoC is the primary non-volatile storage in your 
system.  Off-topic, but if you have a MBR in your target system, what is the 
DoC used for?

> If I use the GRUB firmware, is there any difference if I install it using
> the M-Sys DFORMAT utility or by using the doc_loadbios Linux command?
> Would be great if DFORMAT could be used for the initial install, and
> doc_loadbios for field upgrades.

I have not found a reliable way to use DFORMAT to load the Grub firmware.  

In general, DFORMAT is only needed once (to install M-Sys firmware version 
4.2), and doc_loadbios is used to install GRUB.  

Mark

Re: 48meg DOC

[Henrik Nordstrom]

Mark Meade wrote:

> You shouldn't need to have GRUB on the DoC to support multiple partitions.
> Grub is simply the bootloader -- the MTD/DoC stuff should work the same
> regardless of the presence of GRUB/LILO/whatever.

I ask because the 5.1.2 M-Sys DOS firmware seems to crap out badly if there is 
multiple partitions in the DoC disk image.. and it is a bit hard to boot the 
system if the DoC firmware does not play..

WIth a single partition everithing works just fine.

If I add another partition to the DoC disk image then the DOS firmware no 
longer boots the OS from the DoC, and if I load GRUB or DOS via the netwok 
(PXE) then GRUB cannot read the partition table and finds yet another ghost 
harddrive in the system, and DOS does not find any partition table on the 
DoC.. Funny eh?

> Use the GRUB firmware if the DoC is the primary non-volatile storage in
> your system.  Off-topic, but if you have a MBR in your target system, what
> is the DoC used for?

I am referring to the MBR of the DoC, not any other device. The DoC emulates a 
harddrive and as such it has a MBR for the DOS partition table and OS 
bootstrap code.

> I have not found a reliable way to use DFORMAT to load the Grub firmware.

With the 5.1.2 version of DFORMAT GRUB installed just fine as a binary flash 
image using the DFORMAT dos tool.. only that it didn't like the NTFL 
complaining about UnitSizeFactor once booted..

  dformat /win:d600 /BDKF0:grub_firmware

Haven't yet had time to test the 4.2 DFORMAT utility. Expect to do so during 
the day.

Regards
Henrik

Re: 48meg DOC

[David Woodhouse]

mark@lakeshoremicro.com said:
>  I have not found a reliable way to use DFORMAT to load the Grub
> firmware.  

Oh, have you been trying? At first glance it looked like it should be 
fairly simple to generate a .EXB file with our Grub in it instead of their 
firmware -- are there problems?

Being able to use DFORMAT to load Grub would be very useful.

--
dwmw2

Re: 48meg DOC

[Mark Meade]

Yes, I was experimenting with using DFORMAT to load Grub around the time I 
wrote up the DoC/GRUB Howto.

Henrik is correct that "dformat /win:xxxx /BDKF0:grub_firmware" will install 
GRUB properly, but the UnitSizeFactor issue confuses the NFTL code in Grub.  
I haven't found an easy way to format using version 4.2 and install the grub 
code at the same time.

When the UnitSizeFactor issue is resolved, we should be able to use DFORMAT 
to install GRUB, and doc_loadbios would no longer be needed.  We probably 
wouldn't even need to generate a .EXB file, as the /BDKF option seems to be 
OK with grub_firmware in its raw binary format.

If the UnitSizeFactor thing has been fixed in the latest CVS code, I'd be 
glad to apply the changes to the GRUB code.  If not, can you point us in the 
right direction to fix it?  

David Woodhouse wrote:
> mark@lakeshoremicro.com said:
> >  I have not found a reliable way to use DFORMAT to load the Grub
> > firmware.
>
> Oh, have you been trying? At first glance it looked like it should be
> fairly simple to generate a .EXB file with our Grub in it instead of their
> firmware -- are there problems?
>
> Being able to use DFORMAT to load Grub would be very useful.