Re: DiskOnChip 2000 and Millenium support in GRUB bootloader

[Mark Meade <mark@lakeshoremicro.com>]

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