linux-apus-devel Mailing List for Linux/APUS Kernel (Page 75)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

The file arch/ppc/kernel/head.S has an unterminated comment in line 1609,
that causes the compilation to fail.
(ay least this was the case with my copy)

- glenn

Hi all,

I wish to inform you that i am beginning a revision of the
CLgen driver.
The goals are these:
1) To add the var kernel options handling.
2) To add multiple boards support.
3) General revision of the code, expecially debug strings.
4) Any other thing suggested ...

As I am not a graphic chip's specialist, I don't think to go
in a lower level than the revision of the general organization
of the driver.
But if someone has improvements for Picasso4 board's code i shall
be happy to test & debug them with my card.

If anyone is still working on this please inform me because i don't
want to interfere on other's work.

Thanks
                                Giorgio Terzi

Dan Malek writes:

> It won't work well for 8xx either, because we have the hack to
> allow a PCMCIA flash disk as an IDE device without using PCMCIA
> card services.  Why can't we make these ppc_md calls like other
> IDE things, which makes my hack much easier to do :-).  There are

They are already (well, they're indirect calls to members of
ppc_ide_md).  I will leave them like that, at least for now.  The only
thing I want to do is make the members of ppc_ide_md point directly to
check_region etc. or be NULL, rather than having little wrapper
functions.

Sound OK?

> also other 8xx systems with a memory mapped IDE on the processor
> bus where the check/request region doesn't make sense (in fact,
> these functions don't make sense on most embedded systems).

Check/request region doesn't make much sense whenever the IDE
registers are actually in PCI memory space (or the equivalent) rather
than I/O space.

Paul.

-- 
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
pa...@li..., http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

Hi,

On Wed, 22 Nov 2000, Alan Buxey wrote:

> by the way, is this some CVS 'thing' or am i making an ooops, but to do a
> commit i must use the full line: eg
> 
> cvs -d:ext:ala...@cv...:/cvsroot/linux-apus 
> commit -r mol-branch 2.2/arch/ppc/mm/init.c  
> 
> because when i use the -d part as a CVSROOT, I get prompted for password,
> but then when i do a plain 

What's in CVS/Root? Maybe you checked it out anonymously? If yes, it
should be possible to directly replace that line and copy it to all the
other Root files (somehow something like "find . -name Root -exec cp
CVS/Root {} \;").

bye, Roman

Geert Uytterhoeven wrote:

> This must not be done on APUS, where IDE I/O is memory mapped I/O.

It won't work well for 8xx either, because we have the hack to
allow a PCMCIA flash disk as an IDE device without using PCMCIA
card services.  Why can't we make these ppc_md calls like other
IDE things, which makes my hack much easier to do :-).  There are
also other 8xx systems with a memory mapped IDE on the processor
bus where the check/request region doesn't make sense (in fact,
these functions don't make sense on most embedded systems).

I was going to try and work around this, but since Geert spoke up.....

Thanks.

	-- Dan

Alan Buxey wrote:

> by the way, is this some CVS 'thing' or am i making an ooops, but to do a
> commit i must use the full line: eg
> 
> cvs -d:ext:ala...@cv...:/cvsroot/linux-apus
> commit -r mol-branch 2.2/arch/ppc/mm/init.c
> 
> because when i use the -d part as a CVSROOT, I get prompted for password,
> but then when i do a plain
> 
> cvs commit -r mol-branch 2.2/arch/ppc/mm/init.c
> 
> i get told that theres no password....

You need to be inside the tree for CVS to figure out the repository root
itself (it's in the CVS subdirectories).

> > My opinion is that if someone wants to deal with this low-level code in
> > development, he should take the time to learn about using CVS branches.
>                ^^
> 
> or she, one forever hopes!  okay, i can agree - what i can offer, then, is
> some help to anyone wanting to learn  (though I'm still open to people
> emailing me changes if it'll accelerate any progress 8-) )

The problem I forgot to mention: If people want to email any changes, they'll
have to check out the branch first, so they have to learn using branches.

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

hi,

> > Hopefully the CVS update of the mol-branch was successful!!
> 
> The update yes, but you obviously haven't committed yet (no commit message).

mea culpa.  ok, I am now committing.

> > M 2.2/arch/ppc/config.in
> 
> What changes have you made here? AFAIR I already re-enabled the configuration
> option when I started mol-branch? Before committing, please double-check that
> you are in fact working with mol-branch.

i am treble double checking  :-)
(even *if* the docs say that the -r is sticky, i'm always using -r
mol-branch ! ;-) )

by the way, is this some CVS 'thing' or am i making an ooops, but to do a
commit i must use the full line: eg

cvs -d:ext:ala...@cv...:/cvsroot/linux-apus 
commit -r mol-branch 2.2/arch/ppc/mm/init.c  

because when i use the -d part as a CVSROOT, I get prompted for password,
but then when i do a plain 

cvs commit -r mol-branch 2.2/arch/ppc/mm/init.c  

i get told that theres no password.... 

> > M 2.2/arch/ppc/kernel/head.S
> > M 2.2/arch/ppc/kernel/ppc_ksyms.c
> > M 2.2/arch/ppc/mm/init.c
> 
> These are your local modifications, meaning your tree differs from the
> repository.

and now they've been committed  :-)

> In principle yes, but there are various ways to overcome that issue.

more to learn ;-)

> My opinion is that if someone wants to deal with this low-level code in
> development, he should take the time to learn about using CVS branches.
               ^^

or she, one forever hopes!  okay, i can agree - what i can offer, then, is
some help to anyone wanting to learn  (though I'm still open to people
emailing me changes if it'll accelerate any progress 8-) )

alan

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/mm/
Changes by:	ala...@sl....	00/11/22 04:01:44

Modified files:
	2.2/arch/ppc/mm/: Tag: mol-branch init.c 

Log message:
	added this MOL-related change

	#ifndef CONFIG_MOL
	#define NO_RELOAD_HTAB 1 /* change in kernel/head.S too! */
	#endif

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/kernel/
Changes by:	ala...@sl....	00/11/22 04:00:18

Modified files:
	2.2/arch/ppc/kernel/: Tag: mol-branch ppc_ksyms.c 

Log message:
	Insertion of mol_interface attribution and some ppc code

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/kernel/
Changes by:	ala...@sl....	00/11/22 03:58:18

Modified files:
	2.2/arch/ppc/kernel/: Tag: mol-branch head.S 

Log message:
	Multiple changes :

	Insertion of the MOL instructions and routines.
	Insertion of APUS_PROGRESS routine and calls

CVSROOT:	/cvsroot/linux-apus
Module name:	2.2
Repository:	2.2/arch/ppc/
Changes by:	ala...@sl....	00/11/22 03:57:09

Modified files:
	2.2/arch/ppc/: Tag: mol-branch config.in 

Log message:
	change to allow MOL to be option on configure menu

Alan Buxey wrote:

> Hopefully the CVS update of the mol-branch was successful!!

The update yes, but you obviously haven't committed yet (no commit message).

> changes are to the following files:
> 
> M 2.2/arch/ppc/config.in

What changes have you made here? AFAIR I already re-enabled the configuration
option when I started mol-branch? Before committing, please double-check that
you are in fact working with mol-branch.

> M 2.2/arch/ppc/kernel/head.S
> M 2.2/arch/ppc/kernel/ppc_ksyms.c
> M 2.2/arch/ppc/mm/init.c

These are your local modifications, meaning your tree differs from the
repository.

> I guess that people who want to work on this will need to keep two
> directories....one for the working 2.2, and one for the mol-branch 2.2
> 
> - otherwise, how do you keep gcc compiling the clean , or mol-branch
> sources???  I guess i am correct?

In principle yes, but there are various ways to overcome that issue.

> One last thing....if you can see the problem, but cant use CVS (and
> believe me, the use of branches etc can be confusing!!) then please just
> email me the patches or snippets of code directly!! I'll be able to place
> them into the CVS branch straight away....lets not have any more delays
> due to people having to climb steep learning development curves :-)
> (dont worry Michel, I'll help anyone who WANTS to learn CVS/branches :-) )

My opinion is that if someone wants to deal with this low-level code in
development, he should take the time to learn about using CVS branches.

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

hi,

well, things are never easy...not only becoming used to CVS, but now my
SSH skills have improved ;-)

Hopefully the CVS update of the mol-branch was successful!!

changes are to the following files:

M 2.2/arch/ppc/config.in
M 2.2/arch/ppc/kernel/head.S
M 2.2/arch/ppc/kernel/ppc_ksyms.c
M 2.2/arch/ppc/mm/init.c                 

I guess that people who want to work on this will need to keep two
directories....one for the working 2.2, and one for the mol-branch 2.2

- otherwise, how do you keep gcc compiling the clean , or mol-branch
sources???  I guess i am correct?

Finally, no! dont get over-excited! MOL is still not working in APUS,
however the mol-branch CVS is now in a ready state (on the suggestion of
Michel!!) for others to join in with possible changes!

Please have a look at the head.S, i guess this is where all our troubles
lie. I have put the APUS_PROGRESS system back into play...you may use
APUS_PROGRESS(X) calls (where X is a number) to see how far down head.S
you get...thats if APUS_PROGRESS is working!! 8-)

One last thing....if you can see the problem, but cant use CVS (and
believe me, the use of branches etc can be confusing!!) then please just
email me the patches or snippets of code directly!! I'll be able to place
them into the CVS branch straight away....lets not have any more delays
due to people having to climb steep learning development curves :-)
(dont worry Michel, I'll help anyone who WANTS to learn CVS/branches :-) )

Alan  - back to my Solaris nightmare now

On Sat, Aug 26, 2000 at 08:24:16PM -0400, Adam Di Carlo wrote:
> 
> Wait a minnit.  Why can't we just change dbootstrap to give the mount
> command Michel mentioned, rather than the one which you mentioned?
> 
> Assuming taht doesn't break other arches (don't see why it would) then
> we have a pretty damn good workaround... no?

Adam, i have seen Ben's call for potato r2, and thought we may solve this, as
well as upgrade the apus port to a more recent kernel (well, still 2.2.10, but
with more work done by the linux-apus folk).

Also i did a CD install on an i386 box recently, and noticed that when
installing the kernel & os, it searches for drivers.tgz and not for
rescue.bin.

Since the apus install is much more akin to a CD install anyway (we just copy
the stuff to the harddisk, and take everything from there) it would make much
more sense to do it in the same way.

Is there somethign special involved when dbootstrap installs from a CD ? how
can we make dbootstrap install think it is installing from a CD when we are on
apus ?

It has been a long time since i looked at boot-floppies, though.

Friendly,

Sven Luther

Alan Buxey wrote:

> > I've already done the tagging, and even if you'd have to you wouldn't need
> > much bandwidth for that.
> 
> its quicker and easier (for trialling etc) - also, I dont have CVS working
> under AmigaOS (thats noted down as part of my AmigaOS development list) so
> I'd have to CVS....and my modem speed under APUS is...s.l.o.w.

I know, but have you tried it yet? It can be amazing how little bandwidth it
needs (and how useless lots of bandwidth can be OTOH ;).

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

hi,

> I've already done the tagging, and even if you'd have to you wouldn't need
> much bandwidth for that.

its quicker and easier (for trialling etc) - also, I dont have CVS working
under AmigaOS (thats noted down as part of my AmigaOS development list) so
I'd have to CVS....and my modem speed under APUS is...s.l.o.w. 

alan

Alan Buxey wrote:

> > BTW Alan, what about committing your code now so others can join your
> > experiments?
> 
> i'm close to doing that now, my machine has been in a right state recently
> (is this the case with all of us?? it seems it is!!) I suspect its feeling
> its old age now..being over 8 years old!  I expect to be 'CVSable' in the
> sense of the tagging etc etc as soon as i've got the files up at a T1
> connection :-)

I've already done the tagging, and even if you'd have to you wouldn't need
much bandwidth for that.

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

hi,

> APUS_PROGRESS only makes sense when the MMU is off, which means all addresses
> are physical, like in AmigaOS. So it's 0xeff01234 . AFAIR when the MMU is
> turned on, things should be more or less set up for dmesg debugging to work.

ok, so 4eff01234 is where i should be looking.

> BTW Alan, what about committing your code now so others can join your
> experiments?

i'm close to doing that now, my machine has been in a right state recently
(is this the case with all of us?? it seems it is!!) I suspect its feeling
its old age now..being over 8 years old!  I expect to be 'CVSable' in the
sense of the tagging etc etc as soon as i've got the files up at a T1
connection :-)

alan

Alan Buxey wrote:

> #define APUS_PROGRESS(_a) \ >        lis     r3,0xfff0;
> \
> >        ori     r3,r3,0xeff0;                   \
> >        lis     r4,0x1234;                      \
> >        ori     r4,r4,(_a);                     \
> >        stw     r4,0x0(r3);                     \
> >        dcbf    0,r3;                           \
> >        sync;                                   \
> >        isync
> >
> >
> > So it's 0xeff01234 .
> 
> just to confirm.....if I use a tool like MemoryX under AmigaOS, I will
> find the number from APUS_PROGRESS calls at memory location
> $eff01234  - correct, or is the memory mapping difference under
> Linux/AmigaOS going to mean the info is actually at some other location?

APUS_PROGRESS only makes sense when the MMU is off, which means all addresses
are physical, like in AmigaOS. So it's 0xeff01234 . AFAIR when the MMU is
turned on, things should be more or less set up for dmesg debugging to work.

BTW Alan, what about committing your code now so others can join your
experiments?

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

hi,

just a quick progress report for the MOL-branch (to be submitted soon)

APUS_PROGRESS has now been inserted into head.S  - had problems at first
as head.S won't compile when you put APUS_PROGRESS calls in certain
locations  (and with low assembler knowledge its very easy for me to put
the calls in *those* locations  ;-)) the MOL changes are now all in there
too. I'm now in step 3, finding the fault ;-)

#define APUS_PROGRESS(_a) \ >        lis     r3,0xfff0;
\
>        ori     r3,r3,0xeff0;                   \
>        lis     r4,0x1234;                      \
>        ori     r4,r4,(_a);                     \
>        stw     r4,0x0(r3);                     \
>        dcbf    0,r3;                           \
>        sync;                                   \
>        isync
> 
> 
> So it's 0xeff01234 .

just to confirm.....if I use a tool like MemoryX under AmigaOS, I will
find the number from APUS_PROGRESS calls at memory location
$eff01234  - correct, or is the memory mapping difference under
Linux/AmigaOS going to mean the info is actually at some other location?

Alan

On Sun, 19 Nov 2000, Paul Mackerras wrote:
> pa...@hq...:/home/bk/linuxppc_2_3 remote push from pa...@di...:/home/paulus/kernel/linuxppc_2_3
> 
> ChangeSet@1.348, 2000-11-20 15:42:05+11:00, pa...@di...
>   This patch makes ide_check/request/release_region simple macros
>   in asm-ppc/ide.h which just call check/request/release_region.
>   If this causes problems for anyone, let me (pa...@li...)
>   know.  This is done at the suggestion of Andre Hedrick, the IDE
>   maintainer.

This must not be done on APUS, where IDE I/O is memory mapped I/O.
Since drivers/ide/gayle.c already does request_mem_region(), you can keep on
using dummy functions if CONFIG_APUS.

Yes, it's messy: the ide_* macros may operate on either I/O or memory space,
depending on the box they're running on.

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

Hi,

On Sat, 11 Nov 2000, Ken Tyler wrote:

> Broken again ?  Is that just affs or the lot ?

Affs is still the same.
What got broken due to the test10 import should be fixed now.

bye, Roman

On Thu, 9 Nov 2000, Roman Zippel wrote:

> On Wed, 8 Nov 2000, Ken Tyler wrote:
> 
> > I just compiled 2.4 test 9 from sourceforge, after a few copies of a 2 Meg
> > file to an affs partition I'm not getting any errors.
> 
> No.
> BTW I just imported test10, but there were some bigger mm changes, so it's
> broken again... 

Broken again ?  Is that just affs or the lot ?

Ken.

On Fri, Nov 10, 2000 at 11:54:31AM +0100, Michel D?nzer wrote:
> 
> Anders, the correct address for this list is
> lin...@li... . You sent your post to the -admin
> alias which is only forwarded to me (and Sven ?) and Roman :)

(don't think so, last mail from -admin isdated may 31 ...)

> Anders Kjeldsen wrote:
> > 
> > Could anyone give me an update on the issue
> > "Linux PPC & PCI-Busboards" ? I have a
> > Mediator I'd like to use :)
> 
> Then start hacking on it :)
> 
> Sorry, but this is how it works.

Do you just have the board, or some specs of it ? maybe you could try contacting
the builder about it ?

Did you try anything, or have any tool that can look at how this thing works ?

Michel's response may be a bit surprising to you, but that is really how it
works, and anyway, it is very difficult to make developpment without having
the hardware available. So best way to do this is to setup a kernel
compilation setup, and try stuff. We will help you as much we can in your
experiments.

Friendly,

Svne Luther

Anders, the correct address for this list is
lin...@li... . You sent your post to the -admin
alias which is only forwarded to me (and Sven ?) and Roman :)

Anders Kjeldsen wrote:
> 
> Could anyone give me an update on the issue
> "Linux PPC & PCI-Busboards" ? I have a
> Mediator I'd like to use :)

Then start hacking on it :)

Sorry, but this is how it works.

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

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