Menu
▾
▴
linux-apus-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(210) |
Jun
(169) |
Jul
(167) |
Aug
(128) |
Sep
(218) |
Oct
(120) |
Nov
(86) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(91) |
Feb
(179) |
Mar
(52) |
Apr
(56) |
May
(183) |
Jun
(62) |
Jul
(63) |
Aug
(49) |
Sep
(36) |
Oct
(35) |
Nov
(72) |
Dec
(30) |
| 2002 |
Jan
(53) |
Feb
(61) |
Mar
(56) |
Apr
(13) |
May
(1) |
Jun
(7) |
Jul
(80) |
Aug
(73) |
Sep
(30) |
Oct
(29) |
Nov
(8) |
Dec
(40) |
| 2003 |
Jan
(10) |
Feb
(2) |
Mar
(4) |
Apr
(9) |
May
(3) |
Jun
(19) |
Jul
(64) |
Aug
(53) |
Sep
(28) |
Oct
(7) |
Nov
(3) |
Dec
(21) |
| 2004 |
Jan
(11) |
Feb
(30) |
Mar
(18) |
Apr
(1) |
May
(13) |
Jun
(18) |
Jul
(13) |
Aug
|
Sep
(9) |
Oct
(5) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
(21) |
Sep
(7) |
Oct
(10) |
Nov
(6) |
Dec
|
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(6) |
Oct
(10) |
Nov
(8) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(6) |
Mar
(1) |
Apr
(6) |
May
(10) |
Jun
(7) |
Jul
(13) |
Aug
(8) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Sven L. <lu...@dp...> - 2001-05-17 10:38:29
|
On Wed, May 16, 2001 at 11:04:51AM +0100, Alan Buxey wrote: > hi, > > > Well, we could split the kernel in 2 and join it in ram: before launching it. > > Or we could try for a less than 880Ko modular kernel, but i have not big hopes > > on this one. Michel Daenzer is the apus kernel package maintainer for debian. > > a small, but brief note: > > > IS there not a very very big problem with having the kernel in ram: when > launching? Non, i used to do it before, when there was the interrupt issue with the internal hardrive or the scsi one, don't remember. At that time you had to copy the stuff to ram:, wait for a bit that no more disk interrupts were pending, and then launch the stuff. Unless it changed since then, that is. > joining two files up into ram: is no problem (6 lines of code max.) but > doesnt ram: just get completely trashed when the bootstrap loads up the > kernel (and thus corrupting the kernel image?) Yes, but at that time, bootstrap will already have copied the kernel code to it's rigthfull place, so no problem. > i thought this was the case and people have to have the installer and > kernel on media, rather than in volatile ram: ram: in this case is just another media. > > 3) coordinate with alan for the floppy disk booting thingy. > > working on disk-layout, tools and required libraries now. :))) Friendly, sven Luther |
|
From: Alan B. <al...@ms...> - 2001-05-17 10:37:44
|
hi, > Yep, you can remove OCS/ECS support, but it'll save only a few bytes, I guess. dont A3k PowerUP owners have to have ECS - if they dont have GFX card? (are there any such people?) alan |
|
From: Sven L. <lu...@dp...> - 2001-05-17 10:35:00
|
On Wed, May 16, 2001 at 09:28:01PM +0200, Geert Uytterhoeven wrote: > On Wed, 16 May 2001, Michel D=E4nzer wrote: > > Sven LUTHER wrote: > > > > I am trying to understand why... > > > > For an 880k floppy the space problem makes impossible to do it. > > > > But i wish to be contraddicted... :)) > > >=20 > > > Well, we could split the kernel in 2 and join it in ram: before lau= nching > > > it. Or we could try for a less than 880Ko modular kernel, but i hav= e not big > > > hopes on this one. > >=20 > > I am experimenting, and it looks promising. I basically moved everyth= ing > > except video and disk drivers to modules and here's what it gives so = far: > >=20 > > michdaen@pismo> gzip -cv9 vmlinux > vmapus.gz ~/src/apu= s-cvs/2.4 > > vmlinux: 60.1% > > michdaen@pismo> ll vmapus.gz ~/src/apu= s-cvs/2.4 > > -rw-r--r-- 1 michdaen src 888321 May 16 19:49 vmapus.gz > > michdaen@pismo> du -k vmapus.gz ~/src/apu= s-cvs/2.4 > > 868 vmapus.gz > >=20 > > Is this small enough? I guess I could squeeze out a few more K... >=20 > Probably not yet. >=20 > > Do we need support for foreign partition maps? >=20 > Not for installation. >=20 > > Do the fbcon packed pixels modules work? >=20 > Yes, but only for modular drivers. >=20 > I'd say include fbcon-afb (amifb), fbcon-cfb8 (gfx cards) and fbcon-cfb= 16 > (gfx cards with amiboot -v). >=20 > You don't need fbcon-ilbm since amifb doesn't need it unless you use > video=3Damifb:ilbm. >=20 > You don't need fbcon-mfb since amifb will fallback to fbcon-afb/fbcon-i= lbm for > depth 1 when fbcon-mfb is not available. >=20 > You don't need fbcon-cfb24 and fbcon-cf32 since no one wants to run an = install > console in those depths anyway. I don't think you need it for half-supp= orted > gfx cards with amiboot -v, only depth 16. Also do you have pm2fb and co in there ? maybe this 880 ko kernels would = be only for aga, this way we have only 1 possible video=3D mode in the amibo= ot script. Other modes can be choosen later on. Friendly, Sven Luther |
|
From: Sven L. <lu...@dp...> - 2001-05-17 10:33:01
|
On Wed, May 16, 2001 at 07:58:06PM +0200, Michel D=E4nzer wrote: > Sven LUTHER wrote: >=20 > > > I am trying to understand why... > > > For an 880k floppy the space problem makes impossible to do it. > > > But i wish to be contraddicted... :)) > >=20 > > Well, we could split the kernel in 2 and join it in ram: before launc= hing > > it. Or we could try for a less than 880Ko modular kernel, but i have = not big > > hopes on this one. >=20 > I am experimenting, and it looks promising. I basically moved everythin= g > except video and disk drivers to modules and here's what it gives so fa= r: >=20 > michdaen@pismo> gzip -cv9 vmlinux > vmapus.gz ~/src/apus-= cvs/2.4 > vmlinux: 60.1% > michdaen@pismo> ll vmapus.gz ~/src/apus-= cvs/2.4 > -rw-r--r-- 1 michdaen src 888321 May 16 19:49 vmapus.gz > michdaen@pismo> du -k vmapus.gz ~/src/apus-= cvs/2.4 > 868 vmapus.gz mmm, a bit just maybe, will it fit with amiboot and the script ? But, we definitively need 2 batches of kernels, since i suppose some guys would want the networking stuff also. They can use the non floppy version though. > Is this small enough? I guess I could squeeze out a few more K... >=20 > Do we need support for foreign partition maps? not really, they could be modules. > Do the fbcon packed pixels modules work? >=20 > Do we need Minix fs support yet? Not anymore, since now root images are ext2 fs, not minix, but i am not s= ure, please someone confirm this. > The other side of the story will probably be the space needed for the > modules... That's no problem, the infrastructure is there already for splitten modules.tgz file, they come in 3 floppies for i386. i guess the module re= ading and joining is size independent, we just would need to add the stuff to c= ut it in 880 or 720 Ko chunks (but i386 already support 1.44, 1.2 and 2.88 ones= , so the stuff is in there already). Friendly, Sven Luther |
|
From: Geert U. <ge...@li...> - 2001-05-17 10:18:52
|
On Thu, 17 May 2001, Alan Buxey wrote:
> > > Do we need Minix fs support yet?
> >
> > Not for installation.
>
> the ramdisk image no longer uses MiniFS? if so minifs could be dropped
> ages ago.
Hmm... I don't know. Someone should check this.
> I guess we also dont need OCS gfx support...as PowerPC cards only work on
> ECS and AGA systems.
Yep, you can remove OCS/ECS support, but it'll save only a few bytes, I guess.
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
|
|
From: Alan B. <al...@ms...> - 2001-05-17 10:02:48
|
hi, > > Do we need Minix fs support yet? > > Not for installation. the ramdisk image no longer uses MiniFS? if so minifs could be dropped ages ago. I guess we also dont need OCS gfx support...as PowerPC cards only work on ECS and AGA systems. On this line of thought...sound isnt essential, neither is parallel port?, joystick.. alan |
|
From: Geert U. <ge...@li...> - 2001-05-17 07:38:19
|
On Thu, 17 May 2001, Michel D=E4nzer wrote:
> Geert Uytterhoeven wrote:
> > You don't need fbcon-cfb24 and fbcon-cf32 since no one wants to run a=
n
> > install console in those depths anyway. I don't think you need it for
> > half-supported gfx cards with amiboot -v, only depth 16.
>=20
> Will this prevent X from running in those depths?
No, fbcon-* files are used for the console only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.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
|
|
From: Michel <mic...@ii...> - 2001-05-16 23:32:11
|
Geert Uytterhoeven wrote: > You don't need fbcon-cfb24 and fbcon-cf32 since no one wants to run an > install console in those depths anyway. I don't think you need it for > half-supported gfx cards with amiboot -v, only depth 16. Will this prevent X from running in those depths? Thanks for your feedback! michdaen@pismo> du -sk src/apus-cvs/2.4/vmapus.gz ~ 856 src/apus-cvs/2.4/vmapus.gz More suggestions welcome... -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Michel <mic...@ii...> - 2001-05-16 23:25:07
|
Ken Tyler wrote: > > On Wed, 16 May 2001, Michel Dänzer wrote: > > > But how do you imagine GNOME would cause these crashes? If anything > > from user space, I'd rather suspect the X server. > > I've tried several X servers, off CD, debian, I just compiled X 4.0.2 > which works (with the slow logout screen and no SHAPE), they all run. > But I still get the same crashes with all of them. The SHAPE extension is probably missing because Load "extmod" isn't in the Module Section, and the slow GNOME logout should be fixed as of 4.0.99.2 . > When it does crash my computer is locked up solid, no heartbeat and no > sysreq which shouldn't happen from user space either. > > The task is always X related. > > TASK = c0b24000[544] 'X' mm->pgd c0d17000 Last syscall: 146 > TASK =c1db2000[547] 'gnome-smproxy' mm->pgd c1e61000 Last syscall: 54 > TASK = c17c4000[576] 'gmc' mm->pgd c1a1c000 Last syscall: 13 I doubt the task is very informative other than the fact that you see both the X server and clients, which IMHO points to a kernel problem, be it compiler or code related. It's just the process in the time slice of which the panic happens. Does ksymoops give any useful information? -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Ken T. <ke...@we...> - 2001-05-16 20:40:25
|
On Wed, 16 May 2001, Michel D=E4nzer wrote: Hello, > Upgrading to a later 2.95 version (Debian has 2.95.4-pre) might be a good > idea. OK, will try that. > > Another two seen a few times are : > >=20 > > Page fault in interrupt handler > > Floating point in kernel >=20 > In particular this last one sounds like a potential compiler problem. The= re > should be no floating point code in the kernel. I've never seen anything similar not running X, don't rmemember my box stopping in the last 12 months when not running X, I would have thought something in that time would have triggered similar panics. =20 > But how do you imagine GNOME would cause these crashes? If anything > from user space, I'd rather suspect the X server. I've tried several X servers, off CD, debian, I just compiled X 4.0.2 which works (with the slow logout screen and no SHAPE), they all run. But I still get the same crashes with all of them. When it does crash my computer is locked up solid, no heartbeat and no sysreq which shouldn't happen from user space either. The task is always X related. TASK =3D c0b24000[544] 'X' mm->pgd c0d17000 Last syscall: 146 TASK =3Dc1db2000[547] 'gnome-smproxy' mm->pgd c1e61000 Last syscall: 54 TASK =3D c17c4000[576] 'gmc' mm->pgd c1a1c000 Last syscall: 13 Thanks, Ken. |
|
From: Geert U. <ge...@li...> - 2001-05-16 19:29:58
|
On Wed, 16 May 2001, Michel D=E4nzer wrote:
> Sven LUTHER wrote:
> > > I am trying to understand why...
> > > For an 880k floppy the space problem makes impossible to do it.
> > > But i wish to be contraddicted... :))
> >=20
> > Well, we could split the kernel in 2 and join it in ram: before launc=
hing
> > it. Or we could try for a less than 880Ko modular kernel, but i have =
not big
> > hopes on this one.
>=20
> I am experimenting, and it looks promising. I basically moved everythin=
g
> except video and disk drivers to modules and here's what it gives so fa=
r:
>=20
> michdaen@pismo> gzip -cv9 vmlinux > vmapus.gz ~/src/apus-=
cvs/2.4
> vmlinux: 60.1%
> michdaen@pismo> ll vmapus.gz ~/src/apus-=
cvs/2.4
> -rw-r--r-- 1 michdaen src 888321 May 16 19:49 vmapus.gz
> michdaen@pismo> du -k vmapus.gz ~/src/apus-=
cvs/2.4
> 868 vmapus.gz
>=20
> Is this small enough? I guess I could squeeze out a few more K...
Probably not yet.
> Do we need support for foreign partition maps?
Not for installation.
> Do the fbcon packed pixels modules work?
Yes, but only for modular drivers.
I'd say include fbcon-afb (amifb), fbcon-cfb8 (gfx cards) and fbcon-cfb16
(gfx cards with amiboot -v).
You don't need fbcon-ilbm since amifb doesn't need it unless you use
video=3Damifb:ilbm.
You don't need fbcon-mfb since amifb will fallback to fbcon-afb/fbcon-ilb=
m for
depth 1 when fbcon-mfb is not available.
You don't need fbcon-cfb24 and fbcon-cf32 since no one wants to run an in=
stall
console in those depths anyway. I don't think you need it for half-suppor=
ted
gfx cards with amiboot -v, only depth 16.
> Do we need Minix fs support yet?
Not for installation.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.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
|
|
From: Michel <mic...@ii...> - 2001-05-16 17:59:22
|
Sven LUTHER wrote: > > I am trying to understand why... > > For an 880k floppy the space problem makes impossible to do it. > > But i wish to be contraddicted... :)) > > Well, we could split the kernel in 2 and join it in ram: before launching > it. Or we could try for a less than 880Ko modular kernel, but i have not big > hopes on this one. I am experimenting, and it looks promising. I basically moved everything except video and disk drivers to modules and here's what it gives so far: michdaen@pismo> gzip -cv9 vmlinux > vmapus.gz ~/src/apus-cvs/2.4 vmlinux: 60.1% michdaen@pismo> ll vmapus.gz ~/src/apus-cvs/2.4 -rw-r--r-- 1 michdaen src 888321 May 16 19:49 vmapus.gz michdaen@pismo> du -k vmapus.gz ~/src/apus-cvs/2.4 868 vmapus.gz Is this small enough? I guess I could squeeze out a few more K... Do we need support for foreign partition maps? Do the fbcon packed pixels modules work? Do we need Minix fs support yet? The other side of the story will probably be the space needed for the modules... -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Duncan G. <DG...@Du...> - 2001-05-16 17:55:54
|
On 16-May-01, Giorgio Terzi wrote: >> Well, we could split the kernel in 2 and join it in ram: before >> launching it. Or we could try for a less than 880Ko modular kernel, but >> i have not big hopes on this one. Michel Daenzer is the apus kernel >> package maintainer for debian. GT> As rightly written by Geert Uytterhoeven is possible to join in GT> ram the kernel but as he also writes there maybe problems with GT> Amigas with a small RAM amount. Is this a relevant problem for APUS? How many users have PowerPC boards and less than the critical amount of RAM (8MB?)? Duncan -- ... "That's interesting," said Dougal, turning around in circles. |
|
From: Duncan G. <DG...@Du...> - 2001-05-16 17:45:21
|
On 16-May-01, Alan Buxey wrote: DG> I don't have a functioning APUS system at the moment. DG> Building one is on my (very) long list of things to do. AB> :-) okay, do you not use the 'noscsi' option on your CSPPC, AB> or do you have any extra hardware that you enable etc? The main problem is that my GVP SCSI card blew up (shows up in early startup, but as not working, and the machine won't boot with it in place). This means I've had to rewire all my SCSI devices to use the CSPPC onboard interface, where of course they are invisible under APUS. I do have an IDE hard drive I can install onto, and a LinuxPPC 2000Q4 set which LinuxPPC kindly sent me, but I no longer have an IDE CD-ROM. They one I did have kept locking up while duplicating discs with MakeCD, so I have replaced it with a SCSI one. I'll have to arse about installing from hard drive or over the network... I also have three x86 boxes to play with now, plus rather a lot of work in my day job ;-) And in three weeks my girlfriend is back in the country. She's planning to move in here, so I have to clear out a lot of the computer junk which makes the place so homely ;-) AB> - perhaps we (and other UK/Euro people?) can arrange to meet at AB> LinuxEpxo2001 @ Olympia London 4th-5th July (what day are you going?) I haven't decided yet, I don't think. I've told my boss that it's work-related, so I will be going, and I've registered (now that they've fixed their website). If you're going to organise (?) a piss up^W^Wmeeting, I can probably go whichever day suits the most other people. I can get to London in under an hour, so it makes no odds to me. Time for Star Trek... Duncan -- ... Visual Basic Chicken: USHighways!TheRoad.cross (aChicken) |
|
From: Giorgio T. <de...@ip...> - 2001-05-16 17:12:19
|
Hello Sven
...
> what program are you using on the floppy disk ? I suppose that if it is the
> same as the one you use normally, it would be dependent on warp-up. But i
> guess warp-up is not in rom, so did you put it on the floppy also ?
I am trying to use our classic kernel loader " `bootstrap` ".
> Did you try it with the standard powerup stuff ? Since you are booting from a
> floppy, this should be the standard setting, is it not ?
I shall test it...
> Could you provide us with some logs (bootstrap & dmesg) of the crashed launch
> ? Post it to the linux-apus list please. Also the script you use for
> launching could be usefull.
>> I am trying to understand why...
OK, i finish my tests and if i can't find solutions i will.
>> For an 880k floppy the space problem makes impossible to do it.
>> But i wish to be contraddicted... :))
>
> Well, we could split the kernel in 2 and join it in ram: before launching it.
> Or we could try for a less than 880Ko modular kernel, but i have not big
> hopes on this one. Michel Daenzer is the apus kernel package maintainer for
> debian.
As rightly written by Geert Uytterhoeven is possible to join in ram the kernel
but
as he also writes there maybe problems with Amigas with a small RAM amount.
> BTW,
>
> Upto now, you were able to bootstarp from the floppy disk set,
No... because as written on top this letter i am testing " `bootstrap` "
on floppy.
and able to
> install and configure the kernel & modules, isn't it. All this with the
> 2.2.10 kernel.
Yes, also using floppy-disks.
(btw did you solve the 2.2.19 requirement of install.sh ? did
> you try the little patch i sent to you yesterday or the day before ?
Right! , another thing i must put in the test's list.
> floppies useable. You could try the networked (trough ppp) install after
> that, but i guess this should be ok.
With ppp ? Nice...
But i was not able to find a ppp configuration mask in the
network section of dbootstrap program...
is it a new feature?
I haven't found the woody's base tarball, maybe is still early,
or maybe i have not found its right path,
but its path is so in ftp as in CD-ROM i think:
dists/woody/disks-powerpc/current/
is it right ?
Thank you again,
Regards
--
Giorgio Terzi
|
|
From: Giorgio T. <de...@ip...> - 2001-05-16 17:12:15
|
On 15-Mag-01, Alan Buxey wrote:
> hi,
>
> can people run this little utilty and give some feedback as to any errors
> it makes/gives? Its just the beginning of a small tool i knocked up this
> evening....
>
> I've started looking through bootstrap source..are there any other places
> that i can see options in? the docs I do have are so out of date...can
> anyone supply any/all of the missing flags this utility currently does not
> ask for?
>
>
> alan
>
> PS thanks Duncan for responding!
Nice!
Is a very good idea and works pretty.
Regards
--
Giorgio Terzi
|
|
From: Michel <mic...@ii...> - 2001-05-16 15:20:53
|
Ken Tyler wrote: >=20 > What's the recommended compiler for APUS ? I use gcc version 2.95.2. Upgrading to a later 2.95 version (Debian has 2.95.4-pre) might be a good idea. > Since I installed helix (Ximian) gnome about 12 months ago, X has been > unstable under 2.2.10 and 2.4.?. >=20 > It runs for a while, if I can get it to start without locking up my > computer that is, and will eventually crash, usually with some interrup= t > related panic : >=20 > Kernel panic: Exception in kernel pc c00a4fec signal 4 > Kernel panic: kernel access of bad area pc c0037330 lr c00373cc addres= s > F80B48 tsk X/555 >=20 > Another two seen a few times are : >=20 > Page fault in interrupt handler > Floating point in kernel In particular this last one sounds like a potential compiler problem. The= re should be no floating point code in the kernel. > The back trace usually shows the crash occured during interrupt handlin= g. >=20 > KDE used to be OK IIRC, running without X is rock solid. >=20 > I suppose all this suggests the problem is with gnome and not with > kernel/compiler combination. But how do you imagine GNOME would cause these crashes? If anything from = user space, I'd rather suspect the X server. --=20 Earthling Michel D=E4nzer (MrCooper) \ Debian GNU/Linux (powerpc) de= veloper CS student, Free Software enthusiast \ XFree86 and DRI project m= ember |
|
From: Ken T. <ke...@we...> - 2001-05-16 12:09:15
|
On Wed, 16 May 2001, Alan Buxey wrote: Hello, > is there a source for all thes e- or is it a case of reading through all > the driver .c files for their flags? > from this, i guess such things as virge:1024x768-8, virge:640x480-24 > will work? what controls the refresh for this card? I think all the relevant drivers in 2.2 and those in 2.4 which don't use modedb.c support, take modes like video=name:XRESxYRES-depth apart from amifb which takes options like ntsc, dblpal, vga and more. Some drivers also accept otions like video=cyberfb:cyber16 to give a 16 bit default mode. Yes, each driver needs its own collection of supported modes gathered by searching through the .c files, or a subset of common modes - if you are lucky. The refresh rate is determined by the constants in the mode data base built into each driver (apart from those using modedb). For instance 800x600-16 in (my) virgefb gives 50Hz refresh but 1024x768-8 gives 75Hz refresh, you get the refresh rate you're given!. Mode can be changed later by fbset, either to a mode in /etc/fb.modes, or by giving specific values for some or all of the parmeters. Only way to know the true refresh rate is to calculate it from pixelclock and the horizontal and vertical resolution, sync and margin values. > okay, so I'll base it on the bpp mode for now. With virge driver as it is in kernels (both 2.2 and 2.4) now, bootstrap needs the -v option, keep amiga video and be booted from a WB screen of the same xres, yres and depth. I should commit the virge changes. Ken. |
|
From: Alan B. <al...@ms...> - 2001-05-16 11:32:50
|
hi, > > what about the 'mode' part of virge, it too is 'alien', yes? What is > > you're bootstrap line that works with the virge? > > video=virge:800x600-16 is there a source for all thes e- or is it a case of reading through all the driver .c files for their flags? from this, i guess such things as virge:1024x768-8, virge:640x480-24 will work? what controls the refresh for this card? > With the driver as I have it now it needs -n depth in bpp style for both > 2.2 and 2.4, for 2.4 with modedb (if it ever works) it would accept the -n > refresh style. okay, so I'll base it on the bpp mode for now. alan |
|
From: Ken T. <ke...@we...> - 2001-05-16 11:27:57
|
On Wed, 16 May 2001, Alan Buxey wrote: Hello, > thanks - its this quirky info that i need. was there any move to > standardise the gfx-cards on APUS so they were all called in the same name > format (eg virgefb, cyberfb, pm2fb etc)? I thought the standard was to drop the fb of the end. > what about the 'mode' part of virge, it too is 'alien', yes? What is > you're bootstrap line that works with the virge? video=virge:800x600-16 With the driver as I have it now it needs -n depth in bpp style for both 2.2 and 2.4, for 2.4 with modedb (if it ever works) it would accept the -n refresh style. Ken. |
|
From: Ken T. <ke...@we...> - 2001-05-16 11:19:15
|
What's the recommended compiler for APUS ? I use gcc version 2.95.2. Since I installed helix (Ximian) gnome about 12 months ago, X has been unstable under 2.2.10 and 2.4.?. It runs for a while, if I can get it to start without locking up my computer that is, and will eventually crash, usually with some interrupt related panic : Kernel panic: Exception in kernel pc c00a4fec signal 4 Kernel panic: kernel access of bad area pc c0037330 lr c00373cc address F80B48 tsk X/555 Another two seen a few times are : Page fault in interrupt handler Floating point in kernel The back trace usually shows the crash occured during interrupt handling. KDE used to be OK IIRC, running without X is rock solid. I suppose all this suggests the problem is with gnome and not with kernel/compiler combination. Anyone running gnome without any problem or what are you using ? Ken. |
|
From: Alan B. <al...@ms...> - 2001-05-16 11:16:41
|
hi, > You have the option to turn native (AGA) gfx off...do you want to do this? (Y/N)y > Okay, lets see what you think of this bootstrap: > bootstrap --apus -k vmapus-2.4.4 root=/dev/ram video=cyberfb:mode:800x600-60 video=amifb:off > > video=cyberfb:... is for the CV64 card not the CV64/3D, > which should be video=virge:... (not virgefb!) thanks - its this quirky info that i need. was there any move to standardise the gfx-cards on APUS so they were all called in the same name format (eg virgefb, cyberfb, pm2fb etc)? what about the 'mode' part of virge, it too is 'alien', yes? What is you're bootstrap line that works with the virge? thanks, alan |
|
From: Ken T. <ke...@we...> - 2001-05-16 11:01:16
|
On Tue, 15 May 2001, Alan Buxey wrote: > can people run this little utilty and give some feedback as to any errors > it makes/gives? Its just the beginning of a small tool i knocked up this > evening.... Hello All, My results... Are you installing Debian from this floppy? (Y/N)y Okay, in this case /dev/ram is used as the root Do you have a gfx card? (Y/N)y Okay, what card do you have installed? (choose the number) 1) CVisionPPC/BVisionPPC 2) CVision3D 3) Picasso IV Choice>2 What resolution do you wish to run in? (choose number) 1) 640x480 2) 800x600 3) 1024x768 Choice>2 You have the option to turn native (AGA) gfx off...do you want to do this? (Y/N)y Okay, lets see what you think of this bootstrap: bootstrap --apus -k vmapus-2.4.4 root=/dev/ram video=cyberfb:mode:800x600-60 video=amifb:off video=cyberfb:... is for the CV64 card not the CV64/3D, which should be video=virge:... (not virgefb!) About the CV64/3d, I have a modified virge driver that supports initialization and mode changing for 2.2 and 2.4 kernels but didn't ever commit the changes as I always intended to 'make it better' but never got round to it, but they work. The 2.4 version is almost identical to 2.2, only a few name changes. I also almost have a 2.4 version with modedb support but it has a couple of problems that I haven't got round to fixing (yet). Ken. |
|
From: Geert U. <ge...@li...> - 2001-05-16 10:10:50
|
On Wed, 16 May 2001, Alan Buxey wrote:
> > Well, we could split the kernel in 2 and join it in ram: before launching it.
> > Or we could try for a less than 880Ko modular kernel, but i have not big hopes
> > on this one. Michel Daenzer is the apus kernel package maintainer for debian.
>
> a small, but brief note:
>
> IS there not a very very big problem with having the kernel in ram: when
> launching?
>
> joining two files up into ram: is no problem (6 lines of code max.) but
> doesnt ram: just get completely trashed when the bootstrap loads up the
> kernel (and thus corrupting the kernel image?)
No, the bootstrap first allocates memory for the kernel (and the ramdisk), then
loads the image, and only then trashes the rest.
> i thought this was the case and people have to have the installer and
> kernel on media, rather than in volatile ram:
The only problem is that people might not have enough memory for both RAM: and
kernel/ramdisk.
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
|
|
From: Alan B. <al...@ms...> - 2001-05-16 10:05:13
|
hi, > Well, we could split the kernel in 2 and join it in ram: before launching it. > Or we could try for a less than 880Ko modular kernel, but i have not big hopes > on this one. Michel Daenzer is the apus kernel package maintainer for debian. a small, but brief note: IS there not a very very big problem with having the kernel in ram: when launching? joining two files up into ram: is no problem (6 lines of code max.) but doesnt ram: just get completely trashed when the bootstrap loads up the kernel (and thus corrupting the kernel image?) i thought this was the case and people have to have the installer and kernel on media, rather than in volatile ram: > 3) coordinate with alan for the floppy disk booting thingy. working on disk-layout, tools and required libraries now. alan |
107 messages has been excluded from this view by a project administrator.
