linux-apus-devel

Re: APUS Debian Boot-Floppies Images and bugs

[Sven L. <lu...@dp...>]

On Fri, May 11, 2001 at 10:38:07PM +0200, Giorgio Terzi wrote:
> Hello Sven,
> 
> In first i wish to thank you for your help and for your last 
> e-mail. :)))
> 
> But let's speak about job.
> 
> The second goal is reached!
> 
> Now is possible to load & install Rescue & Driver images from 
> floppies, CD-ROMS,HD-Partitions.
> But to do this we must correct some bugs :
> 
> Bug 1: dbootstrap
> 
> The APUS rescue image is MSDOS formatted but in file
> choose_medium.c from line 34 the code is so:
>    #if cpu(sparc) || #cpu(powerpc)
>    const char *fs_type_tab[] = {  "ext2", NULL };
>    #else
>    const char *fs_type_tab[] = { "msdos", "ext2", NULL };
>    #endif
> as you can understand is impossible for a powerpc machine
> to load a msdos partition, so i have modified it so:
>    #if cpu(sparc) || #cpu(powerpc)
>    const char *fs_type_tab[] = { "msdos", "ext2", NULL };
>    #else
>    const char *fs_type_tab[] = { "msdos", "ext2", NULL };
>    #endif

I changed this to :

 #if cpu(sparc)
 const char *fs_type_tab[] = { "msdos", "ext2", NULL };
 #else
 const char *fs_type_tab[] = { "msdos", "ext2", NULL };
 #endif

Should work, i think. Does one of the powerpc boot floppies people have
anything to say about it before i commit ?

> After this, rescue.bin was loaded and kernel extracted & configured.
> I think this #if is obsolete because, as you will see some lines 
> after in the source file , mount loops between the various filesystems
> (msdos & ext2 now, but may will be more ?) attempting 
> to load the image files.
> 
> For CD-ROM & for HD partition loading system the drivers was also
> successfully loaded & configured. 
> For CD-ROM i used my Potato CD-ROM N.1.For hard disk i have
> built a debian tree in an Amiga partition.
> 
> Bug 2: floppy images build & configuration
> 
> After the kernel configuration, it was renamed as vmlinuz-2.2.19,
> and this comes from the install.sh script. 
> For APUS this name is wrong as it is really a 2.2.10 kernel.
> Maybe it is possible to use the $subarch variable to distinguish the 
> various powerpc kernel architecture's versions during the install.sh 
> configuration ?

mmm, you can use the apuskver variable defined at line 30 of the config file :

ifeq "$(architecture)" "powerpc"
    kver        := 2.2.19
    pcmcia_kver := 2.2.19-pmac
    apuskver    := 2.2.10
endif

So i guess what is used is kver, not apuskver.

Notice that the install.sh script is generated at line 12 of the rescue.sh
script, from the install.sh.txt file, but passing only the kver and arch
variables, not the subarch and apuskver one. There may be need for more
extensive modification here, i don't know m4 enough to really help out here.

Also it seems to me the write_powerpc routine only knows about quick, don't
think this will be working on apus, we may be more near what the
write_m68kinfo does, ity would need testing though.

lines 396-401 of rescue.sh should be generating the right thing for apus,
altough i don't really see a reason why we shall not go the ext2 way.

It would be also be interresting to see if we need lines 450+ of rescue.sh,
about broken loop device, this sound like the loop bug of the original boot
floppies.

Line 552 of rescue.sh also has some $kver related things we shall look into.

mmm, line 573 of rescue.sh calls write_m86kinfo, so we don't have to worry
about quick as feared above, we still would need to make sure that subarch and
apuskver is passed to m4 when generating install.sh.

That's all i see in rescue.sh.

mmm, maybe this would be enough (try the attached patch) ?

write_installsh () {
    if [ "x$noinstall" = x ]; then
	if [ "$subarch" != apus ]; then
	    m4 -D__ERROR_MESS__=$scripts/messages/$language/install.sh.txt \
		-D__version__=$kver -D__arch__=$arch \
		<$scripts/install.sh >$mnt/install.sh
	    chmod 755 $mnt/install.sh
	else
	    m4 -D__ERROR_MESS__=$scripts/messages/$language/install.sh.txt \
		-D__version__=$apuskver -D__arch__=$arch \
		<$scripts/install.sh >$mnt/install.sh
	    chmod 755 $mnt/install.sh
	fi
    fi

Could you try it out ?

> I have tested also the floppy disk use:
> 
> Bug 3: fd0 device problems
> 
> For APUS /dev/fd0 is unable to load the rescue floppy disk. 
> I think it defaults to the Amiga floppy formats.
> I must erase it and recreate it with 'mknod fd0 b 2 28'
> that is the same of /dev/fd0u1440 in a "standard" installation.
>  
> After this change the rescue floppy was successfully loaded.

Ok, but like said most amiga have only the 720/880Ko floppy variety.

> Bug 4: dboostrap problem.
> 
> dbootsrap was not able to recognize the driver's floppy disk
> because the drivers' default names was treated as complete
> names but they are really "root names" for example:
> drv14           is a "root name"
> drv14apus.bin   is a driver's complete name.
> In file floppy_merge.c i have modified the line 197 :
> 
>    if (!strcmp (basenames[i], block.header.name))
> as follows:
>    if (!strncmp (basenames[i], block.header.name,strlen(basenames[i])))
>             
> after this i have also loaded the drivers!

Ok, i read this was already by stephen Marenka, but maybe not as you say here.
I didn't found any mention to it in the cvs log file, but then i may have
missed it.

Friendly,

Sven Luther

Re: APUS Debian Boot-Floppies Images and bugs

[Sven L. <lu...@dp...>]

On Mon, May 14, 2001 at 11:50:40AM +0100, Alan Buxey wrote:
> hi,
> 
> > Bug 3: fd0 device problems
> > 
> > For APUS /dev/fd0 is unable to load the rescue floppy disk. 
> > I think it defaults to the Amiga floppy formats.
> > I must erase it and recreate it with 'mknod fd0 b 2 28'
> > that is the same of /dev/fd0u1440 in a "standard" installation.
> >  
> > After this change the rescue floppy was successfully loaded.
> 
> problem: the internal floppy of the A1200 is only a sub-Mb model,
> so it cannot read HD1440 images. 

But i guess there were some HD1440 models sold, isn't it. I think it makes
sense to support them if possible. Ideally would be to have a warning when you
choose this option that you need 1.4MB floppies support, or else we will get a
lot of complaints about why the floppy method don't work.

I don't know if it is possible to enable such a per subarch warning (altough
it may be common the the m68K/amiga folk).

Friendly,

Sven Luther

Re: APUS Debian Boot-Floppies Images and bugs

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

hi,

> Bug 3: fd0 device problems
> 
> For APUS /dev/fd0 is unable to load the rescue floppy disk. 
> I think it defaults to the Amiga floppy formats.
> I must erase it and recreate it with 'mknod fd0 b 2 28'
> that is the same of /dev/fd0u1440 in a "standard" installation.
>  
> After this change the rescue floppy was successfully loaded.

problem: the internal floppy of the A1200 is only a sub-Mb model,
so it cannot read HD1440 images. 
 
well done on the other work though!

alan

snapshots available!

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

Hi,

"Michel Dänzer" wrote:

> > Maybe I can setup something over the weekend.
> 
> Good luck! :)

Ok, it's done, whenever needed I can recompile the kernel and move to
the snapshots dir at the ftp server. The first one is already there. :)

bye, Roman

Re: What kernel are we going to use for apus in debian/woody ?

[Sven L. <lu...@dp...>]

On Sun, May 13, 2001 at 08:05:08PM +0200, Michel D=E4nzer wrote:
> Sven LUTHER wrote:
>=20
> > I would ask you all what is the current status of the apus kernels, i=
n
> > particular, is the 2.4.x kernel mature for use in the debian boot flo=
ppies.
>=20
> I'd think so. I gather it's about even between people for whom 2.2 or 2=
.4
> works better.
>=20

Ok, let's do it then  ...

> > In particular, Michel, you toke the 2.2.10 kernel package from me. Di=
d you
> > also do a 2.4.x version of it ?
>=20
> Not yet, but I'm planning to do it as soon as I get enough time. BTW I =
assume
> I can upload packages for new kernel versions without ITP or anything?

No you don't need to, just upload them.

Also i think the boot floppies will be freezed soon, i think in june or j=
uly
or so, don't remember well just now.

Please tell Giorgio also when you did upload them, so he can test the boo=
t
floppies with them.

Friendly,

Sven Luther
>=20
>=20
> --=20
> Earthling Michel D=E4nzer (MrCooper)    \   Debian GNU/Linux (powerpc) =
developer
> CS student, Free Software enthusiast   \        XFree86 and DRI project=
 member

Re: What kernel are we going to use for apus in debian/woody ?

[Michel <mic...@ii...>]

Sven LUTHER wrote:

> I would ask you all what is the current status of the apus kernels, in
> particular, is the 2.4.x kernel mature for use in the debian boot floppies.

I'd think so. I gather it's about even between people for whom 2.2 or 2.4
works better.


> In particular, Michel, you toke the 2.2.10 kernel package from me. Did you
> also do a 2.4.x version of it ?

Not yet, but I'm planning to do it as soon as I get enough time. BTW I assume
I can upload packages for new kernel versions without ITP or anything?


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

What kernel are we going to use for apus in debian/woody ?

[Sven L. <lu...@dp...>]

Hello all, ...

I would ask you all what is the current status of the apus kernels, in
particular, is the 2.4.x kernel mature for use in the debian boot floppies. 

This would make it the default kernel to be used in most debian installs, so
if there are still big problems with the 2.4.x kernels, best would be to stay
with 2.2.10.

Now, there is still some time until debian/woody chips, so maybe it is also
possible to fix those issues before then.

What do you think of it ?

In particular, Michel, you toke the 2.2.10 kernel package from me. Did you
also do a 2.4.x version of it ?

Friendly,

Sven Luther

Re: APUS Debian Boot-Floppies Images and bugs

[Sven L. <lu...@dp...>]

On Fri, May 11, 2001 at 10:38:07PM +0200, Giorgio Terzi wrote:
> Hello Sven,
> 
> In first i wish to thank you for your help and for your last 
> e-mail. :)))
> 
> But let's speak about job.
> 
> The second goal is reached!
> 
> Now is possible to load & install Rescue & Driver images from 
> floppies, CD-ROMS,HD-Partitions.
> But to do this we must correct some bugs :
> 
> Bug 1: dbootstrap
> 
> The APUS rescue image is MSDOS formatted but in file
> choose_medium.c from line 34 the code is so:
>    #if cpu(sparc) || #cpu(powerpc)
>    const char *fs_type_tab[] = {  "ext2", NULL };
>    #else
>    const char *fs_type_tab[] = { "msdos", "ext2", NULL };
>    #endif
> as you can understand is impossible for a powerpc machine
> to load a msdos partition, so i have modified it so:
>    #if cpu(sparc) || #cpu(powerpc)
>    const char *fs_type_tab[] = { "msdos", "ext2", NULL };
>    #else
>    const char *fs_type_tab[] = { "msdos", "ext2", NULL };
>    #endif
> After this, rescue.bin was loaded and kernel extracted & configured.
> I think this #if is obsolete because, as you will see some lines 
> after in the source file , mount loops between the various filesystems
> (msdos & ext2 now, but may will be more ?) attempting 
> to load the image files.

Ok, will check it in on monday. BTW, could you send me all your changes in
patch form ? You know how to do so, isn't it ? you use diff -ur original.tree
changed.tree, or if you did change only a file, you do diff -u file.orig
file.new. This is the most usefull manner of sharing changes to code.

As what happened here, i guess it worked ok before (as potato used msdos disks
also) but was changed later on. BTW, it don't really makes sense to use msdos
root images, so we could as well go with the ext2 stuff for apus, but we have
to find were it is that this is specified.

> For CD-ROM & for HD partition loading system the drivers was also
> successfully loaded & configured. 
> For CD-ROM i used my Potato CD-ROM N.1.For hard disk i have
> built a debian tree in an Amiga partition.

mmm, ok, i guess this will not work well because of the link issue, but then
it is only for testing.

> Bug 2: floppy images build & configuration
> 
> After the kernel configuration, it was renamed as vmlinuz-2.2.19,
> and this comes from the install.sh script. 
> For APUS this name is wrong as it is really a 2.2.10 kernel.
> Maybe it is possible to use the $subarch variable to distinguish the 
> various powerpc kernel architecture's versions during the install.sh 
> configuration ?

Yes, i remember there was a apus subarch, and already in potato i had to use
2.2.10, while other ppc subarches used 2.2.12 or later kernels.

Maybe we should also go the 2.4.x route, but i am not sure if it is ready
already. Let's ask on the apus lists about it.

> I have tested also the floppy disk use:
> 
> Bug 3: fd0 device problems
> 
> For APUS /dev/fd0 is unable to load the rescue floppy disk. 
> I think it defaults to the Amiga floppy formats.
> I must erase it and recreate it with 'mknod fd0 b 2 28'
> that is the same of /dev/fd0u1440 in a "standard" installation.
>  
> After this change the rescue floppy was successfully loaded.

Err, do you have a 1.44MB floppy ? Most people would have only 880KB ones, so
this is not really needed. Maybe it would be good if you changedebootstrap, so
as to look for fd0u1440 directly, instead of for /dev/fd0, in case we are on
the apus subarch. Also some comment somewhere about it would be welcome. Don't
know if there is a place for adding description of the entries though.

Also i think i recall that we had /dev/fd0 for 720Ko floppies, and /dev/df0
for 880KB amiga floppies, or maybe it was /dev/pc0 or somethign such ...

> Bug 4: dboostrap problem.
> 
> dbootsrap was not able to recognize the driver's floppy disk
> because the drivers' default names was treated as complete
> names but they are really "root names" for example:
> drv14           is a "root name"
> drv14apus.bin   is a driver's complete name.
> In file floppy_merge.c i have modified the line 197 :
> 
>    if (!strcmp (basenames[i], block.header.name))
> as follows:
>    if (!strncmp (basenames[i], block.header.name,strlen(basenames[i])))
>             
> after this i have also loaded the drivers!

huh, this is very nice work already, very good.

Just when making such changes, it is needed to check that it don't break other
arches/subarches. Is there a way to test for the apus subarch when doing the
changes ? somethign like :

  if (arch="ppc" && subarch="apus")
    if (!strcmp (basenames[i], block.header.name));
  else if (!strncmp (basenames[i], block.header.name,strlen(basenames[i])));

I remember being able to do things like that before.

Maybe they are even macros to do per arch things ?

> I can't test network installations because at this moment i haven't it.

maybe we could put the files somewhere and ask for someone with a network
connection to test this ?

> Next steps:
> 1) I shall take a look for ZIP installation.

mmm, should be the same as harddisk installation, should it not ?

> 2) I shall try to download the woody base_system and install it

Ok, that will permit us to test the rest of it, but i think the most difficult
part is already done.

Friendly,

Sven Luther

Re: APUS Debian Boot-Floppies Images and bugs

[Stephen R M. <st...@ma...>]

At 10:38 PM +0200 5/11/01, Giorgio Terzi wrote:
>Bug 4: dboostrap problem.
>
>dbootsrap was not able to recognize the driver's floppy disk
>because the drivers' default names was treated as complete
>names but they are really "root names" for example:
>drv14           is a "root name"
>drv14apus.bin   is a driver's complete name.
>In file floppy_merge.c i have modified the line 197 :
>
>    if (!strcmp (basenames[i], block.header.name))
>as follows:
>    if (!strncmp (basenames[i], block.header.name,strlen(basenames[i])))

I just fixed this in bf cvs, none of the powerpc driver disks were 
listed as known driver disks, so I added drv14pmac, drv14apus, 
drv14chrp, and drv14prep.

Stephen
-- 

____________________________________________________________________________
Stephen R. Marenka            If life's not fun, you're not doing it right!
<sma...@be...>

APUS Debian Boot-Floppies Images and bugs

[Giorgio T. <de...@ip...>]

Hello Sven,

In first i wish to thank you for your help and for your last 
e-mail. :)))

But let's speak about job.

The second goal is reached!

Now is possible to load & install Rescue & Driver images from 
floppies, CD-ROMS,HD-Partitions.
But to do this we must correct some bugs :

Bug 1: dbootstrap

The APUS rescue image is MSDOS formatted but in file
choose_medium.c from line 34 the code is so:
   #if cpu(sparc) || #cpu(powerpc)
   const char *fs_type_tab[] = {  "ext2", NULL };
   #else
   const char *fs_type_tab[] = { "msdos", "ext2", NULL };
   #endif
as you can understand is impossible for a powerpc machine
to load a msdos partition, so i have modified it so:
   #if cpu(sparc) || #cpu(powerpc)
   const char *fs_type_tab[] = { "msdos", "ext2", NULL };
   #else
   const char *fs_type_tab[] = { "msdos", "ext2", NULL };
   #endif
After this, rescue.bin was loaded and kernel extracted & configured.
I think this #if is obsolete because, as you will see some lines 
after in the source file , mount loops between the various filesystems
(msdos & ext2 now, but may will be more ?) attempting 
to load the image files.

For CD-ROM & for HD partition loading system the drivers was also
successfully loaded & configured. 
For CD-ROM i used my Potato CD-ROM N.1.For hard disk i have
built a debian tree in an Amiga partition.

Bug 2: floppy images build & configuration

After the kernel configuration, it was renamed as vmlinuz-2.2.19,
and this comes from the install.sh script. 
For APUS this name is wrong as it is really a 2.2.10 kernel.
Maybe it is possible to use the $subarch variable to distinguish the 
various powerpc kernel architecture's versions during the install.sh 
configuration ?

I have tested also the floppy disk use:

Bug 3: fd0 device problems

For APUS /dev/fd0 is unable to load the rescue floppy disk. 
I think it defaults to the Amiga floppy formats.
I must erase it and recreate it with 'mknod fd0 b 2 28'
that is the same of /dev/fd0u1440 in a "standard" installation.
 
After this change the rescue floppy was successfully loaded.

Bug 4: dboostrap problem.

dbootsrap was not able to recognize the driver's floppy disk
because the drivers' default names was treated as complete
names but they are really "root names" for example:
drv14           is a "root name"
drv14apus.bin   is a driver's complete name.
In file floppy_merge.c i have modified the line 197 :

   if (!strcmp (basenames[i], block.header.name))
as follows:
   if (!strncmp (basenames[i], block.header.name,strlen(basenames[i])))
            
after this i have also loaded the drivers!

I can't test network installations because at this moment i haven't it.
Next steps:
1) I shall take a look for ZIP installation.
2) I shall try to download the woody base_system and install it

Friendly,

-- 
                                                 Giorgio Terzi

Re: build problems of linux-apus cvs

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

"GürerÖzen" wrote:

> RZ> I guess it's CONFIG_RTC, in the precompiled kernel this is a module, so
> RZ> it does no harm.
> 
> It was the generic pm2 gfx card option, don't know why i enabled it.

Hmm, it's not needed, but it also shouldn't hurt.

> I disabled CONFIG_RTC. Now I get "cannot read/set hardware clock"
> messages each time I bootstrap or halt linux.

CONFIG_GEN_RTC is still enabled? That's actually the driver that takes
care of this.

> Other than that 2.4.3 is working very well on my system. Sound started
> to work again and printer seems like working ok (haven't tested it much
> though).

That would be strange, I haven't seen any important change here, but if
it works... :)

bye, Roman

Re: build problems of linux-apus cvs

[<ma...@e-...>]

RZ>> First problem is in the mem.c. At the end of this file, there is a call
RZ>> to lp_m68k_init(), but "grep -r lp_m68k_init *" shows that this

RZ> It's obsolete, it's replaced with the parallel drivers under
RZ> drivers/parport.

ok.

RZ> I guess it's CONFIG_RTC, in the precompiled kernel this is a module, so
RZ> it does no harm.

It was the generic pm2 gfx card option, don't know why i enabled it.

I disabled CONFIG_RTC. Now I get "cannot read/set hardware clock"
messages each time I bootstrap or halt linux.

Other than that 2.4.3 is working very well on my system. Sound started
to work again and printer seems like working ok (haven't tested it much
though).


-- 
Gurer Ozen (email: ma...@e-..., jid: ma...@ja...)

Re: CVS Update: 2.3 (branch: trunk)

[Michel <mic...@ii...>]

Roman Zippel wrote:

> > BTW I wonder what it would take to setup daily builds on SF like it's done
> > by the DRI now?
> 
> Hmm, that would require setting up a cross compiler.

SF has PPC boxen in their compile farm apparently.

> If it's only a matter of running a script, I could do it on my machine.

I've done it mostly manually but it could certainly be automated for the most
part.

> Maybe I can setup something over the weekend.

Good luck! :)


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

Re: CVS Update: 2.3 (branch: trunk)

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

"Michel Dänzer" wrote:
> 
> Roman Zippel wrote:
> 
> > Log message:
> >   vfat endianess fixes
> 
> (and AFFS updates...)
> 
> Confess, you always hold back a batch of updates until I upload binaries! ;)

Just bad timing. ;)
But the affs fixes are for no serious problems.

> BTW I wonder what it would take to setup daily builds on SF like it's done by
> the DRI now?

Hmm, that would require setting up a cross compiler.
If it's only a matter of running a script, I could do it on my machine.
Maybe I can setup something over the weekend.

bye, Roman

Re: CVS Update: 2.3 (branch: trunk)

[Michel <mic...@ii...>]

Roman Zippel wrote:

> Log message:
>   vfat endianess fixes

(and AFFS updates...)

Confess, you always hold back a batch of updates until I upload binaries! ;)


BTW I wonder what it would take to setup daily builds on SF like it's done by
the DRI now?


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

CVS Update: 2.3 (branch: trunk)

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

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/fs/affs/
Changes by:	zippel@usw-pr-cvs1.	01/05/10 16:13:20

Log message:
  small buffer sync fixes

Modified files:
      2.3/fs/affs/:
        amigaffs.c file.c inode.c namei.c 
  
  Revision      Changes    Path
  1.5           +6 -5      2.3/fs/affs/amigaffs.c
  1.7           +11 -11    2.3/fs/affs/file.c
  1.10          +5 -4      2.3/fs/affs/inode.c
  1.7           +2 -1      2.3/fs/affs/namei.c

CVS Update: 2.3 (branch: trunk)

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

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/fs/vfat/
Changes by:	zippel@usw-pr-cvs1.	01/05/10 16:12:34

Log message:
  vfat endianess fixes

Modified files:
      2.3/fs/fat/:
        dir.c 
      2.3/fs/vfat/:
        namei.c 
  
  Revision      Changes    Path
  1.2           +184 -89   2.3/fs/fat/dir.c
  1.3           +360 -227  2.3/fs/vfat/namei.c

Re: build problems of linux-apus cvs

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

Hi,

"GürerÖzen" wrote:

> First problem is in the mem.c. At the end of this file, there is a call to
> lp_m68k_init(), but "grep -r lp_m68k_init *" shows that this function isn't
> defined anywhere!? I commented it for now to avoid linking problem.

It's obsolete, it's replaced with the parallel drivers under
drivers/parport.

> I wonder how the 2.4.3 binary is compiled. Am I doing something wrong while
> downloading kernel and get older version or something? Or am i doing a
> mistake while configuring it?

I guess it's CONFIG_RTC, in the precompiled kernel this is a module, so
it does no harm.

bye, Roman

CVS Update: 2.3 (branch: trunk)

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

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/arch/ppc/configs/
Changes by:	zippel@usw-pr-cvs1.	01/05/09 10:35:11

Log message:
  remove obsolete printer option & update config

Modified files:
      2.3/arch/ppc/:
        config.in defconfig 
      2.3/drivers/char/:
        mem.c 
      2.3/arch/ppc/configs/:
        apus_defconfig 
  
  Revision      Changes    Path
  1.23          +0 -1      2.3/arch/ppc/config.in
  1.8           +26 -3     2.3/arch/ppc/defconfig
  1.4           +43 -64    2.3/drivers/char/mem.c
  1.6           +26 -3     2.3/arch/ppc/configs/apus_defconfig

Re: build problems of linux-apus cvs

[Michel <mic...@ii...>]

Glenn Hisdal wrote:

> > > Shouldn't the m68k printer option be removed from apus ?
> >
> > I build it as a module for our binaries, why should I remove it?
>=20
> iirc. it don't work if you try to compile it directly into the kernel.
> The function lp_m68k_init is in the file lp_m68k.c in the 2.2 tree, but
> doesn't exist in 2.4.
> It's been a while since I tried it, so maybe something has changed.
>=20
> I know this option had to be enabled in 2.2 to make printing work, but
> iirc. it doesn't work in 2.4.

If that's true then we should either fix or remove it of course.


--=20
Earthling Michel D=E4nzer (MrCooper)    \   Debian GNU/Linux (powerpc) de=
veloper
CS student, Free Software enthusiast   \        XFree86 and DRI project m=
ember

Re: build problems of linux-apus cvs

[Glenn H. <gh...@c2...>]

Michel Dänzer wrote:
> 
> Glenn Hisdal wrote:
> >
> > GürerÖzen wrote:
> > >
> > > I grabbed latest version today from cvs with following commands:
> > >
> > > export CVSROOT=":pserver:ano...@cv...:/cvsroot/linux-apus"
> > > cvs -z3 co 2.4
> > >
> > > Then configured it with "make menuconfig", and compiled it with "make dep"
> > > and "make".
> > >
> > > First problem is in the mem.c. At the end of this file, there is a call to
> > > lp_m68k_init(), but "grep -r lp_m68k_init *" shows that this function
> > > isn't defined anywhere!? I commented it for now to avoid linking problem.
> >
> > disable CONFIG_M68K_PRINTER (or something like that) in .config, and try
> > again.
> >
> > Shouldn't the m68k printer option be removed from apus ?
> 
> I build it as a module for our binaries, why should I remove it?

Oh, sorry then...
iirc. it don't work if you try to compile it directly into the kernel.
The function lp_m68k_init is in the file lp_m68k.c in the 2.2 tree, but
doesn't exist in 2.4.
It's been a while since I tried it, so maybe something has changed.

I know this option had to be enabled in 2.2 to make printing work, but
iirc. it doesn't work in 2.4. 

- glenn

Re: build problems of linux-apus cvs

[Michel <mic...@ii...>]

Glenn Hisdal wrote:
> 
> GürerÖzen wrote:
> >
> > I grabbed latest version today from cvs with following commands:
> >
> > export CVSROOT=":pserver:ano...@cv...:/cvsroot/linux-apus"
> > cvs -z3 co 2.4
> >
> > Then configured it with "make menuconfig", and compiled it with "make dep"
> > and "make".
> >
> > First problem is in the mem.c. At the end of this file, there is a call to
> > lp_m68k_init(), but "grep -r lp_m68k_init *" shows that this function
> > isn't defined anywhere!? I commented it for now to avoid linking problem.
> 
> disable CONFIG_M68K_PRINTER (or something like that) in .config, and try
> again.
> 
> Shouldn't the m68k printer option be removed from apus ?

I build it as a module for our binaries, why should I remove it?


-- 
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

Re: build problems of linux-apus cvs

[Glenn H. <gh...@c2...>]

GürerÖzen wrote:
> 
> I grabbed latest version today from cvs with following commands:
> 
> export CVSROOT=":pserver:ano...@cv...:/cvsroot/linux-apus"
> cvs -z3 co 2.4
> 
> Then configured it with "make menuconfig", and compiled it with "make dep"
> and "make".
> 
> First problem is in the mem.c. At the end of this file, there is a call to
> lp_m68k_init(), but "grep -r lp_m68k_init *" shows that this function isn't
> defined anywhere!? I commented it for now to avoid linking problem.

disable CONFIG_M68K_PRINTER (or something like that) in .config, and try
again.

Shouldn't the m68k printer option be removed from apus ?


-glenn

Re: very FAQ

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

In <200...@gr...>, on 05/08/01 
   at 07:00 PM, Massimo Santoro <m.s...@wo...> said:

>any news about CYBPPC UWSCSI controller driver?

I was all set to start working on it again and then my Amiga  broke.  I'm
trying to get setup so I don't have to have a 
completely working Amiga to continue the work.  I'm not
there yet but hope to be in a week or two.   Then I need
to get a new motherboard (maybe)

So, to answer your question there is no news unless someone
else is trying to work on it besides me.

Fred

build problems of linux-apus cvs

[<ma...@e-...>]

I grabbed latest version today from cvs with following commands:

export CVSROOT=3D":pserver:ano...@cv...:/cvsr=
oot/linux-apus"
cvs -z3 co 2.4

Then configured it with "make menuconfig", and compiled it with "make dep=
"
and "make".

First problem is in the mem.c. At the end of this file, there is a call t=
o =

lp_m68k_init(), but "grep -r lp_m68k_init *" shows that this function isn=
't
defined anywhere!? I commented it for now to avoid linking problem.

Compiled kernel didn't work. My system freezed after bootstrap loaded
bootstrap_pup and inhibited drives. I suspected a configuration problem a=
nd
compared .config file of 2.4.3 release on the sf.net page with my .config=

(attached to my mail). Differences are minimal, I'll try again with "make=

oldconfig" later though. I don't want to do this since config of 2.4.3 is=

bloated (heck, it even has khttpd) but maybe it will solve the problem.

I wonder how the 2.4.3 binary is compiled. Am I doing something wrong whi=
le
downloading kernel and get older version or something? Or am i doing a
mistake while configuring it?


-- =

Gurer Ozen (email: ma...@e-..., jid: ma...@ja...)