linux-apus-devel

Re: Diff`s for MOL

[Michel <da...@re...>]

Alan Buxey wrote:

> > ppc_ksyms.c I deleted the line(238) EXPORT_SYMBOL(mol_interface).
> 
> there is far far more to get MOL running than that single line. I counted
> (and inserted) over 30 lines of code into various arch/ppc files to get
> MOL support,

I'm creating a MOL branch (again) called mol-branch now. Please commit your
MOL changes there.


> however, though the kernel still compiles, it then crashes
> upon bootup..this is an ongoing investigation (i now need to do some
> APUS_PROGRESS calls - but am insufficiently trained to jump straight into
> this (help! anyone? :-)) )

I see APUS_PROGRESS isn't in our code anymore. Time to dig up some old
versions... Anyway, what APUS_PROGRESS(n) basically did was write n to a fixed
memory address (don't remember - something like 0xe0001234 ?) which wouldn't
be cleared on reboot. You could read that value back with a memory viewer in
AmigaOS to find out how far the code ran.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

CVS Update: 2.2

[Michel D. <mda...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/
Changes by:	mda...@sl....	00/09/26 05:07:52

Modified files:
	2.2/arch/ppc/: Tag: mol-branch config.in 

Log message:
	enable MOL again, hopefully this time really in the MOL branch

CVS Update: 2.2

[Michel D. <mda...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/
Changes by:	mda...@sl....	00/09/26 05:04:03

Modified files:
	2.2/arch/ppc/: config.in 

Log message:
	D'oh

CVS Update: 2.2

[Michel D. <mda...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/
Changes by:	mda...@sl....	00/09/26 05:02:51

Modified files:
	2.2/arch/ppc/: config.in 

Log message:
	enable MOL again in the MOL branch :)

CVS Update: 2.2

[Michel D. <mda...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/
Changes by:	mda...@sl....	00/09/26 04:53:37

Modified files:
	2.2/arch/ppc/: config.in 

Log message:
	disable MOL in the trunk

Re: PCI amiga's..

[Michel <da...@re...>]

Geert Uytterhoeven wrote:
> 
> On Sun, 24 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> > Michael Schmitz wrote:
> > > I do know that the option UseFBDev will make XFree use the kernel fbdev
> > > API _once the card has been detected_. What I complain about is the lack
> > > of a mechanism to tell XFree 'don't touch this card, the kernel fbdev
> > > driver at /dev/fb<index> knows how to handle it' already at the probe
> > stage.
> >
> > If you provide the bus ID, the X server won't mess with the device if the
> > memory regions etc. are sane. Development is taking place to automate the
> > (non-trivial) assignment fbdev <-> pcidev . If you know how to do it
> > easily,
> 
> > patches go to pa...@XF... or fi...@XF..., design suggestions
> > to xp...@XF... :)
> 
> However, it's quite easy to match fbdevs with PCI devs, cfr. the patches I
> send to Michel.

Unfortunately, your patch doesn't work with the r128 driver, only with the
plain fbdev driver. I'll have to investigate what's going on, but even more so
why the MMIO region isn't mapped correctly...


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

Re: PCI amiga's..

[Geert U. <ge...@li...>]

On Sun, 24 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> Michael Schmitz wrote:
> > I do know that the option UseFBDev will make XFree use the kernel fbdev
> > API _once the card has been detected_. What I complain about is the lack
> > of a mechanism to tell XFree 'don't touch this card, the kernel fbdev
> > driver at /dev/fb<index> knows how to handle it' already at the probe stage.
> 
> If you provide the bus ID, the X server won't mess with the device if the
> memory regions etc. are sane. Development is taking place to automate the
> (non-trivial) assignment fbdev <-> pcidev . If you know how to do it easily,

> patches go to pa...@XF... or fi...@XF..., design suggestions to
> xp...@XF... :)

However, it's quite easy to match fbdevs with PCI devs, cfr. the patches I
send to Michel.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: Diff`s for MOL

[Alan B. <al...@ms...>]

hi,

> ppc_ksyms.c I deleted the line(238) EXPORT_SYMBOL(mol_interface).

there is far far more to get MOL running than that single line. I counted
(and inserted) over 30 lines of code into various arch/ppc files to get
MOL support, however, though the kernel still compiles, it then crashes
upon bootup..this is an ongoing investigation (i now need to do some
APUS_PROGRESS calls - but am insufficiently trained to jump straight into
this (help! anyone? :-)) ) 

alan

Re: PCI amiga's..

[Michael S. <sc...@op...>]

> > WRT X: I have a hard time to grok the convoluted structure of the X code.
> > Easier to work around such X quirks, f.e. in the kernel (I tried to
> > somehow keep X from messing with my PCI config to no avail).
> 
> Granted, the XFree86 tree is complex and takes time to learn one's way around.
> I don't see a significant difference to the Linux kernel tree though.

The significant difference being I have more or less learned my way around
part of the latter. Plus the Linux kernel doesn't use a friggin' new data
type for every other function or variable that I need to look up
separately :-) 

> > Don't look for any X patches of mine.
> 
> I ask you to be constructive. If you can't improve it yourself, it would be
> nice if you at least contacted the responsible people with your ideas how to
> do it better. Instead of complaining everywhere.

I could do that - once I've talked to Geert about what would be required
on the kernel side to support a new fbdev ioctl. I'd be surprised to hear
anything besides 'it's the kernels fault' or 'send a patch' though.

	Michael

Diff`s for MOL

[MICHAEL H. <101...@ge...>]

Hello User

This Mail I write on Samuel Rydh ( the Developer from MOL )  

Hello Samuel,


I would like to write you today, because I unite questions to MOL had.

The Diff`s those the MOL package is attached I processed and into those

Kernelsourcen 2.2.10 for Linux-APUS(Amiga) with trained.  From the file

ppc_ksyms.c I deleted the line(238) EXPORT_SYMBOL(mol_interface).

Thereby not, if I compile the Kernel the message

"undefined reference mol_interface" is displayed.

This message is displayed, if I switch "loadable modules support" on.

And the line EXPORT_SYMBOL(mol_interface) itself in the file ppc_ksyms.c

finds.

The Kernel with loadable modules support however without the line

EXPORT_SYMBOL(mol_interface) runs very stably.

Also the Runtime Patche are correctly executed, if I the Binary

from MOL start.  But at the end I receive the error message with
mol_interface,

if startmol is executed.

I transmit the four files also, which I processed to you.

Perhaps you can regard it once also.

And say to me, I make which error.  Or like the Reference too mol_interface

to create is.

It would make me happy much, if you can help me.


   with kind regards

                            Micha

Re: PCI amiga's..

[Michel <dae...@st...>]

Michael Schmitz wrote:

> WRT X: I have a hard time to grok the convoluted structure of the X code.
> Easier to work around such X quirks, f.e. in the kernel (I tried to
> somehow keep X from messing with my PCI config to no avail).

Granted, the XFree86 tree is complex and takes time to learn one's way around.
I don't see a significant difference to the Linux kernel tree though.


> Don't look for any X patches of mine.

I ask you to be constructive. If you can't improve it yourself, it would be
nice if you at least contacted the responsible people with your ideas how to
do it better. Instead of complaining everywhere.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

Re: PCI amiga's..

[Geert U. <ge...@li...>]

On Sun, 24 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> Michael Schmitz wrote:
> > > In  free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus
> > > some *Pci.c files for several arches exist, but none for m68k. The files
> > > say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I
> > > only have /proc/bus/zorro, but not pci... so maybe it would not make sense
> > > to add m68k to the Imakefile?
> > 
> > No, that would not make sense unless we add code in the kernel to
> > masquerade the m68k builtin framebuffer devices as PCI devices of some
> > sort (and I don't just mean support for /proc/bus/pci).
> 
> I have implemented something like this for the Permedia2 based boards in the
> APUS tree. But I don't think it's feasible for all graphics hardware.

That's not really true: you didn't fake a PCI bus, you implemented access to
the existing PCI bus on your PPC board.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: PCI amiga's..

[Geert U. <ge...@li...>]

On Sat, 23 Sep 2000, Christian T. Steigies wrote:
> On Fri, Sep 22, 2000 at 08:37:33PM +0200, Michael Schmitz wrote:
> > I know just barely enough to screw up a xfree build, and I don't have a
> > fast m68k for builds. Just in case you were about to ask.
> Well, ask me, I know barely enough to circumvent the glitches in the debian
> package to make 3.3.6 build.
> 
> Ok, here comes the problem. I made patches for two Imakefile errors, build
> fails now here:
> 
> gcc -o pcitweak -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs     -L../../../../../exports/lib pcitweak.o -L../os-support -lxf86_os -L../dummylib -ldummy       -Wl,-rpath-link,../../../../../exports/lib
> pcitweak.o: In function `main':
> pcitweak.o(.text+0x138): undefined reference to `xf86scanpci'
> pcitweak.o(.text+0x2a6): undefined reference to `xf86scanpci'
> pcitweak.o(.text+0x2b8): undefined reference to `pciTag'
> pcitweak.o(.text+0x2d2): undefined reference to `pciReadByte'
> pcitweak.o(.text+0x2f0): undefined reference to `pciReadWord'
> pcitweak.o(.text+0x306): undefined reference to `pciReadLong'
> pcitweak.o(.text+0x338): undefined reference to `pciWriteByte'
> pcitweak.o(.text+0x350): undefined reference to `pciWriteWord'
> pcitweak.o(.text+0x360): undefined reference to `pciWriteLong'
> collect2: ld returned 1 exit status
> make[7]: *** [pcitweak] Error 1
> make[7]: Leaving directory `/build/xfree86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/etc'
> 
> In  free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus
> some *Pci.c files for several arches exist, but none for m68k. The files
> say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I only
> have /proc/bus/zorro, but not pci... so maybe it would not make sense to add
> m68k to the Imakefile?

/proc/bus/pci is present only on a box that actually has PCI.

> However, without pci, I have some problems to get xfree4.0 to build, see
> error messages above. I think (anybody with a clue correct me please) that
> XF4.0 requires some pci functions, or some major rework in the (I)Makefiles
> and whatnot. So if somebody has a proposal (dummy, or maybe some "real" pci
> functions for m68k) or maybe even a patch, I'd be happy to hear about it.

Since some m68k boxes have PCI, just clone (or enable) the code that is used
on other Linux platforms. If /proc/bus/pci is not present, that code should
notice and decide there are no PCI devices. If it doesn't the PCI code in
XFree86 is broken.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: CSPPC SCSI driver

[Geert U. <ge...@li...>]

On Sat, 23 Sep 2000 fh...@at... wrote:
> Anyone care to comment on any of this?
> 
> The first address is the physical address of the 53c770 SCSI. This should
> be correct.  I got the address from Ralph Schmidt.
>  
> paddr: f40000
> 
> When the ioremap_nocache is run using the physical address
> the virtual address comes out to be this:
> 
> vaddr: 80f40000
> 
> The np->reg variable is set to the virtual address and uses
> that address to access the chip registers.

OK.

> How is the kernel using this virtual address to translate
> to the physical address required to access the chip registers?

The kernel uses the MMU to map the virtual addresses. So if you access virtual
0x80f40000, the CPU will really access physical 0xf40000.

(BTW, since 0xf40000 is in Zorro II space (< 16 MB), you don't really have to
 use ioremap(), but could live with ZTWO_VADDR() and ZTWO_PADDR() to convert
 from physical to virtual and vice versa).

> should I be using virt_to_phys() to access all SCSI chip
> registers?

No.

But you have to use virt_to_phys() (or ZTWO_VADDR(), for Zorro II addresses)
to translate addresses for the DMA engine of the SCSI chip.
In the kernel, the CPU needs the virtual address of the buffer in RAM, while
the DMA engine needs the bus address of the buffer in RAM. I assume bus
address == physical address, which is probably the case.

In reality we have:
  - virtual address: view from the CPU in kernel mode, before translation by
    the MMU)
  - physical address: view from the CPU after translation by the MMU
  - bus address: view from the DMA engine in the SCSI chip


Another example: the Ariadne Ethernet card, which sends/receives Ethernet
packets using buffers in the RAM on the card.

In my box, the Ariadne is at 0xe90000 (physical). Since this is in Zorro II
space, the virtual address of the card is 0x80e90000. The RAM on the card
starts at offset 0x8000. So if I have a packet buffer at offset 0x400 inside
the RAM, the following is valid:

  - The CPU in kernel mode accesses the packet at virtual address 0x80e98400
  - The physical address of the packet is 0xe98400
  - The Ethernet chip sees all addresses relative to the start of the RAM on
    the card, so it has to be told the packet is at bus address 0x400

> There is no such thing as an I/O port (at least in the PC
> sense) on the Amiga?

No.

> Someone told me on a linux news group to use check_mem_region()
> /request_mem_region() instead of check_region()/request_region() in the
> driver, although it appears that the latter functions are again aimed
> toward the PC style hardware that has I/O ports.  What does those
> functions do on APUS, if anything?  Also, the "mem" versions of those
> functions are not in the 2.2.10 kernel I have been using. Are they new in
> the 2.3/2.4 kernels?

request_mem_region() is used to mark regions in memory space busy. After that
they show up in /proc/iomem. This is indeed something introduced in 2.3.x.

For now you shouldn't care about that. request_mem_region() is not vital to
get the driver working.

Good luck!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: keymap

[Michel <dae...@st...>]

Alan Buxey wrote:

> > While I was at it, I made a bug cleanup in the FTP area. Almost everything
> > is in obsolete/ now, and I am in the process of uploading the more or less
> > current stuff to the SourceForge file modules.
> 
> even more cleanup? :-) We shouldnt have too many items as file modules

Care to look at it before commenting? There isn't a single module more, the
modules only got more population from the past.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

Re: keymap

[Alan B. <al...@ms...>]

hi,

> While I was at it, I made a bug cleanup in the FTP area. Almost everything is
> in obsolete/ now, and I am in the process of uploading the more or less
> current stuff to the SourceForge file modules.

even more cleanup? :-) We shouldnt have too many items as file modules
 
alan

Re: PCI amiga's..

[Michael S. <sc...@zi...>]

> > > Just look at the PPC PCI code, that works fine without /proc/pci - tested
> > > on APUS.
> > 
> > Does it also work without PCI hardware?
> 
> Yes, I had to add fbdev probing code to the glint driver though which is still
> considered a hack.

Fine, that could be a starting point.  

> > It's not about the convenient API for PCI but about the convenient API for
> > mapping IO and memory of the graphics hardware plus the fbdev ioctls to
> > set video modes, color entries and more. fbdev has been in the official
> > kernel for quite a while now.
> 
> Yes, in the official _Linux_ kernel. What about all the BSDs, Solaris (I know
> that also has some kind of framebuffer device, but nobody has bothered to add
> code for that), the various System V flavours, OS/2, ... ?

I was talking about Linux here. Obviously, on systems without a sane
method to access the display, the low level hacks^H^H^H^Hooks have to be
used. 

> > I do know that the option UseFBDev will make XFree use the kernel fbdev
> > API _once the card has been detected_. What I complain about is the lack
> > of a mechanism to tell XFree 'don't touch this card, the kernel fbdev
> > driver at /dev/fb<index> knows how to handle it' already at the probe stage.
> 
> If you provide the bus ID, the X server won't mess with the device if the
> memory regions etc. are sane. Development is taking place to automate the

Nothing in Apple space has ever been 'sane'. And in the case of the Rage
Pro, the card design isn't sane to begin with (regardless where you map
the MMIO regions in PCI config space, they always show up at the end of
both little and big endian video RAM apertures). The kernel (Linux, that
is :-) fbdev driver just uses the 

> (non-trivial) assignment fbdev <-> pcidev . If you know how to do it easily,
> patches go to pa...@XF... or fi...@XF..., design suggestions to
> xp...@XF... :)

Add a fbdev->private field to hold PCI/Zorro/ISA/whatever dependent
framebuffer information, and an ioctl to retrieve that bit. That's only my
.01 Euro, and Geert may have reasons not to implement this. 

WRT X: I have a hard time to grok the convoluted structure of the X code.
Easier to work around such X quirks, f.e. in the kernel (I tried to
somehow keep X from messing with my PCI config to no avail). Don't look
for any X patches of mine. 

	Michael

[Fwd: [Reminder] 2000 Oldenburg Linux Developers Meeting]

[Michel <dae...@st...>]

-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

2.4 make

[Ken T. <ke...@we...>]

Is there a problem with Makefiles or depedencies in 2.4 ?

When I edit a file, fs/affs/file.c for instance and recompile, make
occasionally decides to make everything from the beginning - the
occasional bit is odd but that's what happens.

Ken.

Re: PCI amiga's..

[Michel <dae...@st...>]

Michael Schmitz wrote:
> 
> > > No, that would not make sense unless we add code in the kernel to
> > > masquerade the m68k builtin framebuffer devices as PCI devices of some
> > > sort (and I don't just mean support for /proc/bus/pci).
> >
> > I have implemented something like this for the Permedia2 based boards in
> > the APUS tree. But I don't think it's feasible for all graphics hardware.
> 
> I guess you have to create a fairly close emulation of real PCI hardware
> to fool XFree.

Right, not hard with the Permedia2 boards where the PCI config space is
available.

> I'd rather have XFree not assume PCI is available on Linux.

It doesn't. Or at least it works without.


> > > Now how does XFree86 4.x deal with legacy Intel hardware with just ISA
> > > or EISA but no PCI bus? Does this still work, at all??
> >
> > Yes. There's similar code for (E)ISA.
> 
> Good. That's just using hardcoded (S)VGA addresses?

Dunno, haven't looked at the code.


> > > There should be a way (in site.def, perhaps) to say 'there's no PCI on
> > > this architecture, use other access methods like VGA or fbdev'. If
> > > that's not possible, dummy PCI functions could be implemented that just
> > > return -ENODEV for anything if /proc/bus/pci isn't present, hoping XFree
> > > does what it is supposed to in this case: fall back on fbdev to map and
> > > access the hardware.
> >
> > Just look at the PPC PCI code, that works fine without /proc/pci - tested
> > on APUS.
> 
> Does it also work without PCI hardware?

Yes, I had to add fbdev probing code to the glint driver though which is still
considered a hack.


> > > If even that isn't possible, the design of XFree86 4.0 is badly broken
> > > (not that I'd be surprised; in my eyes the way XFree messes with PCI
> > > resources bypassing the kernel is a big design flaw and just asking for
> > > trouble).
> >
> > Many people have complained about that, but they forget that XFree86 runs
> > on a lot more OSs than just Linux which may not have such a convenient API
> > for PCI. And even the older Linux kernels don't.
> 
> It's not about the convenient API for PCI but about the convenient API for
> mapping IO and memory of the graphics hardware plus the fbdev ioctls to
> set video modes, color entries and more. fbdev has been in the official
> kernel for quite a while now.

Yes, in the official _Linux_ kernel. What about all the BSDs, Solaris (I know
that also has some kind of framebuffer device, but nobody has bothered to add
code for that), the various System V flavours, OS/2, ... ?


> I do know that the option UseFBDev will make XFree use the kernel fbdev
> API _once the card has been detected_. What I complain about is the lack
> of a mechanism to tell XFree 'don't touch this card, the kernel fbdev
> driver at /dev/fb<index> knows how to handle it' already at the probe stage.

If you provide the bus ID, the X server won't mess with the device if the
memory regions etc. are sane. Development is taking place to automate the
(non-trivial) assignment fbdev <-> pcidev . If you know how to do it easily,
patches go to pa...@XF... or fi...@XF..., design suggestions to
xp...@XF... :)


> Right now there's no way for the kernel fbdev driver to figure out
> Xfree just disabled the PCI IO or memory resource for its card, resulting
> in the first kernel panics I've ever seen with XFree on sane (non-Intel)
> hardware. Makes me think about whether the GGI people had it right all the
> time.
> 
> OTOH, it's all Apple's fault for setting up crazy PCI resources, and the
> kernel's fault for not demangling the PCI resource allocation. At least
> that's going to be solved in 2.4.

Exactly, setting up sane PCI regions is a kernel task IMHO and I consider it
plausible for the X server to assume that overlapping regions are a problem.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

Re: 2.2.10, SCSI driver and parranel port driver

[Ken T. <ke...@we...>]

On Sat, 23 Sep 2000, Marek Szyprowski wrote:

> After looking in source I noticed, that kernel uses "parport",

Hello,

I have a epson stylus on the Amiga port that works, prints anything I send
it.

Does your.config have lines

# CONFIG_PARPORT is not set
CONFIG_M68K_PRINTER=m

which produces lp_m68k.o and lp_intern.o in drivers/char.

> scsi0 : datain+dataout for command 0x42 02 40 01 00 00 00 00 10 00
> scsi0 : datain+dataout for command 0x42 02 40 01 00 00 00 00 10 00
> scsi0 : datain+dataout for command 0x47 00 00 00 02 00 49 00 4a 00
> 53c7xx: Non-aligned buffer with datain && dataout

Have a look at drivers/scsi/53c7xx.c, it would be easy to comment both
printks out.  Possibly the driver does not cope well with commands that
are used for 'playing'.

Ken.

Re: keymap

[Michel <dae...@st...>]

Matteo Cavalleri wrote:
> 
> thanks to _jedi_ ;) on the #linux-apus channel I've been able to fix my
> keymap problem with emacs. basically all the alt key mappings in the
> italian keymap were literally randomly mixed...
> 
> I think it would be a good idea to put it in the apus home page, and remove
> the old one as IIRC I found my old keymap on the old apus site.

Good idea, thanks!

I've put it in the new contrib/keymaps/console directory in the FTP area.

While I was at it, I made a bug cleanup in the FTP area. Almost everything is
in obsolete/ now, and I am in the process of uploading the more or less
current stuff to the SourceForge file modules.


Comments and suggestions welcome,

Michel, who should actually be learning for exams...


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

Re: PCI amiga's..

[Michael S. <sc...@zi...>]

> > No, that would not make sense unless we add code in the kernel to
> > masquerade the m68k builtin framebuffer devices as PCI devices of some
> > sort (and I don't just mean support for /proc/bus/pci).
> 
> I have implemented something like this for the Permedia2 based boards in the
> APUS tree. But I don't think it's feasible for all graphics hardware.

I guess you have to create a fairly close emulation of real PCI hardware
to fool XFree. I'd rather have XFree not assume PCI is available on Linux.
 
> > Now how does XFree86 4.x deal with legacy Intel hardware with just ISA or
> > EISA but no PCI bus? Does this still work, at all??
> 
> Yes. There's similar code for (E)ISA.

Good. That's just using hardcoded (S)VGA addresses? 

> > There should be a way (in site.def, perhaps) to say 'there's no PCI on
> > this architecture, use other access methods like VGA or fbdev'. If that's
> > not possible, dummy PCI functions could be implemented that just return
> > -ENODEV for anything if /proc/bus/pci isn't present, hoping XFree does
> > what it is supposed to in this case: fall back on fbdev to map and access
> > the hardware.
> 
> Just look at the PPC PCI code, that works fine without /proc/pci - tested on
> APUS.

Does it also work without PCI hardware? 

> > If even that isn't possible, the design of XFree86 4.0 is badly broken (not
> > that I'd be surprised; in my eyes the way XFree messes with PCI resources
> > bypassing the kernel is a big design flaw and just asking for trouble).
> 
> Many people have complained about that, but they forget that XFree86 runs on a
> lot more OSs than just Linux which may not have such a convenient API for PCI.
> And even the older Linux kernels don't.

It's not about the convenient API for PCI but about the convenient API for 
mapping IO and memory of the graphics hardware plus the fbdev ioctls to
set video modes, color entries and more. fbdev has been in the official
kernel for quite a while now. 

I do know that the option UseFBDev will make XFree use the kernel fbdev
API _once the card has been detected_. What I complain about is the lack
of a mechanism to tell XFree 'don't touch this card, the kernel fbdev
driver at /dev/fb<index> knows how to handle it' already at the probe
stage. Right now there's no way for the kernel fbdev driver to figure out
Xfree just disabled the PCI IO or memory resource for its card, resulting
in the first kernel panics I've ever seen with XFree on sane (non-Intel)
hardware. Makes me think about whether the GGI people had it right all the
time. 

OTOH, it's all Apple's fault for setting up crazy PCI resources, and the
kernel's fault for not demangling the PCI resource allocation. At least
that's going to be solved in 2.4. 

	Michael

Re: PCI amiga's..

[Michel <dae...@st...>]

Michael Schmitz wrote:

> > In  free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus
> > some *Pci.c files for several arches exist, but none for m68k. The files
> > say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I
> > only have /proc/bus/zorro, but not pci... so maybe it would not make sense
> > to add m68k to the Imakefile?
> 
> No, that would not make sense unless we add code in the kernel to
> masquerade the m68k builtin framebuffer devices as PCI devices of some
> sort (and I don't just mean support for /proc/bus/pci).

I have implemented something like this for the Permedia2 based boards in the
APUS tree. But I don't think it's feasible for all graphics hardware.


> Now how does XFree86 4.x deal with legacy Intel hardware with just ISA or
> EISA but no PCI bus? Does this still work, at all??

Yes. There's similar code for (E)ISA.


> > However, without pci, I have some problems to get xfree4.0 to build, see
> > error messages above. I think (anybody with a clue correct me please) that
> > XF4.0 requires some pci functions, or some major rework in the
> > (I)Makefiles and whatnot. So if somebody has a proposal (dummy, or maybe
> > some "real" pci functions for m68k) or maybe even a patch, I'd be happy to
> > hear about it.
> 
> There should be a way (in site.def, perhaps) to say 'there's no PCI on
> this architecture, use other access methods like VGA or fbdev'. If that's
> not possible, dummy PCI functions could be implemented that just return
> -ENODEV for anything if /proc/bus/pci isn't present, hoping XFree does
> what it is supposed to in this case: fall back on fbdev to map and access
> the hardware.

Just look at the PPC PCI code, that works fine without /proc/pci - tested on
APUS.


> If even that isn't possible, the design of XFree86 4.0 is badly broken (not
> that I'd be surprised; in my eyes the way XFree messes with PCI resources
> bypassing the kernel is a big design flaw and just asking for trouble).

Many people have complained about that, but they forget that XFree86 runs on a
lot more OSs than just Linux which may not have such a convenient API for PCI.
And even the older Linux kernels don't.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

Re: PCI amiga's..

[Michael S. <sc...@zi...>]

> > I know just barely enough to screw up a xfree build, and I don't have a
> > fast m68k for builds. Just in case you were about to ask.
> Well, ask me, I know barely enough to circumvent the glitches in the debian
> package to make 3.3.6 build.

I haven't even done that for a long time. 
 
> Ok, here comes the problem. I made patches for two Imakefile errors, build
> fails now here:
> 
> gcc -o pcitweak -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs     -L../../../../../exports/lib pcitweak.o -L../os-support -lxf86_os -L../dummylib -ldummy       -Wl,-rpath-link,../../../../../exports/lib
> pcitweak.o: In function `main':
> pcitweak.o(.text+0x138): undefined reference to `xf86scanpci'
> pcitweak.o(.text+0x2a6): undefined reference to `xf86scanpci'
> pcitweak.o(.text+0x2b8): undefined reference to `pciTag'
> pcitweak.o(.text+0x2d2): undefined reference to `pciReadByte'
> pcitweak.o(.text+0x2f0): undefined reference to `pciReadWord'
> pcitweak.o(.text+0x306): undefined reference to `pciReadLong'
> pcitweak.o(.text+0x338): undefined reference to `pciWriteByte'
> pcitweak.o(.text+0x350): undefined reference to `pciWriteWord'
> pcitweak.o(.text+0x360): undefined reference to `pciWriteLong'
> collect2: ld returned 1 exit status
> make[7]: *** [pcitweak] Error 1
> make[7]: Leaving directory `/build/xfree86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/etc'
> 
> In  free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus
> some *Pci.c files for several arches exist, but none for m68k. The files
> say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I only
> have /proc/bus/zorro, but not pci... so maybe it would not make sense to add
> m68k to the Imakefile?

No, that would not make sense unless we add code in the kernel to
masquerade the m68k builtin framebuffer devices as PCI devices of some
sort (and I don't just mean support for /proc/bus/pci). 

Now how does XFree86 4.x deal with legacy Intel hardware with just ISA or
EISA but no PCI bus? Does this still work, at all??

> However, without pci, I have some problems to get xfree4.0 to build, see
> error messages above. I think (anybody with a clue correct me please) that
> XF4.0 requires some pci functions, or some major rework in the (I)Makefiles
> and whatnot. So if somebody has a proposal (dummy, or maybe some "real" pci
> functions for m68k) or maybe even a patch, I'd be happy to hear about it.

There should be a way (in site.def, perhaps) to say 'there's no PCI on
this architecture, use other access methods like VGA or fbdev'. If that's
not possible, dummy PCI functions could be implemented that just return
-ENODEV for anything if /proc/bus/pci isn't present, hoping XFree does
what it is supposed to in this case: fall back on fbdev to map and access
the hardware. If even that isn't possible, the design of XFree86 4.0 is
badly broken (not that I'd be surprised; in my eyes the way XFree messes
with PCI resources bypassing the kernel is a big design flaw and just
asking for trouble). 

Just my idea. I'm sure the xperts disagree. We don't have a XFree
maintainer to take care of this anyway, it's not your job as the person
stuck with the task of building X for Debian/68k, and I doubt you'll get
Branden to do the heavy lifting on behalf of m68k. Unless someone is found 
to take care of the fundamental XFree problems on m68k, there won't be
XFree86 4.x for m68k.

	Michael