Amstrad ppc640

Amstrad ppc640

[Joost Vermeulen]

Hi,

I tried to boot ELKS on mine PPC640 (8088 with 640k) Amstrad computer
but i can seem to get it to work. The kernel boots (default and custom),
but when it attemps to mount the root disk and start init it gives the
next errors. 

	VFS: Mounted root (minix filesystem).
	Loading init
	Unable to open /dev/tty (error 2)
	dup failed
	No init - running /bin/sh

	panic: No init or sh found
	apparant call stack:
	(0) ret addr = 151 params = 0 0 0 0 0 0
	(1) ret addr = 0 params = 23A0 Ad A000 2DAC 0 0
	(2) ret addr = 9E params = F200 1EDC E884 0 0 1
	(3) ret addr = 1E params = 0 0 0 0 0 0
	(4) ret addr = 0 params = 0 0 0 0 0 0
	(5) ret addr = 0 params = 0 0 0 0 0 0
	(6) ret addr = 0 params = 0 0 0 0 0 0
	(7) ret addr = 0 params = 0 0 0 0 0 0

I'm using the standard root disks from the website.

Thanks in advance, Joost

Re: Amstrad ppc640

[Riley Williams]

Hi Joost.

> I tried to boot ELKS on mine PPC640 (8088 with 640k) Amstrad
> computer but i can seem to get it to work. The kernel boots (default
> and custom), but when it attemps to mount the root disk and start
> init it gives the next errors.
>
> 	VFS: Mounted root (minix filesystem).
> 	Loading init
> 	Unable to open /dev/tty (error 2)
> 	dup failed
> 	No init - running /bin/sh
>
> 	panic: No init or sh found
> 	apparant call stack:
> 	(0) ret addr = 151 params = 0 0 0 0 0 0
> 	(1) ret addr = 0 params = 23A0 Ad A000 2DAC 0 0
> 	(2) ret addr = 9E params = F200 1EDC E884 0 0 1
> 	(3) ret addr = 1E params = 0 0 0 0 0 0
> 	(4) ret addr = 0 params = 0 0 0 0 0 0
> 	(5) ret addr = 0 params = 0 0 0 0 0 0
> 	(6) ret addr = 0 params = 0 0 0 0 0 0
> 	(7) ret addr = 0 params = 0 0 0 0 0 0
>
> I'm using the standard root disks from the website.

That looks like the bug we've literally just fixed - as part of my
ANSI'fication of the ELKS source, I accidentally inverted one of the
conditions, and it did just what you're reporting as a result.

Harry: Did a version with the bug in it get released as images on the
website?

Best wishes from Riley.

Amstrad ppc640

[Joost Vermeulen]

Hi all,

I tried the current floppy images on my Amstrad 640ppc, but 
after it mounted the root filesystem, it gives some error 
messages. This results in a kernel panic. Has somebody succeeded
in running elks on an Amstrad ? Or does this sound familair to 
someone ?

I tried all the images from images-0.1.0.zip which contains ELKS 0.1.0
Information on the Amstrad can be found at 
http://www.sinasohn.com/cgi-bin/clascomp/bldhtm.pl?computer=ppc640

Error log:

VFS: Mounted root (minix filesystem).
Loading init
sys_execve("/bin/init",args,18) => 65534.
Unable to open /dev/tt (error 2)
dup failed
No init - running /bin/sh

panic: No init or sh found
apparant call stack:
(0) ret addr = 164 params 0 0 0 0 0 0
(1) ret addr = 0 params = 23D0 AD A000 2D86 E784 98
(2) ret addr = 9E params = F0A0 1F0C E748 0 0 1
(3) ret addr = 1E params = 0 0 0 0 0 0
(4) ret addr = 0 params = 0 0 0 0 0 0
(5) ret addr = 0 params = 0 0 0 0 0 0
(6) ret addr = 0 params = 0 0 0 0 0 0
(7) ret addr = 0 params = 0 0 0 0 0 0

Greetings,
   Joost Vermeulen

RE: Amstrad ppc640

[Riley Williams]

Hi Joost.

 > I tried the current floppy images on my Amstrad 640ppc, but
 > after it mounted the root file system, it gives some error
 > messages. This results in a kernel panic. Has somebody succeeded
 > in running elks on an Amstrad ? Or does this sound familiar to
 > someone ?
 >
 > I tried all the images from images-0.1.0.zip which contains ELKS
 > 0.1.0 Information on the Amstrad can be found at
 > http://www.sinasohn.com/cgi-bin/clascomp/bldhtm.pl?computer=ppc640
 >
 > Error log:
 >
 > VFS: Mounted root (minix filesystem).
 > Loading init
 > sys_execve("/bin/init",args,18) => 65534.
 > Unable to open /dev/tt (error 2)
 > dup failed
 > No init - running /bin/sh

According to those messages, the root image is missing both /bin/init
and /bin/sh so it would be an idea to verify whether those files are
actually present at those paths within the root image.

 > panic: No init or sh found
 > apparant call stack:
 > (0) ret addr = 164 params 0 0 0 0 0 0
 > (1) ret addr = 0 params = 23D0 AD A000 2D86 E784 98
 > (2) ret addr = 9E params = F0A0 1F0C E748 0 0 1
 > (3) ret addr = 1E params = 0 0 0 0 0 0
 > (4) ret addr = 0 params = 0 0 0 0 0 0
 > (5) ret addr = 0 params = 0 0 0 0 0 0
 > (6) ret addr = 0 params = 0 0 0 0 0 0
 > (7) ret addr = 0 params = 0 0 0 0 0 0

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 16-Jun-2003

Re: Amstrad ppc640

[Joost Vermeulen]

On Wed, Jun 18, 2003 at 08:43:06PM +0100, Riley Williams wrote:
 >According to those messages, the root image is missing both /bin/init
 >and /bin/sh so it would be an idea to verify whether those files are
 >actually present at those paths within the root image.
 >

The image runs perfectly on my workstation, so I guess both /bin/init
and /bin/sh are on the filesystem :)

Joost

Re: Amstrad ppc640

[Joost Vermeulen]

On Wed, Jun 18, 2003 at 11:20:59PM +0100, Riley Williams wrote:
 >Hi Joost.
 >
 > >> According to those messages, the root image is missing both
 > >> /bin/init and /bin/sh so it would be an idea to verify whether
 > >> those files are actually present at those paths within the
 > >> root image.
 >
 > > The image runs perfectly on my workstation, so I guess both
 > > /bin/init and /bin/sh are on the file system :)
 >
 >The easy way to be certain...
 >
 > 1. Copy the root image to the file ~/elks-root.img on your
 >    workstation.
 >
 > 2. Run the following commands thereon:
 >
 >	mkdir ~/elks-root
 >	mount -o loop ~/elks-root.img ~/elks-root
 >	ls -l /bin/{init,sh}
 >	umount ~/elks-root
 >
 >If the ls -l command fails to list either file, that file isn't
 >where it's supposed to be...
 >

Both files are where they supposed to be, so that couldn't be the problem
I'm thinking that it has to do something with dup, 'cause it says dup failed
but it is kinda odd, that is runs out of filehandlers, that isn't hardware
based is it ? A quick manlookup of dup says: 

ERRORS
     Dup() and dup2() fail if:

     [EBADF]            Oldd or newd is not a valid active descriptor

     [EMFILE]           Too many descriptors are active.

But it could also be something else :)

Joost

Re: Amstrad ppc640

[Richard Wallman]

Just been playing around with ELKS on my TI TravelMate 2000, and I got
the same problems with init and sh.

When I compile the kernel to get drive info from INT13, it seems to get
the number of sectors on a floppy wrong - it seems to think there's 19
sectors. Hence, loading init fails miserably.

Re-compile turning "Use INT13" off, it correctly identifies 18 sectors.

I don't know if that's an issue with my laptop, or with the code - it
might be interesting if people conduct the same experiment (kernels
with and without using INT13) and post the results.

-- 
Richard Wallman
http://www.murkygoth.co.uk/elks

Re: Amstrad ppc640

[Dan Olson]

> I don't know if that's an issue with my laptop, or with the code - it
> might be interesting if people conduct the same experiment (kernels
> with and without using INT13) and post the results.

Would it be of any value to try ELKS on another TI travelmate?  I think
I've got one somewhere.

	Dan

RE: Amstrad ppc640

[Riley Williams]

Hi Richard.

 > Just been playing around with ELKS on my TI TravelMate 2000,
 > and I got the same problems with init and sh.
 >
 > When I compile the kernel to get drive info from INT13, it
 > seems to get the number of sectors on a floppy wrong - it
 > seems to think there's 19 sectors. Hence, loading init fails
 > miserably.

That indicates that your computer doesn't support INT 13 for
determining the parameters of a floppy disk. Such is common for
XT class computers as the INT 13 facility wasn't introduced
until the PC/AT came in. Since there is no means for the ELKS
kernel to determine whether INT 13 support is included, this is
something that |MUST be correctly configured when compiling the
ELKS kernel.

 > Re-compile turning "Use INT13" off, it correctly identifies
 > 18 sectors.

With INT 13 support disabled, the ELKS kernel simply tries to
read sectors on track 0 starting with the highest numbered one,
and counting down until it reads one successfully. It assumes
that the sector number read is the number of sectors that disc
is formatted with for all tracks, so will get copy-protected
floppies wrong and all other floppies correct.

 > I don't know if that's an issue with my laptop, or with the
 > code - it might be interesting if people conduct the same
 > experiment (kernels with and without using INT13) and post
 > the results.

As stated above, it's an issue with the fact that your laptop
is a PC/XT clone, and thus does not include facilities that
were not implemented on the genuine PC/XT. It's thus something
that is pretty much expected on that class of machine.

Incidentally, because of the above, the safe option is to
disable use of INT 13 and let it probe each floppy in turn.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 18-Jun-2003