Re: getting the 8600 to boot 2.4.5

Re: getting the 8600 to boot 2.4.5

[Guillaume Laurès]

[-- Attachment #1: Type: text/plain, Size: 4730 bytes --]

Hollis wrote:

> In your patch you hardcode opening the 2nd display device. Maybe it would be
> better to keep trying to open a display until one succeeds? That way it would
> work for everyone. :)
>
> -Hollis


Hi all,

I've managed to get a powermac 8600 boot linux 2.4 ('s been long since I
didn't try).
The trick is that in 2.4 kernel, linux tries to open the first frame
buffer, and on machines of the 8x00 class this mean opening the sixty
convoluer, a frame buffer that allows the use of the video output (Y/C
and composite).
Unfortunately, linux has not a driver for it so the opening always
fails, and the machine goes back to OF with a DEFAULT CATCH something.

In 2.2, the behaviour was different in that it tried to open every
framebuffer, or every frame buffer up to succes, I don't know, so this
machine was used to work well.

Now, the question is wether we should hardcode opening the second
display on thoses machines, or go back to the previous behaviour, I
don't knwo why it couls have been removed.

Or someone writes a driver for the sixty ;-P

Here is a console log with the patch applied (yes, I made it netboot,
plain boot is just so boring...):

file: 192.168.77.10,vmlinux.coffloading XCOFF
tsize=5FC0 dsize=FAB70 bsize=215E0 entry=500000

SECTIONS:

.text    00500000 00500000 00005FC0 000000E0

.data    00510000 00510000 000FAB70 000060A0

.bss     0060AB70 0060AB70 000215E0 00000000

loading .text, done..

loading .data, done..

clearing .bss, done..

coffboot starting: loaded at 0x500000

heap at 0x60c150

gunzipping (0xc0000000 <- 0x5102c8:0x60aa58)...done 2438856 bytes

46896 bytes of heap consumed, max in use 40816

start address = 0xc0000000

opening display /chaos@F0000000/control@B... ok

copying OF device tree...done

Initializing fake screen: control
Calling quiesce ...

Total memory = 192MB; using 1024kB for hash table (at c0300000)

Linux version 2.4.5-pre1_0c (root@pmg4) (gcc version 2.95.3 20010111
(prereleas1
Cache coherency enabled for bandit/PSX at 00000000

Found Bandit PCI host bridge at 0xf2000000. Firmware bus number: 0->1

Found Chaos PCI host bridge at 0xf0000000. Firmware bus number: 2->2

On node 0 totalpages: 49152

zone(0): 49152 pages.

zone(1): 0 pages.

zone(2): 0 pages.

Kernel command line: console=ttyS0 video=controlfb:vmode:6,cmode:8

System has 32 possible interrupts

GMT Delta read from XPRAM: 0 minutes, DST: off

via_calibrate_decr: ticks per jiffy = 124992 (749957 ticks)

Console: colour dummy device 80x25

Calibrating delay loop... 699.59 BogoMIPS

Memory: 189416k available (1644k kernel code, 776k data, 224k init, 0k
highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)

Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)

Page-cache hash table entries: 65536 (order: 6, 262144 bytes)

Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)

POSIX conformance testing by UNIFIX

PCI: Probing PCI hardware
Unknown bridge resource 2: assuming transparent

PCI:0:10:0: Resource f3000000-f301ffff (f=200)

PCI:1:8:0: Resource 84110000-8411007f (f=200)

PCI:1:8:0: Resource 00001000-0000107f (f=101)

PCI:1:8:0: Resource 82000000-83ffffff (f=1208)

PCI:1:9:0: Resource 84100000-8410ffff (f=200)

Macintosh CUDA driver v0.5 for Unified ADB.

Linux NET4.0 for Linux 2.4

Based upon Swansea University Computer Society NET3.039

Starting kswapd v1.8

controlfb: Memory bank 1 present, bank 2 absent, total VRAM 2MB


On a side note, this is wrong, I have the 2 banks filled, but I'll check
this later

Monitor sense value = 0x623, using video mode 6 and color mode 0.

Console: switching to colour frame buffer device 80x30

fb0: control display adapter

no framebuffer address found for /bandit@F2000000/gc@10/sixty6@1C000

This is the first display device without a driver

input0: Macintosh mouse button emulation

PowerMac Z8530 serial driver version 2.0

tty00 at 0xfcfa6020 (irq = 15) is a Z8530 ESCC, port = modem

tty01 at 0xfcfa3000 (irq = 16) is a Z8530 ESCC, port = printer

pty: 256 Unix98 ptys configured

block: queued sectors max/low 125642kB/41880kB, 384 slots per queue

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

fd0: SWIM3 floppy controller

PCI: Enabling device 01:08.0 (0014 -> 0017)

DAC960: ***** DAC960 RAID Driver Version 2.4.10 of 1 February 2001 *****

DAC960: Copyright 1998-2001 by Leonard N. Zubkoff <lnz@dandelion.com>

And here it becomes bad, and currently my goal in life is getting the
mylex driver to work.

BTW, can anybody tell me if something like this can lead to endianness
problems ?:

InboundDoorBellRegister.All =
   readb(ControllerBaseAddress + DAC960_LA_InboundDoorBellRegisterOffset);

Thanks for the good work and keep on

GoM


[-- Attachment #2: promc.diff --]
[-- Type: text/plain, Size: 710 bytes --]

--- arch/ppc/kernel/prom.c.orig	Mon Jun 18 23:01:49 2001
+++ arch/ppc/kernel/prom.c	Mon Jun 18 23:29:56 2001
@@ -963,17 +963,17 @@
 					= RELOC(prom_display_paths[i-1]);
 		}
 		RELOC(prom_display_paths[i]) = PTRUNRELOC(path);
-		if (i == 0)
+		if (i == 1)
 			RELOC(prom_disp_node) = node;
 		if (RELOC(prom_num_displays) >= FB_MAX)
 			break;
 	}

 	/*
-	 * Open the first display and set its colormap.
+	 * Open the second display and set its colormap.
 	 */
 	if (RELOC(prom_num_displays) > 0) {
-		path = PTRRELOC(RELOC(prom_display_paths[0]));
+		path = PTRRELOC(RELOC(prom_display_paths[1]));
 		prom_print(RELOC("opening display "));
 		prom_print(path);
 		ih = call_prom(RELOC("open"), 1, 1, path);

another endianness issue...

[Guillaume Laurès]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

Hello all,

I've tracked down the problem with the DAC960 driver (drivers/block), a
module that handles the mylex range of raid cards.

All the structures dealing with the card sound like this one:

typedef union DAC960_LA_InboundDoorBellRegister
{
   unsigned char All;
   struct {
     boolean HardwareMailboxNewCommand:1;                /* Bit 0 */
     boolean AcknowledgeHardwareMailboxStatus:1;         /* Bit 1 */
     boolean GenerateInterrupt:1;                        /* Bit 2 */
     boolean ControllerReset:1;                          /* Bit 3 */
     boolean MemoryMailboxNewCommand:1;                  /* Bit 4 */
     unsigned char :3;                                   /* Bits 5-7 */
   } Write;
   struct {
     boolean HardwareMailboxEmpty:1;                     /* Bit 0 */
     boolean InitializationNotInProgress:1;              /* Bit 1 */
     unsigned char :6;                                   /* Bits 2-7 */
   } Read;
}
DAC960_LA_InboundDoorBellRegister_T

And I guess on ppc we would need all the bits line reversed.

So, my question is how to handle this in the best approach, the goal
being a unified driver nt too difficult to maintain

I've attached a little sample written by hollis that reproduces the
problem. I've managed to get gcc choose the right structure according to
the endianness of the host with endian.h and a couple of #ifdef, but
this is still rather bad since we have to maintain two versions of the
structs.

Does antbody has a good idea on this or an example of driver we could
follow ?

Thanks,

GoM

[-- Attachment #2: struct_endian.c --]
[-- Type: text/plain, Size: 1195 bytes --]

/**********************************************
 *                                            *
 * gcc -Wall struct_endian.c -o struct_endian *
 *                                            *
 **********************************************/

#include <stdio.h>
#include <endian.h>

#if __BYTE_ORDER == __LITTLE_ENDIAN
union byte {
  unsigned char all;
  struct {
    unsigned char zero:1;
    unsigned char one:1;
    unsigned char two:1;
    unsigned char three:1;
    unsigned char four:1;
    unsigned char five:1;
    unsigned char size:1;
    unsigned char seven:1;
  } split;
};
#elif __BYTE_ORDER == __BIG_ENDIAN
union byte {
  unsigned char all;
  struct {
    unsigned char seven:1;
    unsigned char size:1;
    unsigned char five:1;
    unsigned char four:1;
    unsigned char three:1;
    unsigned char two:1;
    unsigned char one:1;
    unsigned char zero:1;
  } split;
};
#endif


int main(void)
{
  union byte a;
  unsigned char c;

  a.all = 0x1;
  c = 0x1;

  printf("struct:\n");
  printf("  bit 0 = %u\n", a.split.zero);
  printf("  bit 7 = %u\n", a.split.seven);

  printf("char:\n");
  printf("  bit 0 = %u\n", c & 0x1);
  printf("  bit 7 = %u\n", c >> 7);

  return 0;
}

Re: another endianness issue...

[Timothy A. Seufert]

At 11:29 AM +0200 6/23/01, Guillaume Laurès wrote:

>And I guess on ppc we would need all the bits line reversed.
>
>So, my question is how to handle this in the best approach, the goal
>being a unified driver nt too difficult to maintain

Kill the struct definition, and replace it with a bunch of accessor
macros that mask-and-shift.  When moving the register value to or
from the hardware, use le32_to_cpu() and cpu_to_le32() as appropriate.

Bitfields are not a good way to describe hardware registers.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: another endianness issue...

[Hollis]

On Saturday 23 June 2001 01:19, Timothy A. Seufert wrote:
>
> Bitfields are not a good way to describe hardware registers.

Why is that? Are there generally bitfield problems other than this one?

-Hollis

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: another endianness issue...

[Benjamin Herrenschmidt]

>>
>> Bitfields are not a good way to describe hardware registers.
>
>Why is that? Are there generally bitfield problems other than this one?

Neither structures nor bitfields are good for describing HW registers
because they are always implementation dependant, the actual layout
in memory of a structure of a bitfield depends completely on the
compiler, it's setting, the platform, whatever....

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: getting the 8600 to boot 2.4.5

[Michel Lanners]

On  22 Jun, this message from Guillaume Laurès echoed through cyberspace:
> The trick is that in 2.4 kernel, linux tries to open the first frame
> buffer, and on machines of the 8x00 class this mean opening the sixty
> convoluer, a frame buffer that allows the use of the video output (Y/C
> and composite).

Ah, there it is! I've long wondered how Sixty6 would appear in the
device tree ;-)

> Unfortunately, linux has not a driver for it

Would be a fun project to write one ;-)

[snip]
> controlfb: Memory bank 1 present, bank 2 absent, total VRAM 2MB
>
> On a side note, this is wrong, I have the 2 banks filled, but I'll check
> this later

Yeah; Takashi Oe fixed the VRAM detection for good, but it seems his
patches have not made into any released tree yet. Maybe it's in BenH's
tree; but I didn't check recently.

If you're desperate, I can try to dig it out.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: getting the 8600 to boot 2.4.5

[Takashi Oe]

On Sun, 24 Jun 2001 11:54:29 +0200 (CEST), Michel Lanners wrote:

> Yeah; Takashi Oe fixed the VRAM detection for good, but it seems his
> patches have not made into any released tree yet.

Well, there is a problem with the detection code I wrote.
Occasionally, a machine hangs when vram mapping is changed.  It
seems it has to be done at a right time, but I don't know when
the right time is and how to detect it yet  :(

Any ideas or suggestions are welcome..


Takashi Oe

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: another endianness issue...

[Guillaume Laurès]

Timothy A. Seufert wrote:

> Kill the struct definition, and replace it with a bunch of accessor
> macros that mask-and-shift.  When moving the register value to or
> from the hardware, use le32_to_cpu() and cpu_to_le32() as appropriate.

Okay, so as this are my first steps in kernel programming, let's take an
example :-)

Somewhere at the beginning of the driver we have something like this:

while (DAC960_LA_InitializationInProgressP(BaseAddress))
{blabla}

DAC960_LA_InitializationInProgressP() is defined as follows in the .h:

static inline
boolean DAC960_BA_InitializationInProgressP(void *ControllerBaseAddress)
{
  DAC960_BA_InboundDoorBellRegister_T InboundDoorBellRegister;
  InboundDoorBellRegister.All =
   readb(ControllerBaseAddress + DAC960_BA_InboundDoorBellRegisterOffset);
  return !InboundDoorBellRegister.Read.InitializationNotInProgress;
}

and, for the record, the DAC960_BA_InboundDoorBellRegister_T is
something like this:

typedef union DAC960_BA_InboundDoorBellRegister
{
  unsigned char All;
  struct {
   boolean HardwareMailboxNewCommand:1;                /* Bit 0 */
   boolean AcknowledgeHardwareMailboxStatus:1;         /* Bit 1 */
   boolean GenerateInterrupt:1;                        /* Bit 2 */
   boolean ControllerReset:1;                          /* Bit 3 */
   boolean MemoryMailboxNewCommand:1;                  /* Bit 4 */
   unsigned char :3;                                   /* Bits 5-7 */
  } Write;
  struct {
   boolean HardwareMailboxEmpty:1;                     /* Bit 0 */
   boolean InitializationNotInProgress:1;              /* Bit 1 */
   unsigned char :6;                                   /* Bits 2-7 */
  } Read;
}
DAC960_BA_InboundDoorBellRegister_T;



What would I do now is modify  DAC960_LA_InitializationInProgressP() as
follows:

static inline
boolean DAC960_BA_InitializationInProgressP(void *ControllerBaseAddress)
{
  unsigned long InboundDoorBellRegister =
   le32_to_cpu(ControllerBaseAddress +
DAC960_BA_InboundDoorBellRegisterOffset);
  return (boolean) !(InboundDoorBellRegister & 0x0002);
}

Is it correct ?
And where can I find the cpu_to_le32() and le32_to_cpu() declaration or
a guide on how to use them ?

Thanks


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: another endianness issue...

[Benjamin Herrenschmidt]

>Is it correct ?
>And where can I find the cpu_to_le32() and le32_to_cpu() declaration or
>a guide on how to use them ?

If you use readl/writel, you don't need to byteswap as it's done for
you by those functions. If you used readb/writeb, then you are reading
bytes, swapping has no meaning.

Also, don't hard code 0x0002, better #define a constant, it makes the
code more readable.

cpu_to_le32/le32_to_cpu() are necessary if you are either not using
readx/writex accessors, or when storing datas in memory that the
controller will read directly (bus master)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: another endianness issue...

[Geert Uytterhoeven]

On Sun, 24 Jun 2001, Guillaume Laurès wrote:
> Timothy A. Seufert wrote:
> > Kill the struct definition, and replace it with a bunch of accessor
> > macros that mask-and-shift.  When moving the register value to or
> > from the hardware, use le32_to_cpu() and cpu_to_le32() as appropriate.
>
> Okay, so as this are my first steps in kernel programming, let's take an
> example :-)
>
> Somewhere at the beginning of the driver we have something like this:
>
> while (DAC960_LA_InitializationInProgressP(BaseAddress))
> {blabla}
>
> DAC960_LA_InitializationInProgressP() is defined as follows in the .h:
>
> static inline
> boolean DAC960_BA_InitializationInProgressP(void *ControllerBaseAddress)
> {
>   DAC960_BA_InboundDoorBellRegister_T InboundDoorBellRegister;
>   InboundDoorBellRegister.All =
>    readb(ControllerBaseAddress + DAC960_BA_InboundDoorBellRegisterOffset);
>   return !InboundDoorBellRegister.Read.InitializationNotInProgress;
> }
>
> and, for the record, the DAC960_BA_InboundDoorBellRegister_T is
> something like this:
>
> typedef union DAC960_BA_InboundDoorBellRegister
> {
>   unsigned char All;
>   struct {
>    boolean HardwareMailboxNewCommand:1;                /* Bit 0 */
>    boolean AcknowledgeHardwareMailboxStatus:1;         /* Bit 1 */
>    boolean GenerateInterrupt:1;                        /* Bit 2 */
>    boolean ControllerReset:1;                          /* Bit 3 */
>    boolean MemoryMailboxNewCommand:1;                  /* Bit 4 */
>    unsigned char :3;                                   /* Bits 5-7 */
>   } Write;
>   struct {
>    boolean HardwareMailboxEmpty:1;                     /* Bit 0 */
>    boolean InitializationNotInProgress:1;              /* Bit 1 */
>    unsigned char :6;                                   /* Bits 2-7 */
>   } Read;
> }
> DAC960_BA_InboundDoorBellRegister_T;
>
>
>
> What would I do now is modify  DAC960_LA_InitializationInProgressP() as
> follows:
>
> static inline
> boolean DAC960_BA_InitializationInProgressP(void *ControllerBaseAddress)
> {
>   unsigned long InboundDoorBellRegister =
>    le32_to_cpu(ControllerBaseAddress +
> DAC960_BA_InboundDoorBellRegisterOffset);
>   return (boolean) !(InboundDoorBellRegister & 0x0002);
> }
>
> Is it correct ?

No, you must still use readb(), not a direct memory access.
Furthermore readw() and readl() do byteswapping theirselves on big-endian
architectures.

For this case le32_to_cpu() is wrong too, because it's meant for 32-bit
access while the original code used readb(), which does an 8 bit-access.
And 8-bit accesses don't have to be swapped.

Their is another issue with bitfields, though: their definition is reversed
for little and big endian machines. So you need two different struct
definitions, depending on the endianness.

> And where can I find the cpu_to_le32() and le32_to_cpu() declaration or
> a guide on how to use them ?

include/linux/byteorder/

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: another endianness issue...

[Dan Malek]

Guillaume Laurès wrote:

> static inline
> boolean DAC960_BA_InitializationInProgressP(void *ControllerBaseAddress)
> {
>   DAC960_BA_InboundDoorBellRegister_T InboundDoorBellRegister;


It would also be nice if you would read the Linux kernel coding
standards
document.  Upper/lower case and thirty character object names are
not appreciated.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/