Re: Boot failure with ppc64 port on iMacs G5

2024-03-01 Thread Brad Boyer 
On Fri, Mar 01, 2024 at 03:47:26PM +0100, John Paul Adrian Glaubitz wrote:
> The problem is that the newer image doesn't boot and currently I don't know
> why because installing the exact same kernel later from the package manager
> into an installed system works yields a bootable system with the latest
> kernel.
> 
> The installer images are built from the same kernel package which makes the
> whole thing even more confusing.

Perhaps it's a memory allocation problem before the kernel has fully
configured the MMU? I know in the past the kernel could be touchy
about how memory was mapped in the very early stages of boot. If we
happened to be near some limit, even a small increase in the size of
the kernel might have pushed us over the edge.

I'm not sure of the exact details, but perhaps the memory setup is
slightly different when booted from the CD image. I haven't looked
at recent images, but I know in the past the boot process was
different on CD compared to after the install.

Brad Boyer
f...@allandria.com

Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available

2020-10-20 Thread Brad Boyer 
On Tue, Oct 20, 2020 at 08:42:53PM +0200, Laurent Vivier wrote:
> Le 20/10/2020 ?? 20:32, Greg KH a ??crit??:
> > On Tue, Oct 20, 2020 at 08:19:26PM +0200, Laurent Vivier wrote:
> >> Le 20/10/2020 ?? 19:37, Greg KH a ??crit??:
> >>> Why not fix it to work properly like other arch checks are done
> >> I would be happy to do the same.
> >>
> >>> Put it in a .h file and do the #ifdef there.  Why is this "special"?
> >>
> >> I don't know.
> >>
> > 
> > Yup, that would be a good start, but why is the pmac_zilog.h file
> > responsible for this?  Shouldn't this be in some arch-specific file
> > somewhere?
> 
> For m68k, MACH_IS_MAC is defined in arch/m68k/include/asm/setup.h
> 
> If I want to define it for any other archs I don't know in which file we
> can put it.
> 
> But as m68k mac is only sharing drivers with pmac perhaps we can put
> this in arch/powerpc/include/asm/setup.h?

Wouldn't it be better to rearrange this code to only run if the devices
are present? This is a macio driver on pmac and a platform driver on mac,
so shouldn't it be possible to only run this code when the appropriate
entries are present in the right data structures?

I didn't look at a lot of the other serial drivers, but some other mac
drivers have recently been updated to no longer have MACH_IS_MAC checks
due to being converted to platform drivers.

Brad Boyer
b...@allandria.com

Re: [PATCH 8/8] macintosh/adb-iop: Implement SRQ autopolling

2020-05-31 Thread Brad Boyer 
On Sun, May 31, 2020 at 10:38:04AM +0200, Geert Uytterhoeven wrote:
> >  arch/m68k/include/asm/adb_iop.h |  1 +
> 
> As this header file is used by a single source file only, perhaps it should
> just be absorbed by the latter?
> Then you no longer need my Acked-by for future changes ;-)

While I don't really feel involved in this specific change (although I
was one of the testers when the driver was first written), I am a little
curious about the current coding standards. This header is pretty much
just a declaration of the hardware interface, of which there are many
in this directory. Is it better to just define all the offsets and bits
for hardware registers inside the driver? We used to always put them in
headers like this, but is that not the current standard? Would it be
cleaner to put such headers in the directory with the driver effectively
making them private? I seem to see quite a bit of that as well.

Thank you for your advice.

Brad Boyer
f...@allandria.com

Re: Anyone using PowerPC little-endian mode?

2010-06-13 Thread Brad Boyer 
On Thu, Jun 03, 2010 at 06:25:01AM -0600, Gary Thomas wrote:
 I don't know about today, but my recollection is that the only
 use of little-endian mode on PowerPC was during the early days
 attempt to run Windows-NT.

You could potentially hit this case by running Mac on Linux. A handful
of Mac programs (like early versions of VirtualPC) used this mode. Any
that did had to get fixed to run on a PowerMac G5, obviously. I haven't
personally tried this, and I wouldn't be shocked to find that MoL
chokes on this case for some other reason.

I do know that VirtualPC did this because it was G3/G4 only for a while
until they rewrote it to not use the little-endian mode.

Brad Boyer
f...@allandria.com

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Macintosh: fix brace and trailing statement coding style issues in adb-iop.c This is a patch to the adb-iop.c file that cleans up brace and trailing statement warnings found by the checkpa

2010-03-20 Thread Brad Boyer 

This driver is for m68k based Macintosh systems, not PowerPC based ones. I'm
copying the linux-m68k list on this reply so it is seen there as well.

Brad Boyer
f...@allandria.com

On Tue, Mar 09, 2010 at 01:46:20PM -0800, Michael Beardsworth wrote:
 From: Michael Beardsworth mbea...@mbeards-mbp.lulzzz.info
 
 ---
  drivers/macintosh/adb-iop.c |   41 +++--
  1 files changed, 23 insertions(+), 18 deletions(-)
 
 diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
 index 4446966..e813589 100644
 --- a/drivers/macintosh/adb-iop.c
 +++ b/drivers/macintosh/adb-iop.c
 @@ -19,13 +19,13 @@
  #include linux/init.h
  #include linux/proc_fs.h
  
 -#include asm/macintosh.h 
 -#include asm/macints.h 
 +#include asm/macintosh.h
 +#include asm/macints.h
  #include asm/mac_iop.h
  #include asm/mac_oss.h
  #include asm/adb_iop.h
  
 -#include linux/adb.h 
 +#include linux/adb.h
  
  /*#define DEBUG_ADB_IOP*/
  
 @@ -67,7 +67,8 @@ static void adb_iop_end_req(struct adb_request *req, int 
 state)
  {
   req-complete = 1;
   current_req = req-next;
 - if (req-done) (*req-done)(req);
 + if (req-done)
 + (*req-done)(req);
   adb_iop_state = state;
  }
  
 @@ -85,9 +86,8 @@ static void adb_iop_complete(struct iop_msg *msg)
   local_irq_save(flags);
  
   req = current_req;
 - if ((adb_iop_state == sending)  req  req-reply_expected) {
 + if ((adb_iop_state == sending)  req  req-reply_expected)
   adb_iop_state = awaiting_reply;
 - }
  
   local_irq_restore(flags);
  }
 @@ -113,8 +113,8 @@ static void adb_iop_listen(struct iop_msg *msg)
   req = current_req;
  
  #ifdef DEBUG_ADB_IOP
 - printk(adb_iop_listen %p: rcvd packet, %d bytes: %02X %02X, req,
 - (uint) amsg-count + 2, (uint) amsg-flags, (uint) amsg-cmd);
 + printk(KERN_WARNING adb_iop_listen %p: rcvd packet, %d bytes: %02X 
 %02X,
 + req, (uint) amsg-count + 2, (uint) amsg-flags, (uint) 
 amsg-cmd);
   for (i = 0; i  amsg-count; i++)
   printk( %02X, (uint) amsg-data[i]);
   printk(\n);
 @@ -130,9 +130,8 @@ static void adb_iop_listen(struct iop_msg *msg)
   msg-reply[0] = ADB_IOP_TIMEOUT | ADB_IOP_AUTOPOLL;
   msg-reply[1] = 0;
   msg-reply[2] = 0;
 - if (req  (adb_iop_state != idle)) {
 + if (req  (adb_iop_state != idle))
   adb_iop_end_req(req, idle);
 - }
   } else {
   /* TODO: is it possible for more than one chunk of data  */
   /*   to arrive before the timeout? If so we need to */
 @@ -169,12 +168,13 @@ static void adb_iop_start(void)
  
   /* get the packet to send */
   req = current_req;
 - if (!req) return;
 + if (!req)
 + return;
  
   local_irq_save(flags);
  
  #ifdef DEBUG_ADB_IOP
 - printk(adb_iop_start %p: sending packet, %d bytes:, req, req-nbytes);
 + printk(KERN_WARNING adb_iop_start %p: sending packet, %d bytes:, req, 
 req-nbytes);
   for (i = 0 ; i  req-nbytes ; i++)
   printk( %02X, (uint) req-data[i]);
   printk(\n);
 @@ -203,13 +203,14 @@ static void adb_iop_start(void)
  
  int adb_iop_probe(void)
  {
 - if (!iop_ism_present) return -ENODEV;
 + if (!iop_ism_present)
 + return -ENODEV;
   return 0;
  }
  
  int adb_iop_init(void)
  {
 - printk(adb: IOP ISM driver v0.4 for Unified ADB.\n);
 + printk(KERN_MESSAGE adb: IOP ISM driver v0.4 for Unified ADB.\n);
   iop_listen(ADB_IOP, ADB_CHAN, adb_iop_listen, ADB);
   return 0;
  }
 @@ -219,10 +220,12 @@ int adb_iop_send_request(struct adb_request *req, int 
 sync)
   int err;
  
   err = adb_iop_write(req);
 - if (err) return err;
 + if (err)
 + return err;
  
   if (sync) {
 - while (!req-complete) adb_iop_poll();
 + while (!req-complete)
 + adb_iop_poll();
   }
   return 0;
  }
 @@ -252,7 +255,8 @@ static int adb_iop_write(struct adb_request *req)
   }
  
   local_irq_restore(flags);
 - if (adb_iop_state == idle) adb_iop_start();
 + if (adb_iop_state == idle)
 + adb_iop_start();
   return 0;
  }
  
 @@ -264,7 +268,8 @@ int adb_iop_autopoll(int devs)
  
  void adb_iop_poll(void)
  {
 - if (adb_iop_state == idle) adb_iop_start();
 + if (adb_iop_state == idle)
 + adb_iop_start();
   iop_ism_irq(0, (void *) ADB_IOP);
  }
  
 -- 
 1.6.5
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code

2009-10-07 Thread Brad Boyer 
On Wed, Oct 07, 2009 at 09:52:43AM -0400, Sam Creasey wrote:
 On Wed, Oct 07, 2009 at 03:18:04PM +1000, Julian Calaby wrote:
  On the subject of merging code, I know that the SUN3 code in m68k uses
  a similar prom interface to the sparc32 code. (and I've also
  considered unifying that and ... well ... see above) Does anyone know
  if it has an OpenFirmware interface for it's devices? Is OF on SUN3
  even remotely useful? Does Linux on SUN3 even work with modern
  kernels?
 
 Sun3 doesn't have OF, though I've got some dormant patches to add an
 OF emulation layer to make it easier to reuse Sparc drivers on
 Sun3...   Never finished enough to submit, so it probably shouldn't
 affect anything you're doing here.

I was also looking at using the OF code on m68k, but for a different
reason. My goal was to get macio_bus working so we can merge a few
of the m68k Mac drivers into the ppc Mac drivers. The simplest way
to do that seemed to be supporting OF since macio_dev is a wrapper
for of_device. It was also a nice way to build up a table of all the
onboard devices in memory. Hopefully it would enable better user-space
device detection as well.

I got the framework built against an older kernel, but it wasn't enough
to be useful at that point. This set of patches could help quite a bit.

Brad Boyer
f...@allandria.com

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: High load average but low cpu (xenomai can be the explanation?)

2009-09-21 Thread Brad Boyer 
On Mon, Sep 21, 2009 at 05:13:05PM +0200, diba...@libero.it wrote:
 I have an MPC880 @133MHz. If I look into the load (with uptime) I get 
 values around 3.0 but my CPU is always under 5 percent (top). How could I 
 explain this? I'm using linux 2.6.19 with xenomai but no xenomai application 
 is 
 running at all. I have a cramfs on a nor flash. What could be the problem? If 
 I 
 kill the process I developed the average load goes down.

Does your system have any kernel modules that are used as part of the
application you are creating? I've seen this happen with custom written
kernel modules that sleep in an uninterruptible wait during a call
from a program or inside a kernel thread. This shows up as 'D' state
in your ps output. Any thread in state 'D' counts against the load
average but doesn't show in CPU usage if it is actually sleeping.

I don't think this is the most likely explanation since you said you
can kill your process, but I thought I should mention it.

Brad Boyer
f...@allandria.com

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Bugme-new] [Bug 14021] New: hfsplus caused data loss

2009-08-21 Thread Brad Boyer 
On Thu, Aug 20, 2009 at 03:02:42PM -0700, Andrew Morton wrote:
 
 (switched to email.  Please respond via emailed reply-to-all, not via the
 bugzilla web interface).
 
 On Thu, 20 Aug 2009 02:17:21 GMT
 bugzilla-dae...@bugzilla.kernel.org wrote:
 
  http://bugzilla.kernel.org/show_bug.cgi?id=14021
  
 Summary: hfsplus caused data loss
 Product: File System
 Version: 2.5
  Kernel Version: 2.6.31-rc5
Platform: All
  OS/Version: Linux
Tree: Mainline
  Status: NEW
Severity: normal
Priority: P1
   Component: HFS/HFSPLUS
  AssignedTo: zip...@linux-m68k.org
  ReportedBy: rbr...@ime.usp.br
  Regression: Yes
  
  
  Hi.
  
  I am trying to package a new version of Apple's own fsck/mkfs for HFS+
  filesystems so that they can be used in Linux as a way to transfer data 
  among
  computers, but I had quite a surprise when I was using the hfsplus module.
  
  I just created a 100MB file with nulls (dd if=/dev/null ...) and I created 
  an
  HFS+ filesystem on it.
  
  Then, I loop mounted it and tried to use it a little bit (in particular,
  applying patches with quilt on a source tree). The commands spit some errors
  about not being able to create links (I never had that problem before) and 
  the
  directory where I was became empty!
  
  Furthermore, here is a quite, quite strange directory listing:
  
  ,
  | rbr...@chagas:/media/usb7$ ls -lAF
  | ls: hfsprogs_332.14-7.diff.gz: No such file or directory
  | ls: hfsprogs_332.14-7.dsc: No such file or directory
  | ls: hfsprogs_332.14.orig.tar.gz: No such file or directory
  | ls: hfsprogs_332.18-1.diff.gz: No such file or directory
  | ls: hfsprogs_332.18-1.dsc: No such file or directory
  | ls: hfsprogs_332.18-1_amd64.changes: No such file or directory
  | ls: hfsprogs_332.18-1_amd64.deb: No such file or directory
  | ls: hfsprogs_332.18.orig.tar.gz: No such file or directory
  | total 1636
  | drwxr-xr-x 1 rbrito rbrito 39 Aug 17 08:13 hfsprogs-332.14/
  | drwxr-xr-x 1 rbrito rbrito 39 Aug 17 08:13 hfsprogs-332.14/
  | drwxr-xr-x 1 rbrito rbrito 45 Aug 17 15:30 hfsprogs-332.18/
  | -rw-r--r-- 1 rbrito rbrito  35609 Aug 17 08:13 hfsprogs_332.14-7.diff.gz
  | -rw-r--r-- 1 rbrito rbrito   1193 Aug 17 08:13 hfsprogs_332.14-7.dsc
  | -rw-r--r-- 1 rbrito rbrito 714035 Aug 17 08:13 hfsprogs_332.14.orig.tar.gz
  | -rw-r--r-- 1 rbrito rbrito  35342 Aug 17 15:26 hfsprogs_332.18-1.diff.gz
  | -rw-r--r-- 1 rbrito rbrito954 Aug 17 15:26 hfsprogs_332.18-1.dsc
  | -rw-r--r-- 1 rbrito rbrito   2148 Aug 17 15:26
  hfsprogs_332.18-1_amd64.changes
  | -rw-r--r-- 1 rbrito rbrito 135398 Aug 17 15:26 hfsprogs_332.18-1_amd64.deb
  | -rw-r--r-- 1 rbrito rbrito 732449 Aug 17 08:35 hfsprogs_332.18.orig.tar.gz
  | rbr...@chagas:/media/usb7$
  `
  
  I am using kernel 2.6.31-rc5-1rb.pre6 (that is, rc5 with git updates up to 
  one
  or two days before rc6).
  
  There are no messages in the dmesg, besides these:
  
  ,
  | [30991.501804] loop: module loaded
  | [30991.513337] hfs: create hidden dir...
  | [39897.867830] hfs: create hidden dir...
  | [39960.061622] hfs: splitting index node...
  `
  
  No stack traces, no nothing. Oh, I still have the disk image that I 
  created, if
  it is of any interest.
  
  Please let me know if I can provide any further information.
  
 
 Gee.  Nobody really does much maintenance work on hfs/hfsplus any more.
 I cc'ed the ppc guys as I expect that most HFS users are over there.
 
 It seems like a pretty gross failure - others should be hitting it.
 
 I wonder if it's a weird interaction with the loop driver.

I can explain the ls output in a very generic sense. This is what you
get if the lookup fails on a name returned by a readdir. I suspect
that creating hard links is failing in some way. In particular, the
hidden dir mentioned in the log is used to save the real files for
hard links.

As a quick explanation, HFS+ doesn't have a real concept of hard
links. Apple hacked it in after the fact. The way it works is that
there is a special hidden directory, and the real catalog entries
that match the real names are just references to the hidden file.
Both HFS and HFS+ have no separate notion of directory entries and
inode data. The metadata is stored in records keyed by file name.

Hard links were added after I stopped working on the HFS+ code, so
I don't know it in detail. I know it works for reading hard links,
but I never actually tried creating more links.

Brad Boyer
f...@allandria.com

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Inline assembly queries [2]

2009-07-03 Thread Brad Boyer 
On Fri, Jul 03, 2009 at 12:14:41PM +0530, kernel mailz wrote:
 Thanks for responding to my previous mail. A few more queries
 
 a. What is the use of adding format specifiers in inline assembly
 like
 asm volatile(ld%U1%X1 %0,%1:=r(ret) : m(*ptr) : memory);

The format specifiers limit which registers or addressing modes will
be chosen to access that parameter. For example, if you're using an
instruction that treats r0 as a literal 0 value, you can't use the
r specifier for that or you may see problems if it happens to allocate
r0 for that particular argument. For memory access, the m lets you
use any of the normal load/store patterns (which is why this particular
choice also requires the %U1%X1 part to allow changing the instruction).
The system was setup for an older style chip like x86 or 68k with many
restrictions on which registers can be used where and large numbers of
different addressing modes for accessing memory. It's a little clumsy
for ppc by comparison to most other chips, but it's a fundamental part
of inline assembly processing in gcc.

 b. using m or Z  with a memory address. I tried replacing m/Z but no change
 Is there some guideline ?
 gcc documentation says Z is obsolete. Is m/Z replaceable ?

No idea. I don't remember ever seeing 'Z' used in anything. Maybe somebody
else remembers what it used to mean.

Brad Boyer
f...@allandria.com

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

2009-02-24 Thread Brad Boyer 
On Tue, Feb 24, 2009 at 07:37:08PM +0100, Alessandro Zummo wrote:
 On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
 Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote:
  Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
  class drivers would add ca. 100+ lines of code for each individual driver.
 
  How different are all of those boards? It's simply a matter
  of parameters and offsets? can we group them somehow?

I imagine we could cut down the numbers somewhat with clever code sharing,
but it's still going to be a fairly large number. I don't know all the
embedded boards, but just with all the Macintosh models there are at
least three and maybe four drastically different methods of RTC access,
and all of them are directly tied to some chip that does something else
completely unrelated. For one of them we don't even have a driver at the
moment.  They also are all custom chips that wouldn't be used anywhere
else. The other thing we need to keep in mind is that if we do it right
we can share drivers across m68k and powerpc in some cases.  I imagine
some of the embedded powerpc boards are using chips that are common in
other architectures as well.

Brad Boyer
f...@allandria.com

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: request_irq return errno 38

2009-02-11 Thread Brad Boyer 
On Wed, Feb 11, 2009 at 03:43:26PM +0530, Vijay Nikam wrote:
 I read in LDD book, they give directly irq no. they have given
 parallel port example, here they have set or said irq no. defaults to
 7 and they have not done any irq_mapping so what is the difference ? ?
 ? I mean how I should know when to use irq_mapping and when not ? ? ?
 
 Also is it some difference between writng drivers on embedded Linux
 level and Linux PC (i386) ? ? ?

The basic request_irq() function is generic, but the value of the
arguments (especially the number for the IRQ line) is architecture
specific in many ways. This is one difference between the i386 code
and the powerpc code inside Linux. Most i386 hardware is standard
PC hardware with very clearly defined interrupt sources. Because of
this, the mapping from the numeric IRQ value to a real hardware
interrupt source is defined pretty clearly. The powerpc architecture
code has to support almost arbitrarily complex hardware, and the
embedded world is the source of most of the complexity. Because of
this, the powerpc code has to dynamically allocate those numeric
IRQ sources and tie them to a specific hardware interrupt. There
is functionality to take the information from your device tree and
convert it to a virtual IRQ. That happens automatically for some types
of devices like PCI cards, but your driver may have to do that mapping
itself in other cases. I believe the appropriate API for this is the
function irq_of_parse_and_map(). It takes a device node and index into
the interrupt list for that device and gives a virtual IRQ number.

Brad Boyer
f...@allandria.com

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: 8600 serial support

2008-10-08 Thread Brad Boyer 
On Thu, Oct 09, 2008 at 07:45:11AM +1100, Benjamin Herrenschmidt wrote:
 Yes, it's not totally trivial and I wouldn't recommend using the weirdo
 code in macserial (it does things that I don't understand how they work
 with the dbdma engine).
 
 The best way I see is to start from scratch with two different
 mechanisms:
 
  - For Tx, that's the easiest, the fire off DMA's for outgoing chars,
 maybe queue up a few descriptors to let data accumulate.
 
  - For Rx, one descriptor per byte. That sucks but I think that's also
 what Apple does. No need to have a huge Rx buffer anyway. That gives you
 precise Rx status to the byte.

I know it's not really in the scope of the discussion, but do you have
any suggestions for how we might support this with AMIC or PSC DMA where
we can't have an arbitrary number of in-flight commands? There hasn't
been a lot of traction on getting the non-PCI macs working again, but
that is something that may happen eventually. It would be nice to have
similar designs for both the descriptor based and register driven DMA
engines, but I definitely understand if you think that's not realistic.

It seems to me that an interrupt per-byte (which this design would
imply on the older DMA engines) would make the DMA less useful.

Brad Boyer
[EMAIL PROTECTED]

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX

2008-08-27 Thread Brad Boyer 
On Wed, Aug 27, 2008 at 01:40:10PM +0200, Geert Uytterhoeven wrote:
 On Wed, 27 Aug 2008, Arnd Bergmann wrote:
  On Wednesday 27 August 2008, Kevin Diggs wrote:
   Arnd Bergmann wrote:
Are there even SMP boards based on a 750? I thought only 74xx
and 603/604 were SMP capable.

   Not that I have heard of. I thought it was lacking some hardware that
   was needed to do SMP? Can the 603 do SMP?
  
  No, I was wrong about the 603. The machine I was thinking of is actually
  604e.
 
 The BeBox had a dual 603.

I remember going to a talk by some of the Be engineers, and I think they
said that the 603 had terrible SMP performance. My understanding was that
Motorola recommended the 604 for SMP configurations but the 603 was much
cheaper and mostly worked. The 750 is much more like the 603 than the 604.

Brad Boyer
[EMAIL PROTECTED]

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.

2008-08-06 Thread Brad Boyer 
On Thu, Aug 07, 2008 at 08:28:29AM +1000, Benjamin Herrenschmidt wrote:
 
  there is a bunch of error checking and difference in semantics that  
  you need to fix.  I think introduce a new API for this is silly,  
  especially since we expect there to only be one actual invocation of  
  the API for serial console access.
 
 Not necessarily
 
 There's another aspect to BAT mappings here. First, they should be
 permanent (ie, not unmappable). That way, we have ioremap just use
 an existing BAT mapping when asked for a device that is covered
 by a BAT. This allows to have platform code do something like setup
 a BAT over a bunch of SOC registers or over a device, to automagically
 get drivers doing ioremap to that area benefit from it.

The m68k arch code does something similar with TT registers and ioremap,
but it's a little hackish currently. If there was a more generic way
to handle it, that would make things a little cleaner. In the m68k
implementation, there are just exceptions in the ioremap code that are
hard wired to know about the ranges that are normally set earlier. Since
the ranges end up being in multiple files, it's more fragile to change
what is mapped in these blocks.

Brad Boyer
[EMAIL PROTECTED]

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: questions

2008-05-25 Thread Brad Boyer 
On Sun, May 25, 2008 at 05:32:29PM -0700, Kevin Diggs wrote:
 Hi,
 
   In idle_6xx.S one finds instructions like:
 
   lis   r4,[EMAIL PROTECTED]
   lwz   r4,[EMAIL PROTECTED](r4)
 
 Can someone explain what this is doing? Presumably the first is loading 
 an address and the second a value. What do the '@ha' and '@l' do?

The @ha and @l are modifiers to turn a 32 bit constant into a 16 bit
constant that would be useful in particular contexts. The @l takes
the low halfword, while the @ha takes the high halfword and modifies
it so that if you add in the low halfword you get the full 32 bit
value. There are other modifiers for other uses. You need these in
ppc assembly because there isn't any way to directly use a 32 bit
immediate value. In this particular case, it's taking advantage of
the indirect addressing modes to load a word from a constant 32 bit
address. It loads the high halfword of the pointer into r4 with the
lis instruction, then the low halfword is added during the effective
address calculation. The value at that constant address is loaded
into r4. Normally a 32 bit constant gets loaded with lis and addi,
but this is a way to avoid the extra instruction because it intends
to use the result as a pointer. The indirect addressing gives you
a free addi as long as you don't need to save the result.

   Also, is there any performance difference between:
 
   lbz rD,d(rA)
   lhz rD,d(rA)
   lwz rD,d(rA)

Normally you would use the one you need. I'd be surprised if there was
any difference in performance, but I also can't think of any reason
you would choose one over another for performance reasons even if there
was a difference.

   While I'm wasting your time, I picked up an ADB infrared wireless 
 keyboard. I think it works. But not under Linux. Should it?

If it acts like a normal ADB keyboard, it should work. Does it need a
special driver with the MacOS? If so, then it would probably need a
custom driver in Linux as well.

Brad Boyer
[EMAIL PROTECTED]

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Device node - How does kernel know about it

2007-12-30 Thread Brad Boyer 
On Thu, Dec 27, 2007 at 07:27:17PM -0800, Siva Prasad wrote:
 What is the kernel routine that is first called when there is, for
 example a read() function call from user program? 
 I would like to start debugging from there and see if any thing at all
 happens when there is a call. Appreciate your help with this question.

I don't generally recommend starting debugging at that level, but I'll
try to give you some pointers. Every system call coming into the kernel
from a user space program initially runs a little piece of assembly
language code that looks up a handler (by number) in the system call
table and sets up the proper environment to call the appropriate function
that implements that call (which is written in C). Normally, those
functions are named with a prefix of sys_ and the name of the system
call. For example, the implementation of read(2) is called sys_read. You
should be able to find it in fs/read_write.c. Other system call
implementations are scattered around to be with code related to that
call. Most of the file related ones can be found someplace under the
fs directory.

Brad Boyer
[EMAIL PROTECTED]

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: asm-ppc header issues when building ARCH=powerpc

2007-08-23 Thread Brad Boyer 
On Wed, Aug 22, 2007 at 11:16:03PM -0500, Kumar Gala wrote:
 On Aug 22, 2007, at 10:33 PM, David Gibson wrote:
  My analysis of asm/bootinfo.h usage:
 
  ./drivers/macintosh/adb-iop.c:#include asm/bootinfo.h remove
  ./drivers/char/vme_scc.c:#include asm/bootinfo.h 68k only
  ./drivers/char/serial167.c:#include asm/bootinfo.h   68k only
  ./drivers/serial/dz.c:#include asm/bootinfo.h decstation
  ./drivers/mtd/devices/ms02-nv.c:#include asm/bootinfo.h  decstation
  ./drivers/net/macsonic.c:#include asm/bootinfo.h 68k
  ./drivers/net/jazzsonic.c:#include asm/bootinfo.hmips
  ./drivers/video/pmag-aa-fb.c:#include asm/bootinfo.h mips
  ./drivers/video/maxinefb.c:#include asm/bootinfo.h   mips
  ./drivers/video/logo/logo.c:#include asm/bootinfo.h  mips
  ./drivers/video/macfb.c:#include asm/bootinfo.h  68k
  ./drivers/video/valkyriefb.c:#include asm/bootinfo.h 68k
 
  Uh.. I'm pretty sure valkyriefb.c is for (old) PowerMacs, not 68k.
 
 It appears to be both.  If you look at the include its protected by a  
 #ifdef CONFIG_MAC which we is only defined on m68k.

According to drivers/video/macfb.c, both the Quadra 630 and Performa 588
have the Valkyrie chip for their video. I don't remember which ppc based
models have it, but it's definitely on both architectures.

Just as an extra note, the file drivers/macintosh/adb-iop.c is m68k only,
so you should probably leave that alone as well. It probably doesn't need
that header, but the change should really come from the 68k side of things.

Brad Boyer
[EMAIL PROTECTED]

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev