* Re: MPC8540 DMA routines (channel 0 broken?)
From: Clemens Koller @ 2005-07-19 13:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <550C0481-4DD8-4AFC-AFA2-13AAEBD055E5@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
Hello, Kumar!
> Glad to see that the issue was software. If there is something going
> on in u-boot during init that isn't leaving the DMA channel in a clean
> state let me know.
The MPC8540RM.pdf says: 15.4.1.1.1:
4. _Clear_and_then_set_ the mode register channel start bit, MRn[CS],
to start the DMA transfer
The exact problem was that Jason's original code cleared
the DMA.MR0 register to 0x00000000 in the interrupt service handler
_after_ each transaction.
Then the MR can get re-programmed along with the CS bit (Channel Start)
set at once and everything is fine.
But if MR0 didn't get cleared before that, the DMA won't start.
So, u-boot just didn't clear MR0[CS] _after_ a transaction, too.
The attached patch for u-boot would put in more safety to avoid
things like that in the future. It's optional, as my driver
explicitly clears the MRn[CS] now, _before_ it starts it's work.
> Also, it looks like there maybe some proposal for a general DMA engine
> API. If your interested take a look at the Linux Sympoisum 2005 papers
> (Accelerating Network Receive Processing). I'm hoping to talk to the
> guys doing this to see what their thoughts are. If you have some
> feedback on what they are proposing let me know.
I've had a look at the proposal. Thanks! I guess it shouldn't be too
difficult to implement an API like that.
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
[-- Attachment #2: u-boot_mpc85xx_dma_cleanup.patch --]
[-- Type: text/plain, Size: 442 bytes --]
diff -Nur u-boot/cpu/mpc85xx/cpu.c u-boot-local/cpu/mpc85xx/cpu.c
--- u-boot/cpu/mpc85xx/cpu.c 2005-07-19 14:48:37.000000000 +0200
+++ u-boot-local/cpu/mpc85xx/cpu.c 2005-07-19 14:50:46.000000000 +0200
@@ -191,6 +191,9 @@
while((status & 4) == 4) {
status = dma->sr0;
}
+ /* clear MR0[CS] channel start bit */
+ dma->mr0 &= ~0x00000001;
+ asm("sync;isync;msync");
if (status != 0) {
printf ("DMA Error: status = %x\n", status);
^ permalink raw reply
* Re: [PATCH] ppc32: Register definition for MPC85xx
From: Clemens Koller @ 2005-07-19 13:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppcembed Mailing List
In-Reply-To: <B6B4D7F0-2E8B-4779-95C5-6F8993C6D6A9@freescale.com>
Hello, Kumar,
> This isn't going to get into the kernel tree. I'm against putting full
> register definitions in like this because they are too difficult to
> maintain properly. We currently have some 14 different 85xx devices
> today and the number is only going to grow larger.
Okay, no problem.
I experienced that it is definitely difficult to maintain if there are lot of
changes/patches which can corrupt the whole set if only one register
is misaligned. Once a set it's completed for a device, it could be nailed down
to a specific device by specifying a filename like immap_mpc8540.h
And... it doesn't necessarily stay within the kernel tree... maybe Freescale
can put out those files on their website for reference?
Best greets,
Clemens Koller
Kumar Gala wrote:
> Clemens,
>
> This isn't going to get into the kernel tree. I'm against putting full
> register definitions in like this because they are too difficult to
> maintain properly. We currently have some 14 different 85xx devices
> today and the number is only going to grow larger.
>
> If and when you need something specific in the immap_85xx please
> provide it as a patch along with the driver that you want in. For
> certain devices like PCI, LBC, etc I've got no issue adding info into
> immap_85xx. However, for devices like DUART, I2C, TSEC, etc I'm
> completely against the idea of having their register definitions in
> immap_85xx.
>
> - kumar
>
> On Jul 19, 2005, at 5:01 AM, Clemens Koller wrote:
>
>> Hello!
>>
>> I suggest to put the register definitions into the Kernel _before_
>> more driver writers start using their own / different maps.
>>
>> Greets,
>>
>> Clemens Koller
>>
>> ---
>> Almost complete and verified register map for the MPC85xx.
>> Based on sources from Jason McMullan and the MPC8540 Reference Manual.
>>
>> Signed-off-by: Clemens Koller <clemens.koller@anagramm.de>
>>
>>
>> <immap_85xx-register-update.patch>
>> <ATT1082226.txt>
>>
>
>
^ permalink raw reply
* Re: DTC memory reserve question
From: Jon Loeliger @ 2005-07-19 15:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1121738905.14393.43.camel@gaston>
On Mon, 2005-07-18 at 21:08, Benjamin Herrenschmidt wrote:
> > Naturally, that yields System.map entries like this:
> >
> > c0013988 t _dt_blob_start
> > c0013988 T dt_blob_start
> > c0013988 t _dt_header
> > c0013988 T dt_header
> > c00139b0 t _dt_reserve_map
> > c00139b0 T dt_reserve_map
> > c00139d0 t _dt_struct_start
> > c00139d0 T dt_struct_start
> > c0013df0 t _dt_strings_start
> > c0013df0 T dt_strings_start
> > c0013df0 t _dt_struct_end
> > c0013df0 T dt_struct_end
> > c0013f05 t _dt_blob_end
> > c0013f05 T dt_blob_end
> >
> > Notice that these are 0xC-gazillion addresses.
>
> How are you getting these addresses ? You are trying to link the output
> of dtc with the kernel directly ?
Yep. I'm in testing mode, and wanted a QAD way to get my
initial DTC blob to the code without having to first do
wild U-Boot hackery, or downloading or flash burning or
any number of other annoying solutions. :-)
So I am not handing off r3 pointing to the blob yet.
It's just a data array assembled and linked into the kernel.
Later, when things work better, it will be r3'ed in as
per the spec, of course.
> Hrm... That will not work
Oddly, that is what I noticed too! :-)
> for that
> (and maybe a couple of other things). Might be better to link it with
> the zImage wrapper...
Well, I need to u-boot this kernel into running...
Thanks,
jdl
^ permalink raw reply
* Re: 8272ADS and Linux 2.6.12
From: SIP COP 009 @ 2005-07-19 17:18 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <42DA0024.3050005@compulab.co.il>
Thanks all for the replies and help. I have the 2.6 Kernel running
now. Here are few of the things that i did to make it happen:
1: make ads8272_defconfig
2: edit .config to add the follow:
CONFIG_SERIAL_CORE=3Dy
CONFIG_SERIAL_CORE_CONSOLE=3Dy
CONFIG_SERIAL_CPM=3Dy
CONFIG_SERIAL_CPM_CONSOLE=3Dy
CONFIG_SERIAL_CPM_SCC1=3Dy
CONFIG_SERIAL_CPM_SCC2=3Dy
3. In u-boot, set the bootargs to
bootargs=3Droot=3D/dev/ram rw console=3DttyCPM0,115200
4.Modify the file arch/ppc/platforms/pq2ads.h,
// #define BCSR_ADDR ((uint)0xf4500000)
#define BCSR_ADDR ((uint)0xff080000)
Thanks!
ashutosh
On 7/16/05, Mike Rapoport <mike@compulab.co.il> wrote:
> SIP COP 009 wrote:
>=20
> >Hello,
> >
> >We have a MPC8272 Eval Board which came with Linux 2.4 and U-boot. We
> >wanted to move to 2.6. I downloaded the latest 2.6.12 sources and
> >compiled the sources for this platform. The kernel is built, have run
> >the mkimage tool, but the kernel wont boot. It just hangs after
> >decompressing the image.
> >
> >
> >
>=20
> >Any ideas ? Anything different that needs to be done for 2.6 ? Or any
> >known issues ?
> >
> >
> >
> If you're using the u-boot that came with MPC8272 Eval board it may
> happen that BCSR is mapped differently in u-boot and the kernel 2.6.
> That's what happened when I tried to boot linux 2.6 on MPC8272ADS. Check
> the value of CFG_BCSR in u-boot/include/configs/MPC8260ADS.h and
> BCSR_ADDR in linux/arch/ppc/platforms/pq2ads.h
>=20
> >Thanks!
> >ashutosh
> >
> >
> --
> Sincerely yours,
> Mike
>=20
>
^ permalink raw reply
* Re: ptrace on linux 2.6.12 causes oops
From: Marcelo Tosatti @ 2005-07-15 5:03 UTC (permalink / raw)
To: Anton Wöllert; +Cc: linux-ppc-embedded
In-Reply-To: <faba779805071502425552aefc@mail.gmail.com>
Hi Anton,
On Fri, Jul 15, 2005 at 11:42:27AM +0200, Anton W=F6llert wrote:
> >=20
> > Yep, just that now its the ptraceing process which is faulting in the=
=20
> > page,
> > instead of the (ptraced) process itself.
> >=20
> > So Anton, can you move the _tlbie() call up to
> >=20
> > && !test_bit(PG_arch_1, &page->flags)) {
> > <---------- HERE
> > if (vma->vm_mm =3D=3D current->active_mm)
> > __flush_dcache_icache((void *) address);
> > else
> > flush_dcache_icache_page(page);
> > set_bit(PG_arch_1, &page->flags);
> >=20
> > So that it covers both cases instead of just (vma->vm_mm =3D=3D=20
> > current->active_mm) ?
> >=20
> > Its safe to do it because the address space ID is ignored by tlbie=20
> > accordingly
> > to the manual page:
> >=20
> > The ASID value in the entry is ignored for the purpose of
> > matching an invalidate address, thus multiple entries can be invalida=
ted
> > if they have the same effective address and different ASID values.
>=20
>=20
>=20
> Well, unfortunately, that doesn't work :(.=20
Oh doh, on the case where the process faulting in the page is not the own=
er of the
vma (which is the case with ptrace here), the flushing is done via the ph=
ysical address.
So its expected that the _tlbie() on the process virtual address will not=
change=20
a thing, since flush_dcache_icache_page() is working on the physical addr=
ess.
> If i'm right, the=20
> __flush_dcache_icache((void *) address) should avoid that the cache say=
s=20
> faulting address again.
> The flush_dcache_icache_page(page) should flush the cache, where stands=
,=20
> page not mapped. but the flush_dcache_icache_page(page) oopses on my sy=
stem.=20
> but instead of this call, the call __flush_dcache_icache(page_address(p=
age))=20
> works. for me, that also makes more sence.=20
Well, you end up flushing the page through its kernel virtual address map=
ping (returned
by page_address()).=20
It will be necessary for the kernel virtual map to be faulted in the TLB,=
which is=20
certainly slower than doing the direct physical address flush (requires u=
pdating=20
the MSR twice (+isync) to turn the MMU on/off).
But other than that I see no problem with your suggestion really, as to w=
orkaround the=20
oops.
Still, we should try to understand what is going on...
> and also, the flush_dcache_icache_page(page) calls the flush_dcache_ica=
che_phys, which=20
> turns off the data virtual address mapping. i found that a bit strange.=
any=20
> comments?=20
It seems that the instruction at "__flush_dcache_icache_phys+0x38" is icb=
i - can you send=20
the disassembly of __flush_dcache_icache_phys? =20
We should figure out what is causing the oops.=20
What is causing DAR to be set to "00000010"? ie why the hell is it trying=
to access=20
the 00000010 address.
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tai=
nted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK =3D c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
^ permalink raw reply
* Re: How reliable is jffs2 really (denx cvs devel kernel)?
From: Wolfgang Denk @ 2005-07-19 18:37 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200507191021.52063.david.jander@protonic.nl>
In message <200507191021.52063.david.jander@protonic.nl> you wrote:
>
> I have seen some strange problems with jffs2. I have been victim of the BUG()
> in fs/jffs2/gc.c, line 139. I have been battling with kgdb to see what
> happens there. Here are my findings until now (I am still working on this):
You probably want to ask this on the MTD mailing list; don't forget
to mention the exact version of the MTD / JFFS2 code you're using
(see CVS history).
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
Success in marriage is not so much finding the right person as it is
being the right person.
^ permalink raw reply
* Re: How reliable is jffs2 really (denx cvs devel kernel)?
From: Wolfgang Denk @ 2005-07-19 18:42 UTC (permalink / raw)
To: David Ho; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <4dd15d1805071905573ebcba61@mail.gmail.com>
In message <4dd15d1805071905573ebcba61@mail.gmail.com> you wrote:
>
> I updated the JFFS2 portion of the Denx devel kernel with the latest
> from CVS and it solved the initial mount time problem. But it was a
> while a ago when I did this. Both the devel kernel and the CVS head
> has changed quite a bit since then.
I would rally appreciate if you mentioned which exact version of the
kernel you are talking about. "The Denx devel kernel" can be anything
- either yesterday or 3 years old.
At the moment our CVS tree contains a snapshot from MTD CVS of March
13, 2005; yes, we did the necessary backport to the 2.4 kernel.
Do you want to say that this version still has mount time issues?
Please provide details!
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
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to the
purpose of sitting around all day and eating big heavy meals.
- Terry Pratchett, _Moving Pictures_
^ permalink raw reply
* Re: How reliable is jffs2 really (denx cvs devel kernel)?
From: David Ho @ 2005-07-19 19:03 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20050719184241.78430352671@atlas.denx.de>
Wolfgang,
It must have be more than a year ago that I did this. And I have not
done any testing with the latest devel kernel from your CVS so I am
not making any conclusion about the latest kernel.
Just trying to be helpful. =20
The mount time issue is fixed a long time ago, so your back port most
probably has this fix.
David
On 7/19/05, Wolfgang Denk <wd@denx.de> wrote:
> In message <4dd15d1805071905573ebcba61@mail.gmail.com> you wrote:
> >
> > I updated the JFFS2 portion of the Denx devel kernel with the latest
> > from CVS and it solved the initial mount time problem. But it was a
> > while a ago when I did this. Both the devel kernel and the CVS head
> > has changed quite a bit since then.
>=20
> I would rally appreciate if you mentioned which exact version of the
> kernel you are talking about. "The Denx devel kernel" can be anything
> - either yesterday or 3 years old.
>=20
> At the moment our CVS tree contains a snapshot from MTD CVS of March
> 13, 2005; yes, we did the necessary backport to the 2.4 kernel.
>=20
> Do you want to say that this version still has mount time issues?
> Please provide details!
>=20
>=20
> Best regards,
>=20
> Wolfgang Denk
>=20
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> The word "fit", as I understand it, means "appropriate to a purpose",
> and I would say the body of the Dean is supremely appropriate to the
> purpose of sitting around all day and eating big heavy meals.
> - Terry Pratchett, _Moving Pictures_
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Little glitches in sleep with a G3 iBook
From: Gioele Barabucci @ 2005-07-20 0:30 UTC (permalink / raw)
To: linuxppc-dev
Today I compiled Linux 2.6.12-gentoo-r6 and I tried to put my G3 crystal
iBook to sleep.
I started pmud and this is what happened when I closed the lid:
(I am in X, backlight level is set to half and sound is playing)
* I closed the lid
* after about 1 second the sound has been stopped and the monitor backlight
level has been set to max (what causes this delay? why is the backlight
level set to max?)
* after another second the backlight has been switched off
* the led blinks
* I opened the lid
* I see some logs on the console that tell me that the system is recovering
from sleep (are these lines needed?)
* the backlight level has been set to max (again...)
* after half a second and the backlight has been set back to its original
value (half)
* another second, probably more, and the sound is back (why this long
delay?)
Anyway everything is working fine, and I'm very happy to see sleep working
again. And even sound restarting without all the noise I had in the past.
Thanks to Ben and all the others that worked to make this all!
--
Gioele <dev@gioelebarabucci.com>
^ permalink raw reply
* Re:Problem in locating the file system while Linux bootup in 8260 based board.
From: Sam Song @ 2005-07-20 6:11 UTC (permalink / raw)
To: apoorv sangal, Linuxppc-embedded
Cc: vikrant_basotra, nishant_galange, apoorv_sangal
In-Reply-To: <a7966936050719034139ed2c60@mail.gmail.com>
apoorv sangal <apoorvsangal@gmail.com> wrote:
> Kernel command line: console=ttyS0,115200 root=1f00
Pls have a look how to mount a jffs2 root-fs in
kernel cmdline.
http://www.denx.de/twiki/bin/view/DULG/RootFileSystemOnAJFFS2FileSystem
Best regards,
Sam
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: How reliable is jffs2 really (denx cvs devel kernel)?
From: David Jander @ 2005-07-20 6:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050719183745.AD52A352671@atlas.denx.de>
On Tuesday 19 July 2005 20:37, you wrote:
>[...]
> You probably want to ask this on the MTD mailing list; don't forget
> to mention the exact version of the MTD / JFFS2 code you're using
> (see CVS history).
I already thought it might be a good idea to subscribe to that list.
Any hint about how I can figure out exactly which version of MTD code I have?
The version of linuxppc_2_4_devel I have is about 2 months old, do I have to
expect important changes concerning MTD since then?
While we are there, what other solution would you suggest for this problem: We
need to log data into flash. Right now I use an oversized jffs2 partition,
log via syslogd and logrotate on size. I am getting the impression that this
is not workable for mission critical things. At least not with the kernel and
MTD code I have. Others must have the same problem, so here's my question:
Which way to do such a thing? Write my own filesystem?
Greetings,
--
David Jander
^ permalink raw reply
* Re: How reliable is jffs2 really (denx cvs devel kernel)?
From: Wolfgang Denk @ 2005-07-20 8:37 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200507200830.27141.david.jander@protonic.nl>
In message <200507200830.27141.david.jander@protonic.nl> you wrote:
>
> I already thought it might be a good idea to subscribe to that list.
> Any hint about how I can figure out exactly which version of MTD code I have?
I already answered this in my previous message: it's a snapshot from
MTD CVS of March 13, 2005, backported to the 2.4 kernel.
In general, you can find this type of information when checking the
CVS history. That's why we run a CVS server and not only provide
tarballs.
> The version of linuxppc_2_4_devel I have is about 2 months old, do I have to
> expect important changes concerning MTD since then?
More changes have been made since, of course, but I'm not aware of
anything that might be relevant to your problem.
> need to log data into flash. Right now I use an oversized jffs2 partition,
> log via syslogd and logrotate on size. I am getting the impression that this
This is about the worst case use for JFFS2 - always appending small
chunks (sinlge lines of text) to an ever growing file is exactly what
the filesystem was NOT designed for.
> is not workable for mission critical things. At least not with the kernel and
> MTD code I have. Others must have the same problem, so here's my question:
> Which way to do such a thing? Write my own filesystem?
No. Don't reinvent the wheel. Use a buffer are with unlimited write
cycles (like SRAM or FRAM), or even a reserved area of your system
RAM, and use pramfs on it. If you're using U-Boot, you can even
arrange that such a file system survives warm boots. Then establish a
policy for writing the data from this buffer area to flash (probably
still using JFFS2) at a much lower rate. Avoid append mode. Try to
write files in a single operation. etc.
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
"Summit meetings tend to be like panda matings. The expectations are
always high, and the results usually disappointing." - Robert Orben
^ permalink raw reply
* MPC5200 revisions
From: madhuri shilpi @ 2005-07-20 9:07 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Have anyone tried to make MPC5200 Rev.A or Rev.B to
go into Deep Sleep Mode. I tried some methods but
enabling "ccs_sleep_en" bit in in CDM clock Control
Sequencer (MBAR + 0x021C) just wont make it go to
sleep. Does anyone has any experiences with it. If yes
please do share them.
I heard that MPC5200 Rev.A has some hardware
problems regarding this DeepSleep Mode (I dont know
what exactly it is) .. assuming that the newer version
doesnt have it, why setting the ccs_sleep_en bit have
no effect on the core ???
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Problem mounting ramdisk image
From: "Häpe, Sebastian, HRD/AB" @ 2005-07-20 10:35 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Hi everybody,
I have a litte problem with an initrd-image on a custom board:
I created a gzip-compressed image of an initrd which is loaded to RAM =
by the
bootloader (U-Boot) before it starts the kernel. The kernel is compiled =
with
support for initial ramdisks and knows the right addresses of the image =
in
RAM.
Now the following effects occur:
- if i do not tell the kernel which filesystem I have in my image =
(only
entering: 'root=3D/dev/ram rw init=3D/bin/busybox')
he tells me the following:
=20
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 =
blocksize
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 709k freed
Kernel panic: VFS: Unable to mount root fs on 01:00
- if I tell the kernel to use TMPFS or RAMFS (rootfs=3Dtmpfs or
rootfs=3Dramfs), the error is
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 709k freed
VFS: Mounted root filesystem (tmpfs/ramfs)
Kernel panic: No init found. Try to pass init=3D... To the kernel =
command
line =20
When I examine the return value of the execve() function, I get
error-code 2, which means: File or directory not found
My distribution (ELinOS) creates two files, 'Image.gz' and =
'Image.initrd'.
If I extract Image.gz, the full filesystem is extracted.=20
How can I check wheather the 'Image.initrd' file is correct?
(U-Boot tells me it is correct if I enter 'imi [address of image]')
Or does anyone did have the same problem? Have I forgotten any kernel
options?
Greetings,
Sebastian H=E4pe
^ permalink raw reply
* [PATCH] USBcore: fix invalid function name usb_hcd_put in ohci-ppc-soc.c
From: John Otken @ 2005-07-20 10:46 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: weissg
This patch corrects an invalid function name in
drivers/usb/host/ohci-ppc-soc.c. The correct
function name is usb_put_hcd() not usb_hcd_put().
This patch works against 2.6.12 or 2.6.13.
Signed-off-by: John Otken <jotken@softadvances.com>
diff -up a/drivers/usb/host/ohci-ppc-soc.c b/drivers/usb/host/ohci-ppc-soc.c
--- a/drivers/usb/host/ohci-ppc-soc.c 2005-07-14 09:48:19.000000000 -0500
+++ b/drivers/usb/host/ohci-ppc-soc.c 2005-06-19 10:18:05.000000000 -0500
@@ -123,7 +123,7 @@ static void usb_hcd_ppc_soc_remove(struc
iounmap(hcd->regs);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
- usb_hcd_put(hcd);
+ usb_put_hcd(hcd);
}
static int __devinit
^ permalink raw reply
* Re: swsusp for ppc440
From: Takeharu KATO @ 2005-07-20 13:50 UTC (permalink / raw)
To: Hiroyuki Machida; +Cc: linuxppc-embedded
In-Reply-To: <42DA05BD.3050403@sm.sony.co.jp>
Hi
> It seems to be stopped at console device.
> Do anyone point out where and how to exclude system devices
> like console and swap from device suspend procedure as
> preparation of swsusp?
>
As long as I think, what you want may be realized by changing the condition
to suspend serial device(this is written in serial8250_suspend function
in drivers/serial/8250.c, line: 2334).
Following trivial patch may help you(But I've not tried this patch on PowerPC actually, sorry).
Regards,
diff -Nupr linux-2.6.orig/drivers/serial/8250.c linux-2.6/drivers/serial/8250.c
--- linux-2.6.orig/drivers/serial/8250.c 2005-07-20 05:37:20.000000000 +0900
+++ linux-2.6/drivers/serial/8250.c 2005-07-20 22:07:36.000000000 +0900
@@ -2331,7 +2331,7 @@ static int serial8250_suspend(struct dev
{
int i;
- if (level != SUSPEND_DISABLE)
+ if ( (level != SUSPEND_DISABLE) || (state == PMSG_FREEZE) )
return 0;
for (i = 0; i < UART_NR; i++) {
^ permalink raw reply
* LITE5200 2.6.x kernel support
From: Olivier Singla @ 2005-07-20 17:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am currently using 2.4.25 on the Lite5200 board, but I'd really like to
switch to 2.6.x. The only 5200 specific support I need are the integrated
uart and the PCI. I tried both 2.6.11 and 2.6.12 without luck: the kernel
start, but then is stuck (seems into the init sequence). I use the
configuration
file from arch/ppc/configs/lite5200_defconfig. I cross-compiled the
kernel with gcc-3.4.1.
I was wondering if somebody could give me some help, maybe by telling
be what I am doing wrong.
Thanks,
Olivier
BTW, I tried also 2.6.13-rc3, but I can't even compile for the Lite5200,
there are some syntax error when compile the pci module...
^ permalink raw reply
* [PATCH] 8xx: avoid icbi misbehaviour in __flush_dcache_icache_phys
From: Marcelo Tosatti @ 2005-07-20 6:29 UTC (permalink / raw)
To: Anton Wöllert, linuxppc-embedded
Anton,
Can you please test the following which is equivalent to your=20
suggest changes, the only difference being the location, contained=20
inside flush_dcache_icache_page(). After confirmation that it works
we can send up to the kernel maintainers.
We should still try to understand why this is happening, possibly=20
matching it to a published CPU errata bug, or inform Freescale
otherwise.
I've written that entry down in the 8xx TODO list.
Thanks!
-------------
On 8xx, in the case where a pagefault happens for a process who's not
the owner of the vma in question (ptrace for instance), the flush=20
operation is performed via the physical address.
Unfortunately, that results in a strange, unexplainable "icbi"=20
instruction fault, most likely due to a CPU bug (see oops below).
Avoid that by flushing the page via its kernel virtual address.=20
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tai=
nted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK =3D c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000b154] update_mmu_cache+0x7c/0xa4
[c005ae98] do_wp_page+0x460/0x5ec
[c005c8a0] handle_mm_fault+0x7cc/0x91c
[c005ccec] get_user_pages+0x2fc/0x65c
[c0027104] access_process_vm+0x9c/0x1d4
[c00076e0] sys_ptrace+0x240/0x4a4
[c0002bd0] ret_from_syscall+0x0/0x44
From: Anton W=F6llert <a.woellert@gmail.com>=20
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
--- a/arch/ppc/mm/init.c.orig 2005-07-20 03:05:44.000000000 -0300
+++ b/arch/ppc/mm/init.c 2005-07-20 03:05:46.000000000 -0300
@@ -577,6 +577,9 @@
#ifdef CONFIG_BOOKE
__flush_dcache_icache(kmap(page));
kunmap(page);
+#elif CONFIG_8xx
+ /* On 8xx there is no need to kmap since highmem is not supported */
+ __flush_dcache_icache(page_address(page));=20
#else
__flush_dcache_icache_phys(page_to_pfn(page) << PAGE_SHIFT);
#endif
^ permalink raw reply
* Re: OLS 2005 attendees
From: Grant Likely @ 2005-07-20 19:23 UTC (permalink / raw)
To: PPC64-dev List, Linux PPC Dev, linuxppc-embedded
In-Reply-To: <52642f46a4231ff4111424b0565ddcde@penguinppc.org>
For OLS2005 attendees:
We are planning to hold a BOF for embedded PPC tomorrow for all who
are interested. (Thursday July 21). Meet in the downstairs at 7:00pm
Cheers,
g.
^ permalink raw reply
* Re: Meet at OLS2005
From: David Ho @ 2005-07-20 20:33 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded
In-Reply-To: <528646bc050720121713d62225@mail.gmail.com>
Grant, The CE Linux forum is holding a embedded linux BOF at Les
Suites at the same time. It is probably more ARM based, but it will
have lots of interested talks about XIP, PM suspend/resume, etc.
Not sure if you are interested to attend there as well.
David
On 7/20/05, Grant Likely <glikely@gmail.com> wrote:
> I talked to Kumar on the last break. We're going to have the
> ppcembedded BOF on Thursday at 7:00 in the downstairs lounge. I'm
> about to post an announcement on the mailing list. Let everyone know
>=20
> g.
>=20
> On 7/20/05, David Ho <davidkwho@gmail.com> wrote:
> > btw, Marcelo is asking when/where the ppc BOF will take place, I'm in
> > Room C again from 3-4pm, the last talk ran late. Maybe meet at the
> > Sofas outside Room C at 4pm.
> > Can talk about ppc BOF, I'm interested.
> >
> > David
> >
> > On 7/20/05, Grant Likely <glikely@gmail.com> wrote:
> > > I just got back online after lunch, so I probably missed you; I'm
> > > available between now and the next session. At the moment I'm on the
> > > 3rd floor at the DConf BOF. I'll have my email up that whole time
> > > also.
> > >
> > > Cheers
> > > g.
> > >
> > > On 7/20/05, David Ho <davidkwho@gmail.com> wrote:
> > > > Do you want to meet up now? I'm at Room C at the bottom floor. The=
re
> > > > are a bunch of sofas outside so it might be a better place to
> > > > chill/chat.
> > > >
> > > > David
> > > >
> > > > On 7/20/05, Grant Likely <glikely@gmail.com> wrote:
> > > > > David, Kumar;
> > > > >
> > > > > I'd like to meet both of you today, but as I don't know what eith=
er of
> > > > > you look like it's hard to track you down :-)
> > > > >
> > > > > When you get this, could you please either call me on my cell (40=
3)
> > > > > 399-0195 or email me back?
> > > > >
> > > > > At the moment, I'm in the NLKD session in Room A. (Middle sectio=
n,
> > > > > 4th row back, dark blue tee-shirt.)
> > > > >
> > > > > Thanks,
> > > > > g.
> > > > >
> > > >
> > >
> > >
> > > --
> > > "Why do musicians compose symphonies and poets write poems? They do i=
t
> > > because life wouldn't have any meaning for them if they didn't.
> > > That's why I draw cartoons. It's my life."
> > >
> > > -- Charles Shultz
> > >
> >
>=20
>=20
> --
> "Why do musicians compose symphonies and poets write poems? They do it
> because life wouldn't have any meaning for them if they didn't.
> That's why I draw cartoons. It's my life."
>=20
> -- Charles Shultz
>
^ permalink raw reply
* Re: OLS 2005 attendees
From: Grant Likely @ 2005-07-20 21:51 UTC (permalink / raw)
To: PPC64-dev List, Linux PPC Dev, linuxppc-embedded
In-Reply-To: <528646bc050720122361ec0551@mail.gmail.com>
Change of plans; we are going to meet 1/2 hour earlier so we can
decide as a group whether or not to just head over to the CELinux
forum or just meet amongst ourselves.
The CElinux forum is holding their BOF at Les Suites at 7:00
g.
On 7/20/05, Grant Likely <glikely@gmail.com> wrote:
> For OLS2005 attendees:
>=20
> We are planning to hold a BOF for embedded PPC tomorrow for all who
> are interested. (Thursday July 21). Meet in the downstairs at 7:00pm
>=20
> Cheers,
> g.
>=20
--=20
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life."
-- Charles Shultz
^ permalink raw reply
* Re: AW: AW: initrd rootfs ramdisk
From: T Ziomek @ 2005-07-20 22:05 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: tomz
In-Reply-To: <20050720203355.027CF67CF6@ozlabs.org>
On Wed, 6 Jul 2005 d.grab@hima.com wrote:
>
> i solved my problem with u-boot and linux. Now i have my rootfs ramdisk
> mounted and functioning. But one output is weird.
Can I ask what what you had to change to get your initrd RAM disk working?
I'm having a very similar problem.
Thanks, Tom Ziomek
--
/"\ ASCII Ribbon Campaign | Email to user 'CTZ001'
\ / | at 'email.mot.com'
X Against HTML |
/ \ in e-mail & news |
^ permalink raw reply
* Re: [PATCH] 8xx: avoid icbi misbehaviour in __flush_dcache_icache_phys
From: Anton Wöllert @ 2005-07-20 23:34 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050720062859.GA8477@dmt.cnet>
Marcelo Tosatti wrote:
> Can you please test the following which is equivalent to your
> suggest changes, the only difference being the location, contained
> inside flush_dcache_icache_page(). After confirmation that it works
> we can send up to the kernel maintainers.
of course, i can do that :).
> We should still try to understand why this is happening, possibly
> matching it to a published CPU errata bug, or inform Freescale
> otherwise.
i think so too. as far as i understand it, the thing with the previous
__flush_dcache_icache&tlbie patch was that __flush_dcache_icache should
try to call dcbst on every address on a cache-line-boundary that could
reference the page to give the cpu a hint, so that the next write-access
to this page will be more effective, right? but while trying to do the
dcbst, the TLB is looked up for the addresses for a faster translation.
but here the old TLB-Entry exists, that says invalid Page or something
like that, right? So it should be invalidated before, right?
Question, normally the dcbst should cause a TLB-Error-Exception, that
than should do reload the TLB-Entry automatically, doesn't this work
because of the dcb*-errata (btw. where can i found that?). And the
__flush_dcache_icache should do a dcbst 4096/16=256 times, but there are
just 64 cache-lines à 16Byte (1Kb DCache), so shouldn't be 3/4 of that
routine redundant? and also, as it seems to me, the whole dcache will be
*flushed* or better dcbst'd trough this routine. is that right?
please correct me!
so, now the __flush_dcache_icache_phys(). this is just called, when the
memory-mapping of the vma is not same as the one of that from the
current process. this should be the case with ptrace. couldn't now be
done the same as above? maybe no because the address is the virtual
address as seen from the ptraced process? and so that will *flush* the
pages from the ptraced process (that doesn't exists yet?, because they
were just created for the tracing process?).
so the pte, that was created for the tracing process is used. from that,
the physical address is calculated (how is this done, whats the magic
about the pfn-stuff etc, i didn't really understand that :( ). now
__flush_dcache_icache_phys is used, because the [d|i]cache uses physical
address tags and so the data-mmu could be turned off to flush these entries.
so to understand the things further, i have to understand which
addresses are used with dcbst and icbi. there is
page=pfn_to_page(pte_pfn(pte)) and (page_to_pfn(page) << PAGE_SHIFT).
but what are these values or where do they point. any hints to the
pfn&pte stuff? unfortunately i didn't have much time the last days to
understand this more deeply...
>
> On 8xx, in the case where a pagefault happens for a process who's not
> the owner of the vma in question (ptrace for instance), the flush
> operation is performed via the physical address.
>
> Unfortunately, that results in a strange, unexplainable "icbi"
> instruction fault, most likely due to a CPU bug (see oops below).
where do you know, that "icbi" is the bad?
Anton
^ permalink raw reply
* help
From: 戴红刚 @ 2005-07-21 5:59 UTC (permalink / raw)
To: linuxppc-embedded
can you give me the driver of isp1362, thanks a lot.
^ permalink raw reply
* Re: boot failure help needed
From: Susheel Raj @ 2005-07-21 7:18 UTC (permalink / raw)
To: David Wolfe; +Cc: linuxppc-embedded
In-Reply-To: <20050719153508.GB32476@orthanc.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
Hi David,
I have never done patch (I am a kid, help me grow
:-). the directories look a bit different to me as
compared that in the patch. PWD gives me this
nuguru@SW-server:~/linux_2_4_21_5200/arch/ppc$ pwd
/home/nuguru/linux_2_4_21_5200/arch/ppc
nuguru@SW-server:~/linux_2_4_21_5200/arch/ppc$ ls
4xx_io 8xx_io Makefile boot configs
iSeries lib mgt_io platforms xmon
8260_io CVS amiga config.in defconfig
kernel math-emu mm vmlinux.lds
nuguru@SW-server:~/linux_2_4_21_5200/arch/ppc$
I dont see the 5xxx_io .. but everything in mgt_io has
output files
nuguru@SW-server:~/linux_2_4_21_5200/arch/ppc/mgt_io$
ls
CVS Makefile fec.c fec.o psc.c
sc_task.impl.S sdma.o
Config.in bestcomm fec.h mgt_io.o psc.o sdma.c
sdma_5100.c
the bestcomm directory doesnt have "capi" folder in ..
Attaching the bestcomm folder on my system, and daring
to ask to send me a patch for this one.
If you feel that it will take more of your time can
you please suggest me some other options :-)
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
[-- Attachment #2: 489967008-bestcomm.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 36780 bytes --]
^ 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