linux-apus-devel

Diff`s for MOL

[MICHAEL H. <101...@ge...>]

Hello User

This Mail I write on Samuel Rydh ( the Developer from MOL )  

Hello Samuel,


I would like to write you today, because I unite questions to MOL had.

The Diff`s those the MOL package is attached I processed and into those

Kernelsourcen 2.2.10 for Linux-APUS(Amiga) with trained.  From the file

ppc_ksyms.c I deleted the line(238) EXPORT_SYMBOL(mol_interface).

Thereby not, if I compile the Kernel the message

"undefined reference mol_interface" is displayed.

This message is displayed, if I switch "loadable modules support" on.

And the line EXPORT_SYMBOL(mol_interface) itself in the file ppc_ksyms.c

finds.

The Kernel with loadable modules support however without the line

EXPORT_SYMBOL(mol_interface) runs very stably.

Also the Runtime Patche are correctly executed, if I the Binary

from MOL start.  But at the end I receive the error message with
mol_interface,

if startmol is executed.

I transmit the four files also, which I processed to you.

Perhaps you can regard it once also.

And say to me, I make which error.  Or like the Reference too mol_interface

to create is.

It would make me happy much, if you can help me.


   with kind regards

                            Micha

Re: Diff`s for MOL

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

hi,

> ppc_ksyms.c I deleted the line(238) EXPORT_SYMBOL(mol_interface).

there is far far more to get MOL running than that single line. I counted
(and inserted) over 30 lines of code into various arch/ppc files to get
MOL support, however, though the kernel still compiles, it then crashes
upon bootup..this is an ongoing investigation (i now need to do some
APUS_PROGRESS calls - but am insufficiently trained to jump straight into
this (help! anyone? :-)) ) 

alan

Re: Diff`s for MOL

[Michel <da...@re...>]

Alan Buxey wrote:

> > ppc_ksyms.c I deleted the line(238) EXPORT_SYMBOL(mol_interface).
> 
> there is far far more to get MOL running than that single line. I counted
> (and inserted) over 30 lines of code into various arch/ppc files to get
> MOL support,

I'm creating a MOL branch (again) called mol-branch now. Please commit your
MOL changes there.


> however, though the kernel still compiles, it then crashes
> upon bootup..this is an ongoing investigation (i now need to do some
> APUS_PROGRESS calls - but am insufficiently trained to jump straight into
> this (help! anyone? :-)) )

I see APUS_PROGRESS isn't in our code anymore. Time to dig up some old
versions... Anyway, what APUS_PROGRESS(n) basically did was write n to a fixed
memory address (don't remember - something like 0xe0001234 ?) which wouldn't
be cleared on reboot. You could read that value back with a memory viewer in
AmigaOS to find out how far the code ran.


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

Re: Diff`s for MOL

[Michel <da...@re...>]

Michel Dänzer wrote:
> 
> Alan Buxey wrote:
> 
> > however, though the kernel still compiles, it then crashes
> > upon bootup..this is an ongoing investigation (i now need to do some
> > APUS_PROGRESS calls - but am insufficiently trained to jump straight into
> > this (help! anyone? :-)) )
> 
> I see APUS_PROGRESS isn't in our code anymore. Time to dig up some old
> versions... Anyway, what APUS_PROGRESS(n) basically did was write n to a
> fixed memory address (don't remember - something like 0xe0001234 ?) which
> wouldn't be cleared on reboot. You could read that value back with a memory
> viewer in AmigaOS to find out how far the code ran.

I found it in an old m68k diff:


#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 .


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

Re: Diff`s for MOL

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

hi,

> I found it in an old m68k diff:

can you commit that into the CVS 2.2 tree so I can slurp it in tonight?
 
thanks,

alan

Re: Diff`s for MOL

[Michel <da...@re...>]

Alan Buxey wrote:

> > I found it in an old m68k diff:
> 
> can you commit that into the CVS 2.2 tree so I can slurp it in tonight?

No time, sorry. It's in the oldest (2.2.3pre1) m68k diff which is still in our
FTP's obsolete/ . There you also find the original calls from Jesper.


Don't forget to cvs upd -r mol-branch before committing anything ;)

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

Re: Diff`s for MOL

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

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

Re: Diff`s for MOL

[Michel <da...@re...>]

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

Re: Diff`s for MOL

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

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

Re: Diff`s for MOL

[Michel <dae...@st...>]

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

Re: Diff`s for MOL

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

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

Re: Diff`s for MOL

[Michel <dae...@st...>]

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

Re: Diff`s for MOL

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

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
 

Re: Diff`s for MOL

[Michel <dae...@st...>]

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

Re: Diff`s for MOL

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

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

Re: Diff`s for MOL

[Michel <dae...@st...>]

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

Re: Diff`s for MOL

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

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

Clgen driver revision

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

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

Re: Diff`s for MOL

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

hi,

> 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 {} \;").

firstly, thanks, this was the problem.

secondly.....if i want to get 2.3 from CVS that is in a compilable state
and 'stable' do i just do a CVS grab of 2.3, or is there a particular
branch that i should be using?

i note the bk_20001124 and apus-2_4_0-test10 branches that seem to be
quite 'interesting'

alan

Re: Diff`s for MOL

[Michel <da...@re...>]

Alan Buxey wrote:

> secondly.....if i want to get 2.3 from CVS that is in a compilable state
> and 'stable' do i just do a CVS grab of 2.3, or is there a particular
> branch that i should be using?

There are no branches like mol-branch in 2.3 . Just get the trunk.


> i note the bk_20001124 and apus-2_4_0-test10 branches that seem to be
> quite 'interesting'

AFAIK only the former one is a branch (imports create implicit branches). The
latter is a normal tag which marks the point where Roman has imported test10
and fixed the conflicts.


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

Re: Diff`s for MOL

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

hi,

> There are no branches like mol-branch in 2.3 . Just get the trunk.

okay, I've just hugged the main trunk :-)
 
alan

Re: Diff`s for MOL

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

hi,

> 
> I'm creating a MOL branch (again) called mol-branch now. Please commit your
> MOL changes there.

okay...boy do i need to quickly learn this cvs stuff! :-)

> I see APUS_PROGRESS isn't in our code anymore. Time to dig up some old
> versions... Anyway, what APUS_PROGRESS(n) basically did was write n to a fixed
> memory address (don't remember - something like 0xe0001234 ?) which wouldn't
> be cleared on reboot. You could read that value back with a memory viewer in
> AmigaOS to find out how far the code ran.

thought it would be that easy...i just couldnt find APUS_PROGRESS() in any
of the code (must have got taken out when we did the move to sourceforge
(it needed/needs to go back in))

I can then work with the Head.S quickly then

alan

Re: Diff`s for MOL

[Michel <da...@re...>]

Alan Buxey wrote:

> > I'm creating a MOL branch (again) called mol-branch now. Please commit
> > your MOL changes there.
> 
> okay...boy do i need to quickly learn this cvs stuff! :-)

Learning by doing is still the best paradigm I know :)


> > I see APUS_PROGRESS isn't in our code anymore. Time to dig up some old
> > versions... Anyway, what APUS_PROGRESS(n) basically did was write n to a
> > fixed memory address (don't remember - something like 0xe0001234 ?) which > > wouldn't be cleared on reboot. You could read that value back with a
> > memory viewer in AmigaOS to find out how far the code ran.
> 
> thought it would be that easy...i just couldnt find APUS_PROGRESS() in any
> of the code (must have got taken out when we did the move to sourceforge

No, Jesper removed it in early 2.2 when the kernel booted reliably on all
hardware AFAIR.

> (it needed/needs to go back in))

Not in the trunk please. It's fine in the branch, but we'll have to remember
taking it out before merging to the trunk.


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

Re: Diff`s for MOL

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

hi,

> Learning by doing is still the best paradigm I know :)

:-) Well, I've got the way to tag the branch... now its just getting the
single files updated :-)

2 months ago (CVS == #undef), now (CVS == 'Hello World') wont be long
until (Alan != struct {newbie})
 
> No, Jesper removed it in early 2.2 when the kernel booted reliably on all
> hardware AFAIR.

I'll take a look at the stuff on FTP and see what I need to pull in to get
APUS_PROGRESS working again.
 
> Not in the trunk please. It's fine in the branch, but we'll have to remember
> taking it out before merging to the trunk.

can we have another branch....and then pull it in when needed? I'm sorry,
but i still dont understand how the branch pulling/pushing works in
practice (ie how the new ppc_ksyms.c in the MOL branch will be related to
the ppc_ksyms.c in the main trunk)

alan

Re: Diff`s for MOL

[Michel <da...@re...>]

Alan Buxey wrote:

> > Not in the trunk please. It's fine in the branch, but we'll have to
> > remember taking it out before merging to the trunk.
> 
> can we have another branch....and then pull it in when needed?

Why another branch? Isn't one branch enough for MOL development? ;)


> I'm sorry, but i still dont understand how the branch pulling/pushing works
> in practice (ie how the new ppc_ksyms.c in the MOL branch will be related to
> the ppc_ksyms.c in the main trunk)

They'll be independent of each other. You can break whatever you want in the
branch without affecting the trunk and vice versa. It is however always
possible to merge changes from one to the other. When the branch has reached
stability, we will merge it into the trunk completely and will stop working on
it.


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