On Fri, Oct 17, 2003 at 11:48:51AM +0200, Benjamin Herrenschmidt wrote:
> New patch, let me know how it works:
It says,
Starting at 50
DEFAULT CATCH!, code=FFF00700 at %SAR0: 0250 %SRR1: 00083070
--
Debian GNU/Linux Operating System
By the People, For the People
Chris Tillman (a pe
New patch, let me know how it works:
diff -urN quik-2.0e/first/first.S quik-2.0e-hacked/first/first.S
--- quik-2.0e/first/first.S 2003-10-15 22:03:56.056511120 +0200
+++ quik-2.0e-hacked/first/first.S 2003-10-15 21:49:39.0 +0200
@@ -56,7 +56,7 @@
sync
isync
-/* U
On Thu, Oct 16, 2003 at 11:21:07PM +0200, Mich Lanners wrote:
> On 16 Oct, this message from Chris Tillman echoed through cyberspace:
> >> Chris, since you're rebuilding quik :-), maybe you can give this a
> >> try as well?
> >
> > I can; I need to hook up a SCSI disk to really test it? Does the
On 16 Oct, this message from Chris Tillman echoed through cyberspace:
>> Chris, since you're rebuilding quik :-), maybe you can give this a
>> try as well?
>
> I can; I need to hook up a SCSI disk to really test it? Does the root
> partition/kernel have to be on the SCSI?
Well, I asked myself th
On Thu, Oct 16, 2003 at 09:13:03PM +0200, Mich Lanners wrote:
> On 14 Oct, this message from Sven Luther echoed through cyberspace:
> >> Incidentaly, there's a bug in second/file.c, in load_file(), where a
> >> device path is predefined as '/dev/sdaX', 'X' being replaced later
> >> with partno+'0'
On 14 Oct, this message from Sven Luther echoed through cyberspace:
>> Incidentaly, there's a bug in second/file.c, in load_file(), where a
>> device path is predefined as '/dev/sdaX', 'X' being replaced later
>> with partno+'0', thus limiting working partition numbers to 1-9, and
>> overwriting t
On Thu, 2003-10-16 at 06:04, Chris Tillman wrote:
> Thanks Ben!!
>
> There is a printk in prom.c which wouldn't compile; I changed it to
> printf and it did make with some warnings, which I think were there
> before:
>
> 'return makes pointer from integer without a cast'
> in chrootcpy, find_dev
Thanks Ben!!
There is a printk in prom.c which wouldn't compile; I changed it to
printf and it did make with some warnings, which I think were there
before:
'return makes pointer from integer without a cast'
in chrootcpy, find_dev, and resolve_to_dev (twice)
I installed the patched quik and jus
> OK, but what are the options for 2.6 kernels? Is it possible to compile
> kernels small enough?
Maybe... :)
> >
> > - Update the BAT mapping code to map 16Mb instead of just 8
> > - Use an OF map() call to create a 1:1 mapping in the OF own
> >tables (not that the MAP may be useless tha
On 14 Oct, this message from Benjamin Herrenschmidt echoed through
cyberspace:
>> Recently it was discussed here whether quik has a limit on kernel
>> size.
>>
>> Well, while playing with 2.6 kernels I found out: yes, quik _does_
>> have a limit on kernel size. It is exactly 3981312 bytes. In fac
On Mon, Oct 13, 2003 at 10:34:51PM +0200, Mich Lanners wrote:
> Hi all,
>
> Recently it was discussed here whether quik has a limit on kernel size.
>
> Well, while playing with 2.6 kernels I found out: yes, quik _does_ have
> a limit on kernel size. It is exactly 3981312 bytes. In fact, quik
Yep
On Mon, 2003-10-13 at 22:34, Mich Lanners wrote:
> Hi all,
>
> Recently it was discussed here whether quik has a limit on kernel size.
>
> Well, while playing with 2.6 kernels I found out: yes, quik _does_ have
> a limit on kernel size. It is exactly 3981312 bytes. In fact, quik
> allocates a fix
12 matches
Mail list logo
