public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* [patch] doc_stage1.S : GRUB on DoC
@ 2002-07-16 18:52 Mark Meade
  2002-07-17 18:35 ` Ilguiz Latypov
  2002-07-30  4:11 ` Ilguiz Latypov
  0 siblings, 2 replies; 15+ messages in thread
From: Mark Meade @ 2002-07-16 18:52 UTC (permalink / raw)
  To: linux-mtd; +Cc: Ilguiz Latypov

I'm not sure if this should be posted here, or maybe to the GRUB project, but 
the following are some changes to doc_stage1.S and doc_stage1.h.

This patch is against GRUB 0.92, with Ilguiz's latest (06-21) changes applied.

These changes consolidate two files (doc_stage1.S and doc_stage1b.S) into one 
file.  The main purpose of these changes is to eliminate the compile-time 
options that were required to differentiate between the 256-byte-page and 
512-byte-page DoC Millennium.  This is now done at run-time by checking the 
DoC's device ID, eliminating the need for a "stage 1b".

This is necessary for the Millennium because the entire M-Sys IPL is replaced 
by GRUB.  The DoC 2000 GRUB code placed 256-byte-page code at offset 0x100, 
and 512-byte-page code at 0x200, relying on the IPL to jump to the correct 
code.

These changes *should* also work for the DoC 2000, but I have not verified 
this.  Changes will be necessary to the makefile and/or makecsum.c to 
duplicate whatever code is at 0x100..0x1FF to 0x200..0x2FF.

Ilguiz -- is the DOC_MIL_KEEP_IPL option still used?



--- doc_stage1.S.orig   Tue Jul 16 14:24:03 2002
+++ doc_stage1.S        Tue Jul 16 14:23:43 2002
@@ -40,7 +40,7 @@
         */
        .byte 0x55, 0xAA        /* BIOS extension signature */
        .byte 0x10              /* BIOS extension size in 512 byte blocks */
-       /*
+       /*                                       
         * The checksum byte at offset 511 of every copy of IPL is the
         * complement to 0 of first 511 bytes.  This is because of 2 facts:
         * a) the sum of bytes in the BIOS extension window is supposed to 
@@ -56,7 +56,7 @@
 #else
        pushw   %ds
 #endif
-       cld
+       cld 
        MSG(doc_bios_scan_start_string)
 
        /*
@@ -71,7 +71,7 @@
        /* What we need to do is:
           1. Check the current end-of-memory in the BIOS
           2. Reduce it by the amount of memory we need for our INT 19h 
-          3. Return, and wait for our INT 19h to be called.
+          3. Return, and wait for our INT 18h/19h to be called.
        */
 
                /* Find top of memory */
@@ -87,7 +87,7 @@
        shlw    $6,%ax
        movw    %ax,%es
 
-               /* Set up our shiny new INT 19h handler */
+               /* Set up our shiny new INT 18h or 19h handler */
        movw    %es, (DOC_BIOS_HOOK * 4 + 2)
        movw    $doc_bios_boot_hook, (DOC_BIOS_HOOK * 4)
 
@@ -99,7 +99,7 @@
        xorw    %di,%di
        rep
        movsw
-
+       
                /* Store the DiskOnChip segment */
        popw    %es:doc_seg
        lret
@@ -107,6 +107,7 @@
 
 doc_bios_boot_hook:
        cld
+       
                /* Say hello */
        MSG(doc_bios_hook_execed_string)
 #ifndef SHOW_INFO
@@ -135,9 +136,8 @@
        movb    $NAND_CMD_RESET, %ah
        call    doc_cmd
 
-
-               /********* Display chip ID and segment ***************/
 #ifdef SHOW_INFO
+               /********* Display chip ID and segment ***************/
        pushw   %bx
        pushw   %si
 
@@ -170,30 +170,102 @@
 #endif         /* defined(SHOW_INFO) */
                /*****************************************************/
 
-               /* 
-                  Basically, we know that the DiskOnChip IPL ROM will 
-                  load only the first 256 bytes of each 512-byte page
-                  from a 512-byte-page device, but it'll load _all_
-                  the data from a 256-byte-page device.
-                  
-                  Therefore, we put the code to handle 256-byte-page
-                  devices at offset 0x100, where we know it won't get
-                  loaded if we're actually on a 512-byte-page device.
-                  We put the code to handle 512-byte-page devices at
-                  0x200, in the knowledge that it'll get loaded to 
-                  offset 0x100 if it's appropriate.
-
-                  Now, we don't have to probe the device, we just 
-                  jump to the code at 0x100, because we _know_ that 
-                  the IPL ROM will have loaded the correct code there.
-                  
-                  This is SICK. I love it. 
-               */
+       /* figure out if we have a 256-byte or 512-byte device:
+       ** 
+       ** Basically, we know that the DiskOnChip 2000 IPL ROM will 
+       ** load only the first 256 bytes of each 512-byte page
+       ** from a 512-byte-page device, but it'll load 
+       ** the data from a 256-byte-page device.
+       **
+       ** Therefore, we'll put a copy of the code that normally resides
+       ** at offset 0x100..0x1FF at 0x200.  This way, the correct
+       ** code will be there, regardless of which device we have.
+       **
+       ** The DoC Millennium is slightly different -- here, we are
+       ** actually replacing the IPL, so this code duplication isn't
+       ** necessary.
+       */
 
-       jmp     stage1b
+       movb    $NAND_CMD_READID, %ah
+       call    doc_cmd
 
-       /* Routines used by both 256- and 512- byte/page loaders. */
+       /* Use existing block read routine to get Manufacturer &
+       ** Chip ID.  Overkill, but saves code space.  */  
+
+       movw    $1, %cx         /* read just one page */
+       movw    $GRUBSTART, %ax
+       movw    %ax, %es
+       movw    $0, %di
+       call    read_block
+
+       movw    %es:0,%ax               /* id/mfr in first 2 bytes */
+
+#ifdef SHOW_INFO
+
+       /* Display Chip ID and Manufacturer Code */
+
+       pushw   %ax
+       pushw   %bx
+       pushw   %si
+       call    phword
+       MSG(eol_string)
+       popw    %si
+       popw    %bx
+       popw    %ax
+
+#endif
+
+       /* Look at the device ID code to determine if we have 256 byte pages.
+       ** Based on the "nand_flash_dev" table in ../stage2/bdev_diskonchip.c,
+       ** there are currently only two ID codes that are 256: 0x64 and 0xea. 
+       ** All the other types of chips have 512 byte pages. */
+       
+       cmpb    $0x64,%ah
+       je      have_256
+
+       cmpb    $0xEA,%ah
+       jne     get_grub
+
+have_256:
+
+       movb    $1,%cs:page256
+
+get_grub:
+
+       /* Load %CX with the number of 256-byte blocks to load */       
+       movw    $LOADLEN, %cx
+
+       /* Set up our target address for writing stage2 */
+       movw    $GRUBLOADSEG, %ax
+       movw    %ax, %es
+       movw    $GRUBLOADOFS, %di
+
+       /* Stage2 proper starts at offset 0x300 on the flash. We
+          have defined the load address GRUBLOADSEG so that
+          we're loading this to 0x8000:0000 or 0x8000:0200, 
+          depending on whether this is old or GNU Grub, 
+          respectively.
+       */
+
+#ifdef DOC_MIL_KEEP_IPL
+       cmpw    $DoC_2k_CDSN_IO, %si
+       je      mil_spec_end3
+       /* Keep Millennium's original IPL in the first 1K of flash */
+       addw    $0x400, %di
+       mil_spec_end3:
+#endif
 
+       call    copy_grub
+
+good:  
+       MSG(msgjmp)
+               /* Run it:       jmpf 0:8200 */
+       .byte   0xea
+       .word   GRUBSTART,0
+
+       
+       /* Routines used by both 256- and 512- byte/page loaders. */
+       
                 /* doc_cmd:      Send a command to the flash chip */
 doc_cmd:
                 /* Enable CLE line to flash */
@@ -214,7 +286,114 @@
         testb   $0x80,BX_CDSNControl
         jz      l38
         ret
-                
+
+       /* copy_grub: copies GRUB code from flash to RAM */
+
+ copy_grub:
+
+       /* 256 bytes/page: Send new READ0 command
+       ** 512 bytes/page: READ0 or READ1, depending on address */
+
+       xorb   %ah, %ah
+       call    is_256_byte
+       je      send_cmd
+
+       movw    %di, %ax
+       andb    $1,%ah
+
+ send_cmd:
+
+       call    doc_cmd
+
+ read_block:
+
+       /* Start of new block. Set address */
+       movb    $CDSN_CTRL_FLASH_IO + CDSN_CTRL_WP + CDSN_CTRL_ALE + 
CDSN_CTRL_CE, BX_CDSNControl
+       incw    BX_ChipID
+
+       /* For 256 bytes/page, we send bits 0-7, then 8-15, then 16-23 */
+       /* For 512, We send bits 0-7, then 9-16, then 17-23 */
+       /* Yes bit 8 is missing. Read the NAND flash specs */           
+
+       movw    %di,%dx
+       
+       /* Bits 0-7 are always zero */
+       movb    $0,BX_SlowIO
+       movb    $0,(%si)
+
+       /* Bits 8-15 (256), or Bits 9-16 (512) */
+
+       call    is_256_byte
+       je      adrbytemid
+
+       shrw    $1,%dx
+       .byte   0x80, 0xce /* orb adrbit16, %dh */
+ adrbit16:     
+       .byte   0
+
+ adrbytemid:
+
+       movb    %dh,BX_SlowIO
+       movb    %dh,(%si)
+
+       /* Bits 16-23 (256), or Bits 17-24 (512) */
+
+       .byte   0xb2 /* movb adrbytehi, %dl */
+ adrbytehi:
+       .byte   0
+
+       movb    %dl,BX_SlowIO
+       movb    %dl,(%si)
+
+       /* Clear the ALE line to the flash chip */
+       movb    $CDSN_CTRL_FLASH_IO + CDSN_CTRL_WP + CDSN_CTRL_CE, 
BX_CDSNControl
+       call    doc_wait
+
+       pushw   %cx             /* Store the 'blocks remaining' count */
+       movw    $0x100, %cx     /* Set up to copy 0x100 bytes */
+       cmpw    $DoC_2k_CDSN_IO, %si
+       je      mil_spec_end1
+       testb   BX_ReadPipeInit, %al /* Millennium should use the */
+       decw    %cx             /* LastDataRead register - Pipeline Reads */
+ mil_spec_end1:
+
+ readbyte:     
+       movsb                   /* movb (%si), %al ; stosb would be more */
+       decw    %si             /* obvious, but would take an extra byte. */
+       loop    readbyte
+
+       cmpw    $DoC_2k_CDSN_IO, %si
+       je      mil_spec_end2
+       movb    BX_LastDataRead, %al
+       stosb
+ mil_spec_end2:
+
+       testw   $0xffff, %di    /* Check if we've done a whole 0x10000 bytes 
*/
+       jnz     endloop         /* No - continue regardless */
+
+       /* Yes - increase %es */
+       movw    %es, %cx
+       addb    $0x10, %ch
+       movw    %cx, %es
+
+       call    is_256_byte
+       je      inc_hibyte
+
+       addb    $0x80, %cs:adrbit16     /* Increase bit 16 */
+       jnc     endloop         /* Did it overflow? */
+
+ inc_hibyte:
+       incb    %cs:adrbytehi           /* If so, increase the high byte too 
*/
+
+ endloop:      
+       popw    %cx             /* Restore the 'blocks remaining' count */
+       loop    copy_grub       /* Loop till completely done */
+       ret
+
+ is_256_byte:
+       cmpb    $1,%cs:page256
+       ret
+
 
 /*
  * message: write the string pointed to by %si
@@ -229,34 +408,64 @@
         */
 1:
        call    printchar
-.globl message; message:
+message:
        lodsb   %cs:(%si)
        cmpb    $0, %al
        jne     1b      /* if not end of string, jmp to display */
        ret
 
-.globl printspace; printspace:
+#ifdef SHOW_INFO
+       /* Hex output routines, used at one point in debugging */       
+phword:
+        pushw   %ax
+        xchgb   %al,%ah
+        call    phbyte
+        movb    %ah,%al
+        call    phbyte
+        popw    %ax
+        ret
+
+phbyte:
+        pushw   %ax
+        movb    %al, %ah
+        shrb    $4,%al
+        call    phnibble
+        movb    %ah, %al
+        call    phnibble
+        popw    %ax
+        ret
+
+phnibble:
+        pushw   %ax
+        andb    $0xf,%al
+        addb    $48,%al
+        cmpb    $57,%al
+        jna     ph1
+        add     $7,%al
+ph1:    call   printchar
+        popw    %ax
+        ret
+
+printspace:
        mov     $' ', %al
-.globl printchar; printchar:
+printchar:
        movb    $0xe, %ah
        movw    $0x0001, %bx
        int     $0x10
        ret
 
+#endif         /* defined(SHOW_INFO) */
+
 doc_seg:       .word 0
+page256:       .byte   0
 
 doc_bios_hook_execed_string:   .string "DoC"
-doc_2k_string: .string "2000"
-doc_mil_string:        .string "Mil"
-eol_string:    .string "\r\n"
-doc_bios_scan_start_string:    .string "DoC found\r\n"
-
-       .org 0x100
-stage1b:       
-
-.globl doc_wait
-.globl doc_cmd
-.globl message
-.globl phword
-.globl phbyte
+doc_2k_string:                 .string "2000"
+doc_mil_string:                        .string "Mil"
+eol_string:                            .string "\r\n"
+doc_bios_scan_start_string:            .string "DoC found\r\n"
+msgjmp:                                .string "Jumping to Grub\n\r"
+
+       .org 0x1ff
+       .byte 0 /* checksum */
 

--- doc_stage1.h.orig   Tue Jul 16 14:40:15 2002
+++ doc_stage1.h        Tue Jul 16 14:24:14 2002
@@ -74,6 +74,7 @@
        
 #define NAND_CMD_READ0 0
 #define NAND_CMD_READ1 1
+#define NAND_CMD_READID 0x90
 #define NAND_CMD_RESET 0xff
 
 #include "stage2_size.h"


--- Makefile.orig       Tue Jul 16 14:25:46 2002
+++ Makefile    Tue Jul 16 14:25:42 2002
@@ -332,17 +332,8 @@
 
 # DoC Millennium firmware build
 
-doc_stage1b-$(DOC_MIL_PAGE).o: doc_stage1b.S doc_stage1.h \
-               stage2_size.h Makefile
-       $(CC) -o doc_stage1b-$(DOC_MIL_PAGE).o $(STAGE1_CFLAGS) \
-               -DPAGE$(DOC_MIL_PAGE) -fno-builtin -nostdinc -c doc_stage1b.S
-
-doc_stage1-$(DOC_MIL_PAGE).o: doc_stage1.o doc_stage1b-$(DOC_MIL_PAGE).o
-       $(LD) -N -Ttext 0 -o doc_stage1-$(DOC_MIL_PAGE).o \
-               doc_stage1.o doc_stage1b-$(DOC_MIL_PAGE).o
-
-doc_stage1: doc_stage1-$(DOC_MIL_PAGE).bin
-       cp -f doc_stage1-$(DOC_MIL_PAGE).bin doc_stage1
+doc_stage1: doc_stage1.bin
+       cp -f doc_stage1.bin doc_stage1
 
 # DoC 2000 firmware build
 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-07-16 18:52 [patch] doc_stage1.S : GRUB on DoC Mark Meade
@ 2002-07-17 18:35 ` Ilguiz Latypov
  2002-07-30  4:11 ` Ilguiz Latypov
  1 sibling, 0 replies; 15+ messages in thread
From: Ilguiz Latypov @ 2002-07-17 18:35 UTC (permalink / raw)
  To: Mark Meade; +Cc: linux-mtd

On Tue, 16 Jul 2002, Mark Meade wrote:

> Ilguiz -- is the DOC_MIL_KEEP_IPL option still used?

I never used this conditional piece of code because I don't have DoC
Millennium.  I added that code before I could better understand the
mechanism of initial loading with DoC Millennium.  I don't know if the
Millennium's own IPL can perform extra download from flash offset 1024.  
If it can't, the DOC_MIL_KEEP_IPL piece can be removed.

I am behind my schedule at work at this moment.  I will be able to test 
the improved code on DoC 2000 around next week.

Ilguiz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-07-16 18:52 [patch] doc_stage1.S : GRUB on DoC Mark Meade
  2002-07-17 18:35 ` Ilguiz Latypov
@ 2002-07-30  4:11 ` Ilguiz Latypov
  2002-08-01 18:43   ` Mark Meade
  1 sibling, 1 reply; 15+ messages in thread
From: Ilguiz Latypov @ 2002-07-30  4:11 UTC (permalink / raw)
  To: Mark Meade; +Cc: linux-mtd

Mark,

On Tue, 16 Jul 2002, Mark Meade wrote:

> These changes *should* also work for the DoC 2000, but I have not verified 
> this.  Changes will be necessary to the makefile and/or makecsum.c to 
> duplicate whatever code is at 0x100..0x1FF to 0x200..0x2FF.

Your unification patch has worked with DiskOnChip 2000 without a hitch.  I 
adjusted the stage2/Makefile.am file to reflect the simplified build 
procedure.  Thanks a bunch.  

There is no longer any hassle guessing page size for DoC Millennium at
compile time.  And DoC 2000 code will no longer depend on DoC 2000
pecularity with interleaving pages.

I added floppy disk BIOS number (0) as a last resort when looking for boot
configuration file.  Would you mind testing the aggregate patch I stored
under

    patches/grub-2002-07-29-doc.patch

Ilguiz

I believe the compile time difference will

> Ilguiz -- is the DOC_MIL_KEEP_IPL option still used?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [patch] doc_stage1.S : GRUB on DoC
@ 2002-08-01 14:47 Vadim Khmelnitsky
  0 siblings, 0 replies; 15+ messages in thread
From: Vadim Khmelnitsky @ 2002-08-01 14:47 UTC (permalink / raw)
  To: 'Ilguiz Latypov', Mark Meade; +Cc: linux-mtd

Hi,

DOC_Millennium 8MB has small SRAM of 512bytes in size to accomodate IPL code
.
two copies of IPL code should be placed at offset 0 and offset 0x200 ( first
and second page ) of erasable unit 0 .

Vadim

-----Original Message-----
From: Ilguiz Latypov [mailto:ilatypov@superbt.com]
Sent: Wed, July 17, 2002 11:35 AM
To: Mark Meade
Cc: linux-mtd@lists.infradead.org
Subject: Re: [patch] doc_stage1.S : GRUB on DoC



On Tue, 16 Jul 2002, Mark Meade wrote:

> Ilguiz -- is the DOC_MIL_KEEP_IPL option still used?

I never used this conditional piece of code because I don't have DoC
Millennium.  I added that code before I could better understand the
mechanism of initial loading with DoC Millennium.  I don't know if the
Millennium's own IPL can perform extra download from flash offset 1024.  
If it can't, the DOC_MIL_KEEP_IPL piece can be removed.

I am behind my schedule at work at this moment.  I will be able to test 
the improved code on DoC 2000 around next week.

Ilguiz


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-07-30  4:11 ` Ilguiz Latypov
@ 2002-08-01 18:43   ` Mark Meade
  2002-08-01 20:53     ` Ilguiz Latypov
  0 siblings, 1 reply; 15+ messages in thread
From: Mark Meade @ 2002-08-01 18:43 UTC (permalink / raw)
  To: Ilguiz Latypov; +Cc: linux-mtd

Ilguiz,

I tested the 07-29 patch on a DoC Millennium, and everything seemed to be 
working great.  I was able to build it against cvs grub with no errors, and 
the resulting grub_firmware booted fine on a 1.3Ghz Athlon.

However, I have also been experimenting with booting a variant of the Linux 
Router Project (LRP) from my DoC, and this latest Grub patch locks up on two 
different Pentium-133 PC's.  

Additionally, the M-Sys firmware also locked up on both machines.  The 
earlier Grub patch (the one with the -256 and -512 options) works fine.  I'm 
not sure what's going on here, but I'll continue to try to figure out what is 
wrong.  

Mark

Ilguiz Latypov wrote:
> I added floppy disk BIOS number (0) as a last resort when looking for boot
> configuration file.  Would you mind testing the aggregate patch I stored
> under
>
>     patches/grub-2002-07-29-doc.patch

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-01 18:43   ` Mark Meade
@ 2002-08-01 20:53     ` Ilguiz Latypov
  2002-08-01 21:21       ` Mark Meade
  0 siblings, 1 reply; 15+ messages in thread
From: Ilguiz Latypov @ 2002-08-01 20:53 UTC (permalink / raw)
  To: Mark Meade; +Cc: linux-mtd

On Thu, 1 Aug 2002, Mark Meade wrote:

> Additionally, the M-Sys firmware also locked up on both machines.  The 
> earlier Grub patch (the one with the -256 and -512 options) works fine.  I'm 
> not sure what's going on here, but I'll continue to try to figure out what is 
> wrong.  

Could that be due to change in MTD patch I made?  I added the
informational message output "DoC found" at the time of ROM BIOS extension
scan.  I wonder if the video card's BIOS extension can render INT 10h
unstable at that time.

Ilguiz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-01 20:53     ` Ilguiz Latypov
@ 2002-08-01 21:21       ` Mark Meade
  2002-08-01 23:44         ` Ilguiz Latypov
  0 siblings, 1 reply; 15+ messages in thread
From: Mark Meade @ 2002-08-01 21:21 UTC (permalink / raw)
  To: Ilguiz Latypov; +Cc: linux-mtd

Ilguiz Latypov wrote:

> Could that be due to change in MTD patch I made?  I added the
> informational message output "DoC found" at the time of ROM BIOS extension
> scan.  I wonder if the video card's BIOS extension can render INT 10h
> unstable at that time.

I don't think so -- I temporarily removed that message, and made sure that 
the initial code (what used to be in doc_stage1.S) matched the previous 
version that worked.  It didn't make any difference - it still locked up on 
the P-133's, but not on the Athlon.

For what it's worth, on one of the PC's, the lockup occurs at line 363, in 
the readbyte loop.  We copy a few pages OK (%di = 0x400, 0x500, 0x600), but 
lock up when %di is between 0x700 and 0x800, specifically with ES:DI equal to 
0x07E0:0x0719.

The other board makes it to the "Jumping to Grub" message, but then 
immediately reboots.

Mark

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-01 21:21       ` Mark Meade
@ 2002-08-01 23:44         ` Ilguiz Latypov
  2002-08-02 13:37           ` Mark Meade
  0 siblings, 1 reply; 15+ messages in thread
From: Ilguiz Latypov @ 2002-08-01 23:44 UTC (permalink / raw)
  To: Mark Meade; +Cc: linux-mtd

Would this modification make a difference?  It seems we read the first 
flash block into a different address when identifying the chip.

Ilguiz

--- doc_stage1.S	30 Jul 2002 01:09:35 -0000	1.12
+++ doc_stage1.S	1 Aug 2002 23:22:05 -0000
@@ -192,13 +192,13 @@
        /* Use existing block read routine to get Manufacturer &
        ** Chip ID.  Overkill, but saves code space.  */  
 
-       movw    $1, %cx         /* read just one page */
-       movw    $GRUBSTART, %ax
+       movw    $1, %cx			/* read just one block */
+       movw    $GRUBLOADSEG, %ax
        movw    %ax, %es
-       movw    $0, %di
+       movw    $GRUBLOADOFS, %di
        call    read_block
 
-       movw    %es:0,%ax               /* id/mfr in first 2 bytes */
+       movw    %es:(GRUBLOADOFS), %ax	/* id/mfr in first 2 bytes */
 
 #ifdef SHOW_INFO
 

On Thu, 1 Aug 2002, Mark Meade wrote:

> We copy a few pages OK (%di = 0x400, 0x500, 0x600), but lock up when %di
> is between 0x700 and 0x800, specifically with ES:DI equal to
> 0x07E0:0x0719.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-01 23:44         ` Ilguiz Latypov
@ 2002-08-02 13:37           ` Mark Meade
  2002-08-02 14:02             ` Ilguiz Latypov
  0 siblings, 1 reply; 15+ messages in thread
From: Mark Meade @ 2002-08-02 13:37 UTC (permalink / raw)
  To: Ilguiz Latypov; +Cc: linux-mtd

Ilguiz Latypov wrote:
> Would this modification make a difference?  It seems we read the first
> flash block into a different address when identifying the chip.

This didn't make any difference.  It still works find on the faster machine; 
reboots on the P133.

Using GRUBSTART:0 is probably the better way to do this: GRUBSTART:0 is 
equivalent to GRUBLOADSEG:GRUBLOADOFS (8200:0, 07E0:400), and using zero as 
the offset causes the "read block" command to send an address of 0 after 
sending the READID command, similar to the way it's done in bdev_diskonchip.c.

Either way, the result (mfg/id code) temporarily ends up at 8200:0, prior to 
be replaced by the Grub code.

Mark

> -       movw    $1, %cx         /* read just one page */
> -       movw    $GRUBSTART, %ax
> +       movw    $1, %cx			/* read just one block */
> +       movw    $GRUBLOADSEG, %ax
>         movw    %ax, %es
> -       movw    $0, %di
> +       movw    $GRUBLOADOFS, %di
>         call    read_block

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-02 13:37           ` Mark Meade
@ 2002-08-02 14:02             ` Ilguiz Latypov
  2002-08-02 19:18               ` Ilguiz Latypov
  2002-08-02 19:49               ` Mark Meade
  0 siblings, 2 replies; 15+ messages in thread
From: Ilguiz Latypov @ 2002-08-02 14:02 UTC (permalink / raw)
  To: Mark Meade; +Cc: linux-mtd

Mark,

On Fri, 2 Aug 2002, Mark Meade wrote:

> Using GRUBSTART:0 is probably the better way to do this: GRUBSTART:0 is 
> equivalent to GRUBLOADSEG:GRUBLOADOFS (8200:0, 07E0:400), and using zero as 
                                         ^^^^    ^^^^
I believe GRUBSTART is the offset value while GRUBLOADSEG is the segment 
value, i.e. GRUBSTART == (GRUBLOADSEG << 4) + GRUBLOADOFS.  The original 
code was reading a 256 byte flash block into 0x8200:0 which is 532480, and 
this could be either GRUB's playground or interrupt handlers set up by 
BIOS.

> the offset causes the "read block" command to send an address of 0 after
> sending the READID command, similar to the way it's done in
> bdev_diskonchip.c.

I understand that the same register %di serves as the offset to the
destination in RAM and as the offset in flash.  And stage2 or doc2000.c 
code will read chip ID from offset 0.  I think the offset may not be 
important because the READID command tells the chip to report the ID.  

I'd better assign (GRUBLOADSEG << 4) to %es and 0 to %di to stay safe 
though.

Ilguiz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-02 14:02             ` Ilguiz Latypov
@ 2002-08-02 19:18               ` Ilguiz Latypov
  2002-08-02 19:49               ` Mark Meade
  1 sibling, 0 replies; 15+ messages in thread
From: Ilguiz Latypov @ 2002-08-02 19:18 UTC (permalink / raw)
  To: Mark Meade; +Cc: linux-mtd

On Fri, 2 Aug 2002, Ilguiz Latypov wrote:

> I'd better assign (GRUBLOADSEG << 4) to %es and 0 to %di to stay safe 
> though.

I meant GRUBSTART >> 4.  Sorry.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-02 14:02             ` Ilguiz Latypov
  2002-08-02 19:18               ` Ilguiz Latypov
@ 2002-08-02 19:49               ` Mark Meade
  2002-08-02 21:27                 ` Ilguiz Latypov
  1 sibling, 1 reply; 15+ messages in thread
From: Mark Meade @ 2002-08-02 19:49 UTC (permalink / raw)
  To: Ilguiz Latypov; +Cc: linux-mtd

Ilguiz,

Indeed, the READID command doesn't seem to care what address is sent -- the 
answer came back correctly either way.

Here's what I've learned so far:

1)  The Grub CVS code (from 7/30), with the 2002-06-21 patch applied also 
causes the P133 machine to reboot.  This code has none of the combined 
doc_stage1/1b additions made in the 07-29 patch.

2)  The 0.92 Grub, with an earlier doc patch (I think it was 05-30) boots 
fine.

3)  Using the combined doc_stage1/1b with 0.92 Grub does not work.

Again, all three combinations above work just fine on the faster PC.

Item #1 seems to suggest that cvs grub may have introduced the problem, but 
in that case #3 should work.  Item #3 was patched manually (just doc_stage1.S 
and the Makefile), so it's possible I missed something else in your 07-29 
patch.

Anyway, is it possible to take an unmodified 0.92 Grub, and cleanly apply the 
latest (07-29) patch?  I was not able to do this, mainly because of automake 
version differences.  

Thanks,

Mark

Ilguiz Latypov wrote:
> I understand that the same register %di serves as the offset to the
> destination in RAM and as the offset in flash.  And stage2 or doc2000.c
> code will read chip ID from offset 0.  I think the offset may not be
> important because the READID command tells the chip to report the ID.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-02 19:49               ` Mark Meade
@ 2002-08-02 21:27                 ` Ilguiz Latypov
  2002-08-02 21:57                   ` Ilguiz Latypov
  0 siblings, 1 reply; 15+ messages in thread
From: Ilguiz Latypov @ 2002-08-02 21:27 UTC (permalink / raw)
  To: Mark Meade; +Cc: linux-mtd

On Fri, 2 Aug 2002, Mark Meade wrote:

> Anyway, is it possible to take an unmodified 0.92 Grub, and cleanly apply the 
> latest (07-29) patch?  I was not able to do this, mainly because of automake 
> version differences.  

I once moved to post-0.92 snapshot by adjusting the MTD DOC patch to the
new terminal emulation.  It's not a big deal to downgrade the terminal
emultaion changes, but I have some other issues at work till the middle of
August.

I updated the 07-29 patch in the folowing areas:
 
  a) correct the READID memory block and flash addresses
  b) restore the accidentally dropped builtins.c modifications

The correction (b) came up after a routine check of the new patch against
the old patch.  Could be another reason for GRUB malfunction on P133...

Ilguiz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-02 21:27                 ` Ilguiz Latypov
@ 2002-08-02 21:57                   ` Ilguiz Latypov
  2002-08-06 16:26                     ` Mark Meade
  0 siblings, 1 reply; 15+ messages in thread
From: Ilguiz Latypov @ 2002-08-02 21:57 UTC (permalink / raw)
  To: Mark Meade; +Cc: linux-mtd

On Fri, 2 Aug 2002, Ilguiz Latypov wrote:

> It's not a big deal to downgrade the terminal emultaion changes, but I
> have some other issues at work till the middle of August.

I produce more noise than I code :)  I attempted to downgrade to 0.92 and 
added the grub-0.92-doc.patch to the CVS mtd/patches area.

Both 07-29 and 0.92 patches work with 32M DoC 2000 on the Advantech PCA 
6753 F board.

Ilguiz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [patch] doc_stage1.S : GRUB on DoC
  2002-08-02 21:57                   ` Ilguiz Latypov
@ 2002-08-06 16:26                     ` Mark Meade
  0 siblings, 0 replies; 15+ messages in thread
From: Mark Meade @ 2002-08-06 16:26 UTC (permalink / raw)
  To: Ilguiz Latypov; +Cc: linux-mtd

Ilguiz Latypov wrote:
> Both 07-29 and 0.92 patches work with 32M DoC 2000 on the Advantech PCA
> 6753 F board.

Ilguiz,

Both patches are now working great on both the faster PC and the P133 system.

I finally figured out what is going on with Grub not working on a P133 
system:  The grub_firmware produced on a Debian system (gcc 2.95.4) works 
fine on both machines; grub_firmware from a Gentoo system (gcc 2.95.3) works 
on the faster PC, but not on the P133.

> I believe GRUBSTART is the offset value while GRUBLOADSEG is the segment 
> value, i.e. GRUBSTART == (GRUBLOADSEG << 4) + GRUBLOADOFS.

My apologies for misunderstanding your earlier post.  Your latest change puts 
the manufacturer/id code where I had intended it to be; I goofed on the 
offset value in the original patch.

It's my understanding that these DoC 2000/Millennium patches will soon be 
incorporated into the official Grub sources.   Until then, if anyone else is 
interested in trying the latest patches, here's a summary:

GRUB CVS: http://savannah.gnu.org/cvs/?group=grub
Patch: grub-2002-07-29-doc.patch (MTD cvs)
On a Debian system, use: 
aclocal-1.6 && automake-1.6 --add-missing && autoconf2.50

GRUB 0.92: http://www.gnu.org/software/grub/grub-0.92.tar.gz
Patch: grub-0.92-doc.patch (MTD cvs)

Instructions:
http://lists.infradead.org/pipermail/linux-mtd/2002-June/005240.html
(With these patches, use "--enable-diskonchip-mil" for all DoC Millenniums)

Mark

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2002-08-06 16:27 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-07-16 18:52 [patch] doc_stage1.S : GRUB on DoC Mark Meade
2002-07-17 18:35 ` Ilguiz Latypov
2002-07-30  4:11 ` Ilguiz Latypov
2002-08-01 18:43   ` Mark Meade
2002-08-01 20:53     ` Ilguiz Latypov
2002-08-01 21:21       ` Mark Meade
2002-08-01 23:44         ` Ilguiz Latypov
2002-08-02 13:37           ` Mark Meade
2002-08-02 14:02             ` Ilguiz Latypov
2002-08-02 19:18               ` Ilguiz Latypov
2002-08-02 19:49               ` Mark Meade
2002-08-02 21:27                 ` Ilguiz Latypov
2002-08-02 21:57                   ` Ilguiz Latypov
2002-08-06 16:26                     ` Mark Meade
  -- strict thread matches above, loose matches on Subject: below --
2002-08-01 14:47 Vadim Khmelnitsky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox