Re: A question about S/390 port
Apparently, On Thu, Jul 11, 2002 at 09:11:47AM +0400, Serguei Tzukanov said words to the effect of; On Thursday 11 July 2002 02:45, Jake Burkholder wrote: I think this is because your console driver (hc) doesn't have a tty interface, just the low level cn* stuff. If you look at the ofw_console driver, it provides a rudimentary tty interface using polling and cngetc, cnputc equivalents. Hm, what about /dev/console (tty_cons)? I put into /etc/ttys line console /usr/libexec/getty std.1200 vt100 on secure. Where exactly in init are you trying to print? If you're in the single_user function, you can only use stdio in the forked child after it calls setctty. Before that you have to open an fd on /dev/console yourself and write(2) to it, or call login_tty on it which dups the standard descriptors from it. I don't know if starting a getty on /dev/console will work, but in any case this doesn't happen until you go multi-user, iirc this line is only used for the secure keyword. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A question about S/390 port
On Thursday 11 July 2002 18:43, Jake Burkholder wrote: Where exactly in init are you trying to print? If you're in the single_user function, you can only use stdio in the forked child after it calls setctty. Before that you have to open an fd on /dev/console yourself and write(2) to it, or call login_tty on it which dups the standard descriptors from it. I don't know if starting a getty on /dev/console will work, but in any case this doesn't happen until you go multi-user, iirc this line is only used for the secure keyword. Problem is solved, I made as you'd said earlier: fixed hc to support tty interface. Right now I'm debugging sh crushing with sig 11. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
A question about S/390 port
Some working notes. I've written the libc/csu part, kernel successfully starts init and init forks off for the execve of -sh, (http://tzukanov.narod.ru/freebsd390/bootlog.txt) but there is problem with printing from userland, e.g. output from userland are not visible. Write syscall to descs 1,2 in init returns with success. I'm sure it's something very stupid, so maybe someone have a clue? And another problem (well-known?): __syscall returns 64-bit value but mmap returns 4-byte word in the td-td_retval[0]. Wrapper for mmap in libc casts 64 rv to 32 and alays gets zero. This leads to truncating to zero due to cast on 32-bit big-endian architectures. The solution is obvious - using constructs like td-td_retval[_QUAD_LOWWORD] = xxx in MI code. For now I just avoid it with hack in syscall handler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: A question about S/390 port
On 10-Jul-2002 Serguei Tzukanov wrote: Some working notes. I've written the libc/csu part, kernel successfully starts init and init forks off for the execve of -sh, (http://tzukanov.narod.ru/freebsd390/bootlog.txt) but there is problem with printing from userland, e.g. output from userland are not visible. Write syscall to descs 1,2 in init returns with success. I'm sure it's something very stupid, so maybe someone have a clue? And another problem (well-known?): __syscall returns 64-bit value but mmap returns 4-byte word in the td-td_retval[0]. Wrapper for mmap in libc casts 64 rv to 32 and alays gets zero. This leads to truncating to zero due to cast on 32-bit big-endian architectures. The solution is obvious - using constructs like td-td_retval[_QUAD_LOWWORD] = xxx in MI code. For now I just avoid it with hack in syscall handler. td_retval[0] is the low word, and td_retval[1] is the high word, you just need to make sure the values from those two words get returned properly to userland. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A question about S/390 port
td_retval[0] is the low word, and td_retval[1] is the high word, you
just need to make sure the values from those two words get returned
properly to userland.
1) syscall returns 32-bit value:
r2 = rv[0];
r3 = rv[1];
r3 is irrelevant here (ABI: 32-bit values returned in r2)
2) syscall returns 64-bit value:
MI code uses something like
*(int64_t *)rv = xxx, so I have to do
r2 = rv[0];
r3 = rv[1];
ABI says long long shall be returned with the lower
addressed half in r2 and the higher in r3
3) syscall folded into __syscall returns 32-bit value (e.g. mmap):
MI code does usual
r[0] = xxx;
svc (syscall) handler does
r2 = rv[0];
r3 = rv[1]; /* zeroed before */
then mmap wrapper in userspace casts this 64-bit to 32-bit
(loads r2 with r3 really) and always gets 0.
So to make it consistent I have to know size of returned value for every
syscall and for case 3 do {r3 = rv[0]; r2 = rv[1]}.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A question about S/390 port
On 10-Jul-2002 Serguei Tzukanov wrote: td_retval[0] is the low word, and td_retval[1] is the high word, you just need to make sure the values from those two words get returned properly to userland. 1) syscall returns 32-bit value: r2 = rv[0]; r3 = rv[1]; r3 is irrelevant here (ABI: 32-bit values returned in r2) 2) syscall returns 64-bit value: MI code uses something like *(int64_t *)rv = xxx, so I have to do r2 = rv[0]; r3 = rv[1]; ABI says long long shall be returned with the lower addressed half in r2 and the higher in r3 3) syscall folded into __syscall returns 32-bit value (e.g. mmap): MI code does usual r[0] = xxx; svc (syscall) handler does r2 = rv[0]; r3 = rv[1]; /* zeroed before */ then mmap wrapper in userspace casts this 64-bit to 32-bit (loads r2 with r3 really) and always gets 0. Why does the cast from 32 to 64 treat r3 as the lower 32-bits when a 64-bit return value treats r3 as the upper 32-bits and r2 as the lower 32-bits? That is inconsistent and you are going to have problems with either one or the other. I also don't understand exactly what you mean by syscall folded into __syscall. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A question about S/390 port
It sounds like a tty driver problem. Does the emulator even support this? Do you have a package, so that people can install your developement environment and use your patches so they can participate in helping you code? -- Terry Serguei Tzukanov wrote: Some working notes. I've written the libc/csu part, kernel successfully starts init and init forks off for the execve of -sh, (http://tzukanov.narod.ru/freebsd390/bootlog.txt) but there is problem with printing from userland, e.g. output from userland are not visible. Write syscall to descs 1,2 in init returns with success. I'm sure it's something very stupid, so maybe someone have a clue? And another problem (well-known?): __syscall returns 64-bit value but mmap returns 4-byte word in the td-td_retval[0]. Wrapper for mmap in libc casts 64 rv to 32 and alays gets zero. This leads to truncating to zero due to cast on 32-bit big-endian architectures. The solution is obvious - using constructs like td-td_retval[_QUAD_LOWWORD] = xxx in MI code. For now I just avoid it with hack in syscall handler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A question about S/390 port
John Baldwin wrote: Why does the cast from 32 to 64 treat r3 as the lower 32-bits when a 64-bit return value treats r3 as the upper 32-bits and r2 as the lower 32-bits? That is inconsistent and you are going to have problems with either one or the other. I also don't understand exactly what you mean by syscall folded into __syscall. God's byte order, rather than Intel's? 8-) 8-) ;^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A question about S/390 port
On Wednesday 10 July 2002 23:04, Julian Elischer wrote: OK so I have to ask.. S/390 as in IBM Mainframem S/390? Yeas, ESA/390. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A question about S/390 port
On Thursday 11 July 2002 02:45, Jake Burkholder wrote: I think this is because your console driver (hc) doesn't have a tty interface, just the low level cn* stuff. If you look at the ofw_console driver, it provides a rudimentary tty interface using polling and cngetc, cnputc equivalents. Hm, what about /dev/console (tty_cons)? I put into /etc/ttys line console /usr/libexec/getty std.1200 vt100 on secure. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
