* Any Patches for MPC 8270 ?
From: Bharath G - CTD , Chennai @ 2005-01-06 6:16 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
This is my fist mail to this mailing list. New year
greetings to all on the list.
I am working on a MPC8270 Based board with a montavista linux
kernel.Now i seem to have bumped into a lot of problems with this =
kernel.I
dont seem have support for USB-1.0 or I2C on the controller in this
distribution.=20
I was wondering where should i kick start my porting effort on a
2.4.X and a 2.6.x kernel, if anyone has any patches for the MPC8270 i =
would
be much obliged to use the same.=20
I am also using a PCI-USB 2.0 on my board.I have seen some nasty
problems in 2.4.X with a EPIA-M board on the USB 2.0 bus , are these =
issues
relevant in the PPC 2.4.X kernel ? I know that a backport has been done =
for
the 2.4.X kernel series, but still wanted to check with forum if anyone =
has
had any problems on the 2.4.X kernel with USB 2.0.
Any pointers on this would be really helpful,
Waiting for a reply,
Thanks in advance,
.Bharath.
Be warned that typing \fBkillall \fIname\fP may not have the desired
effect on non-Linux systems, especially when done by a privileged user.
-From the killall manual page.=20
DISCLAIMER=20
This message and any attachment(s) contained here are information that =
is confidential, proprietary to HCL Technologies=20
and its customers. Contents may be privileged or otherwise protected by =
law. The information is solely intended for the=20
individual or the entity it is addressed to. If you are not the intended =
recipient of this message, you are not authorized to=20
read, forward, print, retain, copy or disseminate this message or any =
part of it. If you have received this e-mail in error,=20
please notify the sender immediately by return e-mail and delete it from =
your computer
^ permalink raw reply
* Re: 43p-140 install issues
From: Mike Martin @ 2005-01-06 3:35 UTC (permalink / raw)
To: Ulrich Teichert; +Cc: linuxppc-dev, debian-powerpc, Philippe Guyot
In-Reply-To: <855e88d005010420367a92617a@mail.gmail.com>
> > > 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,
[snip]
> 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
An update (Sucess!!!):
After jogging some people's memory I found out that this machine has a
PCI token ring card (which I wasn't using) because the on-board
ethernet went flaky. This certainly helps explain my intermitent
network, and quite possibly the short up-times before crashing. As we
guessed - a hardware problem.
Is there any way (jumper ?) to disable the onboard ethernet? I may try
not loading the modules for it and see if the machine becomes stable.
Would a standard PCI ethernet card work as a substitute (likely won't
netboot)?
Now the success:
I put Leigh's boot floppy and the Woody root floppy (from
debian.yorku.ca mirror) into the second machine at noon today. By 1pm
I had a fully installed, configured and self-booting installation of
Woody on a 43p-140.
By 1:30 I had it re-pinned to "testing" and "dist-upgrad"ing. It was
finished and running great when I left work.
Since the machine is at work, I don't have much time to mess with it,
(since that's not my job!) but I will try in the next week to test
Sven's d-i disks on a second hard disk. It's the least I can do for
the help you've all given.
Thanks!
MikeMartin
^ permalink raw reply
* RE: simple bootloader 2.6.10-rc3 8xx
From: Povolotsky, Alexander @ 2005-01-06 0:53 UTC (permalink / raw)
To: 'Tom Rini'; +Cc: linuxppc-embedded
start_:
Interestingly, - as soon as I additionally defined CONFIG_FORCE in head.S
(after disabling MMU for my case
CONFIG_60POTS) to disable I-cache, my board would not
even get to the booting level (of inflating kernel in zlib, where it
currently fails ).
Then I tried to reverse the order: first disable I-cache, then disable MMU
(I just copied assembler code that was under
#ifdef CONFIG_FORCE to be under #if defined (CONFIG_V52) || defined
(CONFIG_60POTS) || defined (CONFIG_COMBO) but
above # disable MMU...) - but result again was the same... - so it looks
like that irregardless of the order this
combination does not work ... ?
....
start_:
#ifndef CONFIG_60POTS
#define CONFIG_60POTS 1
#endif
#if defined (CONFIG_V52) || defined (CONFIG_60POTS) || defined
(CONFIG_COMBO)
# disable MMU
sync
mfmsr r11
lis r10,0xffff
ori r10,r10,0xffcf
and r11,r11,r10
mtmsr r11
isync
lis r11,0xfa20
mtspr 638,r11
lwz r12,0x11c(r11)
lis r10,0xfeff
ori r10,r10,0xffff
and r12,r12,r10
stw r12,0x11c(r11)
#endif
#ifdef CONFIG_FORCE
/* We have some really bad firmware. We must disable the L1
* icache/dcache now or the board won't boot.
*/
li r4,0x0000
isync
mtspr HID0,r4
sync
isync
#endif
-----Original Message-----
From: Tom Rini [mailto:trini@kernel.crashing.org]
Sent: Wednesday, January 05, 2005 12:37 PM
To: Steven Rostedt
Cc: Povolotsky, Alexander; linuxppc-embedded@ozlabs.org
Subject: Re: simple bootloader 2.6.10-rc3 8xx
On Tue, Dec 28, 2004 at 12:47:57PM -0500, Steven Rostedt wrote:
> On Tue, 2004-12-28 at 12:28 -0500, Povolotsky, Alexander wrote:
> > Hi! (Thanks !)
> >
> > I guess I need some more education - since I am getting my problem right
at
> > the boot - is I-Cache enabled (by default ?) for 8xx on 2.6 at the
booting ? - I do not
> > see anything in .config
> > which controls it (or I am missing it there ?)
> > How (where and at what point during the boot)-) I could disable I-Cache
?
>
> Since you where able to get to the prekernel portion (that was
> relocated) I don't think you have a problem with caches, unless for some
> reason the pre-kernel can relocate itself, but it doesn't know to
> refresh the cache after relocating the actual kernel.
The in-kernel bootwrapper codes does indeed relocate itself (overlap
isn't a problem either, except for a small window. All of this can be
avoided if you link the kernel where it will be loaded into memory by
the firmware as well), but it should also do all needed cache flushing.
But as has been said before, since the CPU15 errata doesn't exist with
i-cache disabled, the simple workaround would be to disable the i-cache
as quickly as possible from the head.S portions of the in-kernel
bootwrapper and make sure we don't re-enable it later on (I _think_ we
do for speed reasons).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: 43p-140 install issues
From: Ulrich Teichert @ 2005-01-05 22:09 UTC (permalink / raw)
To: Ulrich Teichert; +Cc: linuxppc-dev, mikemartin, debian-powerpc
In-Reply-To: <200501050807.j0587L5J026680@arbas.nms.ulrich-teichert.org>
Hi,
the only reference number on my board is the IBM FRU number:
FRU 93H7143
I would expect that you will have the same marking on your mainboard.
My box ran all day with various loads from high to low or no load
at all:
wehrle:~> uptime
22:29:24 up 1 day, 2:39, 2 users, load average: 0.15, 0.32, 0.61
with Leigh's 2.4.19 kernel. As I searched for the number, I noticed
that the CPU fan was *covered* with dirt. Perhaps you should have
a look at yours too, because the front fan will pick up all dust and
throw it right on the CPU fan. I still wonder why mine was still
spinning....
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: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Marc Dietrich @ 2005-01-05 20:57 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
In-Reply-To: <20050105165551.GA29287@pegasos>
Hi all,
I didn't recognise that the kernel from Sebastian - which was working fine
here - was build from the debian sources (no hint in the kernel version).
So I build everything again from debian source and fixed the irq's in
prep_pci.c.
I can confirm now, that this debian+irq_fix kernel 2.6.8 runs fine and
produces no scsi timeouts!
Something happend in kernels >= 2.6.9 which makes the scsi unusable. Also it
seems, that even in 2.6.8 kernels and with ide hard disks (Sebastians setup)
the scsi controller timeouts, but continues to operate - correct?
That's all for now (and this year), because I have to leave this nice machine
alone and go home. Thanks to all who helped me - maybe see you next year
again...
Greetings
Marc
Am Mittwoch, 5. Januar 2005 17:55 schrieben Sie:
>
> (...)
>
> Also, apt-get install kernel-patch-debian-2.6.8 should give you the latest
> debian patch. No idea how it applies to the non-free pruned stuff though.
>
> > Do you have any idea, why a stock 2.6.8 kernel (with prep_pci.c patch)
> > doesn't boot a prep image?
>
> Either a missing patch or a wrong .config.
>
> I am personally much more interested in having the debian kernel working
> correctly though.
>
> Friendly,
>
> Sven Luther
^ permalink raw reply
* Re: Kernel 2.6.10 running on mpc8272ads
From: Dan Malek @ 2005-01-05 19:03 UTC (permalink / raw)
To: Tom Rini; +Cc: alebas, linuxppc-embedded
In-Reply-To: <20050105174838.GF4213@smtp.west.cox.net>
On Jan 5, 2005, at 12:48 PM, Tom Rini wrote:
> Indeed. While I had a PQ2FADS for a bit, I had to do that as well.
> Kumar, what/why is that needed exactly? Did I screw up in re-working
> the 82xx init stuff and it needs to happen a bit later in boot?
I don't understand the what/why question, but that has never stopped
me from providing answers in the past :-)
So, In 2.6, and I think in some of the 2.4 cpm2 stuff, we no longer
automatically map any of the hardware IO resources for common
access like I used to do in the past. If you want to access the
BCSR, you need to make sure it is ioremap()'ed in your driver before
you make the access. Was that the question, or was it that
the BCSR should have been set someplace outside of the
driver for the serial port to work?
-- Dan
^ permalink raw reply
* Re: MPC5200 - problem with CF card
From: Eugene Surovegin @ 2005-01-05 17:56 UTC (permalink / raw)
To: J?n Benediktsson; +Cc: linuxppc-embedded
In-Reply-To: <OF9A6BA55A.0E01CA7E-ON00256F80.0051303B-00256F80.0051795E@marel.is>
On Wed, Jan 05, 2005 at 02:49:42PM +0000, J?n Benediktsson wrote:
> > I am working with a custom MPC5200 board which uses the built-in
> > ATA/IDE controller for a compact flash card.
> > The Linux kernel is Denx linux_2_4_devel.
[snip]
> > mpc5xxx_ide: Setting up IDE interface ide0...
> > Probing IDE interface ide0...
> > hda: SanDisk SDCFBI-1024, ATA DISK drive
> > hdb: probing with STATUS(0x00) instead of ALTSTATUS(0x7f)
> > ide0: unexpected interrupt, status=0x00, count=1
I had similar problem with some CF cards (while other like in your
case worked fine).
Try disabling probing of the slave ide0 interface (hdb). I'm not
familiar with MPC5xxx, but most likely you can modify mpc5xxx_ide or
whatever code sets up access to your CF card.
Find where an instance of ide_hwif_t is initialized for ide0 and add
something like:
/* Don't probe second drive */
hwif->drives[1].noprobe = 1;
--
Eugene
^ permalink raw reply
* Re: Kernel 2.6.10 running on mpc8272ads
From: Tom Rini @ 2005-01-05 17:48 UTC (permalink / raw)
To: alebas, Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <1102585377.41b81e218d6df@webmail.televes.com:443>
On Thu, Dec 09, 2004 at 10:42:57AM +0100, alebas@televes.com wrote:
> Hi to all,
>
> Finally I got my mpc8272ads board running the 2.6.20-rc1 kernel.
> The trick was:
>
> First, I had to comment out the BCSR modification for second UART
> in m82xx_board_init function (arch/ppc/platforms/pq2ads.c). As
> suggested by Dan Malek, MMU is still off at this point.
Indeed. While I had a PQ2FADS for a bit, I had to do that as well.
Kumar, what/why is that needed exactly? Did I screw up in re-working
the 82xx init stuff and it needs to happen a bit later in boot?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: MPC8260 strange virtual addresses returned by kmalloc()
From: Eugene Surovegin @ 2005-01-05 17:41 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000001c4f32b$cfe37470$5201a8c0@GEG2400>
On Wed, Jan 05, 2005 at 02:38:12PM +0100, Laurent Lagrange wrote:
> Hi and Happy New Year to all,
>
> I use a Linux 2.4.25 kernel on a MPC8260 custom board with 128MB of RAM.
> PCI is activated and my drivers are loaded as modules.
> The RAM is mapped at 0xC0000000 as usual.
>
> On MPC8XX I used kmalloc and iopa to get the physical addresses of the
> allocated buffers.
> On MPC82XX I used kmalloc and __pa for the same thing and it worked fine
> with previous kernel.
>
> But now, when I want to use kmalloc, I get addresses like 0xC9xxxxxx.
> The __pa gives me physical addresses 0x09xxxxxx which are out of my physical
> RAM.
> I tried old iopa function and got some real physical addresses and the
> module works.
> The virt_to_bus gives me too addresses like 0x09xxxxxx
> (ie substract kernel base address 0xC0000000 as usual).
>
> I don't understand why I get virtual addresses which seem to be out of my
> memory and why it runs.
Yeah, this looks strange, please, check that this address is really
from kmalloc and not from vmalloc.
Also, check that PAGE_OFFSET is really 0xc000'0000.
> More, I have a global variable which is a little buffer. It is also mapped
> at a 0xC9xxxxxx address.
Is this global variable in the loaded module? If yes, this is normal,
because modules are loaded into vmalloced space and you cannot use
__pa for such addresses.
--
Eugene
^ permalink raw reply
* Re: simple bootloader 2.6.10-rc3 8xx
From: Tom Rini @ 2005-01-05 17:36 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Povolotsky, Alexander, linuxppc-embedded
In-Reply-To: <1104256077.20042.125.camel@localhost.localdomain>
On Tue, Dec 28, 2004 at 12:47:57PM -0500, Steven Rostedt wrote:
> On Tue, 2004-12-28 at 12:28 -0500, Povolotsky, Alexander wrote:
> > Hi! (Thanks !)
> >
> > I guess I need some more education - since I am getting my problem right at
> > the boot - is
> > I-Cache enabled (by default ?) for 8xx on 2.6 at the booting ? - I do not
> > see anything in .config
> > which controls it (or I am missing it there ?)
> > How (where and at what point during the boot)-) I could disable I-Cache ?
>
> Since you where able to get to the prekernel portion (that was
> relocated) I don't think you have a problem with caches, unless for some
> reason the pre-kernel can relocate itself, but it doesn't know to
> refresh the cache after relocating the actual kernel.
The in-kernel bootwrapper codes does indeed relocate itself (overlap
isn't a problem either, except for a small window. All of this can be
avoided if you link the kernel where it will be loaded into memory by
the firmware as well), but it should also do all needed cache flushing.
But as has been said before, since the CPU15 errata doesn't exist with
i-cache disabled, the simple workaround would be to disable the i-cache
as quickly as possible from the head.S portions of the in-kernel
bootwrapper and make sure we don't re-enable it later on (I _think_ we
do for speed reasons).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Sven Luther @ 2005-01-05 17:39 UTC (permalink / raw)
To: Christian; +Cc: linuxppc-dev
In-Reply-To: <41DC1F7E.5030003@gmx.net>
On Wed, Jan 05, 2005 at 06:10:22PM +0100, Christian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
> >>
>
> yes, it's booting, but i get timeouts here on my PReP (however Marc says,
> that he does not get errors). would you be so kind and publish the .config
> too?
>
> > Did you try :
> >
> > http://people.debian.org/~luther/prep/d-i-2005.01.03-prep
> >
>
> and Sven: nice d-i, really. but i couldn't see any config for this kernel
> either. it would be nice if you could put the config somewhere too.
It is the standard powerpc debian kernel. apt-get install
kernel-image-2.6.8-powerpc, and you will find the config in
/boot/config-2.6.8-powerpc. All the rest of the stuff can be found in the
debian kernel svn repo :
http://svn.debian.org/wsvn/kernel/trunk/kernel/
> mine are here, now with SCSI enabled too and thus errors showing up:
>
> http://www.nerdbynature.de/bits/hal/daily/configs/config-ppc-2.6.10
> http://www.nerdbynature.de/bits/hal/daily/boot/dmesg-2.6.10
>
> (but network is fine now ;-))
Well, i am really interested to know if the above debian kernel boots for you
or not. And to find the patches that fix it if it doesn't.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Christian @ 2005-01-05 17:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20050105154753.GA26760@pegasos>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
>>
yes, it's booting, but i get timeouts here on my PReP (however Marc says,
that he does not get errors). would you be so kind and publish the .config
too?
> Did you try :
>
> http://people.debian.org/~luther/prep/d-i-2005.01.03-prep
>
and Sven: nice d-i, really. but i couldn't see any config for this kernel
either. it would be nice if you could put the config somewhere too.
mine are here, now with SCSI enabled too and thus errors showing up:
http://www.nerdbynature.de/bits/hal/daily/configs/config-ppc-2.6.10
http://www.nerdbynature.de/bits/hal/daily/boot/dmesg-2.6.10
(but network is fine now ;-))
thank you both,
Chrisitian.
- --
BOFH excuse #305:
IRQ-problems with the Un-Interruptible-Power-Supply
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB3B9+C/PVm5+NVoYRAmjiAJ4hrZAtauVVUjR6cWj+7l70+4X+lgCg/RlD
rPCFIAeCt5eiGxTYplSDONk=
=9pzA
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: 43p-140 install issues
From: Hollis Blanchard @ 2005-01-05 16:52 UTC (permalink / raw)
To: Philippe Guyot; +Cc: Ulrich Teichert, linuxppc-dev, mikemartin, debian-powerpc
In-Reply-To: <200501051718.19198.pguyot@cvf.fr>
On Jan 5, 2005, at 10:18 AM, Philippe Guyot wrote:
> On Wednesday 05 January 2005 17:08, Sven Luther wrote:
>> On Wed, Jan 05, 2005 at 09:45:13AM -0600, Hollis Blanchard wrote:
>>>
>>> The size of that partition depends on firmware limitations. I have
>>> definitely seen reports of systems not booting when the PReP boot
>>> partition was too large. I think on some systems that has even
>>> happened
>>> at 8MB.
>>
>> Is the problem really the size of the partition, or the space used by
>> the
>> kernel. I mean we could make a 100MB partition at start, and since we
>> just
>> dd the kernel to it, the kernel would be found at the start of the
>> partition, and the firmware probably doesn't care about the real size
>> of
>> the partition, as long as it can access all the kernel data we dded
>> to it,
>> no ?
>
> I agree, see the IEEE P1275 on solinno's site. OF determines the load
> image
> length and transfers only that. I was able to verify that by dumping
> storage
> after a "load" when debugging boot process.
Are you specifically talking about booting from a PReP partition and
not a floppy disk or netboot? Did you dump the bytes from the disk just
after the kernel and see if they were also present in memory?
I have no doubt that OF will correctly load an ELF file, but a PReP
boot partition does not contain an ELF file.
>> Do we have some documentation of the firmware limitations ?
>
> Yes, on solinnos's site.
That page (http://www.solinno.co.uk/7043-140/getstarted.php) doesn't
mention any restrictions on the size of the PReP boot partition, so
it's clearly not a complete list. :)
-Hollis
^ permalink raw reply
* Re: 43p-140 install issues
From: Sven Luther @ 2005-01-05 17:00 UTC (permalink / raw)
To: Leigh Brown
Cc: Ulrich Teichert, Philippe Guyot, linuxppc-dev, debian-powerpc,
mikemartin
In-Reply-To: <25607.195.212.29.91.1104942605.squirrel@195.212.29.91>
On Wed, Jan 05, 2005 at 04:30:05PM -0000, Leigh Brown wrote:
> Sven Luther said:
> > On Wed, Jan 05, 2005 at 09:45:13AM -0600, Hollis Blanchard wrote:
> >> On Jan 5, 2005, at 5:47 AM, 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.
> >> >
> >> >>That works for me.
> >> >
> >> >Until the kernel grows beyond 4MB.
> >>
> >> The size of that partition depends on firmware limitations. I have
> >> definitely seen reports of systems not booting when the PReP boot
> >> partition was too large. I think on some systems that has even happened
> >> at 8MB.
> >
> > Is the problem really the size of the partition, or the space used by
> > the kernel. I mean we could make a 100MB partition at start, and since
> > we just dd the kernel to it, the kernel would be found at the start of
> > the partition, and the firmware probably doesn't care about the real
> > size of the partition, as long as it can access all the kernel data we
> > added to it, no ?
> >
> > Do we have some documentation of the firmware limitations ?
> >
> >> In other words, should you need more space than 4-5MB at some point in
> >> the future, you cannot simply make a bigger boot partition.
> >
> > 8MB would be good, 4-5MB only would probably be a bit just.
>
> Surely if you make the default mkinitrd behaviour a bit more sensible
> there won't be a problem. A compressed 2.6 kernel is about 1.5MB, and
The compressed kernel should be arounf 1.0MB only.
> an initrd using MODULES=dep is about 1.5MB, which makes about 3MB,
> giving a comfortable amount of space for future growth...
well, when i use MODULES=dep, i still get all the filesystem and a bunch of
extra ide drivers, so it is no less than 4MB. Mmm, you are right about this
one, it is only 1499136 now, which makes a total of 2856844, quite reasonable.
Mmm, i wonder it may even boot on the pegasos 1 with the broken OF now.
Still, partman-prep is currently written to make sure the prep partition is in
the first 8MB.
Friendly,
Sven Luther
^ permalink raw reply
* Re: 43p-140 install issues
From: Leigh Brown @ 2005-01-05 16:30 UTC (permalink / raw)
To: Sven Luther
Cc: Ulrich Teichert, Philippe Guyot, linuxppc-dev, debian-powerpc,
mikemartin
In-Reply-To: <20050105160816.GA28046@pegasos>
Sven Luther said:
> On Wed, Jan 05, 2005 at 09:45:13AM -0600, Hollis Blanchard wrote:
>> On Jan 5, 2005, at 5:47 AM, 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.
>> >
>> >>That works for me.
>> >
>> >Until the kernel grows beyond 4MB.
>>
>> The size of that partition depends on firmware limitations. I have
>> definitely seen reports of systems not booting when the PReP boot
>> partition was too large. I think on some systems that has even happened
>> at 8MB.
>
> Is the problem really the size of the partition, or the space used by
> the kernel. I mean we could make a 100MB partition at start, and since
> we just dd the kernel to it, the kernel would be found at the start of
> the partition, and the firmware probably doesn't care about the real
> size of the partition, as long as it can access all the kernel data we
> added to it, no ?
>
> Do we have some documentation of the firmware limitations ?
>
>> In other words, should you need more space than 4-5MB at some point in
>> the future, you cannot simply make a bigger boot partition.
>
> 8MB would be good, 4-5MB only would probably be a bit just.
Surely if you make the default mkinitrd behaviour a bit more sensible
there won't be a problem. A compressed 2.6 kernel is about 1.5MB, and
an initrd using MODULES=dep is about 1.5MB, which makes about 3MB,
giving a comfortable amount of space for future growth...
Cheers,
Leigh.
^ permalink raw reply
* Re: 43p-140 install issues
From: Philippe Guyot @ 2005-01-05 16:18 UTC (permalink / raw)
To: Sven Luther, Hollis Blanchard
Cc: Ulrich Teichert, linuxppc-dev, mikemartin, debian-powerpc
In-Reply-To: <20050105160816.GA28046@pegasos>
On Wednesday 05 January 2005 17:08, Sven Luther wrote:
> On Wed, Jan 05, 2005 at 09:45:13AM -0600, Hollis Blanchard wrote:
> > On Jan 5, 2005, at 5:47 AM, 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.
> > >
> > >>That works for me.
> > >
> > >Until the kernel grows beyond 4MB.
> >
> > The size of that partition depends on firmware limitations. I have
> > definitely seen reports of systems not booting when the PReP boot
> > partition was too large. I think on some systems that has even happened
> > at 8MB.
>
> Is the problem really the size of the partition, or the space used by the
> kernel. I mean we could make a 100MB partition at start, and since we just
> dd the kernel to it, the kernel would be found at the start of the
> partition, and the firmware probably doesn't care about the real size of
> the partition, as long as it can access all the kernel data we dded to it,
> no ?
I agree, see the IEEE P1275 on solinno's site. OF determines the load image
length and transfers only that. I was able to verify that by dumping storage
after a "load" when debugging boot process.
>
> Do we have some documentation of the firmware limitations ?
Yes, on solinnos's site.
>
> > In other words, should you need more space than 4-5MB at some point in
> > the future, you cannot simply make a bigger boot partition.
>
> 8MB would be good, 4-5MB only would probably be a bit just.
>
Clear.
Friendly.
Felipe
^ permalink raw reply
* Re: 43p-140 install issues
From: Sven Luther @ 2005-01-05 16:08 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Ulrich Teichert, Philippe Guyot, linuxppc-dev, debian-powerpc,
mikemartin
In-Reply-To: <C9ACD772-5F30-11D9-A2C3-000A95A0560C@penguinppc.org>
On Wed, Jan 05, 2005 at 09:45:13AM -0600, Hollis Blanchard wrote:
> On Jan 5, 2005, at 5:47 AM, 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.
> >
> >>That works for me.
> >
> >Until the kernel grows beyond 4MB.
>
> The size of that partition depends on firmware limitations. I have
> definitely seen reports of systems not booting when the PReP boot
> partition was too large. I think on some systems that has even happened
> at 8MB.
Is the problem really the size of the partition, or the space used by the
kernel. I mean we could make a 100MB partition at start, and since we just dd
the kernel to it, the kernel would be found at the start of the partition, and
the firmware probably doesn't care about the real size of the partition, as
long as it can access all the kernel data we dded to it, no ?
Do we have some documentation of the firmware limitations ?
> In other words, should you need more space than 4-5MB at some point in
> the future, you cannot simply make a bigger boot partition.
8MB would be good, 4-5MB only would probably be a bit just.
Friendly,
Sven Luther
^ permalink raw reply
* Re: 43p-140 install issues
From: Hollis Blanchard @ 2005-01-05 15:45 UTC (permalink / raw)
To: Sven Luther
Cc: Ulrich Teichert, linuxppc-dev, mikemartin, debian-powerpc,
Philippe Guyot
In-Reply-To: <20050105114719.GB14332@pegasos>
On Jan 5, 2005, at 5:47 AM, 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.
>
>> That works for me.
>
> Until the kernel grows beyond 4MB.
The size of that partition depends on firmware limitations. I have
definitely seen reports of systems not booting when the PReP boot
partition was too large. I think on some systems that has even happened
at 8MB.
In other words, should you need more space than 4-5MB at some point in
the future, you cannot simply make a bigger boot partition.
-Hollis
^ permalink raw reply
* Re: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Sven Luther @ 2005-01-05 15:47 UTC (permalink / raw)
To: Marc Dietrich; +Cc: linuxppc-dev
In-Reply-To: <200501051233.25622.marvin24@gmx.de>
On Wed, Jan 05, 2005 at 12:33:25PM +0100, Marc Dietrich wrote:
>
> 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.
Did you try :
http://people.debian.org/~luther/prep/d-i-2005.01.03-prep
It is the debian kernel with the prep_pci patch, and the debian-installer
(yesterdays or so daily-built) initrd on top of it. I simply boot it from
netboot with :
boot enet:192.168.1.10,d-i-2005.01.03-prep,192.168.1.17
(where .10 is my tftp server, and .17 a random free address on the subnet).
And it works fine. I plan to do a kernel upload soonishly to fix those issues
in debian, but i would like to have also the fixes for the other prep systems
if needed.
Friendly,
Sven Luther
^ permalink raw reply
* Re: watchdog vs inflate in zlib
From: Wolfgang Denk @ 2005-01-05 15:32 UTC (permalink / raw)
To: Povolotsky, Alexander; +Cc: linuxppc-embedded
In-Reply-To: <313680C9A886D511A06000204840E1CF0A64744E@whq-msgusr-02.pit.comms.marconi.com>
In message <313680C9A886D511A06000204840E1CF0A64744E@whq-msgusr-02.pit.comms.marconi.com> you wrote:
>
> 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. ?
Have a look at the U-Boot code ...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"There are things that are so serious that you can only joke about
them" - Heisenberg
^ permalink raw reply
* RE: watchdog vs inflate in zlib
From: Povolotsky, Alexander @ 2005-01-05 15:28 UTC (permalink / raw)
To: 'wd@denx.de', 'Tom Rini', 'Dan Malek'
Cc: 'linuxppc-embedded@ozlabs.org'
I just have found while searching the web the old Linux 2.4 posting by Jan
Roelens ... and
I am experiencing (but on newer Linux 2.6) exactly the same problem (on PPC
880) as he has mentioned:
> the linux statup code encounters
> a watchdog timeout (and thus a reset), somewhere when it is decompressing
> the ramdisk image.
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."
Also I just got addional info from my "vendor" that: "The timeout period
of the watchdog is 800msec."
The "vendor" also suggested that "to be sure", the watchdog should be reset
each 100msec ...
The boot monitor used 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 with several watch dog reset calls put into
"while" loops within zlib decompression functions) - perhaps I need to put
more watch dog resets into zlib code ... ? - Any advise on where to put
those extra resets, etc. ?
Could I use the fix, posted - see below - by Jan Rowlens - have anyone tried
it on Linux 2.6 ?
What are suggested modifications I need to do to bring this fix to 2.6 ?
Thanks,
Best Regards,
I will Highly Appreciate replies,
Alex
********************************************************
FROM: Jan Roelens
DATE: 07/26/2001 11:06:54
SUBJECT: RE: [Ppcboot-users] Can we use watchdog timer with Linux?
The following code changes to the kernel work:
arch/ppc/kernel/m8xx-setup.c:
+/* added this function, called from arch/ppc/kernel/time.c*/
+void m8xx_reset_watchdog(void)
+{
+ ((volatile immap_t *)IMAP_ADDR)->im_siu_conf.sc_swsr = 0x556c;
+ ((volatile immap_t *)IMAP_ADDR)->im_siu_conf.sc_swsr = 0xaa39;
+}
in m8xx_init():
ppc_md.time_init = NULL;
ppc_md.set_rtc_time = m8xx_set_rtc_time;
ppc_md.get_rtc_time = m8xx_get_rtc_time;
ppc_md.calibrate_decr = m8xx_calibrate_decr;
+ ppc_md.reset_watchdog = m8xx_reset_watchdog;
arch/ppc/kernel/time.c:
+unsigned long sched_watchdog_counter = 0;
void timer_interrupt(struct pt_regs * regs)
{
int dval, d;
unsigned long cpu = smp_processor_id();
.
.
.
+ if ((++sched_watchdog_counter&0x3F)==0) /*every 640msec */
+ ppc_md.reset_watchdog();
hardirq_exit(cpu);
}
in include/asm-ppc/machdep.h:
struct machdep_calls {
void (*setup_arch)(unsigned long * memory_start_p,
unsigned long * memory_end_p);
/* Optional, may be NULL. */
int (*setup_residual)(char *buffer);
/* Optional, may be NULL. */
int (*get_cpuinfo)(char *buffer);
/* Optional, may be NULL. */
unsigned int (*irq_cannonicalize)(unsigned int irq);
void (*init_IRQ)(void);
void (*do_IRQ)(struct pt_regs *regs, int cpu, int
isfake);
/* A general init function, called by ppc_init in init/main.c.
May be NULL. */
void (*init)(void);
void (*restart)(char *cmd);
void (*power_off)(void);
void (*halt)(void);
void (*time_init)(void); /* Optional, may be NULL */
int (*set_rtc_time)(unsigned long nowtime);
unsigned long (*get_rtc_time)(void);
void (*calibrate_decr)(void);
+ void (*reset_watchdog)(void);
************************************************************************
Jan Roelens wrote:
> Hi,
>
> I'm using ppcboot-1.0.1 on a board with an MPC860.
>
> I'm loading and running Linux-2.2.14.
>
> This works fine if ppcboot disables the watchdog timer of the 860.
>
> If ppcboot enables the watchdog timer, the linux statup code encounters
> a watchdog timeout (and thus a reset), somewhere when it is decompressing
> the ramdisk image.
>
> The watchdog timeout is set to its maximum : with a 50MHz clock and a
> 2048 prescaler and a SWTC of 0xFFFF, that's a timeout of about 2.68
seconds.
>
> Can we use the watchdog timer with Linux?
>
> Thanks,
>
> --
> Jan Roelens
> <EMAIL: PROTECTED>
>
> _______________________________________________
> Ppcboot-users mailing list
> <EMAIL: PROTECTED>
> http://lists.sourceforge.net/lists/listinfo/ppcboot-users
--
Jan Roelens
-----Original Message-----
From: Povolotsky, Alexander
Sent: Wednesday, January 05, 2005 8:58 AM
To: 'wd@denx.de'; 'Tom Rini'; 'Dan Malek'
Cc: linuxppc-embedded@ozlabs.org
Subject: watchdog vs inflate in zlib
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: MPC5200 - problem with CF card
From: Jón Benediktsson @ 2005-01-05 14:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OFE3F13085.168CF615-ON00256F80.003C6775-00256F80.004A9C3D@marel.is>
Whoops, sorry for the HTML. I forgot to change my e-mail options.
Here comes the plain text:
> Hi=20
>=20
> I am working with a custom MPC5200 board which uses the built-in=20
> ATA/IDE controller for a compact flash card.=20
> The Linux kernel is Denx linux=5F2=5F4=5Fdevel.=20
>=20
> I have been using an old SanDisk 16MB CF card which works fine.=20
> Here is the console output with this card plugged in:=20
>=20
> U-Boot 1.1.2 (Dec 2 2004 - 16:01:06)=20
>=20
> CPU: MPC5200 v1.2 at 396 MHz=20
> Bus 132 MHz, IPB 66 MHz, PCI 33 MHz=20
> Board: Marel NS4=20
> I2C: 85 kHz, ready=20
> DRAM: 128 MB=20
> FLASH: 16 MB=20
> In: serial=20
> Out: serial=20
> Err: serial=20
> Net: FEC ETHERNET=20
> IDE: Bus 0: OK=20
> Device 0: Model: SanDisk SDCFB-16 Firm: vde 1.10 Ser#: 24349220714=20
> Type: Removable Hard Disk=20
> Capacity: 15.3 MB =3D 0.0 GB (31360 x 512)=20
>=20
> Type "run flash=5Fnfs" to mount root filesystem over NFS=20
>=20
> Hit any key to stop autoboot: 0=20
> Using FEC ETHERNET device=20
> TFTP from server 10.100.1.30; our IP address is 10.100.50.68=20
> Filename 'mpc5200/uImage'.=20
> Load address: 0x200000=20
> Loading:=20
#################################################################=20
> #################################################################=20
> #############################=20
> done=20
> Bytes transferred =3D 810417 (c5db1 hex)=20
> ## Booting image at 00200000 ...=20
> Image Name: Linux-2.4.25=20
> Created: 2004-12-03 11:35:18 UTC=20
> Image Type: PowerPC Linux Kernel Image (gzip compressed)=20
> Data Size: 810353 Bytes =3D 791.4 kB=20
> Load Address: 00000000=20
> Entry Point: 00000000=20
> Verifying Checksum ... OK=20
> Uncompressing Kernel Image ... OK=20
> Memory BAT mapping: BAT2=3D128Mb, BAT3=3D0Mb, residual: 0Mb=20
> Linux version 2.4.25 (jonb@tux.marel.is) (gcc version 3.2.2 20030217
> (Yellow Dog=20
> Linux 3.0 3.2.2-2a=5F1)) #4 F=F6s Des 3 11:34:35 UTC 2004=20
> On node 0 totalpages: 32768=20
> zone(0): 32768 pages.=20
> zone(1): 0 pages.=20
> zone(2): 0 pages.=20
> Kernel command line: root=3D/dev/nfs rw nfsroot=3D10.100.1.30:
> /opt/eldk/ppc=5F82xx ip=3D=20
> 10.100.50.68:10.100.1.30:10.100.254.254:255.255.0.0:ns4b:eth0:off=20
panic=3D1=20
> Calibrating delay loop... 263.78 BogoMIPS=20
> Memory: 127080k available (1396k kernel code, 464k data, 76k init, 0k=20
highmem)
> Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)=20
> Inode cache hash table entries: 8192 (order: 4, 65536 bytes)=20
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)=20
> Buffer cache hash table entries: 8192 (order: 3, 32768 bytes)=20
> Page-cache hash table entries: 32768 (order: 5, 131072 bytes)=20
> POSIX conformance testing by UNIFIX=20
> PCI: Probing PCI hardware=20
> Linux NET4.0 for Linux 2.4=20
> Based upon Swansea University Computer Society NET3.039=20
> Initializing RT netlink socket=20
> Starting kswapd=20
> Journalled Block Device driver loaded=20
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.=20
> i2c-core.o: i2c core module version 2.6.1 (20010830)=20
> i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)=20
> pty: 256 Unix98 ptys configured=20
> ttyS0 on PSC1=20
> ttyS1 on PSC2=20
> ttyS2 on PSC3=20
> PCF8563 Real-Time Clock Driver $Revision: 1.3 $ wd@denx.de=20
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize=20
> loop: loaded (max 8 devices)=20
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4=20
> ide: Assuming 33MHz system bus speed for PIO modes; override with=20
idebus=3Dxx=20
> Port Config is: 0x91050404=20
> ipb=3D66MHz, set clock period to 15=20
> GPIO config: 91050404=20
> ATA invalid: 00800000=20
> ATA hostcnf: 03000000=20
> ATA pio1 : 100a0a00=20
> ATA pio2 : 02040600=20
> XLB Arb cnf: 80002006=20
> mpc5xxx=5Fide: Setting up IDE interface ide0...=20
> Probing IDE interface ide0...=20
> hda: SanDisk SDCFB-16, CFA DISK drive=20
> ide0 at 0xf0003a60-0xf0003a67,0xf0003a5c on irq 45=20
> hda: attached ide-disk driver.=20
> hda: 31360 sectors (16 MB) w/1KiB Cache, CHS=3D490/2/32=20
> Partition check:=20
> hda: hda1=20
> NS4 Bank 0: Found 1 x16 devices at 0x0 in 8-bit mode=20
> Amd/Fujitsu Extended Query Table at 0x0040=20
> NS4 Bank 0: CFI does not contain boot bank location. Assuming top.=20
> number of CFI chips: 1=20
> cfi=5Fcmdset=5F0002: Disabling erase-suspend-program due to code brokenne=
ss.=20
> NS4 flash bank 0: Using static image partition definition=20
> Creating 5 MTD partitions on "NS4 Bank 0":=20
> 0x00000000-0x00100000 : "U-Boot"=20
> 0x00100000-0x00200000 : "kernel"=20
> 0x00200000-0x00500000 : "initrd"=20
> 0x00500000-0x00b00000 : "jffs2"=20
> 0x00b00000-0x01000000 : "Spare"=20
>=20
> --- cut out insignificant rest of console output ---=20
>=20
>=20
> Now I have a brand new SanDisk 1GB Industrial Grade card that is=20
> giving me a problem. Here is what happens=20
> with exactly the same u-boot and kernel versions, just this new CF=20
> card plugged in instead of the older one.=20
>=20
> U-Boot 1.1.2 (Dec 2 2004 - 16:01:06)=20
>=20
> CPU: MPC5200 v1.2 at 396 MHz=20
> Bus 132 MHz, IPB 66 MHz, PCI 33 MHz=20
> Board: Marel NS4=20
> I2C: 85 kHz, ready=20
> DRAM: 128 MB=20
> FLASH: 16 MB=20
> In: serial=20
> Out: serial=20
> Err: serial=20
> Net: FEC ETHERNET=20
> IDE: Bus 0: OK=20
> Device 0: Model: SanDisk SDCFBI-1024 Firm: HDX 2.15 Ser#:=20
111515L1004P3254=20
> Type: Hard Disk=20
> Capacity: 977.4 MB =3D 0.9 GB (2001888 x 512)=20
>=20
> Type "run flash=5Fnfs" to mount root filesystem over NFS=20
>=20
> Hit any key to stop autoboot: 0=20
> Using FEC ETHERNET device=20
> TFTP from server 10.100.1.30; our IP address is 10.100.50.68=20
> Filename 'mpc5200/uImage'.=20
> Load address: 0x200000=20
> Loading:=20
#################################################################=20
> #################################################################=20
> #############################=20
> done=20
> Bytes transferred =3D 810417 (c5db1 hex)=20
> ## Booting image at 00200000 ...=20
> Image Name: Linux-2.4.25=20
> Created: 2004-12-03 11:35:18 UTC=20
> Image Type: PowerPC Linux Kernel Image (gzip compressed)=20
> Data Size: 810353 Bytes =3D 791.4 kB=20
> Load Address: 00000000=20
> Entry Point: 00000000=20
> Verifying Checksum ... OK=20
> Uncompressing Kernel Image ... OK=20
> Memory BAT mapping: BAT2=3D128Mb, BAT3=3D0Mb, residual: 0Mb=20
> Linux version 2.4.25 (jonb@tux.marel.is) (gcc version 3.2.2 20030217
> (Yellow Dog=20
> Linux 3.0 3.2.2-2a=5F1)) #4 F=F6s Des 3 11:34:35 UTC 2004=20
> On node 0 totalpages: 32768=20
> zone(0): 32768 pages.=20
> zone(1): 0 pages.=20
> zone(2): 0 pages.=20
> Kernel command line: root=3D/dev/nfs rw nfsroot=3D10.100.1.30:
> /opt/eldk/ppc=5F82xx ip=3D=20
> 10.100.50.68:10.100.1.30:10.100.254.254:255.255.0.0:ns4b:eth0:off=20
panic=3D1=20
> Calibrating delay loop... 263.78 BogoMIPS=20
> Memory: 127080k available (1396k kernel code, 464k data, 76k init, 0k=20
highmem)
> Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)=20
> Inode cache hash table entries: 8192 (order: 4, 65536 bytes)=20
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)=20
> Buffer cache hash table entries: 8192 (order: 3, 32768 bytes)=20
> Page-cache hash table entries: 32768 (order: 5, 131072 bytes)=20
> POSIX conformance testing by UNIFIX=20
> PCI: Probing PCI hardware=20
> Linux NET4.0 for Linux 2.4=20
> Based upon Swansea University Computer Society NET3.039=20
> Initializing RT netlink socket=20
> Starting kswapd=20
> Journalled Block Device driver loaded=20
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.=20
> i2c-core.o: i2c core module version 2.6.1 (20010830)=20
> i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)=20
> pty: 256 Unix98 ptys configured=20
> ttyS0 on PSC1=20
> ttyS1 on PSC2=20
> ttyS2 on PSC3=20
> PCF8563 Real-Time Clock Driver $Revision: 1.3 $ wd@denx.de=20
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize=20
> loop: loaded (max 8 devices)=20
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4=20
> ide: Assuming 33MHz system bus speed for PIO modes; override with=20
idebus=3Dxx=20
> Port Config is: 0x91050404=20
> ipb=3D66MHz, set clock period to 15=20
> GPIO config: 91050404=20
> ATA invalid: 00800000=20
> ATA hostcnf: 03000000=20
> ATA pio1 : 100a0a00=20
> ATA pio2 : 02040600=20
> XLB Arb cnf: 80002006=20
> mpc5xxx=5Fide: Setting up IDE interface ide0...=20
> Probing IDE interface ide0...=20
> hda: SanDisk SDCFBI-1024, ATA DISK drive=20
> hdb: probing with STATUS(0x00) instead of ALTSTATUS(0x7f)=20
> ide0: unexpected interrupt, status=3D0x00, count=3D1=20
>=20
> Here the boot process fails and the kernel hangs without further=20
> messages to the console.=20
>=20
> Actually I did get one bootup with this 1 GB SanDisk Industrial=20
> Grade card that succeeded without this happening, where the card seemed =
to be
> properly identiified, but I have not been able to repeat that.=20
>=20
> Does anyone have a clue what might be causing this ?=20
>=20
>=20
> Thanks,=20
> Jon Benediktsson=20
> Marel hf.=20
^ permalink raw reply
* MPC8260 strange virtual addresses returned by kmalloc()
From: Laurent Lagrange @ 2005-01-05 13:38 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
Hi and Happy New Year to all,
I use a Linux 2.4.25 kernel on a MPC8260 custom board with 128MB of RAM.
PCI is activated and my drivers are loaded as modules.
The RAM is mapped at 0xC0000000 as usual.
On MPC8XX I used kmalloc and iopa to get the physical addresses of the
allocated buffers.
On MPC82XX I used kmalloc and __pa for the same thing and it worked fine
with previous kernel.
But now, when I want to use kmalloc, I get addresses like 0xC9xxxxxx.
The __pa gives me physical addresses 0x09xxxxxx which are out of my physical
RAM.
I tried old iopa function and got some real physical addresses and the
module works.
The virt_to_bus gives me too addresses like 0x09xxxxxx
(ie substract kernel base address 0xC0000000 as usual).
I don't understand why I get virtual addresses which seem to be out of my
memory and why it runs.
More, I have a global variable which is a little buffer. It is also mapped
at a 0xC9xxxxxx address.
Has anyone an idea or a link to a detailed howto ?
Thanks
Bye
Laurent
PS : Linux console informations about memory.
Memory BAT mapping: BAT2=128Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.25 (version gcc 3.2.3)
On node 0 totalpages: 32768
zone(0): 32768 pages.
zone(1): 0 pages.
zone(2): 0 pages.
...
Memory: 127008k available (948k kernel code, 296k data, 60k init, 0k
highmem)
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
[-- Attachment #2: Type: text/html, Size: 4205 bytes --]
^ permalink raw reply
* MPC5200 - problem with CF card
From: Jón Benediktsson @ 2005-01-05 13:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 18100 bytes --]
^ 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