linux-apus-devel

Re: Kernel packages

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

hi,

> It isn't, try it.
> 
> The point is that gzip can't further compress the gzipped contents of the
> tarball, but it may compress the original contents better because there is
> more data to eliminate redundancy in.

okay, matching what is available in the other files, i get it
 
> I disagree. What's so hard about 'cp -R modules/* /lib/modules/' ? I consider
> that easier than having to figure out how to use tar. You could put in a
> script which does that and maybe runs depmod -a or whatever.

I'll work on this...would just keeping them in a plain .tar be a start
anyway?
 
> > it fails in the /arch/kernel direcrtory, problems with fork.c
> 
> What about posting the problems?

it happened late last0night, i havent had time to go further on this.

I'll download the 2.4test kernel image from sourceforge and use the
.config that that came with and see if the error is still present. if so,
then I'll continue and post the errors.

alan

Re: Kernel packages

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

Alan Buxey wrote:

> > One thing I noticed in the 'main' packages is that the tarball contains
> > another gzipped tarball with the modules. This doesn't make sense as it
> > prevents gzip from exploiting full compression for the 'outer' one. I
> > suggest either putting the modules in a modules/<version>/ subdirectory or
> > at least not gzipping their tarball.
> 
> this doesnt make sense...if gzip follows all sane rules of compression,
> then it doesnt matter whether you compress it all, or just compress what
> isnt already compressed.
> 
> ie take 4 directories, either tar them and gzip them, or tar and gzip each
> of them and tar and gzip the resulting .tgz's, the result should be the
> same in file size.

It isn't, try it.

The point is that gzip can't further compress the gzipped contents of the
tarball, but it may compress the original contents better because there is
more data to eliminate redundancy in.


> the reason why I chose the 'encapsulate' method for the modules is it
> makes it 4x easier for users to install the modules, as they dont have to
> make directories etc, untarring the modules package from root will do the
> work for them (i cant imagine how many user problems we'd face if they had
> to go around actually making directories! ;-) - after all, just see the
> number of problem emails that just HAVING modules creates :-))

I disagree. What's so hard about 'cp -R modules/* /lib/modules/' ? I consider
that easier than having to figure out how to use tar. You could put in a
script which does that and maybe runs depmod -a or whatever.


> > Another point is that I have forgotten to include the modules in the
> > latest 2.4 test package. It would be nice if from time to time, someone
> > who builds a working 2.4 kernel puts it in a package and uploads it.
> 
> i cant build a kernel from the 2.3 CVS tree (the first time I've ever
> tried was last night) I was going to make a '2.4' version similar to the
> vmapus-kit of 000814.
> 
> it fails in the /arch/kernel direcrtory, problems with fork.c

What about posting the problems?


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: Kernel packages

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

hi,

> One thing I noticed in the 'main' packages is that the tarball contains
> another gzipped tarball with the modules. This doesn't make sense as it
> prevents gzip from exploiting full compression for the 'outer' one. I suggest
> either putting the modules in a modules/<version>/ subdirectory or at least
> not gzipping their tarball.

this doesnt make sense...if gzip follows all sane rules of compression,
then it doesnt matter whether you compress it all, or just compress what
isnt already compressed.

ie take 4 directories, either tar them and gzip them, or tar and gzip each
of them and tar and gzip the resulting .tgz's, the result should be the
same in file size.
 
the reason why I chose the 'encapsulate' method for the modules is it
makes it 4x easier for users to install the modules, as they dont have to
make directories etc, untarring the modules package from root will do the
work for them (i cant imagine how many user problems we'd face if they had
to go around actually making directories! ;-) - after all, just see the
number of problem emails that just HAVING modules creates :-))

> Another point is that I have forgotten to include the modules in the latest
> 2.4 test package. It would be nice if from time to time, someone who builds a
> working 2.4 kernel puts it in a package and uploads it.

i cant build a kernel from the 2.3 CVS tree (the first time I've ever
tried was last night) I was going to make a '2.4' version similar to the
vmapus-kit of 000814. 

it fails in the /arch/kernel direcrtory, problems with fork.c

alan

Kernel packages

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

One thing I noticed in the 'main' packages is that the tarball contains
another gzipped tarball with the modules. This doesn't make sense as it
prevents gzip from exploiting full compression for the 'outer' one. I suggest
either putting the modules in a modules/<version>/ subdirectory or at least
not gzipping their tarball.


Another point is that I have forgotten to include the modules in the latest
2.4 test package. It would be nice if from time to time, someone who builds a
working 2.4 kernel puts it in a package and uploads it.


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

ZTWO_VADDR

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

Shouldn't ZTWO_VADDR() return a `void *' instead of an `unsigned long'?

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: debug=mem works now

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

On Thu, 14 Sep 2000, Geert Uytterhoeven wrote:
> On Thu, 14 Sep 2000, Geert Uytterhoeven wrote:
> > On Thu, 14 Sep 2000, Geert Uytterhoeven wrote:
> > > I'll try to cook an (untested) patch...
> > 
> > Does this sound OK? Please remove the debug code (marked with FIXME) after
> > testing. These cases just shouldn't happen.
> 
> Hmmm... since we need the struct resource anyway, perhaps it's even better to
> always use the static struct resource. And it doesn't make much sense to have
> two types of resource management (struct resource and struct chip_desc), so
> I'll remove the latter. Wait and see...

So what about this? Now the Chip RAM allocator uses the resource management
system to track allocations.

Caveat: the patch is untested, but it compiles.

I think something similar can be done for zorro_unused_z2ram[], but I don't
dare to touch it since I can't test the z2ram driver. Besides, I already
expect `Zorro: Address space collision on device ...' messages on systems with
Z2 RAM on Zorro expansion cards.

--- geert-chipram-2.4.0-test8/include/asm-m68k/amigahw.h.orig	Mon Jul 17 15:13:48 2000
+++ geert-chipram-2.4.0-test8/include/asm-m68k/amigahw.h	Mon Sep 18 16:31:43 2000
@@ -279,9 +279,12 @@
 #define ciab   ((*(volatile struct CIA *)(zTwoBase + CIAB_PHYSADDR)))
 
 #define CHIP_PHYSADDR	    (0x000000)
-#define chipaddr ((unsigned long)(zTwoBase + CHIP_PHYSADDR))
+
 void amiga_chip_init (void);
-void *amiga_chip_alloc (long size, const char *name);
+struct resource;
+void *__amiga_chip_alloc (unsigned long size, const char *name,
+			  struct resource *res);
+#define amiga_chip_alloc(size, name)	__amiga_chip_alloc(size, name, NULL)
 void amiga_chip_free (void *);
 unsigned long amiga_chip_avail( void ); /*MILAN*/
 
--- geert-chipram-2.4.0-test8/arch/ppc/amiga/chipram.c.orig	Tue Jul 18 14:08:47 2000
+++ geert-chipram-2.4.0-test8/arch/ppc/amiga/chipram.c	Mon Sep 18 17:26:56 2000
@@ -3,181 +3,111 @@
 **
 **      Modified 03-May-94 by Geert Uytterhoeven <ge...@li...>
 **          - 64-bit aligned allocations for full AGA compatibility
+**
+**	Rewritten 15/9/2000 by Geert to use resource management
 */
 
 #include <linux/config.h>
 #include <linux/types.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
-#include <linux/zorro.h>
+#include <linux/ioport.h>
+#include <linux/slab.h>
 #include <asm/amigahw.h>
 
-struct chip_desc {
-	unsigned first   :  1;
-	unsigned last    :  1;
-	unsigned alloced :  1;
-	unsigned length  : 24;
-	long pad;					/* We suppose this makes this struct 64 bits long!! */
-};
+unsigned long amiga_chip_size;
 
-#define DP(ptr) ((struct chip_desc *)(ptr))
-
-u_long amiga_chip_size;
+static struct resource chipram_res = { "Chip RAM", CHIP_PHYSADDR };
 static unsigned long chipavail;
 
-static struct resource chipram = { "Chip RAM", 0 };
-
-unsigned long amiga_chip_avail( void )
-{
-#ifdef DEBUG
-	printk("chip_avail : %ld bytes\n",chipavail);
-#endif
-	return chipavail;
-}
-
 
-void __init amiga_chip_init (void)
+void __init amiga_chip_init(void)
 {
-  struct chip_desc *dp;
-
-  if (!AMIGAHW_PRESENT(CHIP_RAM))
-    return;
+    if (!AMIGAHW_PRESENT(CHIP_RAM))
+	return;
 
 #ifndef CONFIG_APUS_FAST_EXCEPT
-  /*
-   * Remove the first 4 pages where PPC exception handlers will
-   * be located.
-   */
-  amiga_chip_size -= 0x4000;
+    /*
+     *  Remove the first 4 pages where PPC exception handlers will be located
+     */
+    amiga_chip_size -= 0x4000;
 #endif
-  chipram.end = amiga_chip_size-1;
-  request_resource(&iomem_resource, &chipram);
-
-  /* initialize start boundary */
-
-  dp = DP(chipaddr);
-  dp->first = 1;
-
-  dp->alloced = 0;
-  dp->length = amiga_chip_size - 2*sizeof(*dp);
-
-  /* initialize end boundary */
-  dp = DP(chipaddr + amiga_chip_size) - 1;
-  dp->last = 1;
-  
-  dp->alloced = 0;
-  dp->length = amiga_chip_size - 2*sizeof(*dp);
-  chipavail = dp->length;  /*MILAN*/
+    chipram_res.end = amiga_chip_size-1;
+    request_resource(&iomem_resource, &chipram_res);
 
-#ifdef DEBUG
-  printk ("chipram end boundary is %p, length is %d\n", dp,
-	  dp->length);
-#endif
+    chipavail = amiga_chip_size;
 }
 
-void *amiga_chip_alloc(long size, const char *name)
-{
-	/* last chunk */
-	struct chip_desc *dp;
-	void *ptr;
-
-	/* round off */
-	size = (size + 7) & ~7;
+    
+    /*
+     *  Warning:
+     *  `res' is meant to be non-NULL only for drivers that need to allocate
+     *  Chip RAM before kmalloc() is functional. As a consequence, those
+     *  drivers must not free that Chip RAM afterwards.
+     */
 
-#ifdef DEBUG
-   printk("amiga_chip_alloc: allocate %ld bytes\n", size);
-#endif
+void *__amiga_chip_alloc(unsigned long size, const char *name,
+			 struct resource *res)
+{
+    void *ptr;
+    int kmalloced = 0;
 
-	/*
-	 * get pointer to descriptor for last chunk by 
-	 * going backwards from end chunk
-	 */
-	dp = DP(chipaddr + amiga_chip_size) - 1;
-	dp = DP((unsigned long)dp - dp->length) - 1;
-	
-	while ((dp->alloced || dp->length < size)
-	       && !dp->first)
-		dp = DP ((unsigned long)dp - dp[-1].length) - 2;
-
-	if (dp->alloced || dp->length < size) {
-		printk ("no chipmem available for %ld allocation\n", size);
-		return NULL;
-	}
-
-	if (dp->length < (size + 2*sizeof(*dp))) {
-		/* length too small to split; allocate the whole thing */
-		dp->alloced = 1;
-		ptr = (void *)(dp+1);
-		dp = DP((unsigned long)ptr + dp->length);
-		dp->alloced = 1;
-#ifdef DEBUG
-		printk ("amiga_chip_alloc: no split\n");
-#endif
-	} else {
-		/* split the extent; use the end part */
-		long newsize = dp->length - (2*sizeof(*dp) + size);
+    /* round off */
+    size = (size + 7) & ~7;
 
 #ifdef DEBUG
-		printk ("amiga_chip_alloc: splitting %d to %ld\n", dp->length,
-			newsize);
+    printk("__amiga_chip_alloc: allocate %ld bytes\n", size);
 #endif
-		dp->length = newsize;
-		dp = DP((unsigned long)(dp+1) + newsize);
-		dp->first = dp->last = 0;
-		dp->alloced = 0;
-		dp->length = newsize;
-		dp++;
-		dp->first = dp->last = 0;
-		dp->alloced = 1;
-		dp->length = size;
-		ptr = (void *)(dp+1);
-		dp = DP((unsigned long)ptr + size);
-		dp->alloced = 1;
-		dp->length = size;
-	}
 
+    if (!res) {
+	if (!(res = kmalloc(sizeof(*res), GFP_KERNEL)))
+	    return NULL;
+	memset(res, 0, sizeof(*res));
+	res->name = name;
+	kmalloced = 1;
+    }
+    if (allocate_resource(&chipram_res, res, size, 0, -1, 8, NULL, NULL) < 0) {
+	printk("__amiga_chip_alloc: no chipmem available for %ld allocation\n",
+	       size);
+	if (kmalloced)
+	    kfree(res);
+	return NULL;
+    }
+    ptr = (void *)ZTWO_VADDR(res->start);
+    chipavail -= size;
 #ifdef DEBUG
-	printk ("amiga_chip_alloc: returning %p\n", ptr);
+    printk("__amiga_chip_alloc: returning %p\n", ptr);
 #endif
-
-	if ((unsigned long)ptr & 7)
-		panic("amiga_chip_alloc: alignment violation\n");
-
-    chipavail -= size + (2*sizeof(*dp)); /*MILAN*/
-
-    if (!request_mem_region(ZTWO_PADDR(ptr), size, name))
-	printk(KERN_WARNING "amiga_chip_alloc: region of size %ld at 0x%08lx "
-	       "is busy\n", size, ZTWO_PADDR(ptr));
-
     return ptr;
 }
 
-void amiga_chip_free (void *ptr)
+
+void amiga_chip_free(void *ptr)
 {
-	struct chip_desc *sdp = DP(ptr) - 1, *dp2;
-	struct chip_desc *edp = DP((unsigned long)ptr + sdp->length);
+    unsigned long start = ZTWO_PADDR(ptr);
+    struct resource **p, *res;
+    unsigned long size;
+
+    for (p = &chipram_res.child; (res = *p); p = &res->sibling) {
+	if (res->start != start)
+	    continue;
+	*p = res->sibling;
+	size = res->end-start;
+#ifdef DEBUG
+	printk("amiga_chip_free: free %ld bytes at %p\n", size, ptr);
+#endif
+	chipavail += size;
+	kfree(res);
+	return;
+    }
+    printk("amiga_chip_free: trying to free nonexistent region at %p\n", ptr);
+}
 
-    chipavail += sdp->length + (2* sizeof(sdp)); /*MILAN*/
+
+unsigned long amiga_chip_avail(void)
+{
 #ifdef DEBUG
-   printk("chip_free: free %ld bytes at %p\n",sdp->length,ptr);
+	printk("amiga_chip_avail : %ld bytes\n", chipavail);
 #endif
-	/* deallocate the chunk */
-	sdp->alloced = edp->alloced = 0;
-	release_mem_region(ZTWO_PADDR(ptr), sdp->length);
-
-	/* check if we should merge with the previous chunk */
-	if (!sdp->first && !sdp[-1].alloced) {
-		dp2 = DP((unsigned long)sdp - sdp[-1].length) - 2;
-		dp2->length += sdp->length + 2*sizeof(*sdp);
-		edp->length = dp2->length;
-		sdp = dp2;
-	}
-
-	/* check if we should merge with the following chunk */
-	if (!edp->last && !edp[1].alloced) {
-		dp2 = DP((unsigned long)edp + edp[1].length) + 2;
-		dp2->length += edp->length + 2*sizeof(*sdp);
-		sdp->length = dp2->length;
-		edp = dp2;
-	}
+	return chipavail;
 }
--- geert-chipram-2.4.0-test8/arch/ppc/amiga/config.c.orig	Mon Jul 17 14:57:32 2000
+++ geert-chipram-2.4.0-test8/arch/ppc/amiga/config.c	Mon Sep 18 17:16:03 2000
@@ -732,9 +732,12 @@
     }
 }
 
+static struct resource debug_res = { "Debug" };
+
 static void amiga_savekmsg_init(void)
 {
-    savekmsg = (struct savekmsg *)amiga_chip_alloc(SAVEKMSG_MAXMEM);
+    savekmsg = (struct savekmsg *)__amiga_chip_alloc(SAVEKMSG_MAXMEM, NULL,
+						     &debug_res);
     savekmsg->magic1 = SAVEKMSG_MAGIC1;
     savekmsg->magic2 = SAVEKMSG_MAGIC2;
     savekmsg->magicptr = virt_to_phys(savekmsg);
--- geert-chipram-2.4.0-test8/arch/m68k/amiga/chipram.c.orig	Tue Jul 18 14:04:31 2000
+++ geert-chipram-2.4.0-test8/arch/m68k/amiga/chipram.c	Mon Sep 18 17:26:40 2000
@@ -3,173 +3,104 @@
 **
 **      Modified 03-May-94 by Geert Uytterhoeven <ge...@li...>
 **          - 64-bit aligned allocations for full AGA compatibility
+**
+**	Rewritten 15/9/2000 by Geert to use resource management
 */
 
 #include <linux/types.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
-#include <linux/zorro.h>
+#include <linux/ioport.h>
+#include <linux/slab.h>
 #include <asm/amigahw.h>
 
-struct chip_desc {
-	unsigned first   :  1;
-	unsigned last    :  1;
-	unsigned alloced :  1;
-	unsigned length  : 24;
-	long pad;					/* We suppose this makes this struct 64 bits long!! */
-};
+unsigned long amiga_chip_size;
 
-#define DP(ptr) ((struct chip_desc *)(ptr))
-
-u_long amiga_chip_size;
+static struct resource chipram_res = { "Chip RAM", CHIP_PHYSADDR };
 static unsigned long chipavail;
 
-static struct resource chipram = { "Chip RAM", 0 };
-
-unsigned long amiga_chip_avail( void )
-{
-#ifdef DEBUG
-	printk("chip_avail : %ld bytes\n",chipavail);
-#endif
-	return chipavail;
-}
-
 
-void __init amiga_chip_init (void)
+void __init amiga_chip_init(void)
 {
-  struct chip_desc *dp;
+    if (!AMIGAHW_PRESENT(CHIP_RAM))
+	return;
 
-  if (!AMIGAHW_PRESENT(CHIP_RAM))
-    return;
+    chipram_res.end = amiga_chip_size-1;
+    request_resource(&iomem_resource, &chipram_res);
 
-  chipram.end = amiga_chip_size-1;
-  request_resource(&iomem_resource, &chipram);
-
-  /* initialize start boundary */
-
-  dp = DP(chipaddr);
-  dp->first = 1;
-
-  dp->alloced = 0;
-  dp->length = amiga_chip_size - 2*sizeof(*dp);
-
-  /* initialize end boundary */
-  dp = DP(chipaddr + amiga_chip_size) - 1;
-  dp->last = 1;
-  
-  dp->alloced = 0;
-  dp->length = amiga_chip_size - 2*sizeof(*dp);
-  chipavail = dp->length;  /*MILAN*/
-
-#ifdef DEBUG
-  printk ("chipram end boundary is %p, length is %d\n", dp,
-	  dp->length);
-#endif
+    chipavail = amiga_chip_size;
 }
 
-void *amiga_chip_alloc(long size, const char *name)
-{
-	/* last chunk */
-	struct chip_desc *dp;
-	void *ptr;
+    
+    /*
+     *  Warning:
+     *  `res' is meant to be non-NULL only for drivers that need to allocate
+     *  Chip RAM before kmalloc() is functional. As a consequence, those
+     *  drivers must not free that Chip RAM afterwards.
+     */
 
-	/* round off */
-	size = (size + 7) & ~7;
-
-#ifdef DEBUG
-   printk("amiga_chip_alloc: allocate %ld bytes\n", size);
-#endif
+void *__amiga_chip_alloc(unsigned long size, const char *name,
+			 struct resource *res)
+{
+    void *ptr;
+    int kmalloced = 0;
 
-	/*
-	 * get pointer to descriptor for last chunk by 
-	 * going backwards from end chunk
-	 */
-	dp = DP(chipaddr + amiga_chip_size) - 1;
-	dp = DP((unsigned long)dp - dp->length) - 1;
-	
-	while ((dp->alloced || dp->length < size)
-	       && !dp->first)
-		dp = DP ((unsigned long)dp - dp[-1].length) - 2;
-
-	if (dp->alloced || dp->length < size) {
-		printk ("no chipmem available for %ld allocation\n", size);
-		return NULL;
-	}
-
-	if (dp->length < (size + 2*sizeof(*dp))) {
-		/* length too small to split; allocate the whole thing */
-		dp->alloced = 1;
-		ptr = (void *)(dp+1);
-		dp = DP((unsigned long)ptr + dp->length);
-		dp->alloced = 1;
-#ifdef DEBUG
-		printk ("amiga_chip_alloc: no split\n");
-#endif
-	} else {
-		/* split the extent; use the end part */
-		long newsize = dp->length - (2*sizeof(*dp) + size);
+    /* round off */
+    size = (size + 7) & ~7;
 
 #ifdef DEBUG
-		printk ("amiga_chip_alloc: splitting %d to %ld\n", dp->length,
-			newsize);
+    printk("__amiga_chip_alloc: allocate %ld bytes\n", size);
 #endif
-		dp->length = newsize;
-		dp = DP((unsigned long)(dp+1) + newsize);
-		dp->first = dp->last = 0;
-		dp->alloced = 0;
-		dp->length = newsize;
-		dp++;
-		dp->first = dp->last = 0;
-		dp->alloced = 1;
-		dp->length = size;
-		ptr = (void *)(dp+1);
-		dp = DP((unsigned long)ptr + size);
-		dp->alloced = 1;
-		dp->length = size;
-	}
 
+    if (!res) {
+	if (!(res = kmalloc(sizeof(*res), GFP_KERNEL)))
+	    return NULL;
+	memset(res, 0, sizeof(*res));
+	res->name = name;
+	kmalloced = 1;
+    }
+    if (allocate_resource(&chipram_res, res, size, 0, -1, 8, NULL, NULL) < 0) {
+	printk("__amiga_chip_alloc: no chipmem available for %ld allocation\n",
+	       size);
+	if (kmalloced)
+	    kfree(res);
+	return NULL;
+    }
+    ptr = (void *)ZTWO_VADDR(res->start);
+    chipavail -= size;
 #ifdef DEBUG
-	printk ("amiga_chip_alloc: returning %p\n", ptr);
+    printk("__amiga_chip_alloc: returning %p\n", ptr);
 #endif
-
-	if ((unsigned long)ptr & 7)
-		panic("amiga_chip_alloc: alignment violation\n");
-
-    chipavail -= size + (2*sizeof(*dp)); /*MILAN*/
-
-    if (!request_mem_region(ZTWO_PADDR(ptr), size, name))
-	printk(KERN_WARNING "amiga_chip_alloc: region of size %ld at 0x%08lx "
-	       "is busy\n", size, ZTWO_PADDR(ptr));
-
     return ptr;
 }
 
-void amiga_chip_free (void *ptr)
+
+void amiga_chip_free(void *ptr)
 {
-	struct chip_desc *sdp = DP(ptr) - 1, *dp2;
-	struct chip_desc *edp = DP((unsigned long)ptr + sdp->length);
+    unsigned long start = ZTWO_PADDR(ptr);
+    struct resource **p, *res;
+    unsigned long size;
+
+    for (p = &chipram_res.child; (res = *p); p = &res->sibling) {
+	if (res->start != start)
+	    continue;
+	*p = res->sibling;
+	size = res->end-start;
+#ifdef DEBUG
+	printk("amiga_chip_free: free %ld bytes at %p\n", size, ptr);
+#endif
+	chipavail += size;
+	kfree(res);
+	return;
+    }
+    printk("amiga_chip_free: trying to free nonexistent region at %p\n", ptr);
+}
 
-    chipavail += sdp->length + (2* sizeof(sdp)); /*MILAN*/
+
+unsigned long amiga_chip_avail(void)
+{
 #ifdef DEBUG
-   printk("chip_free: free %ld bytes at %p\n",sdp->length,ptr);
+	printk("amiga_chip_avail : %ld bytes\n", chipavail);
 #endif
-	/* deallocate the chunk */
-	sdp->alloced = edp->alloced = 0;
-	release_mem_region(ZTWO_PADDR(ptr), sdp->length);
-
-	/* check if we should merge with the previous chunk */
-	if (!sdp->first && !sdp[-1].alloced) {
-		dp2 = DP((unsigned long)sdp - sdp[-1].length) - 2;
-		dp2->length += sdp->length + 2*sizeof(*sdp);
-		edp->length = dp2->length;
-		sdp = dp2;
-	}
-
-	/* check if we should merge with the following chunk */
-	if (!edp->last && !edp[1].alloced) {
-		dp2 = DP((unsigned long)edp + edp[1].length) + 2;
-		dp2->length += edp->length + 2*sizeof(*sdp);
-		sdp->length = dp2->length;
-		edp = dp2;
-	}
+	return chipavail;
 }
--- geert-chipram-2.4.0-test8/arch/m68k/amiga/amisound.c.orig	Fri Jul 28 21:19:00 2000
+++ geert-chipram-2.4.0-test8/arch/m68k/amiga/amisound.c	Mon Sep 18 16:29:00 2000
@@ -11,6 +11,7 @@
 #include <linux/sched.h>
 #include <linux/timer.h>
 #include <linux/init.h>
+#include <linux/ioport.h>
 
 #include <asm/system.h>
 #include <asm/amigahw.h>
@@ -40,9 +41,11 @@
 
 static u_long clock_constant;
 
+static struct resource beep_res = { "Beep" };
+
 void __init amiga_init_sound(void)
 {
-	snd_data = amiga_chip_alloc(sizeof(sine_data), "Beep");
+	snd_data = __amiga_chip_alloc(sizeof(sine_data), NULL, &beep_res);
 	if (!snd_data) {
 		printk (KERN_CRIT "amiga init_sound: failed to allocate chipmem\n");
 		return;
--- geert-chipram-2.4.0-test8/arch/m68k/amiga/amiga_ksyms.c.orig	Tue Jul 18 14:04:31 2000
+++ geert-chipram-2.4.0-test8/arch/m68k/amiga/amiga_ksyms.c	Fri Sep 15 16:34:18 2000
@@ -18,7 +18,7 @@
 EXPORT_SYMBOL(amiga_hw_present);
 EXPORT_SYMBOL(amiga_eclock);
 EXPORT_SYMBOL(amiga_colorclock);
-EXPORT_SYMBOL(amiga_chip_alloc);
+EXPORT_SYMBOL(__amiga_chip_alloc);
 EXPORT_SYMBOL(amiga_chip_free);
 EXPORT_SYMBOL(amiga_chip_avail);
 EXPORT_SYMBOL(amiga_chip_size);
--- geert-chipram-2.4.0-test8/arch/m68k/amiga/config.c.orig	Mon Jul 17 15:13:27 2000
+++ geert-chipram-2.4.0-test8/arch/m68k/amiga/config.c	Mon Sep 18 17:16:22 2000
@@ -828,9 +828,12 @@
     }
 }
 
+static struct resource debug_res = { "Debug" };
+
 static void amiga_savekmsg_init(void)
 {
-    savekmsg = (struct savekmsg *)amiga_chip_alloc(SAVEKMSG_MAXMEM, "Debug");
+    savekmsg = (struct savekmsg *)__amiga_chip_alloc(SAVEKMSG_MAXMEM, NULL,
+						     &debug_res);
     savekmsg->magic1 = SAVEKMSG_MAGIC1;
     savekmsg->magic2 = SAVEKMSG_MAGIC2;
     savekmsg->magicptr = virt_to_phys(savekmsg);

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: PowerPC SCSI driver

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

On Sun, 17 Sep 2000, F. Heitkamp wrote:
> On Sun, Sep 17, 2000 at 08:01:03PM +0200, Geert Uytterhoeven wrote:
> > On Sun, 17 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> > > "F. Heitkamp" schrieb:
> > > > CACHE TEST FAILED: host wrote 5, ncr read 0.
> > > > CACHE TEST FAILED: ncr wrote 7, host read 5.
> > > > CACHE INCORRECTLY CONFIGURED.
> > > 
> > > This looks like the CPU only writes to and reads from cache. Maybe you should
> > > map the memory as uncacheable?
> > 
> > Or you wrote to a different place than the NCR expects, so the result in
> > memory wasn't modified.
> 
> It is beyond me how the structure is aligned in memory.
> I wish I could draw a nice picture of where things should
> be but I don't know enough about the memory layout of 
> the Amiga or Linux.
> 
> Yes.  It apears that the scratcha register which had a 
> non zero value in it, had a zero written to it, however
> the value the was in the ncr_cache variable was unchanged.
> So the script did not access the proper location.  Here is
> the script section:

Is it possible cpu_to_scr(), scr_to_cpu(), ncr_offb() and ncr_offw() are
wrong?

Perhaps it would help if you could find a script created by the AmigaOS
driver?

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: Mac-On-Linux

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

hi,

> Either do cvs stat -v <some file> or use the SourceForge CVSweb interface.

okay
 
> Nope, printk's only work when the initial console is set up (after head.S).

..thought so. head.S problems == headache  :-)
 
> APUS_PROGRESS writes an integer to memory which survives the reset, so you can
> read it back with a memory viewer in AmigaOS.

I take it that its obvious how to use/call APUS_PROGRESS then ;-)

alan

Re: Mac-On-Linux

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

Alan Buxey wrote:

> if i create a branch, that keeps it seperate, right?

Right.

> otherwise have to specifically ask for that branch?

Yep, others have to update to the branch with cvs upd -r <branch tag>

> If so, how do you find out what branches are available in the tree?

Either do cvs stat -v <some file> or use the SourceForge CVSweb interface.


> PS how would I go about doing PROGRESS debugging here....its in head.S,
> can I printk stuff?

Nope, printk's only work when the initial console is set up (after head.S).

APUS_PROGRESS writes an integer to memory which survives the reset, so you can
read it back with a memory viewer in AmigaOS.


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: Mac-On-Linux

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

hi,

> Let's make a MOL branch then. cvs tag -b mol-branch or something.

sorry, I dont know too much about cvs yet (i'm happy enough checking out
stuff, but not much more right now) so I'll have to get up to speed on
this. if i create a branch, that keeps it seperate, right? otherwise have
to specifically ask for that branch? If so, how do you find out what
branches are available in the tree?

 > > Time for some APUS_PROGRESS and dmesg debugging? :) > > 

I'll do some debug=mem tonight. i dont think it even gets that far, as i
said, the machine just resets (and boots back to AmigaOS) it doesnt hang

alan

PS how would I go about doing PROGRESS debugging here....its in head.S,
can I printk stuff?

Re: Mac-On-Linux

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

Alan Buxey wrote:

> well, an interesting Sunday...I've changed all of the kernel files that
> required changes for MOL. Anyhow, the arch/ppc/kernel/head.S required
> around 9 more changes to bring it in line with the official MOL patches.
> 
> the kernel compiles, but I just get a reset when I try booting into it.
> frustrating! So, cant CVS submit it yet! ;-)

Let's make a MOL branch then. cvs tag -b mol-branch or something.


Time for some APUS_PROGRESS and dmesg debugging? :)


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

Mac-On-Linux

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

hi,

well, an interesting Sunday...I've changed all of the kernel files that
required changes for MOL. Anyhow, the arch/ppc/kernel/head.S required
around 9 more changes to bring it in line with the official MOL patches.

the kernel compiles, but I just get a reset when I try booting into it.
frustrating! So, cant CVS submit it yet! ;-)

So, since I'm a little bit of a newbie at all this, I've put the head.S
file at the following location

http://ftfir.mols.sussex.ac.uk/linuxppc

If you download this (or take an online look at it) search for "MOL"
within the file. You'll find the MOL changes in around 10 places.
I cant see where it is failing. I'm *guessing* its the part which says

/*
 * Mac-On-Linux hook_table. Don`t put these in the data section -
 * it must be present in the first 16k of physical memory.
 */
#ifdef CONFIG_MOL
        .globl mol_interface
mol_interface:  
        .long   0x1     /* MOL interface version */
        .fill   16,4,0  /* space for 16 hooks    */
#endif

now, since on APUS we have lots of reserved memory blocks and
non-cachables, cachables, hacks, patches, ChipRAM, FastRAM, Z2_RAM etc I
think this part screws up. certainly I cant easily see why any of the
other parts would...your mileage may vary, I guess a couple of you will
see some part that will cause you to run kicking and screaming from the
VDU at what its trying to do in certain places  8-)

any help will be appreciated, I believe we're 95% to getting MOL on APUS.

PS great news on the Symbios 770 driver for the CSPPC, thats a lot of
progress made with that one now!!

Soon we'll be able to look at the USB issue on Linux, oh wait...we dont
have to! ;-)

alan

Re: Not sure sure if I should commit

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

On Mon, 18 Sep 2000, Michel [iso-8859-1] Dänzer wrote:

> Oh, I thought this was when you tried to commit. I think this is just a hint,
> CVS remember that there was a conflict, but you have dealt with it and so the
> commit should work fine. Otherwise, it will abort anyway :)

What I've done now is move my 2.2 out of the way and got a 'new' 2.2 (and
2.3) and diffed my old 2.2 against the fresh 2.2.  The only code changes
are mine but there are about 3000 lines of diffs in the CVS directories.
I don't know if this because I'm starting out again or if my old tree has
been corrupted.

I'll hold off on the commit and look into Geert's suggestion about the 2.4
way.

Ken.

Re: Not sure sure if I should commit

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

Ken Tyler wrote:
> 
> On Sun, 17 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> 
> > > File: ppc_ksyms.c       Status: File had conflicts on merge
> 
> > Look at the file. If there's a conflict, there is at least one line that
> > consists only of a lot of '<', then some lines of code, then a line with
> > only '=', some code again and finally a line with only '>'. CVS couldn't
> > merge the two code bits on its own. Do it manually and you should be able
> > to commit.
> 
> That's what i got the first time as i didn't have the MOL changes in
> ppc_ksyms and got the conflict <<<===>>> markers. Moved my changes out of
> the way, did update -D now (thank you) to get the MOL changes, put my
> changes back in ppc_ksyms.
> 
> If I do cvs diff everthing looks OK, shows my changes, no conflict markers
> but cvs status still says 'File had conflicts on merge'.

Oh, I thought this was when you tried to commit. I think this is just a hint,
CVS remember that there was a conflict, but you have dealt with it and so the
commit should work fine. Otherwise, it will abort anyway :)


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: test 8 does not boot.

[Frank P. <fp...@zu...>]

On Fri, Sep 15, 2000 at 06:40:21PM +0200, Roman Zippel wrote:
> Hi,
> 
> > After the cvs update yesterday, a freshly compiles -test8 kernel did
> > not boot. test7 boots (same config).
> 
> dmesg output?

Of course not. But I have to correct myself, it boots if MOL is disabled.
But then some SCSI driver (gvp11, I suppose) reports something >57000 scsi
CD-ROMS (I have none), when its module is loaded. I reset the machine after
some minutes of scrolling messages.

> That patch was more a compile fix. For most of the stuff I can only test
> if it compiles, but I can't test if it really works.

I see. I did not test it, as I did not get -test8 to come up to a login shell.
-- 
Frank Petzold, IBM Zurich Research Laboratory, Säumerstrasse 4,
CH-8803 Rüschlikon/Switzerland, Tel.  +41-1-724-84-42  Fax.   +41-1-724-89-56
 Business email: fp...@zu...          Private email: pe...@he...
   The opinions expressed here are mine and not necessarily those of IBM.

Re: Not sure sure if I should commit

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

On Sun, 17 Sep 2000, Michel [iso-8859-1] Dänzer wrote:

> > File: ppc_ksyms.c       Status: File had conflicts on merge

> Look at the file. If there's a conflict, there is at least one line that
> consists only of a lot of '<', then some lines of code, then a line with only
> '=', some code again and finally a line with only '>'. CVS couldn't merge the
> two code bits on its own. Do it manually and you should be able to commit.

That's what i got the first time as i didn't have the MOL changes in
ppc_ksyms and got the conflict <<<===>>> markers. Moved my changes out of
the way, did update -D now (thank you) to get the MOL changes, put my
changes back in ppc_ksyms.

If I do cvs diff everthing looks OK, shows my changes, no conflict markers
but cvs status still says 'File had conflicts on merge'.

I'll do some more investigating but i'm fooled (which is not hard).

Ken.

Re: Not sure sure if I should commit

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

On Sun, 17 Sep 2000, Geert Uytterhoeven wrote:

> Wouldn't it be better to implement it the same way as in 2.4.x? Iain Sandoe is
> working on sharing the dmasound drivers between 2.2.x and 2.4.x.

I don't know, what are the 'rules' ?

I can't see the point, a lot looks like it changed in dmasound, this works
(if I could work out the cvs thing).

I'll have a look, if its easy yes, if not no.

Ken.

Re: PowerPC SCSI driver

[F. H. <fh...@at...>]

On Sun, Sep 17, 2000 at 08:01:03PM +0200, Geert Uytterhoeven wrote:
> On Sun, 17 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> > "F. Heitkamp" schrieb:
> > > CACHE TEST FAILED: host wrote 5, ncr read 0.
> > > CACHE TEST FAILED: ncr wrote 7, host read 5.
> > > CACHE INCORRECTLY CONFIGURED.
> > 
> > This looks like the CPU only writes to and reads from cache. Maybe you should
> > map the memory as uncacheable?
> 
> Or you wrote to a different place than the NCR expects, so the result in
> memory wasn't modified.

It is beyond me how the structure is aligned in memory.
I wish I could draw a nice picture of where things should
be but I don't know enough about the memory layout of 
the Amiga or Linux.

Yes.  It apears that the scratcha register which had a 
non zero value in it, had a zero written to it, however
the value the was in the ncr_cache variable was unchanged.
So the script did not access the proper location.  Here is
the script section:

3679 }/*-------------------------< SNOOPTEST >-------------------*/,{
   3680     /*
   3681     **  Read the variable.
   3682     */
   3683     SCR_COPY (4),
   3684         NADDR(ncr_cache),
   3685         RADDR (scratcha),
   3686     /*
   3687     **  Write the variable.
   3688     */
   3689     SCR_COPY (4),
   3690         RADDR (temp),
   3691         NADDR(ncr_cache),
   3692     /*
   3693     **  Read back the variable.
   3694     */
   3695     SCR_COPY (4),
   3696         NADDR(ncr_cache),
   3697         RADDR (temp),
   3698 }/*-------------------------< SNOOPEND >-------------------*/,{

> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geertOlinux-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
> 

-- 
Fred

Re: PowerPC SCSI driver

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

On Sun, 17 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> "F. Heitkamp" schrieb:
> > CACHE TEST FAILED: host wrote 5, ncr read 0.
> > CACHE TEST FAILED: ncr wrote 7, host read 5.
> > CACHE INCORRECTLY CONFIGURED.
> 
> This looks like the CPU only writes to and reads from cache. Maybe you should
> map the memory as uncacheable?

Or you wrote to a different place than the NCR expects, so the result in
memory wasn't modified.

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: PowerPC SCSI driver

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

"F. Heitkamp" schrieb:

> CACHE TEST FAILED: host wrote 5, ncr read 0.
> CACHE TEST FAILED: ncr wrote 7, host read 5.
> CACHE INCORRECTLY CONFIGURED.

This looks like the CPU only writes to and reads from cache. Maybe you should
map the memory as uncacheable?


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

PowerPC SCSI driver

[F. H. <fh...@at...>]

This is what I get with the latest hacking on the 
PUP SCSI.  This is forcing the driver into MMIO
mode.  It fails two of the three cache tests. I need
to figure out why.  BTW I used 5 and 7 as the swapper
values because I thought the 1 and 2 might give a
misleading  result.  They didn't...

BTW  Richard Hirst (spelling?) has modified the 
sym53c8xx driver to work with a 53c720 chip on
some HP hardware.  I know the 53c720 chips is a 
very close relative or predecessor to the 53c770
chip.  The only thing is is that the interface to
the driver is through a special 'zalon' chip.

I may try applying his patch and see if I can get
that driver to do anything.  Nothing like parallel
development on two drivers that don't work. :)

Trying to detect PuP SCSI...
ncr53c8xx: 53c770 detected 
ncr53c770-0: rev=0x00, base=0xf40000, io_port=0x0, irq=12
new NCB[2932] @c02f2000.
Storing input
new SCRIPT[3772] @c3f33000.
new SCRIPTH[3708] @c3f32000.
np: ID: 770 REV: 0 FEA: 15382 CLCK: 5 OF: 10
Initialize timer
paddr: f40000 paddr2: 0
io_port: 0
Peparing...
stuff: 10 5 192 32 1
set verbose:
myaddr: 0
myaddr: 7
myaddr: 7
ncr53c770-0: ID 7, Fast-20, Parity Checking
verbose:5
ncr53c770-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/c0/20/00/00/04
ncr53c770-0: final   SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/82/20/00/08/24
no on-board ram
scripth: c3f32000 p_scripth: bf32000 script: c3f33000 p_script: bf33000
Resetting for snoop test
offset: c
istat: 0
SCSI reset
istat: 40
cleared
istat: 0
test: aabbff11 aabbff11
offset: c
virt_to_phys(np): 82f2000
np: c02f2000
ncr_cache: 00000000 pc: 0bf32e50
np->ncr_cache: 00000005
nc_dsp: 0bf32e5c
offset: 00000014
offset: 00000014
CACHE TEST FAILED: host wrote 5, ncr read 0.
CACHE TEST FAILED: ncr wrote 7, host read 5.
CACHE INCORRECTLY CONFIGURED.
ncr53c770-0: detaching...
-- 
Fred

[vmc@vmc.de: Re: Hypercom4+ technical information wanted.]

[F. H. <fh...@at...>]

----- Forwarded message from Harald Frank <vm...@vm...> -----

I got this message from the VMC people, makers of the
Hypercom cards.  I have a hypercom4+ that I'm trying to
get working with APUS.  I asked the VMC people to give
me some technical information on the card and they 
responded after a fairly long time.  However it seems
it was definitely worth the wait.  You can check out 
the web page yourselves.

Fred

From: Harald Frank <vm...@vm...>
Reply-To: vm...@vm...
To: "F. Heitkamp" <fh...@at...>
Date: Sun, 17 Sep 2000 07:21:53 +0200
In-Reply-To: <395...@at...>
X-Mailer: YAM 2.1 [020] AmigaOS E-Mail Client (c) 1995-2000 by Marcel Beck  http://www.yam.ch
Organization: VMC Harald Frank
Subject: Re: Hypercom4+ technical information wanted.
X-Sender: 340...@t-...

Hello Fred.

On 23-Jun-00, you wrote:

> Hi,
> 
> Do you have technical information on the Hypercom4+ so that a Linux
> driver can be written? Thank you.
> 
> Fred Heitkamp
> 

sorry for the very long delay.. but i are extrem busy these days here..

Because of you request, i finished now my first version of the online
tehcnical library about vmc products..

Please check the technican lib on http://www.vmc.de and tell me if you
miss some important information there...

Would be great if you can add drivers for all cards that i list on my
technical lib..

Hope to hear from you soon...

Best regards

VMC Harald Frank


----- End forwarded message -----

-- 
Fred

Re: Not sure sure if I should commit

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

On Sun, 17 Sep 2000, Ken Tyler wrote:
> I was about to commit the heartbeat/soundfilter patch when I noticed this
> from a cvs ... status command :
> 
> File: ppc_ksyms.c       Status: File had conflicts on merge
> 
>    Working revision:    1.3
>    Repository revision: 1.3  /cvsroot/linux-apus/2.2/arch/ppc/kernel/ppc_ksyms.c,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
> 
> This error/warning doesn't rate a mention in my book

Search for `^<<<' (`^' is start of line) in ppc_ksyms.c.

> All I'm trying to do is add 4 lines to ppc_ksyms.c :
> 
> diff -u -u -r1.3 ppc_ksyms.c
> --- arch/ppc/kernel/ppc_ksyms.c 2000/09/12 12:15:19     1.3
> +++ arch/ppc/kernel/ppc_ksyms.c 2000/09/16 11:32:35
> @@ -231,6 +231,11 @@
>  EXPORT_SYMBOL(memory);
>  #endif /* CONFIG_APUS */
> 
> +#ifdef CONFIG_HEARTBEAT
> +EXPORT_SYMBOL(enable_heartbeat);
> +EXPORT_SYMBOL(disable_heartbeat);
> +#endif
> +
>  #ifdef CONFIG_MOL
>  #include <asm/mmu_context.h>
>  extern PTE *Hash;
> 
> Is it safe to commit or what's wrong ?

Wouldn't it be better to implement it the same way as in 2.4.x? Iain Sandoe is
working on sharing the dmasound drivers between 2.2.x and 2.4.x.

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: Need SGML expert :-)

[Roman Z. <zi...@fh...>]

Hi,

On 17 Sep 2000, Jesper Skov wrote:

> As for SGML/DocBook info, you are aware of http://www.docbook.org/,
> right? And http://sgmltools-lite.sourceforge.net/

I tried that first to get the kernel docs, but in the end I gave up and
simply installed the packages from RH6.2.

bye, Roman

Re: Not sure sure if I should commit

[Roman Z. <zi...@fh...>]

Hi,

> This error/warning doesn't rate a mention in my book

info -f cvs
(Multiple developers -> File status)

After you resolved all conflicts you can rerun cvs update and the state
should change to "Locally Modified".

bye, Roman