linux-apus-devel

Re: find on AFFS

[Ken T. <ke...@we...>]

On Sun, 14 Oct 2001, Roman Zippel wrote:

Hello,

> Does "-noleaf" make a difference? The problem is that AFFS has no link

It does !

> count, so the value is just faked (1 = no hard links, 2 = at least one
> hard link). I was already thinking about using different values here for
> directories. I'm not sure if it's really needed, since AFFS isn't the
> only filesystem with that behavior.

And after reading the man page I understand why.

Thanks, Ken.

Re: find on AFFS

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

Hi,

Ken Tyler wrote:

> On my system, "find" does not recurse into directories on AFFS file
> systems, ext2 is OK.
> 
> Can someone verify this is the case ?

Does "-noleaf" make a difference? The problem is that AFFS has no link
count, so the value is just faked (1 = no hard links, 2 = at least one
hard link). I was already thinking about using different values here for
directories. I'm not sure if it's really needed, since AFFS isn't the
only filesystem with that behavior.

bye, Roman

Re: CVS Update: 2.3 (branch: trunk)

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

Hi,

Alan Buxey wrote:

> >   add sync to cache_push again
> 
> is this a reversing of the CVS you submitted earlier?

Only a partial one. Ken told me, that I removed a bit too much.

bye, Roman

find on AFFS

[Ken T. <ke...@we...>]

Hello,

On my system, "find" does not recurse into directories on AFFS file
systems, ext2 is OK.

Can someone verify this is the case ?

Ken.

Re: More cache_push/SCSI/virgefb

[Ken T. <ke...@we...>]

> Hi!
> 
> I guess the printk`s need so much CPU time, that a cache-flush is forced 
> sometimes and sometimes not. I noticed the same as I used printk`s on my 
> cache problem.

I added the missing "sync" to cache_push and now running again with the
printks commented - not convinced that was the problem though.

Ken.

Re: More cache_push/SCSI/virgefb

[Rene B. <re...@we...>]

Ken Tyler wrote:

> I've added some printks to the scsi driver around the cache_push/clear =
and
> (__)get_free_pages calls, now I can mount and access the drive - at
> least on two boots - odd.


Hi!

I guess the printk`s need so much CPU time, that a cache-flush is forced=20
sometimes and sometimes not. I noticed the same as I used printk`s on my=20
cache problem.

Ciao, Ren=E8

Re: CVS Update: 2.3 (branch: trunk)

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

On Thu, 11 Oct 2001, Roman Zippel wrote:

> CVSROOT:	/cvsroot/linux-apus
> Module name:	2.3
> Repository:	2.3/arch/ppc/kernel/
> Changes by:	zippel@usw-pr-cvs1.	01/10/11 11:28:05
>
> Log message:
>   add sync to cache_push again

is this a reversing of the CVS you submitted earlier?

alan

boot methods (fwd)

[Geert U. <ge...@li...>]

---------- Forwarded message ----------
Date: Fri, 12 Oct 2001 17:32:34 +1000 (EST)
From: Paul Mackerras <pa...@sa...>
To: lin...@li...
Subject: boot methods


I would like to make a complete list of the methods people use to boot
the PPC/Linux kernel on different platforms.  As a start, here is what
I can think of off the top of my head:

Powermac:
	vmlinux loaded with BootX
	vmlinux loaded with quik
	vmlinux loaded with yaboot
	vmlinux.coff loaded via OF netboot
	vmlinux.elf-pmac loaded via OF (disk or net boot)

RS/6000 CHRP:
	vmlinux loaded with yaboot
	zImage.chrp-rs6k loaded via OF netboot

RS/6000 43p-140:
	zImage.prep loaded via OF (floppy or hard disk)

Can others contribute entries to this list please?

I am particularly interested in the cases where the kernel vmlinux
binary is loaded directly from some external software, because those
are the cases that constrain our freedom to choose how information
gets passed in to the kernel.  From a long-term maintainability
viewpoint, it would be better if we could say that we always have a
zImage-style wrapper, because then we could change the interface
between the wrapper and the kernel at will without breaking anything.
It would then be up to the wrapper to do any translation needed
between what the external software passed in to it and what the kernel
is expecting.

Along those lines, I have been thinking that it would be good if the
wrapper built a data structure describing the hardware in the system,
particularly things like:

- the amount of RAM and any holes
- type and register addresses for PCI host bus adaptors
- ditto for interrupt controllers
- interrupt mapping

The open firmware device tree does a good job of describing things
like this, so I would suggest it as the structure.  Whatever structure
we use needs to be flexible and open-ended rather than only describing
a fixed set of things, as well as being easy to traverse and
interpret (so I don't think prep-style residual data is an option).

Thoughts?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

CVS Update: 2.3 (branch: trunk)

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

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

Log message:
  add sync to cache_push again

Modified files:
      2.3/arch/ppc/kernel/:
        apus_setup.c 
  
  Revision      Changes    Path
  1.23          +1 -0      2.3/arch/ppc/kernel/apus_setup.c

Re: More cache_push/SCSI/virgefb

[Ken T. <ke...@we...>]

Hello, on Wed, 10 Oct 2001 you Roman Zippel wrote:

> No, the length should only be rounded up to push the correct number of
> cache lines.

There's still something not quite right.  I applied your patch and it
fixed the booting problem but an attempt to mount a scsi drive locked up
the kernel good and proper, no heartbeat, no caps lock led.

I've added some printks to the scsi driver around the cache_push/clear and
(__)get_free_pages calls,  now I can mount and access the drive - at
least on two boots - odd.

(note the 53c7xx.c/A4091/CVPPC never worked really well, OK on slow CDs
and ZIP drives but work it hard on a pair of hard drives and it would hang
up sooner or later).

I'll keep poking around.

Ken.

CVS Update: 2.3 (branch: trunk)

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

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/arch/ppc/kernel/
Changes by:	zippel@usw-pr-cvs1.	01/10/10 10:47:48

Log message:
  correctly align to cache line

Modified files:
      2.3/arch/ppc/kernel/:
        apus_setup.c 
  
  Revision      Changes    Path
  1.22          +3 -10     2.3/arch/ppc/kernel/apus_setup.c

Re: More cache_push/SCSI/virgefb

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

Hi,

Ken Tyler wrote:

> Two questions, should the trailing block be pushed if it attempts to go
> beyond physical memory (not that there should be anything in the cache to
> push),

No, the length should only be rounded up to push the correct number of
cache lines.

> and why does virge DEBUG make __get_free_pages return blocks at
> such a very different physical address ?

Usually the kernel starts allocating from the top, but you just get the
last freed page back. During boot several memory areas are freed and
depending on memory allocation scheme or kernel code/data size, you can
get a different page.

bye, Roman

More cache_push/SCSI/virgefb

[Ken T. <ke...@we...>]

Hello,

For anyone following my exciting story about how turning on DEBUG in
virgefb causes my kernel to hang initializing 53c7xx.c scsi, here is my
latest episode.

From dmesg of a successful boot, no virge DEBUG :

SCSI subsystem driver Revision: 1.00
ioremap: 50000000 (01000000) -> c5018000
scsi-ncr53c7xx : NCR53c710 at memory 0xc5818000, io 0x0, irq 12
scsi : get_free_pages (virt) 0xc0340000
scsi : get_free_pages (phys) 0x08340000
scsi0: Revision 0x1

The physical address of the two pages returned by __get_free_pages is
somewhere low in my 64 Meg of PPC memory.

With virge DEBUG on :

SCSI subsystem driver Revision: 1.00
ioremap: 50000000 (01000000) -> c5018000
scsi-ncr53c7xx : NCR53c710 at memory 0xc5818000, io 0x0, irq 12
scsi : get_free_pages (virt) 0xc3f7e000
scsi : get_free_pages (phys) 0x0bf7e000
(cache_push here)
Oops: kernel access of bad area, sig: 11

The physical address of the two pages is now right at the very top of my
64 Meg.  The cache_push pushes two pages and always the "trailing block",
32 bytes more, this causes the oops.  Taking out the trailing block push
stops the oops.

Two questions, should the trailing block be pushed if it attempts to go
beyond physical memory (not that there should be anything in the cache to
push), and why does virge DEBUG make __get_free_pages return blocks at
such a very different physical address ?

Any suggestions ?

Ken.

Re: Short question concnerning PCI support within APUS

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

hi,

> But by the way, I also thinking about to buy a G-Rex board and if I have
> the time and money I will try to get it running on APUS. But there are 2
> problems. First we probably need some information how we can scan the
> G-Rex PCI-bus (maybe from Mr. Dellert). Second, if the G-Rex is in the
> slot, the CV-PPC is not in the slot and so you probably have to work on
> the G-Rex driver with AmiFb...

hmm, I'm tempted byt he Mediator, which is now very popular in the AmigaOS
world.... *that* board would also require its access to PCI space. In this
way we could have a similar 'access port'

fortunately work could be done on it under the PM2FB as that can coexist


I'm more 'worried' about AmigaONE as that works backwards.....the PPC is
on the AmigaONE and the old Amiga is accessed as a PCI device....
perhaps a new kernel... Linux/A1 project would have to be done for this?
..except that it should be so much closer to a CHrp/PreP Mac kernel
than the current APUS one.

alan

Re: Short question concnerning PCI support within APUS

[Geert U. <ge...@li...>]

On 8 Oct 2001, Michel [ISO-8859-1] D=E4nzer wrote:
> On Sun, 2001-10-07 at 21:08, Rene Brothuhn wrote:
> > But by the way, I also thinking about to buy a G-Rex board and if I h=
ave=20
> > the time and money I will try to get it running on APUS. But there ar=
e 2=20
> > problems. First we probably need some information how we can scan the=
=20
> > G-Rex PCI-bus (maybe from Mr. Dellert).
>=20
> As the other Rene mentioned in his post, it might only be a matter of
> knowing the addresses of PCI config and memory space. But of course
> vendor supplied information would always be appreciated.

I think I once found the information about one of the two PCI bridges (do=
n't
remember which one) on the website of its company.

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

Re: Short question concnerning PCI support within APUS

[Rene B. <re...@we...>]

Ren=E9 Thol wrote:

> By the way are there any news concerning support of FASTLANE or even
> UW-SCSI?
> I also asked Mr. Dellert for documents which enable the APUS coders=20
> finally
> to support the UW-SCSI. He told me that he can't do anything concerning
> this point but asking Ralf (forgot the surname) and I was told to call =
him
> back later this week (tomorrow; today Mr.Dellert was not in house).


Hi!

I`m working on the UW-SCSI driver and I`ll give you some information=20
about it`s state. The 53c770 chip is detected and configured by the=20
driver and then the driver makes some tests, which works fine. The 4k=20
on-chip RAM is used for SCSI-SCRIPTS and the chip can execute SCRIPTS at=20
on-chip RAM and also at system-memory. The LED is working, which is=20
switched on and off by SCRIPTS in on-chip RAM when the scsi-bus is=20
selected or reselected. Also the driver is reacting on IRQ`s and calls=20
by the generic SCSI driver. After booting, you can find some information=20
about the driver in /proc/scsi/53c770.
And there is the problem, the generic driver tries to detect devices on=20
the scsi-bus and fails. I don`t know whats wrong here, maybe its another=20
cache related problem. But in this state I think there is no need for=20
help from Ralf Schmidt anymore (unless he has a working=20
linux-driver...). So let him work on MorphOS.

But by the way, I also thinking about to buy a G-Rex board and if I have=20
the time and money I will try to get it running on APUS. But there are 2=20
problems. First we probably need some information how we can scan the=20
G-Rex PCI-bus (maybe from Mr. Dellert). Second, if the G-Rex is in the=20
slot, the CV-PPC is not in the slot and so you probably have to work on=20
the G-Rex driver with AmiFb...


Ciao, Ren=E8

Re: Short question concnerning PCI support within APUS

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

hi,

> I only want to know if there are plans to support upcoming PCI-hardware for
> our Amigas used with Mediator or G-Rex. Concerning G-Rex I was told by Mr.
> Dellert (DCE) that writing drivers should be no problem, as the coder only
> has to know, where the appropriate memory addresses will be. Mr. Dellert
> also said, that there is a Software coming with the G-Rex boards which
> solves exactly this question.
>
> Are there already plans for supporting the "new" hardware? Cause I want to
> keep my Amiga as only computer and therefore I want to buy an expansion for
> the A4000 enabling me the use of faster network cards, sound-, GFX- and
> TV-cards!
>
> Hope APUS won't miss these new developing direction of our Amiga!


well, supporting these PCI cards shouldnt be too much of a problem - it is
just finding where the PCI access point is in memory space (as such).
however there are 2 issues.

no APUS developers have such board (iirc!) and secondly there are quite a
few cards out there that are x86 centric.....ie the drivers have the wrong
bit order and x86 asm code .  those are, however , minor issues really ;-)

> I also asked Mr. Dellert for documents which enable the APUS coders finally
> to support the UW-SCSI. He told me that he can't do anything concerning
> this point but asking Ralf (forgot the surname) and I was told to call him
> back later this week (tomorrow; today Mr.Dellert was not in house).
> I hope I'll have some good news leading in this direction soon!

I believe that Ralph Schmidt was already asked several times...and did
profer some info (to one indivisual iirc

alan

Re: Short question concnerning PCI support within APUS

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

On Thu, 2001-10-04 at 19:13, Ren=E9 Thol wrote:

> I only want to know if there are plans to support upcoming PCI-hardware f=
or
> our Amigas used with Mediator or G-Rex. Concerning G-Rex I was told by Mr=
.
> Dellert (DCE) that writing drivers should be no problem, as the coder onl=
y
> has to know, where the appropriate memory addresses will be.

If that's true, adding support for it should be straightforward looking
at the existing PCI support for the B/CVisionPPC. Someone with the
hardware will have to do it, what about you? :)

> Mr. Dellert also said, that there is a Software coming with the G-Rex boa=
rds which
> solves exactly this question.

How so? They don't provide source code, do they?


> By the way are there any news concerning support of FASTLANE or even
> UW-SCSI?

There have been posts about the latter on the devel list lately which
looked rather promising.

> I also asked Mr. Dellert for documents which enable the APUS coders final=
ly
> to support the UW-SCSI. He told me that he can't do anything concerning
> this point but asking Ralf (forgot the surname) and I was told to call hi=
m
> back later this week (tomorrow; today Mr.Dellert was not in house).
> I hope I'll have some good news leading in this direction soon!

That certainly wouldn't hurt, thanks for your efforts!


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

Short question concnerning PCI support within APUS

[T. <Ren...@gm...>]

Hi everybody!

I only want to know if there are plans to support upcoming PCI-hardware f=
or
our Amigas used with Mediator or G-Rex. Concerning G-Rex I was told by Mr=
=2E
Dellert (DCE) that writing drivers should be no problem, as the coder onl=
y
has to know, where the appropriate memory addresses will be. Mr. Dellert
also said, that there is a Software coming with the G-Rex boards which
solves exactly this question.

Are there already plans for supporting the "new" hardware? Cause I want t=
o
keep my Amiga as only computer and therefore I want to buy an expansion f=
or
the A4000 enabling me the use of faster network cards, sound-, GFX- and
TV-cards!

Hope APUS won't miss these new developing direction of our Amiga!

By the way are there any news concerning support of FASTLANE or even
UW-SCSI?
I also asked Mr. Dellert for documents which enable the APUS coders final=
ly
to support the UW-SCSI. He told me that he can't do anything concerning
this point but asking Ralf (forgot the surname) and I was told to call hi=
m
back later this week (tomorrow; today Mr.Dellert was not in house).
I hope I'll have some good news leading in this direction soon!

Kind regards
-- =

Ren=E9 Thol
Mail: Ren...@gm...=

My 2.4.9 problem in cache_push

[Ken T. <ke...@we...>]

Hello,

I described yesterday how 53c7xx.c driver is hanging up during booting
after I turned on DEBUG in virgefb.c.

As best I can determine a cache_push call in 53c7xx.c is where the booting
stops.

The 53c7xx.c does __get_free_pages(GFP_ATOMIC,1); and gets 8192 bytes,
later calls cache_push() with the returned address and 8192 bytes.

During/after the the cache_push "Oops: kernel access of bad area, sig: 11"
appears in dmesgs.

I can 'fix' this two ways, either by getting more mem with
__get_free_pages(GFP_ATOMIC,3) which boots OK, or 
by commenting out the code following /* Also flush trailing block */ in
cache_push (arch/ppc/kernel/apus_setup.c), this moves the problem down to
the susequent call of cache_clear.  When the "trailing" code there is
commented out boot is again OK.

Is it OK to "flush trailing block" when the called with MAX_CACHE_SIZE ?
Or does it mean there is an address in the cache in the trailing block
that is invalid in that it's not mapped in ?

Ken.

2.4.9 odd problem

[Ken T. <ke...@we...>]

Hello,

A while ago I mentioned I was having an odd problem with 2.4.8.  A one
piece kernel with A4091 53c7xx.c driver was fine but a modular kernel with
the same driver hung up in the driver when booting even though the A4091
driver is not (and can't be) a module.

The problem went away with 2.4.9 but now has re-appeared.  I modified
virgefb.c CV64-3d driver, changed some of the ioremap calls and turned on
DEBUG, now both monolithic and modular kernels hang up in the A4091
initialization.

It looks like it hangs in ncr53c7xx_init() around

    page = __get_free_pages(GFP_ATOMIC,1);
    ...
    instance->hostdata[0] = page;
    memset((void *)instance->hostdata[0], 0, 8192);
    cache_push(virt_to_phys((void *)(instance->hostdata[0])), 8192);
    cache_clear(virt_to_phys((void *)(instance->hostdata[0])), 8192);
    kernel_set_cachemode(instance->hostdata[0], 8192, IOMAP_NOCACHE_SER);

I don't have much confidence poking around the cache code but will have a
go.

dmesg attached.

Ken.

Re: cache problem

[Ken T. <ke...@we...>]

On Sat, 29 Sep 2001, Rene Brothuhn wrote:

> OK, I`l describe it. If you use __get_free_pages(GFP_ATOMIC, 1) you get 
> 2 pages and you will probably apply 8192 to the size argument of 
> kernel_set_cachemode(). Thats OK.
> But if you apply sizeof(struct x) to the size argument and sizeof(struct 
> x) isn`t a multiply of PAGE_SIZE then the last page is not remapped by 
> kernel_set_cachemode(). Because the loop in kernel_set_cachemode() is 
> initialized at value: size = size / PAGE_SIZE.
> If size = 10000, so you have to remap 3 pages, but 10000 / 4096 = 
> 2(u_long) and the loop only remaps 2 pages.
> 
> I hope now its clear what I mean.

Yes, clear as mud ;)

> > Thinking about yet another play with the A4091...

Well, I won't bother then as nothing's affected. 

Thanks, Ken.

Re: cache problem

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

Hi,

Rene Brothuhn wrote:

> Documentation/DMA-mapping.txt says that can pci_alloc_consistent()
> also be used on machines that don`t have PCI-bus.

It says the API can also be used for other machines, I'm not that sure
about the implementation (although most of it should be generic enough).
For pci_alloc_consistent() it says to pass NULL for non-PCI devices and
mentions only (E)ISA, what sounds like it's just meant for the normal pc
architecture.
Anyway, shouldn't the bus need any special consideration, it should work
as well, but then I'd prefer a better naming.

bye, Roman

Re: cache problem

[Rene B. <re...@we...>]

Ken Tyler wrote:

>
> Hello,
>
> Don't understand what you mean by "last page" or "upper boundary of siz=
e".
>
> Do you mean if I :
>
> page =3D __get_free_pages(GFP_ATOMIC,1);
>
> which allocates two pages, the second of which does not have cache mode
> set correctly ?


Hi,

OK, I`l describe it. If you use __get_free_pages(GFP_ATOMIC, 1) you get=20
2 pages and you will probably apply 8192 to the size argument of=20
kernel_set_cachemode(). Thats OK.
But if you apply sizeof(struct x) to the size argument and sizeof(struct=20
x) isn`t a multiply of PAGE_SIZE then the last page is not remapped by=20
kernel_set_cachemode(). Because the loop in kernel_set_cachemode() is=20
initialized at value: size =3D size / PAGE_SIZE.
If size =3D 10000, so you have to remap 3 pages, but 10000 / 4096 =3D=20
2(u_long) and the loop only remaps 2 pages.

I hope now its clear what I mean.

>
> Thinking about yet another play with the A4091...


It`s weekend, have fun...


Ciao, Ren=E8

Re: cache problem

[Rene B. <re...@we...>]

Roman Zippel wrote:

> Hi,
>
> Rene Brothuhn wrote:
>
>> As far as I know the standard interface to get some uncached mem is
>> pci_alloc_consistent() as described in Documentation/DMA-mapping.txt.
>> This seems to working on APUS, but I`m not sure if the TLB`s are marke=
d
>> as cache-inhibit.
>
>
> No there aren't. First it's pci specific and it doesn't mention the
> cache at all. If you look at arch/ppc/kernel/pci-dma.c, you see it's
> just a __get_free_pages(), but you need a new mapping to get the new
> cache mode.


Hello,

Documentation/DMA-mapping.txt says that pci_alloc_consistent() can also=20
be used on machines that don`t have PCI-bus.


Ciao, Ren=E8