From: David Edelsohn <hidden> Date: 2000-03-20 02:57:45
I do not have any hardware specs for these machines offhand, but
the interrupt controller may very well be PC-like cascaded 8259s.
The PPC601 was a POWER architecture chip with additional user-mode
PowerPC instructions. It was based on the existing RSC (RIOS Single Chip)
processor that IBM already was using and allowed the first PowerPC chip
implementation to be developed and deployed very rapidly. The supervisor
state of the chip was all POWER architecture, not PowerPC Books II and
III. The direct store segments were a way to access special devices on
the I/O bus.
David
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-20 20:45:05
On Sun, 19 Mar 2000, David Edelsohn wrote:
The PPC601 was a POWER architecture chip with additional user-mode
PowerPC instructions. It was based on the existing RSC (RIOS Single Chip)
processor that IBM already was using and allowed the first PowerPC chip
implementation to be developed and deployed very rapidly. The supervisor
state of the chip was all POWER architecture, not PowerPC Books II and
III. The direct store segments were a way to access special devices on
the I/O bus.
Actually I thought that the supervisor mode of the 601 was a mixture of
POWER and PPC. I read somewhere that the hash table implementation of the
POWER was very different for example (and POWER had only SPR 0 to 31
while PPCs, including 601, have many more).
Have a look at the code, there are quite a lot of tests for 601 specific
differences (for cache control operations, to avoid touching HID0,
different BATs). And a few ugly things like using the decrementer even in
cases where the tb/rtc would be more appropriate IMHO but the wraparound
at 1e9 of 601's RTCL would be awkward to handle.
However, if the use direct store segments is _unavoidable_, significant
kernel modifications are required.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dave Weis <hidden> Date: 2000-03-21 12:50:44
On Mon, 20 Mar 2000, Gabriel Paubert wrote:
However, if the use direct store segments is _unavoidable_, significant
kernel modifications are required.
I know we've (Gabriel and I) discussed this, but could you elaborate?
Based on what I've read in my docs, I think it is unavoidable. I'm getting
closer to having the boot process figured out. Once I've got some more
questions, I'm going to send my info to the list and see if my data looks
accurate.
dave
--
David Weis | 10520 New York Ave, Des Moines, IA 50322
djweis@plconline.com | Voice 515-278-0133 Ext 231
| http://www.perfectionlearning.com/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-21 14:30:12
On Tue, 21 Mar 2000, Dave Weis wrote:
On Mon, 20 Mar 2000, Gabriel Paubert wrote:
quoted
However, if the use direct store segments is _unavoidable_, significant
kernel modifications are required.
I know we've (Gabriel and I) discussed this, but could you elaborate?
Based on what I've read in my docs, I think it is unavoidable. I'm getting
closer to having the boot process figured out. Once I've got some more
questions, I'm going to send my info to the list and see if my data looks
accurate.
Right now the segment registers are only changed on task switches.
To access devices which are addressed through direct store segments, you
have to load one segment register (which occupies 256Mb of virtual address
space) when you enter the driver for this device.
You might also have to save/restore the segment register on interrupts,
and you'd better remove this segment when returning to user space or you
may create a huge security hole.
The best solution might be to designate one segment as reserved for this
purpose (say the last one) and use a save/restore mechanism in each
routine which needs to acces this kind of device. You have to make sure
that all paths restore it to the state it had on entry, but at least you
don't have to muck with the low level system call and interrupt entry and
exit code.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dave Weis <hidden> Date: 2000-03-21 20:45:29
On Tue, 21 Mar 2000, Gabriel Paubert wrote:
On Tue, 21 Mar 2000, Dave Weis wrote:
quoted
On Mon, 20 Mar 2000, Gabriel Paubert wrote:
quoted
However, if the use direct store segments is _unavoidable_, significant
kernel modifications are required.
I know we've (Gabriel and I) discussed this, but could you elaborate?
Based on what I've read in my docs, I think it is unavoidable. I'm getting
closer to having the boot process figured out. Once I've got some more
questions, I'm going to send my info to the list and see if my data looks
accurate.
Right now the segment registers are only changed on task switches.
To access devices which are addressed through direct store segments, you
have to load one segment register (which occupies 256Mb of virtual address
space) when you enter the driver for this device.
The way the drivers/info I've seen do it is to call iomem_att when they
need access to whatever they are looking for. I had a tarball of aix
driver source for a few devices but can't seem to find it now. If anyone
else knows where to find it, please let me know. The docs on this function
are viewable at
http://aix43.uwaterloo.ca/aix/doc_link/en_US/a_doc_lib/libs/ktechrf1/iomem_att.htm
You might also have to save/restore the segment register on interrupts,
and you'd better remove this segment when returning to user space or you
may create a huge security hole.
True.
The best solution might be to designate one segment as reserved for this
purpose (say the last one) and use a save/restore mechanism in each
routine which needs to acces this kind of device. You have to make sure
that all paths restore it to the state it had on entry, but at least you
don't have to muck with the low level system call and interrupt entry and
exit code.
I think the aix way would probably work okay, especially since there's a
minimum number of drivers that would work on the machine anyway.
dave
--
David Weis | 10520 New York Ave, Des Moines, IA 50322
djweis@plconline.com | Voice 515-278-0133 Ext 231
| http://www.perfectionlearning.com/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/