linuxdc-dev

[linuxdc-dev] hello

[Erik A. <and...@co...>]

Hi, I'm new to the list.  I spent some time this morning porting
the linux-sh and linux-sh-dc kernel trees up to
linux-2.4.20-pre10.  The ports were not especially difficult and
the only place that required any violence was the sh watchdog
driver, which had some conflicts vs the kernel version.  I've
given it a quick try (replacing boot/vmlinux in
dreamcast-linux-010605 and burning a CD), but when ecos tries to
load it, it gives me: 
    RedBoot> load -v /boot/vmlinux
    load_elf_image_aborted: seek: attempt to seek backwards" 
Suggestions on how to track down why ecos refuses to load the
kernel image?

I used the sh toolchain from 
    ftp://ftp.m17n.org/pub/dodes/debian/
but I don't have a lot of confidence in gcc 3.0.3 -- I've had
some bad luck with gcc 3.0 in general, so it may very well be the
toolchain.  dunno.  What is the recommended toolchain for
Dreamcast/SH4 kernel hacking?  gcc 3.2 / binutils 2.12.1? 

For the curious (or the helpful), my patches for 2.4.20-pre10
can be found here:
    http://codepoet.org/dreamcast/

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: [linuxdc-dev] hello

[M. R. B. <mr...@0x...>]

* Erik Andersen <and...@co...> on Sat, Oct 19, 2002:

> Hi, I'm new to the list.  I spent some time this morning porting
> the linux-sh and linux-sh-dc kernel trees up to
> linux-2.4.20-pre10.  The ports were not especially difficult and
> the only place that required any violence was the sh watchdog
> driver, which had some conflicts vs the kernel version.

Note the mainline version of the watchdog is more up-to-date than the
linuxsh one, iirc.

> 
> I used the sh toolchain from 
>     ftp://ftp.m17n.org/pub/dodes/debian/
> but I don't have a lot of confidence in gcc 3.0.3 -- I've had
> some bad luck with gcc 3.0 in general, so it may very well be the
> toolchain.  dunno.  What is the recommended toolchain for
> Dreamcast/SH4 kernel hacking?  gcc 3.2 / binutils 2.12.1? 
> 

I recommend stable as being GCC 3.0.4 and binutils 2.13 w/ patches.  The
patches can be found at ftp://ftp.m17n.org/pub/linux-sh/testing/.  Look for
the highest patch revision (0 for GCC 3.0.4 and 6 for binutils 2.11.2).
The binutils 2.11.2 patch should apply cleanly to 2.13.

I have built a GCC 3.2 toolchain (based on uClibc even :P) but I haven't
had a chance to test it yet.  I've attached the patch for 3.2 (Karl, do you
remember the original location of Kaz' 3.1/3.2 patch?).  It should also
apply cleanly to stock 3.2.

> For the curious (or the helpful), my patches for 2.4.20-pre10
> can be found here:
>     http://codepoet.org/dreamcast/
> 

Thanks!  I'll grab your patches and integrate them into both the linuxsh
and linuxdc trees.  I've been busy scrambling to get the bitrotten linuxsh
tree up to snuff for 2.5 before the freeze, so I'll probably switch our
experimental linux-sh-dc tree over to 2.5 RSN.

M. R.

Re: [linuxdc-dev] hello

[Karl T. K. <ka...@pr...>]

On Sat, 19 Oct 2002 07:15:54 -0500
"M. R. Brown" <mr...@0x...> wrote:

> * Erik Andersen <and...@co...> on Sat, Oct 19, 2002:
> 
> I have built a GCC 3.2 toolchain (based on uClibc even :P) but I haven't
> had a chance to test it yet.  I've attached the patch for 3.2 (Karl, do
> you remember the original location of Kaz' 3.1/3.2 patch?).  It should
> also apply cleanly to stock 3.2.

I mirrored it at least:
http://www.boblycat.org/~karltk/gcc-3.1-branch-tmp.diff.gz

It does apply cleanly to 3.2 as well. However, I ran into the problem of
missing the symbol __fpscr_values, which I believe is supposed to go into
libgcc(_s).a

If memory serves, Kaz mentioned somewhere that the above patch still has
some issues, but whether it was with FPU mode switching or with
multithreaded apps, I cannot recall.

(I think it would be the latter, as even if we put the __fpscr_values into
libgcc.a/libgcc_s.a, we need to take care of each thread having its own
storage area for 

This was with uClibc-0.9.14, gcc-3.2, binutils-2.13 and the above patch.

AFAICT, it only affects programs for which the compiler actually emits FPU
code. 


Kind regards,

Karl T

Re: [linuxdc-dev] hello

[Erik A. <and...@co...>]

On Sat Oct 19, 2002 at 07:15:54AM -0500, M. R. Brown wrote:
> > For the curious (or the helpful), my patches for 2.4.20-pre10
> > can be found here:
> >     http://codepoet.org/dreamcast/
> >=20
>=20
> Thanks!  I'll grab your patches and integrate them into both the linuxsh
> and linuxdc trees.  I've been busy scrambling to get the bitrotten linuxsh
> tree up to snuff for 2.5 before the freeze, so I'll probably switch our
> experimental linux-sh-dc tree over to 2.5 RSN.

Looks like I forgot a small piece...  001-linux-sh_2.4.20-pre10=20
also needs the following, which I forgot to include in my patch
(I have now updated the patch on my webpage).

--- linux-2.4.19.orig/include/asm-sh/page.h	2001-09-08 13:29:09.000000000 -=
0600
+++ linux/include/asm-sh/page.h	2002-10-19 04:19:45.000000000 -0600
@@ -118,6 +118,9 @@
=20
 #endif
=20
-#endif /* __KERNEL__ */
+#define VM_DATA_DEFAULT_FLAGS	(VM_READ | VM_WRITE | VM_EXEC | \
+				 VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+
=20
+#endif /* __KERNEL__ */
 #endif /* __ASM_SH_PAGE_H */

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: [linuxdc-dev] hello

[Erik A. <and...@co...>]

On Sat Oct 19, 2002 at 09:32:07AM -0600, Erik wrote:
> Looks like I forgot a small piece...  001-linux-sh_2.4.20-pre10=20
> also needs the following, which I forgot to include in my patch
> (I have now updated the patch on my webpage).

And yet another missing piece...  Turns out the BBA is connected
via PCI, but I'd failed to adapt that part for the new kernel.
Here is yet another fix.

--- arch/sh/kernel/pcibios.c.orig	2002-10-19 03:37:25.000000000 -0600
+++ arch/sh/kernel/pcibios.c	2002-10-21 19:11:13.000000000 -0600
@@ -73,7 +73,7 @@
 	}
 }
=20
-int pcibios_enable_device(struct pci_dev *dev)
+int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
 	u16 cmd, old_cmd;
 	int idx;
@@ -82,6 +82,9 @@
 	pci_read_config_word(dev, PCI_COMMAND, &cmd);
 	old_cmd =3D cmd;
 	for(idx=3D0; idx<6; idx++) {
+		/* Only set up the requested stuff */
+		if (!(mask & (1<<idx)))
+			continue;
 		r =3D &dev->resource[idx];
 		if (!r->start && r->end) {
 			printk(KERN_ERR "PCI: Device %s not available because of resource colli=
sions\n", dev->slot_name);

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--