Re: I write a patch for Japanese NEC i386 old computers.

Re: I write a patch for Japanese NEC i386 old computers.

[Ernest Sales]

On Sun, 25 Mar 2007 00:00:32 +0100 Yoshinori K. Okuji wrote:

> I have a question about the naming. Is it usual to call the platform
"nec98"? 
> I don't know how it is called in Linux/PC98 or FreeBSD(98), but it should
be 
> named in a similar way, I guess.

AFAIK in FreeBSD it is known as pc98, see for instance:

http://www.freebsd.org/relnotes/6-STABLE/hardware/

...but you better check this is the architecture you mean.

Regards,
Ernest Sales

---------------------------------------------------------------
plain text emails preferred, cf http://expita.com/nomime.html

Re: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello, all.

1. name of architecture.

In Japan, The 'PC-98' means the NEC PC-9800 series and its compatible
machines.
But, In the other country, 'PC98' means a hardware standard set by Microsoft
and
a consortium of hardware manufacturers.
I afraid to mistake, so named as 'NEC98'. But, I do not have a intent to
persist this name.

2. sharing of code with PC's.

Sharing of code with PC's bring me several problems.
Firstly, In this time, My patch includes a lot of PC's code. But amount of
the PC-9800 depended code will increase.
Secondaly, when changes PC's depended code, PC-9800 code shuld change also.
I think GRUB2 is next generation
of GRUB, not on the stable.

3. known bugs/problems of patches in this time.

* Scroll routine of console has a bug, bares trashes on the lowest line.
Should fix.
* Remains code of VGA and VBE, I'll replace to PC-9800 graphics routine.
* In the high-rezo mode, I do not have tested, not have any datasheet and
machine.
   (NEC released a few high-rezo supported machines, so this is little
problem.)
* Algorythm of transfering from LBA to CHS, I have trusted the answer of
BIOS. Should compute myself.(difficult)
* SASI/ATAPI device is not supported, should support this.(difficult)
* Listing devices by 'ls' command. when exists not-ready removable device,
its command ends with fail.
* cannot boot the FreeBSD(pc98). Should fix.
* 'play' command is not tested.
* On booting the Linux with framebuffer console,  cannot display correctly.
* First NEC PC-9801, PC-9801E, PC-9801F, and PC-9801M are not supported.
Support those.(not a big problem.)

4. Wish to discuss.

* Support of different sector-sizes, MO(Magneto Optical) disk uses
512/1024/2048 b/s(bytes per sector).
  CD-ROM uses 2048 b/s, FD of formatted by PC-9800 series often uses 1024
b/s, Old OS uses 256/128 b/s.
* When doing 'chainloader' command, the all disk devices cannot use via
'dev.c',
  because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
  I think it is disirable to do 'grub_loader_unload_func' on 'grub_*_boot'.

I try to fix this patches, and disclose in future.

Regard,

-- 
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

Re: I write a patch for Japanese NEC i386 old computers.

[Yoshinori K. Okuji]

On Wednesday 28 March 2007 17:27, Hitoshi Ozeki wrote:
> 1. name of architecture.
>
> In Japan, The 'PC-98' means the NEC PC-9800 series and its compatible
> machines.
> But, In the other country, 'PC98' means a hardware standard set by
> Microsoft and
> a consortium of hardware manufacturers.
> I afraid to mistake, so named as 'NEC98'. But, I do not have a intent to
> persist this name.

It is very difficult to say what name is appropriate. As far as I know, there 
is no consensus about this. FreeBSD uses "pc98", but I guess this is only 
because 386BSD(98) used "pc98", which was probably named by Ishii-san or 
Kojima-san.

Uhmm, very difficult. You are right, PC98 might be a bit confusing for some 
people. But NEC98 is unusual to me, and it sounds like excluding Epson's 
models.

For now, I prefer "pc98", because it is at least consistent with FreeBSD.

> 2. sharing of code with PC's.
>
> Sharing of code with PC's bring me several problems.
> Firstly, In this time, My patch includes a lot of PC's code. But amount of
> the PC-9800 depended code will increase.

Good point. If you think it is hard to share code, please don't try to share 
too much. Something I really want to avoid is to use a lot of cpp 
conditionals, only to share code.

> Secondaly, when changes PC's depended code, PC-9800 code shuld change also.
> I think GRUB2 is next generation
> of GRUB, not on the stable.

Yes, but I don't think it will change radically. I would like to change the 
way of reserving memory for GRUB, but this change should not affect so much.

> 4. Wish to discuss.
>
> * Support of different sector-sizes, MO(Magneto Optical) disk uses
> 512/1024/2048 b/s(bytes per sector).
>   CD-ROM uses 2048 b/s, FD of formatted by PC-9800 series often uses 1024
> b/s, Old OS uses 256/128 b/s.

I think there are two different ways to address this issue. One way is to use  
variable sector size. This looks elegant, but this affects the disk device 
API very much. The other is to use fixed sector size, as it is for now, but 
align boundaries at a device driver level. The latter way is used for GRUB 
Legacy to support CDROM, and it works well.

I don't know which way is better. What do you think?

> * When doing 'chainloader' command, the all disk devices cannot use via
> 'dev.c',
>   because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
>   I think it is disirable to do 'grub_loader_unload_func' on 'grub_*_boot'.

Could you elaborate on why this is bad?

Okuji

i386-pc 'chainloader' is something wrong. (RE: I write a patch for Japanese NEC i386 old computers.)

[Hitoshi Ozeki]

Hello,

I wrote:
> * When doing 'chainloader' command, the all disk devices cannot use via
> 'dev.c',
>   because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
>   I think it is disirable to do 'grub_loader_unload_func' on
'grub_*_boot'.

Okuji-san wrote:
> Could you elaborate on why this is bad?

At first, excuse me. 'grub_loader_unload_func' is not bad.
Please see 'grub-1.96/loader/i386/pc/chainloader.c' and
 'grub-1.96/kern/loader.c'

When we execute the 'boot' command, process the 'grub_loader_boot()'
--------------------------------------------------
grub_loader_boot (void)
{
  if (! grub_loader_loaded)
    return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");

  if (grub_loader_noreturn)
    grub_machine_fini (); <--- includes 'grub_biosdisk_fini()'
  
  return (grub_loader_boot_func) ();  <--- call the
'grub_chainloader_boot()'
}
--------------------------------------------------

And 'grub_loader_boot()' passes to 'grub_chainloader_boot()'

--------------------------------------------------
grub_chainloader_boot (void)
{
  grub_device_t dev;
  int drive = -1;
  void *part_addr = 0;
  
  /* Open the root device.  */
  dev = grub_device_open (0);  <--- Ouch! Cannot open device!
  if (dev)
    {
      grub_disk_t disk = dev->disk;
--------------------------------------------------      

I experience this trouble during my work,
 so 'grub_chainloader_boot()' doesn't open the root device in PC-9800 patch.

RE: i386-pc 'chainloader' is something wrong. (RE: I write a patch forJapanese NEC i386 old computers.)

[Hitoshi Ozeki]

Hello,

I wrote:
> Please see 'grub-1.96/loader/i386/pc/chainloader.c' and
>  'grub-1.96/kern/loader.c'
> 
> When we execute the 'boot' command, process the 'grub_loader_boot()'

(omit it)

To sum up, On 'chainloader' of i386-pc,
However 'grub_loader_boot()' executes 'grub_device_open()', it will fail
always.
But 'grub_loader_boot()'  do it.

If this behavior is wrong, we do only fix it.

What I wish to know is which is the boot drive.

1. 'root' environment indicates it.
2. argument of 'chainloader' command indicates it.

For example:
grub> set root=hd0,1
grub> chainloader (hd0,2)0+2
grub> boot

If the 1st is, boot from (hd0,1) and bootloader is (hd0,2)0+2.
If the 2nd is, boot from (hd0,2) and bootloader is (hd0,2)0+2.

...Aha! EFI looks to choose 1st. Should I obey it?

Re: i386-pc 'chainloader' is something wrong. (RE: I write a patch forJapanese NEC i386 old computers.)

[Yoshinori K. Okuji]

On Saturday 31 March 2007 06:24, Hitoshi Ozeki wrote:
> > Please see 'grub-1.96/loader/i386/pc/chainloader.c' and
> >  'grub-1.96/kern/loader.c'
> >
> > When we execute the 'boot' command, process the 'grub_loader_boot()'
>
> (omit it)
>
> To sum up, On 'chainloader' of i386-pc,
> However 'grub_loader_boot()' executes 'grub_device_open()', it will fail
> always.
> But 'grub_loader_boot()'  do it.
>
> If this behavior is wrong, we do only fix it.

You are right. This is wrong. I will have a look later.

> What I wish to know is which is the boot drive.
>
> 1. 'root' environment indicates it.
> 2. argument of 'chainloader' command indicates it.
>
> For example:
> grub> set root=hd0,1
> grub> chainloader (hd0,2)0+2
> grub> boot
>
> If the 1st is, boot from (hd0,1) and bootloader is (hd0,2)0+2.
> If the 2nd is, boot from (hd0,2) and bootloader is (hd0,2)0+2.
>
> ...Aha! EFI looks to choose 1st. Should I obey it?

Yes. This is the intented behavior. The distinction is important, because you 
might want to save a boot sector at somewhere else, and chainload it later. 
This feature makes recovery much easier.

Okuji

Re: i386-pc 'chainloader' is something wrong. (RE: I write a patch for Japanese NEC i386 old computers.)

[Yoshinori K. Okuji]

On Friday 30 March 2007 11:34, Hitoshi Ozeki wrote:
> I wrote:
> > * When doing 'chainloader' command, the all disk devices cannot use via
> > 'dev.c',
> >   because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
> >   I think it is disirable to do 'grub_loader_unload_func' on
>
> 'grub_*_boot'.
>
> Okuji-san wrote:
> > Could you elaborate on why this is bad?
>
> At first, excuse me. 'grub_loader_unload_func' is not bad.
> Please see 'grub-1.96/loader/i386/pc/chainloader.c' and
>  'grub-1.96/kern/loader.c'

I have fixed this right now. Thank you.

Okuji

RE: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello, all.

Okuji-san wrote about the different(128-2048 bytes) sector-size support:
	 I think there are two different ways to address this issue. One way
is to use  
	 variable sector size. This looks elegant, but this affects the disk
device 
	 API very much. The other is to use fixed sector size, as it is for
now, but 
	 align boundaries at a device driver level. The latter way is used
for GRUB 
	 Legacy to support CDROM, and it works well.
	 I don't know which way is better. What do you think?


Maybe, The implement of GRUB legacy comes from PC architecture.
On the PC architecture BIOS, regards 512 bytes as a block. And
BIOS requires a number of blocks.

On NEC PC-9800 series, Disk BIOS requires data size in byte,
not a number of sectors. Data size must be divisible by sector size.
And the partition table starts with LBA sector 1, and its length
equals to sector size.

It's too difficult to change the API.

I think to set the GRUB_DISK_SECTOR_SIZE as the least.
(As far as I know, The least hardware sector size is 128 bytes.)
and add the variable to 'struct grub_disk'. Its variable stores 
 sector size(blocks per sector).

In this case, A name of 'GRUB_DISK_SECTOR_SIZE' does not match
the actual situation. I'd like its name changed.

-- 
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

RE: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello, all.
	
Okuji-san wrote about the different(128-2048 bytes) sector-size support:
	I think there are two different ways to address this issue. One way
is to use
	variable sector size. This looks elegant, but this affects the disk
device 
	API very much. The other is to use fixed sector size, as it is for
now, but 
	align boundaries at a device driver level.
	(omit)
	 I don't know which way is better. What do you think?
	
I wrote in last article:
	I think to set the GRUB_DISK_SECTOR_SIZE as the least.
	(As far as I know, The least hardware sector size is 
	128 bytes.) and add the variable to 'struct grub_disk'. 
	Its variable stores 
	 sector size(blocks per sector).

In addition, Let me talk about the recent PC-9800 patch.
I use the GRUB_DISK_SECTOR_SIZE in a meaning of default sector size(=512).
and add the variable 'sector_size' to 'struct grub_disk'. 
GRUB_DISK_SECTOR_SIZE is used to initialize the 'sector_size'.
GRUB_DISK_SECTOR_SIZE is replaced with 'sector_size' in most case.

Re: I write a patch for Japanese NEC i386 old computers.

[Vesa Jääskeläinen]

Hitoshi Ozeki wrote:
> Hello, all.
> 	
> Okuji-san wrote about the different(128-2048 bytes) sector-size support:
> 	I think there are two different ways to address this issue. One way
> is to use
> 	variable sector size. This looks elegant, but this affects the disk
> device 
> 	API very much. The other is to use fixed sector size, as it is for
> now, but 
> 	align boundaries at a device driver level.
> 	(omit)
> 	 I don't know which way is better. What do you think?
> 	
> I wrote in last article:
> 	I think to set the GRUB_DISK_SECTOR_SIZE as the least.
> 	(As far as I know, The least hardware sector size is 
> 	128 bytes.) and add the variable to 'struct grub_disk'. 
> 	Its variable stores 
> 	 sector size(blocks per sector).
> 
> In addition, Let me talk about the recent PC-9800 patch.
> I use the GRUB_DISK_SECTOR_SIZE in a meaning of default sector size(=512).
> and add the variable 'sector_size' to 'struct grub_disk'. 
> GRUB_DISK_SECTOR_SIZE is used to initialize the 'sector_size'.
> GRUB_DISK_SECTOR_SIZE is replaced with 'sector_size' in most case.

Just a quick comment. Should we one day have direct support for CD-ROM's
or such devices which have larger sector sizes, I would propose that
this information should be dynamic and device specific. This change
probably causes some issues about how should grub be installed on
devices having sector size != 512. And should there be emulation layer
for 512 byte sector size? At least El Torito does provide this...