DiskOnChip 2000 and Millenium support in GRUB bootloader

DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

Hello,

I copied the Millenium-specific operations from the existing MTD driver to
the GRUB bootloader.  Thanks a lot to David for his original
implementation of the GRUB-compatible booloader.

Can anybody with DOC Millenium try the patch?  It's
    patches/grub-2002-02-19-doc.patch
in the Linux MTD repository described at
    http://linux-mtd.infradead.org/

The patch can be applied against the 2002-02-19 version of GRUB CVS at 
    http://savannah.gnu.org/cvs/?group_id=68

I tested the patch with a 64M DiskOnChip 2000.  The GRUB configure command 
was as follows:
    ./configure --enable-diskonchip --disable-ffs --disable-xfs 
                --disable-jfs --disable-vstafs --disable-reiserfs 
                --disable-minix --disable-fat

This left only ext2 read access in GRUB to load the kernel, as my 
DiskOnChip was split into ext2 and ext3 partitions.

The firmware file will be generated in the GRUB's stage1 directory.  I 
copied the stage1 source code to generate a stand-alone patch against 
GRUB repository.

Ilguiz

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

On 19 Feb 2002, Ilguiz Latypov wrote:

> Can anybody with DOC Millenium try the patch?  It's
>     patches/grub-2002-02-19-doc.patch

Hi,

I have an 8MB DOC Millenium, and have been booting successfully with the mtd-patched LILO.

I was able to apply the patch, and successfully build the grub_firmware file.  I've
followed the instructions posted earlier on this list (using doc_loadbios), but I can't
seem to make it boot.

I'm trying to boot from the DOC ISA eval board on a PC with an AMI BIOS -- and I believe
"boot from NETWORK" should call INT 18h.  I also tried booting from a floppy with the boot
record modified to call int 18.  In either case, my PC doesn't seem to recognize the DOC
at boot time.

I'd love to help out in testing this part -- Can I provide any more information, or maybe
I'm just missing something easy?

Regards,

Mark

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

Mark,

After reading the int 19h description in Ralf Brown's interrupt list at
    http://www.ctyme.com/intr/rb-2270.htm 
I realize that the BIOS boot options (floppy drive, hard disk, CD-ROM,
network) should come to effect after BIOS calls the INT 19h handler.

At system startup the motherboard BIOS code checks for the BIOS extension
signatures in the region 0c0000h through 0e0000h and executes the
extensions if found:
    http://www.acl.lanl.gov/linuxbios/faq/archive/0059.html

I believe DoC has this signature in its "IPL" area.

Once the DoC "BIOS initialization", or "stage 1" area gets control, the
MTD DoC GRUB loader will install its own INT 19h handler.

This means that the BIOS boot drive order options will not have any effect
when DoC is present.  Once motherboard BIOS code invokes INT 19h, DoC
bootloader will load the kernel off particular filesystem placed on top of
NFTL DoC partition according to /boot/grub/menu.lst configuration file.

[I believe the interrupt number is mistyped as INT 18h in 
README_DiskOnChip, former grub/README].

Does the "Jumping to Grub" message show up during startup 
(stage1/doc_stage1.S)?  Does this message come next?
   Attempting to open /boot/grub/menu.lst on drive 0xe0, partition 0xff

If yes, enabling the DOC_DEBUG definition in stage2/shared.h might make 
sense.  If no, the stage1/doc_stage1{,b}.S code will need some work.

In either case the open source MTD drivers will have to be used later in 
the kernel.  The proprietory M-Sys drivers rely on their own boot loader 
which installs INT 13h as a disk I/O call.

Thanks for trying,

Ilguiz

On Wed, 20 Feb 2002, Mark Meade wrote:

> I'm trying to boot from the DOC ISA eval board on a PC with an AMI BIOS
> -- and I believe "boot from NETWORK" should call INT 18h.  I also tried
> booting from a floppy with the boot record modified to call int 18.  In
> either case, my PC doesn't seem to recognize the DOC at boot time.

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

Ilguiz,

I don't get any "Jumping to Grub" messages on boot; it's like the DOC is not installed at
all (no messages on boot).

The difference between INT 18/19 is a bit confusing.  I thought that int 18h was the old
"bootstrap" handler that used to jump to ROM BASIC (many years ago), and that int 19h
simply tried to first read the MBR on the floppy, and then on the first hard disk drive.
According to a very old DOS book I have, it looks like INT 19h will transfer control to
INT 18h if attempts to read the boot sector from floppy or hard drive are unsuccessful.

I'll try booting from a floppy with MBR = int 19 tomorrow.

I did enable the DOC_DEBUG in shared.h, but obviously this didn't make any difference as I
haven't been able to even attempt to boot yet.

The kernel I'm using does have the open source MTD drivers compiled in, and everything
works great when booted from (mtd-patched) LILO.

Thanks for your quick response.

Mark

On Wed, 20 Feb 2002, Ilguiz Latypov wrote:

> Does the "Jumping to Grub" message show up during startup
> (stage1/doc_stage1.S)?  Does this message come next?
>    Attempting to open /boot/grub/menu.lst on drive 0xe0, partition 0xff

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

Mark,

I updated the patches/grub-2002-02-19-doc.patch with regard to Millenium 
specifics at stage 1.  Sorry I missed that last time.  And again, someone 
with Millenium chip has to test the change as I don't have such chip.

I can't understand why would the message "Loading GRUB from DiskOnChip" 
not appear at startup.  It is the first thing in step (b):

  a) The motherboard BIOS finds the 2-byte signature of DoC in the 
     C0000-E0000 area and jumps there.  This is Initial Program Loader in 
     M-Sys notation.  It will copy 512 bytes of the flash code to 0x2000:0 
     and jump there.

  b) The 512 bytes flash code (Secondary Program Loader, or stage 1) 
     copies the rest of itself into the end of the real memory 640K area, 
     adjusts the BIOS memory size accordingly, installs the INT 19h 
     pointer to that area and returns.

  c) Once the BIOS scan is done, the motherboard BIOS invokes INT 19h 
     which would otherwise be handled by the BIOS itself.  Thus the rest 
     of stage 1 code receives control.  The code initializes DoC and reads 
     the whole bootloader off the DoC into 0x7f0:0 and jumps to stage 2 at 
     0:0x8200.

Can you please try the updated DoC GRUB patch?  This shouldn't fix the INT 
19h problem though.

Ilguiz

P.S.  It is funny that the same DoC handling code has to be stored in 3 
places: 
  a) in stage 1 to load "plain" stage 2
  b) in stage 2 to load kernel
  c) in kernel to provide a file system

On Wed, 20 Feb 2002, Mark Meade wrote:

> I don't get any "Jumping to Grub" messages on boot; it's like the DOC is
> not installed at all (no messages on boot).

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

Correction: I meant step (c).

On Thu, 21 Feb 2002, Ilguiz Latypov wrote:

> I can't understand why would the message "Loading GRUB from DiskOnChip" 
> not appear at startup.  It is the first thing in step (b):

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

Ilguiz,

It appears that the 2-byte signature (55 AA) is not there after I run the "doc_loadbios"
program.  The entire IPL that was there (after the M-Sys DFORMAT) is modified by
doc_loadbios.  The motherboard BIOS is no longer seeing that 2-byte signature, so none of
the other steps are even attempted.

I did apply the grub-2002-02-19-doc.patch prior to trying all of this; I used the
2002-02-19 version of GRUB as detailed in your initial post, using the configure options
specified.

Regards,

Mark

On Thur, 21 Feb 2002,  Ilguiz Latypov wrote:

> Can you please try the updated DoC GRUB patch?  This shouldn't fix the INT
> 19h problem though.

RE: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Vadim Khmelnitsky]

Guys,
I'm not sure what doc-loadbios is doing, but i assume that it writes some
stuff to the physical offset 0 of the diskonchip
in order to replace diskonchip BIOS driver with grub loader .
It should work fine with DOC2000 series , since the IPL code ( the one that
starts with 55AA signature ) is placed in ROM .
It will not work for the Millennium chip because IPL code is placed in flash
( offset 0 ) and downloaded to SRAM upon reset.
Millennium chip has small piece of SRAM instead of ROM . So, like i said
upon reset first 512 bytes of data are downloaded from flash to SRAM . Then
BIOS can access it read 55AA signature and hand control over to this piece
of code .
If you want to make doc-loadbios to work with Millennium chip you should put
it behind IPL code . IPL is 512 bites long . We have two copies of it . So,
you can put your code at offset 1KB .

Vadim


-----Original Message-----
From: Mark Meade [mailto:mark@lakeshoremicro.com]
Sent: Thu, February 21, 2002 2:32 PM
To: Ilguiz Latypov
Cc: linux-mtd@lists.infradead.org
Subject: Re: DiskOnChip 2000 and Millenium support in GRUB bootloader 


Ilguiz,

It appears that the 2-byte signature (55 AA) is not there after I run the
"doc_loadbios"
program.  The entire IPL that was there (after the M-Sys DFORMAT) is
modified by
doc_loadbios.  The motherboard BIOS is no longer seeing that 2-byte
signature, so none of
the other steps are even attempted.

I did apply the grub-2002-02-19-doc.patch prior to trying all of this; I
used the
2002-02-19 version of GRUB as detailed in your initial post, using the
configure options
specified.

Regards,

Mark

On Thur, 21 Feb 2002,  Ilguiz Latypov wrote:

> Can you please try the updated DoC GRUB patch?  This shouldn't fix the INT
> 19h problem though.





______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

OK, I updated the util/doc_loadbios to accept an extra offset paramter
(1024).

Also, patches/grub-2002-02-19-doc.patch will skip the 1K IPL area if
Millenium is detected (I know it is silly to detect the DoC type in the
bootloader at run time -- please change that to conditional compilation if
you wish).

The updated patch will need proper auto-configured files.  You can
re-generate them by running
   aclocal && automake && autoconf
in the GRUB's top level directory.

Anyone wants to try his/her Millenium? Mark?

Ilguiz

On Thu, 21 Feb 2002, Vadim Khmelnitsky wrote:

> If you want to make doc-loadbios to work with Millennium chip you should
> put it behind IPL code . IPL is 512 bites long . We have two copies of
> it . So, you can put your code at offset 1KB .

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

Hi Ilguiz,

> OK, I updated the util/doc_loadbios to accept an extra offset paramter
> (1024).

I can't seem to find an updated doc_loadbios.  Where should I look?

> The updated patch will need proper auto-configured files.  You can
> re-generate them by running
>    aclocal && automake && autoconf
> in the GRUB's top level directory.

The "aclocal && automake && autoconf" caused some errors; the errors I had were identical
to those posted by Herman Theron in the "Error using GRUB patch" thread.

Thanks,

Mark

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

On Fri, 22 Feb 2002, Mark Meade wrote:

> I can't seem to find an updated doc_loadbios.  Where should I look?

The source code for doc_loadbios is in the util/ directory of the Linux
MTD CVS repository.

> The "aclocal && automake && autoconf" caused some errors; the errors I
> had were identical to those posted by Herman Theron in the "Error using
> GRUB patch" thread.

Mind upgrading autoconf and automake?

Ilguiz

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

On Fri, 22 Feb 2002, Ilguiz Latypov wrote:

> The source code for doc_loadbios is in the util/ directory of the Linux
> MTD CVS repository.
>
 > Mind upgrading autoconf and automake?

Thanks, Ilguiz.  I now have the latest from the CVS archive, and I also upgraded autoconf
and automake.  Everything went flawlessly.

The doc_loadbios output to /dev/mtd0 is off by 512 bytes (when I use an offset of 1024):

*** doc_loadbios.c Fri Feb 22 15:22:17 2002
--- doc_loadbios.c.orig Fri Feb 22 15:16:30 2002
***************
*** 89,98 ****
       perror("read");
       goto error;
      }
-     if (lseek(ofd, 0L, SEEK_SET) < 0) {
-      perror("lseek");
-      goto error;
-     }
     }

     erase.length = meminfo.erasesize;
--- 89,94 ----

After making that change, the grub_firmware appears to be in the correct place (0x400),
and the IPL is still at 0x0 and 0x200.

I created an ext2 partition and copied the necessary files to /boot and /boot/grub.

My system now recognizes that something is there, but refuses to boot:
    Searching for boot record from SCSI: Not Found.

I'll keep trying; if you have any ideas, let me know.

Regards,

Mark

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

Mark,

On Fri, 22 Feb 2002, Mark Meade wrote:

> The doc_loadbios output to /dev/mtd0 is off by 512 bytes (when I use an
> offset of 1024):

Thanks for the correction.   I adjusted your patch to take into account 
the almost impossible case when IPL is bigger than erase sector.

> My system now recognizes that something is there, but refuses to boot:
>     Searching for boot record from SCSI: Not Found.

Perhaps, IPL refuses to execute SPL (GRUB's doc_stage1) because the
doc_stage1's check sum didn't include IPL itself.  

Vadim, should the Millennium SPL check sum include IPL?

The other thought is if the stage1 code can be placed instead of IPL.

Ilguiz

RE: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Vadim Khmelnitsky]

[Ilguiz]
Vadim, should the Millennium SPL check sum include IPL?

[Vadim]
I will verify it with IPL developer , but as far as i know there is no
difference in behavior between IPL of DOC2000 and Millennium .

IPL that you use should load SPL ( secondary program loader ) . In case
of Millennium chip SPL should be placed right after IPL ( offset 0x400 ) and
i think that size of SPL should be no longer than 7K . 1KB of IPL + 7KB of
SPL = 8KB , which is the size of the Millennium chip erasable unit .


Vadim
  



-----Original Message-----
From: Ilguiz Latypov [mailto:ilatypov@superbt.com]
Sent: Fri, February 22, 2002 2:39 PM
To: Mark Meade
Cc: linux-mtd@lists.infradead.org
Subject: Re: DiskOnChip 2000 and Millenium support in GRUB bootloader 



Mark,

On Fri, 22 Feb 2002, Mark Meade wrote:

> The doc_loadbios output to /dev/mtd0 is off by 512 bytes (when I use an
> offset of 1024):

Thanks for the correction.   I adjusted your patch to take into account 
the almost impossible case when IPL is bigger than erase sector.

> My system now recognizes that something is there, but refuses to boot:
>     Searching for boot record from SCSI: Not Found.

Perhaps, IPL refuses to execute SPL (GRUB's doc_stage1) because the
doc_stage1's check sum didn't include IPL itself.  

Vadim, should the Millennium SPL check sum include IPL?

The other thought is if the stage1 code can be placed instead of IPL.

Ilguiz



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Vadim Khmelnitsky]

[Ilguiz]
Vadim, should the Millennium SPL check sum include IPL?

[Vadim]
No . IPL of Millennium chip copies 7K of data out of offset 0x400 and
calculates the checksum  , which should be 0x55 . If it's not 0x55 IPL
returns to BIOS without executing SPL .

Vadim
-----Original Message-----
From: Ilguiz Latypov [mailto:ilatypov@superbt.com]
Sent: Fri, February 22, 2002 2:39 PM
To: Mark Meade
Cc: linux-mtd@lists.infradead.org
Subject: Re: DiskOnChip 2000 and Millenium support in GRUB bootloader 



Mark,

On Fri, 22 Feb 2002, Mark Meade wrote:

> The doc_loadbios output to /dev/mtd0 is off by 512 bytes (when I use an
> offset of 1024):

Thanks for the correction.   I adjusted your patch to take into account 
the almost impossible case when IPL is bigger than erase sector.

> My system now recognizes that something is there, but refuses to boot:
>     Searching for boot record from SCSI: Not Found.

Perhaps, IPL refuses to execute SPL (GRUB's doc_stage1) because the
doc_stage1's check sum didn't include IPL itself.  

Vadim, should the Millennium SPL check sum include IPL?

The other thought is if the stage1 code can be placed instead of IPL.

Ilguiz



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Vadim Khmelnitsky]

Another thing that i forgot to mention earlier . When you guys write SPL to
flash i assume you read the content of the first 1Kb ( 2 copies of IPL ) of
flash and attach it to your SPL . The important thing here is to write IPL
part with ECC/EDC syndrom . Otherwise, IPL will not be able to read SPL out
of flash .

Vadim

-----Original Message-----
From: Vadim Khmelnitsky [mailto:VadimK@m-sys.com]
Sent: Mon, February 25, 2002 4:26 PM
To: 'Ilguiz Latypov'; Mark Meade
Cc: linux-mtd@lists.infradead.org
Subject: RE: DiskOnChip 2000 and Millenium support in GRUB bootloader 


[Ilguiz]
Vadim, should the Millennium SPL check sum include IPL?

[Vadim]
No . IPL of Millennium chip copies 7K of data out of offset 0x400 and
calculates the checksum  , which should be 0x55 . If it's not 0x55 IPL
returns to BIOS without executing SPL .

Vadim
-----Original Message-----
From: Ilguiz Latypov [mailto:ilatypov@superbt.com]
Sent: Fri, February 22, 2002 2:39 PM
To: Mark Meade
Cc: linux-mtd@lists.infradead.org
Subject: Re: DiskOnChip 2000 and Millenium support in GRUB bootloader 



Mark,

On Fri, 22 Feb 2002, Mark Meade wrote:

> The doc_loadbios output to /dev/mtd0 is off by 512 bytes (when I use an
> offset of 1024):

Thanks for the correction.   I adjusted your patch to take into account 
the almost impossible case when IPL is bigger than erase sector.

> My system now recognizes that something is there, but refuses to boot:
>     Searching for boot record from SCSI: Not Found.

Perhaps, IPL refuses to execute SPL (GRUB's doc_stage1) because the
doc_stage1's check sum didn't include IPL itself.  

Vadim, should the Millennium SPL check sum include IPL?

The other thought is if the stage1 code can be placed instead of IPL.

Ilguiz



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[David Woodhouse]

VadimK@m-sys.com said:
> [Ilguiz] Vadim, should the Millennium SPL check sum include IPL?
> [Vadim] No . IPL of Millennium chip copies 7K of data out of offset
> 0x400 and calculates the checksum  , which should be 0x55 . If it's
> not 0x55 IPL returns to BIOS without executing SPL . 

What we want to achieve here is to install a tiny INT 19h handler which 
instead of bootstrapping the normal way, loads the Grub bootloader from the 
DiskOnChip IPL area and runs it. 

That tiny INT 19h handler and the code to install it ought to fit in the 
512-byte IPL space on the Millennium, so I think we should be writing our 
own version of the IPL code on the Millennium, rather than using the 
existing IPL which tries to load a whole 8KiB of SPL.

On the DiskOnChip 2000, the IPL in ROM loads the whole 8KiB, but still we 
only use 512 bytes for our own INT 19h-installer code, and that later 
reloads the whole of Grub from the flash. You can see this code at

ftp://www.uk.linux.org/pub/people/dwmw2/mtd/cvs/mtd/grub/doc_stage1.S
ftp://www.uk.linux.org/pub/people/dwmw2/mtd/cvs/mtd/grub/doc_stage1b.S

Some documentation is in the 'README' file in the same directory.

--
dwmw2

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

Yoshinori,

1. I cleaned up the patch with regard to the debugging leftovers.  Do you 
think I need to remove extra debug information activated by the DOC_DEBUG 
switch (dprintf calls)?  What other adjustments are necessary?

2. Besides, I changed stage1/doc_stage1{,b}.S so that the GRUB firmware
will correctly replace the BIOS extension initialization code of DoC
Millennium.

DoC Millennium maps its BIOS extension initialization code to the
beginning of flash memory.  When --enable-diskonchip-ipl option is
supplied to the configure script in addition to --enable-diskonchip, the
necessary 3 byte BIOS signature will be generated in the beginning of the
code.

Unfortunately, the signature cannot be tolerated with DoC 2000 where IPL
is in ROM. This is because the ROM IPL will jump to offset 0 of GRUB
firmware.  The signature 0x55, 0xAA would be executed as "push bp; stosb"  
which is dangerous.

3. I wish to assign my copyright to FSF.  This refers only to the changes
that were not copyrighted by others, of course.  Hopefully, I didn't break
things in the existing code.

Most of the new code in the patch has a copyright notice.  The only
exception is stage2/bdev_diskonchip.c.

David, would you like to put your copyright notice in the above file?  I
can do this for you.

4. The updated patch is available at

http://savannah.gnu.org/patch/?func=detailpatch&patch_id=164&group_id=68

and through anonymous CVS access to Linux MTS repository:

cvs -d ":pserver:anoncvs@cvs.infradead.org:/home/cvs" login
cvs -d ":pserver:anoncvs@cvs.infradead.org:/home/cvs" co \
    mtd/patches/grub-2002-02-19-doc.patch

Thanks a lot for your comments,

Ilguiz

On Thu, 28 Feb 2002, Yoshinori K. Okuji wrote:

> You haven't written ChangeLog entries. Also, you need to add your name
> into the copyright notice in each file you modified (unless you would
> assign your copyright to the FSF).
> 
> Besides those above, you should clean your patch. For example, see
> the diff on "stage2/common.c".
> 
> Thanks,
> Okuji

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[David Woodhouse]

ilatypov@superbt.com said:
>  3. I wish to assign my copyright to FSF.  This refers only to the
> changes that were not copyrighted by others, of course.  Hopefully, I
> didn't break things in the existing code.

> Most of the new code in the patch has a copyright notice.  The only
> exception is stage2/bdev_diskonchip.c.

> David, would you like to put your copyright notice in the above file?
> I can do this for you. 

Er, did I write that? Yeah - looks like my scribblings. I think it predates 
my employment with Red Hat, who own my new output and have FSF copyright 
assignment stuff all sorted out. If it's optional, then I can't be bothered 
with the paperwork - yes, please do add
	(C) 2000  David Woodhouse  <dwwm2@infradead.org>

If only emacs would complain at you when you edit a file which doesn't have 
a copyright for the current year, and possibly even update it for you :)

--
dwmw2

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

On Thu, 28 Feb 2002, Ilguiz Latypov wrote:

> I changed stage1/doc_stage1{,b}.S so that the GRUB firmware
> will correctly replace the BIOS extension initialization code of DoC
> Millennium.

Ilguiz,

I've downloaded your latest GRUB patches, and I've discovered a few minor problems:

1) Some BIOS's don't like extensions without correct checksums.  I modified doc_stage1.S
and added Makefile calls to the "makerom" program (originally found in /mtd/boot).  This
fixes the checksum problem; now the code to install the int 19 handler will be executed.

2) For some reason, my BIOS won't let me override the int 19 handler.  To get around this,
I changed it to an int 18 handler, and this works fine when the BIOS is set to boot from
"Network".  Using int 18 rather than 19 also allows me to boot from the hard drive without
having to remove the DOC.

IMHO, it might be a good idea to allow the use of int 18 or int 19 as a compile time
option.

3) I made additional minor changes in doc_stage1.S to save and restore the doc segment
correctly.   The boot block on a Millennium is an XIP block; _start is not running at
0x20000 in this case.

At this point, I get all the way to the "Jumping to Grub" message, and then it locks up.
I suspect that there might be a problem in the logic that copies stage2 from the DOC to
0x8200.  I haven't found any documentation on Millennium pipeline reads, so I might need
some help here :-).

I'm an open source newbie, so if you think these changes will do you any good, let me know
how to get them to you.

Regards,

Mark

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[ilatypov]

Mark,

Thanks a lot for your contribution.  I totally missed the DoC segment
issue you have identified.  What was your fix?  Do you copy %cs to %ds in
case doc_stage1 is IPL itself?  Are there any extra things to be done to 
make the code eXecute-In-Place?

I will modify the checksum program to generate a different value when
"--enable-diskonchip-ipl" option is supplied to the configure script.

I will also add an option to hook to the diskless boot int 18h handler.  

I found a detailed explanation of the PC BIOS startup at
    http://etherboot.sourceforge.net/doc/html/devman-3.html

Dave, is DoC Millennium documentation still available?  Mark has made
significant testing and coding with the GRUB patch.

Mark, my DoC Millennium modifications to the MTD GRUB patch were based on 
the doc2000.c kernel driver code from MTD repository.  Perhaps, I wasn't 
careful enough in copying the necessary operations.

Ilguiz

On Fri, 1 Mar 2002, Mark Meade wrote:

> 1) Some BIOS's don't like extensions without correct checksums.
[..]
> 2) For some reason, my BIOS won't let me override the int 19 handler.  
[..]
> 3) I made additional minor changes in doc_stage1.S to save and restore
> the doc segment correctly.  The boot block on a Millennium is an XIP
> block; _start is not running at 0x20000 in this case.
[..]

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

On Mon, 4 Mar 2002, Ilguiz Latypov wrote:

> What was your fix?  Do you copy %cs to %ds in
> case doc_stage1 is IPL itself?  Are there any extra things to be done to
> make the code eXecute-In-Place?

Ilguiz,

The segment issue is minor -- the original code assumed that _start was loaded at 0x20000
by the IPL, but in this case, we are executing in place, at 0xD0000 (for example).

So instead of this:

#ifndef DOC_REPLACE_IPL
    /* Store the DiskOnChip segment */
    movw %ds, %cs:doc_seg
#endif

I added the following, after the int 18/19 handler has been copied to the end of memory:

#ifdef DOC_REPLACE_IPL
    /* Store the DiskOnChip segment (XIP from the IPL area) */
    movw %cs, %es:doc_seg
#endif

When the interrupt handler is called, doc_seg is now in the correct spot.

I suppose it's possible to let the int handler XIP also, but it just seemed to fit better
with existing code to copy it to the 1K segment at the top of memory.  This way, no more
Millennium-specific changes are required in doc_stage1b.S.

> I will modify the checksum program to generate a different value when
> "--enable-diskonchip-ipl" option is supplied to the configure script.

I had to add the checksum byte and a jump to the _start routine:

#ifdef DOC_REPLACE_IPL
    /*
      * _start is in the beginning of DoC Millennium flash memory
      */
     .byte 0x55, 0xAA        /* BIOS extension signature */
     .byte 0x10                  /* DoC window is 8K (16*512) in size */
     /* BIOS will call far _start + 3 */

    jmp over
    .byte 0                       /* BIOS extension checksum goes here */
#endif
over:

> I will also add an option to hook to the diskless boot int 18h handler.

Thanks!  This makes it easier for me to test.  I had one occasion when a botched int 19
handler made it impossible to boot with the DOC installed.  I had to remove the DOC, boot
into DOS, install the DOC (with the PC turned on), and then erase it.  Needless to say,
I'm trying to avoid having to do this again.  ;-)

> Mark, my DoC Millennium modifications to the MTD GRUB patch were based on
> the doc2000.c kernel driver code from MTD repository.  Perhaps, I wasn't
> careful enough in copying the necessary operations.

I looked at that source late Friday, but I haven't had time to get real serious about it
yet.  I've found some assembly sources related to the Linux BIOS project that may help,
also.

Mark

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

On Sun, 10 Mar 2002, Ilguiz Latypov wrote:

> I was able to test the grub_firmware file produced by the patch on a 64M
> DoC 2000.  Yes, I could get to the GRUB prompt and play with "root (dc0,"
> command.  GRUB can access the configuration file and the kernel image
> stored in ext2 partition.  The partition was created on top of NFTL block
> device layer.
>
> Mark Meade has offered few improvements to the patch.  I think there are 2 
> latest changes that may be of interest to you:
>
>  a) New configuration option --enable-diskonchip-biosnetboot will make 
>      GRUB firmware to attach itself to INT 18h (BIOS network boot) rather 
>      than to INT 19h (BIOS bootstrap loader).  If you try that option, 
>      enable network boot in BIOS as well.
>
>   b) The DoC SlowIO register is no longer read when fetching the data 
>      from the flash memory.
>
> I updated the patch.  It is available at
>    
> http://savannah.gnu.org/patch/?func=detailpatch&patch_id=164&group_id=68

Ilguiz,

I have been testing your latest patch with the DoC Millennium.  I'm able to 
get a GRUB prompt only after forcing the 512-byte-page code (doc_stage1b.S) 
to address 0x100.

Normally, it looks like the 256-byte/page code ends up at 0x100, and the 
512-byte at 0x200.  With the DoC 2000, this insures that the proper code 
(loaded by the IPL) ends up at 0x100.

Since the Millennium is XIP, jumping to 0x100 ends up running 256-byte-page 
code, which doesn't work in this case.

You mentioned that there are DoC Millennium parts based on 256-byte-page 
chips -- so my hack to force the 512-byte code to 0x100 will not work 
correctly for all Millennium parts.

Any thoughts or ideas?

Thanks,

Mark

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Ilguiz Latypov]

Mark,

1. Thanks for the latest patch to stage2/bdev_diskonchip.c that rectifies
the chip identification.

2. As for the device page size issue in Millennium IPL, the data sheets
and application notes at

    http://www.m-sys.com/content/Products/ShowInformation.asp?PID=1&Code=1

inform that DoC Millennium and DoC Millennium Plus feature a Download
Engine which takes care of copying the flash image into the read-only area
available at offset 0 of the window.

The above process takes place when the device is reset.

Apparently, the XIP IPL doesn't need the DoC 2000 trick with duplicating
the code for 256-byte and 512-byte page size devices at offsets 0x100 and
0x200 respectively.

3. There is a data sheet on Millennium Plus at the aove link, if anyone is
interested.  The chip has ID 0x40, its IPL is downloaded from a non-zero
flash offset, and there are few data structures in the beginning of the
flash memeory.

Ilguiz

On Mon, 11 Mar 2002, Mark Meade wrote:

> You mentioned that there are DoC Millennium parts based on 256-byte-page
> chips -- so my hack to force the 512-byte code to 0x100 will not work
> correctly for all Millennium parts.

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade]

On Tue, 12 Mar 2002, Ilguiz Latypov wrote:

> inform that DoC Millennium and DoC Millennium Plus feature a Download
> Engine which takes care of copying the flash image into the read-only area
>available at offset 0 of the window.

> Apparently, the XIP IPL doesn't need the DoC 2000 trick with duplicating
> the code for 256-byte and 512-byte page size devices at offsets 0x100 and
> 0x200 respectively.

Ilguiz,

With a DoC Millennium , the doc_stage1 logic will always copy the 
256-byte-page code to RAM, regardless of the chip type.  In fact, because of 
the Millennium's 512 byte "boot block" window, the actual 512-byte page code 
is never directly accessible -- it is always located at 0x200 in this case.

As I mentioned previously, my hack to get my part to work was simply to force 
the 512-byte-page code to 0x100, and everything worked great.  If there are 
256-byte-page parts, this obviously won't work.

One alternative is to have both 256- and 512-byte code located at 
0x100..0x1FF, and determine (at run time) which type of part we have.

One way of doing this would be to have a small look-up table, and based on 
the chip ID, determine the part type.  

Another way (which I've already tested) is to read from flash address 0x200, 
using the 256-byte-page access method.  If we are indeed on a 256-byte 
device, the word at 0x200 will always match the code word at %cs:doc_stage1b.

In a 512-byte device, reading this address actually reads 0x400, which will 
*most likely* not match, as it is actually stage 2 GRUB code.  We could 
compare more bytes, if necessary, to reduce the possibility that this could 
happen.

Maybe there is an easier, cleaner way to handle this problem -- but I haven't 
found it yet.  Does it make sense to pursue this further?

Regards,

Mark

Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Yoshinori K. Okuji]

At Fri, 01 Mar 2002 07:19:14 +0000,
David Woodhouse wrote:
> Er, did I write that? Yeah - looks like my scribblings. I think it predates 
> my employment with Red Hat, who own my new output and have FSF copyright 
> assignment stuff all sorted out. If it's optional, then I can't be bothered 
> with the paperwork - yes, please do add
> 	(C) 2000  David Woodhouse  <dwwm2@infradead.org>

If the code you wrote was for GRUB, you should sign an
assignment. Otherwise (i.e. you just copied code from another
software), you don't have to do that.

Currently we are making GRUB copyrighted (only) by FSF as much as
possible, so I hope you would assign the copyright to the FSF, if
possible.

Thanks,
Okuji