* Re: 43p-140 install issues
From: Ulrich Teichert @ 2005-01-04 15:23 UTC (permalink / raw)
To: mikemartin; +Cc: Ulrich Teichert, linuxppc-dev, debian-powerpc, Philippe Guyot
In-Reply-To: <855e88d005010405417d49dcfb@mail.gmail.com>
Hi,
>I gave Leigh's 2.4.22 a try. It gave me the same result with the
>debian root disk:
>
>VFS: Insert root floppy and press ENTER
>
>FAT: bogus logical sector size 1981
>FAT: bogus logical sector size 1981
>read_super_block: can't find a reiserfs filesystem on (dev 02:00,
>block 64, size 1024)
>read_super_block: can't find a reiserfs filesystem on (dev 02:00,
>block 8, size 1024)
>Kernel panic: VFS: Unable to mount root fs on 02:00
Could you try to format them before dd'ing on them, like fdformat /dev/fd0h1440?
I am not sure if that will change anything, though.
>Tonight I'll grab a different root floppy and see what happens.
>
>Leigh's 2.4.22 will also boot the system installed on /dev/sdb1,
>however it also stopped responding after awhile. I think it lasted
>longer than with 2.4.19.
I am begining to believe that there is some sort of hardware problem with your
box or it is an upgraded version which was a -140 in it's previous life, but my
-140 is rock solid with Leigh's 2.4.19 kernel - once it's up, that is.
I will leave it running tonight to see what happens,
HTH,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
Stormweg 24 |listening to: Suicide Drive (The Deep Eynde)
24539 Neumuenster, Germany|Public Pervert (Interpol) Clé De Contact (Metal Urbain)
^ permalink raw reply
* Re: 43p-140 install issues
From: Mike Martin @ 2005-01-04 15:39 UTC (permalink / raw)
To: Ulrich Teichert; +Cc: linuxppc-dev, debian-powerpc, Philippe Guyot
In-Reply-To: <200501041523.j04FNoO0009594@arbas.nms.ulrich-teichert.org>
On Tue, 4 Jan 2005 16:23:50 +0100 (MET), Ulrich Teichert
> Could you try to format them before dd'ing on them, like fdformat /dev/fd0h1440?
> I am not sure if that will change anything, though.
Will do.
>
> I am begining to believe that there is some sort of hardware problem with your
> box or it is an upgraded version which was a -140 in it's previous life, but my
> -140 is rock solid with Leigh's 2.4.19 kernel - once it's up, that is.
> I will leave it running tonight to see what happens,
>
> HTH,
> Uli
I am starting to believe this as well. I'm going to see if I can get
some history on the machine from before it was shelved. As well, I
know there is a second machine, I'm going to see if I can swap this
one for that one and see if the same issues exist.
MikeMartin
^ permalink raw reply
* RE: CPU15 errata workaround for 8xx by WD
From: Joakim Tjernlund @ 2005-01-04 18:26 UTC (permalink / raw)
To: Wrobel Heinz-r39252, 'Wolfgang Denk'; +Cc: linuxppc-embedded
In-Reply-To: <DF02D66C37C26B4C8018BF84F0E37FEC3AB842@zwg18exm01.ea.freescale.net>
Hi Heinz
> Wolfgang, Joakim,
>
> > I have to admit that I didn't believe our customer when he
> > reported that he has problems that were caused by the CPU15
> > bug - I never saw this on any other 8xx processor before, and
> > as you say it has been mentioned in all errata sheets I
> > can remember. As far as I can tell it is only the MPC870/885
> > duet family of processors where this CPU15 bug actually
> > hits. I have no idea why.
>
> CPU15 is highly timing dependent. Even a single clock difference in the bus interface can make it (dis)appear.
> It can happen on Duet's as on any other 8xx ... or not.
Ahh, better not change any timing then on our boards :)
I have been running the cpu15 program from Wolfgang for 2 days now and no problem so far.
>
> The simple workaround of invalidating the prev/next page is exactly that. Simple. It works, but for code with page
> locality it can hurt performance because you would get excessive reloads. A smarter workaround affecting only pages that
> need the workaround is preferrable, if it fits into the MMU table framework.
Are it there any know timing patterns that won't show this bug?
>
> Heinz
Since you work at Freescale and appear to know 8xx I want to ask this:
Are there any plans on documenting/fixing the buggy cache insns. such dcbz, icbi etc. that
don't update the DAR register when causing a TLB Miss/Error?
I got this report from Motorola in May 2003:
We have generated the case of dcbx instruction and tlb miss
in verilog. We see that the DAR is not updated and the root couse is a
follows:
The load store treats dcbx instructions as a mtspr so it gets the tlb miss
error but does not update the DAR.
DAR is updated by two kind of errors
1) During the address phase.
2) During the data phase.
When there is a load store instruction the tlb miss error comes together
with the address phase. On dcbx instructions it comes one clock after the
address phase. So the DAR update mechanism does not update the DAR.
Jocke
^ permalink raw reply
* RE: CPU15 errata workaround for 8xx by WD
From: Wrobel Heinz-r39252 @ 2005-01-04 17:07 UTC (permalink / raw)
To: 'Wolfgang Denk', Joakim.Tjernlund; +Cc: linuxppc-embedded
Wolfgang, Joakim,
> I have to admit that I didn't believe our customer when he
> reported that he has problems that were caused by the CPU15
> bug - I never saw this on any other 8xx processor before, and
> as you say it has been mentioned in all errata sheets I
> can remember. As far as I can tell it is only the MPC870/885
> duet family of processors where this CPU15 bug actually
> hits. I have no idea why.
CPU15 is highly timing dependent. Even a single clock difference in the bus interface can make it (dis)appear.
It can happen on Duet's as on any other 8xx ... or not.
The simple workaround of invalidating the prev/next page is exactly that. Simple. It works, but for code with page locality it can hurt performance because you would get excessive reloads. A smarter workaround affecting only pages that need the workaround is preferrable, if it fits into the MMU table framework.
Heinz
^ permalink raw reply
* Re: 43p-140 install issues
From: Sven Luther @ 2005-01-04 22:28 UTC (permalink / raw)
To: Ulrich Teichert; +Cc: linuxppc-dev, mikemartin, debian-powerpc
In-Reply-To: <200501032211.j03MB7A1021340@arbas.nms.ulrich-teichert.org>
On Mon, Jan 03, 2005 at 11:11:06PM +0100, Ulrich Teichert wrote:
> Hi,
>
> >Delete the "console=tty0", so you end up with:
> >
> > Linux/PPC load: console=ttyS0,9600 root=/dev/ram
> >
> >and try again!
> [del]
>
> Right, then the installer knows what to do. I think this should go into
> the Debian installation docs, there are a lot of boxes with graphic cards
> out which are not supported by Linux.
Err, it should default to vga tedxt mode if the graphic card fbdev is not
builtin, at least it does it here.
> But the low level SCSI-driver is missing in this image, or any low level
> SCSI drivers for that matter. There are only the high level modules there,
> like sd_mod.ko and sr_mod.ko:
Sure, these should be loaded through the network. Try the
powerpc/cdrom/vmlinuz-prep.initrd for images with scsi modules included.
> Nov 30 00:06:32 hw-detect: Using discover version 1.
> Nov 30 00:06:35 hw-detect: Detecting hardware...
> Nov 30 00:06:36 hw-detect: Missing module 'sym53c8xx'.
> Nov 30 00:06:36 hw-detect: Missing module 'usb-storage'.
> Nov 30 00:06:36 hw-detect: Missing module 'ide-mod'.
> Nov 30 00:06:36 hw-detect: Missing module 'ide-probe-mod'.
> Nov 30 00:06:36 hw-detect: Missing module 'ide-detect'.
> Nov 30 00:06:36 hw-detect: Missing module 'ide-generic'.
> Nov 30 00:06:37 hw-detect: Missing module 'ide-floppy'.
> --More-- (57% of 44385 bytes) Nov 30 00:06:37 hw-detect: Missing module 'ide-disk'.
> Nov 30 00:06:37 hw-detect: Missing module 'isofs'.
> Nov 30 00:06:37 hw-detect: Loading modules...
> Nov 30 00:06:37 hw-detect: Detected module 'pcnet32' for 'Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE]'
> Nov 30 00:06:37 hw-detect: Trying to load module 'pcnet32'
> Nov 30 00:06:37 kernel: pcnet32.c:v1.30i 06.28.2004 tsbogend@alpha.franken.de
> Nov 30 00:06:37 kernel: PCI: Enabling device 0000:00:0c.0 (0000 -> 0003)
> Nov 30 00:06:37 kernel: pcnet32: PCnet/PCI II 79C970A at 0x1020, 00 06 29 2e 98 9d assigned IRQ 22.
> Nov 30 00:06:37 kernel: divert: allocating divert_blk for eth0
> Nov 30 00:06:37 kernel: eth0: registered as PCnet/PCI II 79C970A
> Nov 30 00:06:37 kernel: pcnet32: 1 cards_found.
> Nov 30 00:06:38 hw-detect: Detected module 'floppy' for 'Linux Floppy'
> Nov 30 00:06:38 hw-detect: Trying to load module 'floppy'
> Nov 30 00:06:38 kernel: inserting floppy driver for 2.6.8-powerpc
> Nov 30 00:06:38 kernel: Using anticipatory io scheduler
> Nov 30 00:06:38 kernel: Floppy drive(s): fd0 is 2.88M
> Nov 30 00:06:38 kernel: FDC 0 is a National Semiconductor PC87306
> Nov 30 00:06:38 hw-detect: Detected module 'ide-cd' for 'Linux ATAPI CD-ROM'
> Nov 30 00:06:38 hw-detect: Trying to load module 'ide-cd'
> Nov 30 00:06:39 kernel: Linux Kernel Card Services
> Nov 30 00:06:39 kernel: options: [pci] [cardbus] [pm]
> Nov 30 00:06:39 hw-detect: Starting PCMCIA services: using yenta_socket instead of i82365
> Nov 30 00:06:39 hw-detect: cardmgr[1070]: no sockets found!
> Nov 30 00:06:39 cardmgr[1070]: no sockets found!
> Nov 30 00:06:39 hw-detect: done.
> Nov 30 00:06:39 hw-detect: Detected discover version 1, installing discover1.
> Nov 30 00:06:39 hw-detect: Detected hotplug support, installing hotplug.
> Nov 30 00:06:40 hw-detect: Missing modules 'sym53c8xx (Symbios Logic Inc. / NCR 53c825), usb-storage (USB storage), ide-mod (Linux IDE driver), ide-probe-mod (Linux IDE probe driver), ide-detect (Linux IDE detection), ide-generic (Linux IDE support), ide-floppy (Linux IDE floppy), ide-disk (Linux ATA DISK), isofs (Linux ISO 9660 filesystem)
>
> /lib/modules/2.6.8-powerpc/kernel/drivers/scsi # ls
> scsi_mod.ko sd_mod.ko sr_mod.ko
>
> So, either this is the wrong image (I've taken the same as Daniel mentioned
> in one of his mails: http://debian.yorku.ca/debian/dists/testing/main/installer-powerpc/current/images/powerpc/netboot/vmlinuz-prep.initrd),
> or it's missing some vital modules.
Notice, the canonical address for the daily builds is :
http://people.debian.org/~luther/d-i/images/daily
Friendly,
Sven Luther
^ permalink raw reply
* Re: 43p-140 install issues
From: Leigh Brown @ 2005-01-04 22:39 UTC (permalink / raw)
To: Sven Luther; +Cc: Ulrich Teichert, linuxppc-dev, mikemartin, debian-powerpc
In-Reply-To: <20050104222854.GA30919@pegasos>
Sven Luther said:
> On Mon, Jan 03, 2005 at 11:11:06PM +0100, Ulrich Teichert wrote:
>> Hi,
>>
>> >Delete the "console=tty0", so you end up with:
>> >
>> > Linux/PPC load: console=ttyS0,9600 root=/dev/ram
>> >
>> >and try again!
>> [del]
>>
>> Right, then the installer knows what to do. I think this should go into
>> the Debian installation docs, there are a lot of boxes with graphic
>> cards
>> out which are not supported by Linux.
>
> Err, it should default to vga tedxt mode if the graphic card fbdev is not
> builtin, at least it does it here.
The PReP specs says that the cards should be initialised to a
minimum resolution of 640x480 iirc. The boot loader has code to
manually reprogram the card *back* into VGA text mode, but only
for a very limited number of cards. So, if your card is not
supported by fbdev, and isn't one of the very few supported
cards in the boot loader, it simply won't work under PReP.
[...]
Cheers,
Leigh.
^ permalink raw reply
* Cross-compiling for MPC82xx on an Apple G5
From: annamaya @ 2005-01-04 22:51 UTC (permalink / raw)
To: linuxppc-embedded
I was wondering if code cross-compiled on a G5 host
machine for the MPC82xx would actually run on the G5?
I see that the G5 is a 64-bit processor. Is that going
to be a problem?
The only reason I am asking about this is because some
packages create intermediate executables that are
executed during the latter stages of the build
process. I would like to cross-compile some readily
available packages that are not designed to be
cross-compiled easily. I remember doing something
similar to this on a Apple G4 a long time ago.
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
^ permalink raw reply
* realtime preemption patch on PPC
From: Tim Bird @ 2005-01-04 21:26 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
I sent the message below to LKML, but someone suggested to send it
to this list as well.
I'm planning on doing some work with Ingo's realtime preemption patch
on a PowerPC platform. I did some preliminary investigation of the
patch before Christmas, and am ready to do some serious work in the
next few weeks.
Has anyone else worked on this patch on PPC? Is anyone else interested
in working with me on it?
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
^ permalink raw reply
* Re: [PATCH 0/7] ppc: remove cli()/sti() from arch/ppc/*
From: Jim Nelson @ 2005-01-05 2:44 UTC (permalink / raw)
To: Brian Gerst; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <41DB4E99.3060200@didntduck.org>
Brian Gerst wrote:
> James Nelson wrote:
>
>> This series of patches is to remove the last cli()/sti() function
>> calls in arch/ppc.
>>
>> These are the only instances in active code that grep could find.
>
>
> Are you sure none of these need real spinlocks instead of just
> disabling interrupts?
>
> --
> Brian Gerst
>
These are for single-processor systems, mostly evaluation boards and
embedded processors. I coudn't find any reference to multiprocessor
setups for the processors in question after a peruse of the code or a
quick google on the boards in question.
Jim
^ permalink raw reply
* 440GP (Ebony) Eval Board documentation needed
From: Blair Aakre @ 2005-01-05 1:55 UTC (permalink / raw)
To: linuxppc-embedded
Help! I have a 440GP eval board without any kind of documentation. Does
anyone out there have some basic, getting-started information for this
board? A hardware reference manual would be ideal, as this thing has
lots of jumpers, debug connectors, etc.
Can anyone help me out?
-Blair
^ permalink raw reply
* Re: [PATCH 0/7] ppc: remove cli()/sti() from arch/ppc/*
From: Brian Gerst @ 2005-01-05 2:19 UTC (permalink / raw)
To: James Nelson; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20050104214048.21749.85722.89116@localhost.localdomain>
James Nelson wrote:
> This series of patches is to remove the last cli()/sti() function calls in arch/ppc.
>
> These are the only instances in active code that grep could find.
Are you sure none of these need real spinlocks instead of just disabling
interrupts?
--
Brian Gerst
^ permalink raw reply
* Re: 43p-140 install issues
From: Mike Martin @ 2005-01-05 4:36 UTC (permalink / raw)
To: Ulrich Teichert; +Cc: linuxppc-dev, debian-powerpc, Philippe Guyot
In-Reply-To: <855e88d005010407396309a9f9@mail.gmail.com>
On Tue, 4 Jan 2005 10:39:41 -0500, Mike Martin <sydneymartin@gmail.com> wrote:
> On Tue, 4 Jan 2005 16:23:50 +0100 (MET), Ulrich Teichert
> > Could you try to format them before dd'ing on them, like fdformat /dev/fd0h1440?
> > I am not sure if that will change anything, though.
>
> Will do.
Done - no difference. Same message. Written multiple images, multiple
times on multiple machine. Each one with the same result. At least I'm
not completely alone, I found this:
http://wikihip.cern.ch/twiki/bin/view/RS6000/KernelTestsOn43P240 exact
same error.
> >
> > I am begining to believe that there is some sort of hardware problem with your
> > box or it is an upgraded version which was a -140 in it's previous life, but my
> > -140 is rock solid with Leigh's 2.4.19 kernel - once it's up, that is.
> > I will leave it running tonight to see what happens,
> >
> > HTH,
> > Uli
>
> I am starting to believe this as well. I'm going to see if I can get
> some history on the machine from before it was shelved. As well, I
> know there is a second machine, I'm going to see if I can swap this
> one for that one and see if the same issues exist.
>
> MikeMartin
>
The machine was working fine under AIX when it was decomissioned. It
had some issues with a disk going bad due to heat (blocked vents). But
once they were cleared there were no issues. I am going to try the
other machine. I'll keep my finger's crossed.
MikeMartin
^ permalink raw reply
* Re: 440GP (Ebony) Eval Board documentation needed
From: Eugene Surovegin @ 2005-01-05 4:49 UTC (permalink / raw)
To: Blair Aakre; +Cc: linuxppc-embedded
In-Reply-To: <DFD6FD98-5EBC-11D9-889D-0030657E48E8@mac.com>
On Tue, Jan 04, 2005 at 07:55:28PM -0600, Blair Aakre wrote:
> Help! I have a 440GP eval board without any kind of documentation. Does
> anyone out there have some basic, getting-started information for this
> board? A hardware reference manual would be ideal, as this thing has
> lots of jumpers, debug connectors, etc.
>
Last time I checked AMCC web site had eval board docs.
--
Eugene
^ permalink raw reply
* Re: 43p-140 install issues
From: Ulrich Teichert @ 2005-01-05 8:07 UTC (permalink / raw)
To: mikemartin; +Cc: Ulrich Teichert, linuxppc-dev, debian-powerpc, Philippe Guyot
In-Reply-To: <855e88d005010420367a92617a@mail.gmail.com>
Hi,
[del]
>Done - no difference. Same message. Written multiple images, multiple
>times on multiple machine. Each one with the same result. At least I'm
>not completely alone, I found this:
>http://wikihip.cern.ch/twiki/bin/view/RS6000/KernelTestsOn43P240 exact
>same error.
Perhaps there are two different board revisions of -140's out? I'll check
what's written on the system board when I'm home again today.
>> > I am begining to believe that there is some sort of hardware problem with your
>> > box or it is an upgraded version which was a -140 in it's previous life, but my
>> > -140 is rock solid with Leigh's 2.4.19 kernel - once it's up, that is.
>> > I will leave it running tonight to see what happens,
[del]
Still running fine:
wehrle:~> uname -a
Linux wehrle 2.4.19 #3 Sun Aug 4 08:28:30 BST 2002 ppc unknown
wehrle:~> uptime
08:58:25 up 13:08, 1 user, load average: 0.00, 0.00, 0.00
I did a kernel compile with a parallel scp transfer as well to put the box
under a bit of load before, no issues.
HTH,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
Stormweg 24 |listening to: Suicide Drive (The Deep Eynde)
24539 Neumuenster, Germany|Public Pervert (Interpol) Clé De Contact (Metal Urbain)
^ permalink raw reply
* Re: 43p-140 install issues
From: Sven Luther @ 2005-01-05 9:03 UTC (permalink / raw)
To: Leigh Brown; +Cc: Ulrich Teichert, linuxppc-dev, mikemartin, debian-powerpc
In-Reply-To: <33151.82.10.231.190.1104878355.squirrel@82.10.231.190>
On Tue, Jan 04, 2005 at 10:39:15PM -0000, Leigh Brown wrote:
> Sven Luther said:
> > On Mon, Jan 03, 2005 at 11:11:06PM +0100, Ulrich Teichert wrote:
> >> Hi,
> >>
> >> >Delete the "console=tty0", so you end up with:
> >> >
> >> > Linux/PPC load: console=ttyS0,9600 root=/dev/ram
> >> >
> >> >and try again!
> >> [del]
> >>
> >> Right, then the installer knows what to do. I think this should go into
> >> the Debian installation docs, there are a lot of boxes with graphic
> >> cards
> >> out which are not supported by Linux.
> >
> > Err, it should default to vga tedxt mode if the graphic card fbdev is not
> > builtin, at least it does it here.
>
> The PReP specs says that the cards should be initialised to a
> minimum resolution of 640x480 iirc. The boot loader has code to
> manually reprogram the card *back* into VGA text mode, but only
> for a very limited number of cards. So, if your card is not
> supported by fbdev, and isn't one of the very few supported
> cards in the boot loader, it simply won't work under PReP.
Ah, ok ... Well i have a cirrus logic card also, and it seems to work. I have
anot yet tried the matrox cards though. Do they need to be special cards with
forth rom, or will any do ?
BTW, i have another question. I am trying to fix debian-installer to create
the prep partition, but i would like to have some info on the expected
constraints of said partition. Some tell it has to be entirely in the first
8MB, others the first 5MB, and my powerstack has a 17MB boot partition right
now.
I guess it is really not all that important what the size of the partition is,
it just needs to be first, and the kernel needs to fit in what the firmware
supports.
This goes for various prep boxes, but also for later IBM chrp machines,
including current pseries. It may be problematic, though if the size is too
small, as debian uses an initrd kernel, and altough the kernel itself is
rather small (around 1MB compressed), the current initrd generation method is
not all that fine-grained.
Ah, another thing. I am about to make a new kernel upload, which fixes the
powerstack II (utah) pci irq issue (backported from 2.6.10), but i hear about
problems with other systems, among them the popular 43p-140. Do you know of
any other patch that needs to be applied ? We use a 2.6.8 kernel as basis, so
the stuff will need to be backported, and i think i saw a bunch of prep fixes
in 2.6.9. What about the patches which enables prep-tool ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH 0/7] ppc: remove cli()/sti() from arch/ppc/*
From: Christoph Hellwig @ 2005-01-05 9:26 UTC (permalink / raw)
To: Jim Nelson; +Cc: linuxppc-dev, Brian Gerst, paulus, linux-kernel
In-Reply-To: <41DB5476.9040103@cwazy.co.uk>
On Tue, Jan 04, 2005 at 09:44:06PM -0500, Jim Nelson wrote:
> Brian Gerst wrote:
>
> >James Nelson wrote:
> >
> >>This series of patches is to remove the last cli()/sti() function
> >>calls in arch/ppc.
> >>
> >>These are the only instances in active code that grep could find.
> >
> >
> >Are you sure none of these need real spinlocks instead of just
> >disabling interrupts?
> >
> >--
> > Brian Gerst
> >
> These are for single-processor systems, mostly evaluation boards and
> embedded processors. I coudn't find any reference to multiprocessor
> setups for the processors in question after a peruse of the code or a
> quick google on the boards in question.
think CONFIG_PREEMPT. In either case a spinlock becomes
lock_irq_disable in the !SMP, !PREEMPT case but it documents the
intention a whole lot better.
Also you're locking only in a single plpace which is a ***BIG*** warning
sign. At least look at the other users of the data structure, it's
extremly likely they'll need locking aswell.
^ permalink raw reply
* Re: 43p-140 install issues
From: Philippe Guyot @ 2005-01-05 9:49 UTC (permalink / raw)
To: Sven Luther, Leigh Brown
Cc: Ulrich Teichert, linuxppc-dev, mikemartin, debian-powerpc
In-Reply-To: <20050105090318.GA12317@pegasos>
On Wednesday 05 January 2005 10:03, Sven Luther wrote:
> On Tue, Jan 04, 2005 at 10:39:15PM -0000, Leigh Brown wrote:
> > Sven Luther said:
> > > On Mon, Jan 03, 2005 at 11:11:06PM +0100, Ulrich Teichert wrote:
> > >> Hi,
> > >>
> > >> >Delete the "console=tty0", so you end up with:
> > >> >
> > >> > Linux/PPC load: console=ttyS0,9600 root=/dev/ram
> > >> >
> > >> >and try again!
> > >>
> > >> [del]
> > >>
> > >> Right, then the installer knows what to do. I think this should go
> > >> into the Debian installation docs, there are a lot of boxes with
> > >> graphic cards
> > >> out which are not supported by Linux.
> > >
> > > Err, it should default to vga tedxt mode if the graphic card fbdev is
> > > not builtin, at least it does it here.
> >
> > The PReP specs says that the cards should be initialised to a
> > minimum resolution of 640x480 iirc. The boot loader has code to
> > manually reprogram the card *back* into VGA text mode, but only
> > for a very limited number of cards. So, if your card is not
> > supported by fbdev, and isn't one of the very few supported
> > cards in the boot loader, it simply won't work under PReP.
>
> Ah, ok ... Well i have a cirrus logic card also, and it seems to work. I
> have anot yet tried the matrox cards though. Do they need to be special
> cards with forth rom, or will any do ?
Well, my box seems to have a matrox video card and I did the install with my
graphical console, not the tty.
>
> BTW, i have another question. I am trying to fix debian-installer to create
> the prep partition, but i would like to have some info on the expected
> constraints of said partition. Some tell it has to be entirely in the first
> 8MB, others the first 5MB, and my powerstack has a 17MB boot partition
> right now.
All I can say, it's that my boot PReP partition is the 1st and about 4 MB in
size (cannot size it less than 1% of the disk.....)
second partition is /
third is swap.
That works for me.
>
> I guess it is really not all that important what the size of the partition
> is, it just needs to be first, and the kernel needs to fit in what the
> firmware supports.
>
> This goes for various prep boxes, but also for later IBM chrp machines,
> including current pseries. It may be problematic, though if the size is too
> small, as debian uses an initrd kernel, and altough the kernel itself is
> rather small (around 1MB compressed), the current initrd generation method
> is not all that fine-grained.
>
> Ah, another thing. I am about to make a new kernel upload, which fixes the
> powerstack II (utah) pci irq issue (backported from 2.6.10), but i hear
> about problems with other systems, among them the popular 43p-140. Do you
> know of any other patch that needs to be applied ? We use a 2.6.8 kernel as
> basis, so the stuff will need to be backported, and i think i saw a bunch
> of prep fixes in 2.6.9. What about the patches which enables prep-tool ?
>
> Friendly,
>
> Sven Luther
^ permalink raw reply
* Re: 43p-140 install issues
From: Leigh Brown @ 2005-01-05 10:00 UTC (permalink / raw)
To: Philippe Guyot; +Cc: Ulrich Teichert, linuxppc-dev, mikemartin, debian-powerpc
In-Reply-To: <200501051049.19225.pguyot@cvf.fr>
Philippe Guyot said:
> On Wednesday 05 January 2005 10:03, Sven Luther wrote:
>> On Tue, Jan 04, 2005 at 10:39:15PM -0000, Leigh Brown wrote:
[...]
>> > The PReP specs says that the cards should be initialised to a
>> > minimum resolution of 640x480 iirc. The boot loader has code to
>> > manually reprogram the card *back* into VGA text mode, but only
>> > for a very limited number of cards. So, if your card is not
>> > supported by fbdev, and isn't one of the very few supported
>> > cards in the boot loader, it simply won't work under PReP.
>>
>> Ah, ok ... Well i have a cirrus logic card also, and it seems to work. I
>> have anot yet tried the matrox cards though. Do they need to be special
>> cards with forth rom, or will any do ?
>
> Well, my box seems to have a matrox video card and I did the install with
> my graphical console, not the tty.
[...]
That's because your Matrox card is fully supported by fbdev.
Cheers,
Leigh.
^ permalink raw reply
* Re: i2c on mpc5200
From: ivica @ 2005-01-05 10:29 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <41CD5E60.10404@246tNt.com>
Sylvain Munaut wrote:
>
> Are you sure it doesn't work ?
> On my system there are no I2C init message either, the driver is just
> not noisy ... (unless you activate all the I2C debug stuff).
Debug stuff didn't output any messages. Then I simply listed kernel
symbol table and grep for i2c. This is what I got.:
# cat proc/kallsyms |grep i2c
c00e4134 T i2c_device_probe
c00e413c T i2c_device_remove
c00e4144 t i2c_adapter_dev_release
c00e4168 t i2c_adapter_class_dev_release
c00e41bc t i2c_client_release
c00e4210 T i2c_add_adapter
c00e447c T i2c_del_adapter
c00e4758 T i2c_add_driver
c00e48a4 T i2c_del_driver
c00e4adc t __i2c_check_addr
c00e4b20 T i2c_check_addr
c00e4be8 T i2c_adapter_id
c00e4bf0 T i2c_attach_client
c00e4dec T i2c_detach_client
c00e4f48 t i2c_dec_use_client
c00e4f4c T i2c_use_client
c00e4f98 T i2c_release_client
c00e4ff8 T i2c_clients_command
c00e512c t i2c_device_match
c00e5134 t i2c_bus_suspend
c00e5194 t i2c_bus_resume
c00e51f4 T i2c_transfer
c00e5304 T i2c_master_send
c00e5438 T i2c_master_recv
c00e55b4 T i2c_control
c00e56a4 T i2c_get_adapter
c00e57a8 T i2c_put_adapter
c00e57dc T i2c_smbus_partial_pec
c00e5870 T i2c_smbus_pec
c00e58a4 T i2c_smbus_add_pec
c00e5994 T i2c_smbus_check_pec
c00e5ad0 T i2c_get_functionality
c00e5b10 T i2c_check_functionality
c00e5b4c T i2c_smbus_xfer
c00e6130 T i2c_smbus_read_i2c_block_data
c00e61b8 T i2c_smbus_block_process_call
c00e627c T i2c_smbus_write_block_data
c00e6304 T i2c_smbus_write_word_data
c00e6348 T i2c_smbus_read_word_data
c00e6398 T i2c_smbus_write_byte_data
c00e63dc T i2c_smbus_read_byte_data
c00e642c T i2c_smbus_write_byte
c00e646c T i2c_smbus_read_byte
c00e64bc T i2c_smbus_write_quick
c00e64e0 T i2c_probe
c00e6a2c T i2c_dev_get_by_minor
c00e6a40 T i2c_dev_get_by_adapter
c00e6a80 t return_i2c_dev
c00e6b0c t i2cdev_read
c00e6c20 t i2cdev_write
c00e6d30 T i2cdev_ioctl
c00e74e0 t i2cdev_open
c00e7580 t i2cdev_release
c00e75c8 t release_i2c_dev
c00e75ec t i2cdev_attach_adapter
c00e77b4 t i2cdev_detach_adapter
c00e7868 t i2cdev_detach_client
c00e7870 t i2cdev_commandc00e7878 T i2c_detect
c00e7d74 T i2c_which_vrm
c00e7da0 t mpc_i2c_isr
c00e7e20 t i2c_wait
c00e953c t i2c_start
c00e95e0 t i2c_repstart
c00e9790 t i2c_stop
c00e9904 t i2c_outb
c00ea71c T i2c_bit_add_bus
c00eace4 T i2c_bit_del_bus
c00ead04 t i2c_start
c00ead8c t i2c_repstart
c00eae14 t i2c_stop
c00eb608 T i2c_pcf_add_bus
c00eb8e8 T i2c_pcf_del_bus
c00ec1c4 T i2c_pca_add_bus
c00ec2e4 T i2c_pca_del_bus
c01569a0 t i2c_exit
c01569e0 t i2c_dev_exit
c0156a34 t mpc_i2c_remove
c01b7e20 t i2c_init
c01b7e7c t i2c_dev_init
c01b7f40 t mpc_i2c_probe
I think this proves i2c support is in the kernel. Right?
regards,
Ivica
^ permalink raw reply
* Re: 43p-140 install issues
From: Leigh Brown @ 2005-01-05 11:17 UTC (permalink / raw)
To: mikemartin; +Cc: Ulrich Teichert, linuxppc-dev, debian-powerpc, Philippe Guyot
In-Reply-To: <855e88d005010420367a92617a@mail.gmail.com>
Mike Martin said:
> On Tue, 4 Jan 2005 10:39:41 -0500, Mike Martin <sydneymartin@gmail.com>
> wrote:
>> On Tue, 4 Jan 2005 16:23:50 +0100 (MET), Ulrich Teichert
>> > Could you try to format them before dd'ing on them, like fdformat
>> /dev/fd0h1440?
>> > I am not sure if that will change anything, though.
>>
>> Will do.
>
> Done - no difference. Same message. Written multiple images, multiple
> times on multiple machine. Each one with the same result. At least I'm
> not completely alone, I found this:
> http://wikihip.cern.ch/twiki/bin/view/RS6000/KernelTestsOn43P240 exact
> same error.
I think I know what's going on here. What boot arguments are you using?
You should have "load_ramdisk=1" in there somewhere at the very least.
Cheers,
Leigh.
^ permalink raw reply
* Re: [PATCH 0/7] ppc: remove cli()/sti() from arch/ppc/*
From: Jim Nelson @ 2005-01-05 11:19 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Brian Gerst, paulus, linux-kernel
In-Reply-To: <20050105092659.GA27103@lst.de>
Christoph Hellwig wrote:
> On Tue, Jan 04, 2005 at 09:44:06PM -0500, Jim Nelson wrote:
>
>>Brian Gerst wrote:
>>
>>
>>>James Nelson wrote:
>>>
>>>
>>>>This series of patches is to remove the last cli()/sti() function
>>>>calls in arch/ppc.
>>>>
>>>>These are the only instances in active code that grep could find.
>>>
>>>
>>>Are you sure none of these need real spinlocks instead of just
>>>disabling interrupts?
>>>
>>>--
>>> Brian Gerst
>>>
>>
>>These are for single-processor systems, mostly evaluation boards and
>>embedded processors. I coudn't find any reference to multiprocessor
>>setups for the processors in question after a peruse of the code or a
>>quick google on the boards in question.
>
>
> think CONFIG_PREEMPT. In either case a spinlock becomes
> lock_irq_disable in the !SMP, !PREEMPT case but it documents the
> intention a whole lot better.
>
> Also you're locking only in a single plpace which is a ***BIG*** warning
> sign. At least look at the other users of the data structure, it's
> extremly likely they'll need locking aswell.
>
Some of the cli() uses were in shutdown and IRQ setup code, where you'd just need
to disable interrupts. There are a few files that will need a more thourough
going-through, however.
I'll start checking those later.
Jim
^ permalink raw reply
* Re: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Marc Dietrich @ 2005-01-05 11:33 UTC (permalink / raw)
To: sheutlin; +Cc: linuxppc-dev
In-Reply-To: <1104850036.6164.25.camel@weizen.left.earth>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
Hallo Sebastian,
Am Dienstag, 4. Januar 2005 15:47 schrieb Sebastian Heutling:
> Hello again Marc,
>
> > > >Can you put a working zImage.prep somewhere on the web (<1.44 MB, so I
> > > > can write it to a floppy disk)?
> > >
> (...)
> It is on: http://sengor.ath.cx/~sheutlin/prep/zImage.prep
hehe! It is booting!!!
Different to your setup, I get no timeouts here (boot.log is attached) - this
makes me wondering if there are different board revisions out there.
Another thing is, I tried to compile a stock 2.6.8 kernel with your config
from "/proc/config.gz" and the modified irq tables in prep_pci.c (I guess you
also did this modification). This kernel does not boot! It even doesn't show
the boot loader - it just hangs after finished loading the kernel from floppy
disk. Either a) I have a corrupt kernel tree, b) my compiler (gcc 3.3.4,
debian/sarge) has problems or c) you changed something else in your kernel.
I check a) and I think it is ok.
for b) I'm currently downloading the 3.3.5 compile from unstable debian (the
you you are using I guess), and will try it again.
c) how does you prep_pci.c looks like, any other changes?
I have to leave this machine alone tomorrow, so I won't be able to do any
testing further. From what we have now here, it seems that something is
broken for kernels >2.6.8. It would be nice, if someone can double check
this.
Best wishes
Marc
[-- Attachment #2: dmsg-2.6.8-Sebastian --]
[-- Type: text/plain, Size: 5552 bytes --]
Total memory = 128MB; using 256kB for hash table (at c0340000)
Linux version 2.6.8 (root@sengor) (gcc version 3.3.5 (Debian 1:3.3.5-5)) #10 Tue Jan 4 13:03:42 CET 2005
PReP architecture
On node 0 totalpages: 32768
DMA zone: 32768 pages, LIFO batch:8
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=/dev/sda3 console=tty0 video=clgen:mode:640x480
PID hash table entries: 1024 (order 10: 8192 bytes)
time_init: decrementer frequency = 16.657984 MHz
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 126208k available (1932k kernel code, 1060k data, 156k init, 0k highmem)
Calibrating delay loop... 398.33 BogoMIPS
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
NET: Registered protocol family 16
PCI: Probing PCI hardware
Setting PCI interrupts for a "Utah (Powerstack II Pro4000)"
PCI: Cannot allocate resource region 5 of device 0000:00:01.1
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
RAM (1024 kB) at 0xxc0000000, Cirrus Logic chipset on PCI bus
cirrusfb: Driver for Cirrus Logic based graphic boards, v2.0-pre2
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
cirrusfb: This board has 1048576 bytes of DRAM memory
cirrusfb: This board has 1048576 bytes of DRAM memory
Console: switching to colour frame buffer device 80x30
Macintosh non-volatile memory driver v1.1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
W82C105: IDE controller at PCI slot 0000:00:01.1
PCI: Enabling device 0000:00:01.1 (0000 -> 0001)
W82C105: chipset revision 5
W82C105: 100% native mode on irq 14
W82C105: dma_base is invalid (0x0000)
ide0: W82C105 Bus-Master DMA disabled (BIOS)
W82C105: dma_base is invalid (0x0000)
ide1: W82C105 Bus-Master DMA disabled (BIOS)
Probing IDE interface ide0...
Probing IDE interface ide1...
Probing IDE interface ide0...
Probing IDE interface ide1...
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
PCI: Enabling device 0000:00:02.0 (0000 -> 0003)
sym0: <825a> rev 0x13 at pci 0000:00:02.0 irq 15
sym0: No NVRAM, ID 7, Fast-10, SE, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18j
Using anticipatory io scheduler
Vendor: SEAGATE Model: ST34573W Rev: 5764
Type: Direct-Access ANSI SCSI revision: 02
sym0:1:0: tagged command queuing enabled, command queue depth 16.
scsi(0:0:1:0): Beginning Domain Validation
sym0:1: wide asynchronous.
sym0:1: FAST-10 WIDE SCSI 20.0 MB/s ST (100.0 ns, offset 8)
scsi(0:0:1:0): Domain Validation skipping write tests
scsi(0:0:1:0): Ending Domain Validation
Vendor: NEC Model: CD-ROM DRIVE:463 Rev: 1.05
Type: CD-ROM ANSI SCSI revision: 02
scsi(0:0:3:0): Beginning Domain Validation
sym0:3: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 8)
scsi(0:0:3:0): Domain Validation skipping write tests
scsi(0:0:3:0): Ending Domain Validation
st: Version 20040403, fixed bufsize 32768, s/g segs 256
SCSI device sda: 8888924 512-byte hdwr sectors (4551 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 1, lun 0, type 0
Attached scsi generic sg1 at scsi0, channel 0, id 3, lun 0, type 5
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 156k init 36k pmac 4k chrp 4k openfirmware
Adding 262252k swap on /dev/sda2. Priority:-1 extents:1
EXT3 FS on sda3, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
cirrusfb: This board has 1048576 bytes of DRAM memory
cirrusfb: This board has 1048576 bytes of DRAM memory
cirrusfb: This board has 1048576 bytes of DRAM memory
cirrusfb: This board has 1048576 bytes of DRAM memory
cirrusfb: This board has 1048576 bytes of DRAM memory
cirrusfb: This board has 1048576 bytes of DRAM memory
cirrusfb: This board has 1048576 bytes of DRAM memory
cirrusfb: This board has 1048576 bytes of DRAM memory
^ permalink raw reply
* Re: 43p-140 install issues
From: Sven Luther @ 2005-01-05 11:47 UTC (permalink / raw)
To: Philippe Guyot; +Cc: Ulrich Teichert, linuxppc-dev, debian-powerpc, mikemartin
In-Reply-To: <200501051049.19225.pguyot@cvf.fr>
On Wed, Jan 05, 2005 at 10:49:19AM +0100, Philippe Guyot wrote:
> > BTW, i have another question. I am trying to fix debian-installer to create
> > the prep partition, but i would like to have some info on the expected
> > constraints of said partition. Some tell it has to be entirely in the first
> > 8MB, others the first 5MB, and my powerstack has a 17MB boot partition
> > right now.
>
>
> All I can say, it's that my boot PReP partition is the 1st and about 4 MB in
> size (cannot size it less than 1% of the disk.....)
> second partition is /
> third is swap.
BTW, for debian, it makes more sense to have the second partition as swap, and
the third as /, i think, since it was decided some time back to default to
root=/dev/sda3, and not sda2.
> That works for me.
Until the kernel grows beyond 4MB.
Friendly,
Sven Luther
^ permalink raw reply
* watchdog vs inflate in zlib
From: Povolotsky, Alexander @ 2005-01-05 13:57 UTC (permalink / raw)
To: 'wd@denx.de', 'Tom Rini', 'Dan Malek'
Cc: linuxppc-embedded
Hi,
I got confirmation from my board "vendor" that:
"The watch dog is enabled by the boot monitor, so it must be handled by the
loader and by the kernel too."
At this point I do not know the watch dog's time out period.
The boot monitor is custom modified (by the board "vendor") pSOS bootloader
for which I do not have the code.
The compressed kernel image for Linux 2.6 is considerably larger than for
Linux 2.4 (which works fine) - perhaps I need to put more watch dog resets
into zlib code ... ? - Any advise on where to put those resets, etc. ?
Thanks,
Best Regards,
Alex
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Thursday, December 30, 2004 6:09 PM
To: Povolotsky, Alexander
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: inflate returned FFFFFFFD - what does this error exactly mean ?
Hi Alex,
in message
<313680C9A886D511A06000204840E1CF0A647439@whq-msgusr-02.pit.comms.marconi.co
m> you wrote:
>
> After few days of wondering through debugging (and with
> great help) I fixed (by inserting watch dog resets into
> beginning of while loops in zlib functions) my first problem > - strange
reboot failures during decompression of
You know why I recommended U-Boot :-)
> Now I am getting "controlled" failure (during the same
> decompression as described above):
>
> I_BAD
> return Z_DATA_ERROR
> after zlib_inflate
> inflate returned FFFFFFFD
> exit
>
> what does this error exactly mean ?
Most probably it means that the areas where the compressed image is stored
and to where you copy the uncompressed code to are over-lapping.
Try storing the compressed image at a higher address
(like 0x400000 or so).
Best regards,
Wolfgang Denk
-----Original Message-----
From: Nigel Cunningham [mailto:Nigel.Cunningham@cyclades.com]
Sent: Thursday, December 30, 2004 5:45 PM
To: Povolotsky, Alexander
Cc: linuxppc-embedded@ozlabs.org; linuxppc-embedded-bounces@ozlabs.org
Subject: Re: inflate returned FFFFFFFD - what does this error exactly mean ?
Hi.
linuxppc-embedded-bounces@ozlabs.org wrote on 31/12/2004 09:27:53:
> Hi,
>
> After few days of wondering through debugging (and with
> great help) I fixed (by inserting watch dog resets into
> beginning of while loops in zlib functions) my first
> problem -strange reboot failures during decompression of
> the kernel image by the bootloader.
> However my luck expired beyond this fix so far ... ;-).
> Now I am getting "controlled" failure (during the same
> decompression as described above):
>
> I_BAD
> return Z_DATA_ERROR
> after zlib_inflate
> inflate returned FFFFFFFD
> exit
>
> what does this error exactly mean ?
Going from include/linux/zlib.h, it is a data error: your compressed stream
has somehow been corrupted?
Regards,
Nigel
--
^ permalink raw reply
* Re: 43p-140 install issues
From: Philippe Guyot @ 2005-01-05 14:02 UTC (permalink / raw)
To: Sven Luther; +Cc: Ulrich Teichert, linuxppc-dev, debian-powerpc, mikemartin
In-Reply-To: <20050105114719.GB14332@pegasos>
On Wednesday 05 January 2005 12:47, Sven Luther wrote:
> On Wed, Jan 05, 2005 at 10:49:19AM +0100, Philippe Guyot wrote:
> > > BTW, i have another question. I am trying to fix debian-installer to
> > > create the prep partition, but i would like to have some info on the
> > > expected constraints of said partition. Some tell it has to be entirely
> > > in the first 8MB, others the first 5MB, and my powerstack has a 17MB
> > > boot partition right now.
> >
> > All I can say, it's that my boot PReP partition is the 1st and about 4 MB
> > in size (cannot size it less than 1% of the disk.....)
> > second partition is /
> > third is swap.
>
> BTW, for debian, it makes more sense to have the second partition as swap,
> and the third as /, i think, since it was decided some time back to default
> to root=/dev/sda3, and not sda2.
Yes, I did that on my two 150.
>
> > That works for me.
>
> Until the kernel grows beyond 4MB.
>
Friendly.
Felipe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox