* Re: [PATCH][PPC32] mktree fix
From: Tom Rini @ 2005-02-08 22:33 UTC (permalink / raw)
To: Andre' Draszik; +Cc: linuxppc-embedded
In-Reply-To: <4206EFDC.3090904@gmx.net>
On Mon, Feb 07, 2005 at 05:34:36AM +0100, Andre' Draszik wrote:
> This one fixes mktree. The image size stored in the header is pretty off
> without
> this patch. (yes, it can make a difference of upto almost 64k)
>
> Signed-off-by: Andre' Draszik <andid@gmx.net>
With this wrong, what breaks? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: RTAI+ELDK Compile Problems
From: Andrew Dennison @ 2005-02-08 21:58 UTC (permalink / raw)
To: 'Björn Östby', linuxppc-embedded
In-Reply-To: <004B1D7A5257174C9044A1B7BD0E60ED0178CBE7@ratatosk.combitechsystems.com>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On Tuesday, 8 February 2005 10:09 PM, linuxppc-embedded-bounces@ozlabs.org
wrote:
> I've got a major problem trying to compile RTAI using the
> ELDK cross compiler.
> I'm using ELDK version 3.1, and my target is ppc_8xx (823). I
> have followed the instructions given at
> ftp://ftp.denx.de/pub/RTAI/24.1.12/README.install
> <ftp://ftp.denx.de/pub/RTAI/24.1.12/README.install> , using the
>
> linuxppc_2_4_devel kernel (2004_04_30_1320) and rtai-24.1.12-denx.
>
> Now, the rtai patch works fine, and the kernel compiles, but
> when I try to compile rtai
> The following error occurs:
>
> /opt/eldk-3.1/ppc_8xx/usr/src/rtai-24.1.12/include/asm/rtai_srq.h: In
> function `rtai_srq':
> /opt/eldk-3.1/ppc_8xx/usr/src/rtai-24.1.12/include/asm/rtai_srq.h:32:
> error: asm-specifier for variable `__sc_3' conflicts with asm clobber
> list
>
I had a problem like this a while ago with gcc 3.3.2 (see this list from
22 March 2004) - seems later gcc versions are more pedantic about the way
the clobber list is specified, at least that is what some googling seemed
to indicate.
Attached patch worked for me when I was using linuxppc_devel patched with
patch-denx-linuxppc_2_4_devel-LABEL_2003_12_22_1500-ltt and
rtai-24.1.12-denx.tar.bz2.
[-- Attachment #2: rtai-24.1.12-denx.patch --]
[-- Type: application/octet-stream, Size: 547 bytes --]
diff -ur rtai-24.1.12.orig/include/asm-ppc/rtai_srq.h rtai-24.1.12/include/asm-ppc/rtai_srq.h
--- rtai-24.1.12.orig/include/asm-ppc/rtai_srq.h Tue Oct 24 11:32:28 2000
+++ rtai-24.1.12/include/asm-ppc/rtai_srq.h Thu Mar 18 14:38:35 2004
@@ -33,8 +33,7 @@
("trap \n\t"
: "=&r" (__sc_3), "=&r" (__sc_4)
: "0" (__sc_3), "1" (__sc_4),
- "r" (__sc_0)
- : "r0", "r3", "r4" );
+ "r" (__sc_0));
((unsigned long *)&retval)[0] = __sc_3;
((unsigned long *)&retval)[1] = __sc_4;
return retval;
^ permalink raw reply
* [PATCH][PPC32] Fix mv64x60 register relocation bug in bootwrapper
From: Mark A. Greer @ 2005-02-08 20:59 UTC (permalink / raw)
To: akpm; +Cc: Nathaniel Case, Embedded PPC Linux list
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
The gt64260 looks at the highest 20 bits while the mv64[34]60 looks at
only the highest 16 bits when determining the base address for the
bridge's registers. This patch adds support for both.
Please apply.
Signed-off-by: Nate Case <ncase@xes-inc.com>
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
[-- Attachment #2: misc-mv64x60.patch --]
[-- Type: text/plain, Size: 499 bytes --]
diff -Nru a/arch/ppc/boot/simple/misc-mv64x60.S b/arch/ppc/boot/simple/misc-mv64x60.S
--- a/arch/ppc/boot/simple/misc-mv64x60.S 2005-02-08 13:55:06 -07:00
+++ b/arch/ppc/boot/simple/misc-mv64x60.S 2005-02-08 13:55:06 -07:00
@@ -32,7 +32,11 @@
#if (CONFIG_MV64X60_NEW_BASE != CONFIG_MV64X60_BASE)
move_base:
li r20,0
+#ifdef CONFIG_GT64260
li r23,20
+#else /* Must be mv64[34]60 which uses top 16 bits */
+ li r23,16
+#endif
/* Relocate bridge's regs */
addis r25,0,CONFIG_MV64X60_BASE@h
^ permalink raw reply
* RE: 8266 SMC uart corruption
From: Rune Torgersen @ 2005-02-08 17:45 UTC (permalink / raw)
To: linuxppc-embedded
TW9yZSBJbmZvOg0KVGhpcyBzZWVtcyB0byBiZSByZWxhdGVkIHRvIGNwbV91YXJ0X3N0b3BfdHgo
KQ0KVGhlcmUgc2VlbXMgdG8gYmUgYW4gZXhjZXNzaXZlIGFtb3VudCBvZiBzdG9wcyBhbmQgc3Rh
cnRzIGdvaW5nIG9uDQpJbiB0aGUgZm9sbG93aW5nLCBJIHByaW50IGFuIFwgZm9yIGVhY2ggdGlt
ZSBzdG9wX3R4IGlzIGNhbGxlZCwgYW5kIGEgLyBmb3Igc3RhcnRfdHgNCg0KLS0tLS0tLS0tDQpF
WFQzLWZzOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4NClZGUzog
TW91bnRlZCByb290IChleHQzIGZpbGVzeXN0ZW0pLg0KRnJlZWluZyB1bnVzZWQga2VybmVsIG1l
bW9yeTogMjg4ayBpbml0DQpcL0lcL1RcL8K3XC92ZXJzXC9pXC9vbiAyXC8uXC84NSBiXC9vXC9v
dGluXC/CoC8NClwvQWN0aVwvdlwvYXRpblwvZ1wvIGFsbFwvIFwvc3dhcFwvIFwvZmlsZVwvc1wv
L3BhclwvdFwvaXRpb1wvblwvcy4uLlw8Nj5BZGRpbmcgMTAyODE1Mmsgc3dhcCBvbiAvZGV2L2hk
YTIuICBQcmlvcml0eToxIGV4dGVudHM6MQ0KLyAgICAgICBcL1sgIFwvT0tcLyAgXVwvDQpcL01v
dW5cL3RcL2luZyBcL3BcL3JvYyBcL2ZcL2lsZSBcL3NcL3lzdGVcL21cLy4uLlwvICAgIFwvWyAg
XC9PS1wvICBdXC8NClwvTW91blwvdFwvaW5nIFwvclwvb290IFwvZlwvaWxlIFwvc1wveXN0ZVwv
bVwvIGluIFwvclwvZWFkLVwvb1wvbmx5IFwvbVwvb2RlLlwvLlwvLlwvDQoNCi0tLS0tLS0tLS0N
CkFuZCBzbyBvbi4NCg0KSWYgSSBwdXQgaW4gYSB1ZGVsYXkoMTAwMDApIGF0IHRoZSBlbmQgb2Yg
Y3BtX3VhcnRfc3RvcF90eCwgYWxsIG91dHB1dCBwcmludHMgT0ssIGJ1dCBzbG93Lg0KDQoyLjYu
NyBhbmQgcHJpb3IgZG9lcyBub3QgdXNlIHRoZSBzdG9wIGF0IGFsbCBmb3JtIHdoYXQgSSBjYW4g
c2VlLg0KIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJ1bmUgVG9y
Z2Vyc2VuIA0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwMSwgMjAwNSAwODo0Mg0KPiBUbzog
bGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZw0KPiBTdWJqZWN0OiA4MjY2IFNNQyB1YXJ0IGNv
cnJ1cHRpb24NCj4gDQo+IEhpDQo+IA0KPiBIYXMgYW55Ym9yZHkgZWxzZSBzZWVuIGNvcnJ1cHRp
b24gb2YgdGhlIG91dHB1dCBmcm9tIFNNQzEgDQo+IHdoZW4gdXNlZCBhcyBzZXJpYWwgY29uc29s
ZT8NCj4gVGhpcyBvbmx5IG9jY3VycyBpbiBpbiAyLjYuOCBhbmQgbGF0ZXIgKHdoZW4gdGhlIENQ
TSBzZXJpYWwgDQo+IGRyaXZlcnMgZ290IG1vdmVkKQ0KPiBBbmQgaXQgb25seSBvY2N1cnMgd2hl
biBpbml0IGlzIHdyaXRpbmcgdG8gc2NyZWVuLiAyLjYuNyBhbmQgDQo+IGVhcmxpZXIgd29ya3Mg
cGVyZmVjdGx5Lg0KPiBJdCBoYXBwZW5zIGF0IGFsbCBiYXVkcmF0ZXMgdGVzdGVkICg5NjAwIGFu
ZCAxMTUyMDApDQo+IA0KPiBBbnlib2R5IHNlZW4gc29tZXRoaW5nIHNpbWlsYXIgYW5kL29yIGhh
dmUgYSBjbHVlIHdoZXJlIHRvIA0KPiBzdGFydCBsb29raW5nIGZvciB0aGlzPw0KPiBJIGhhdmUg
bG9va2VkIGF0IHRoZSBzZXJpYWwgZHJpdmVycywgYW5kIGNhbm5vdCBmaW5kIGFueSANCj4gZGlm
ZmVyZW5jZXMgbGFyZ2UgZGlmZmVyZW5jZXMgZnJvbSB3aGVudGhleSBzdGlsbCB3ZXJlIGluIA0K
PiBhcmNoL3BwYy84MjYwX2lvIHRvIHRoZSBvbmVzIGluIGRyaXZlcnMvc2VyaWFsL2NwbV91YXJ0
DQo+IA0KPiBDYXB0dXJlOg0KPiANCj4gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMjg4
ayBpzrV0DQo+IEnilqBUOiB2ZXJzaW9uIDIuODUgYm9vdOKImWcNCj4gLi4uDQo+IEnilqBUwqBF
bnRlcmluZyBydW5sZXZlbDogMw0KPiANCj4gDQo+IFRoZXNlIGxpbmVzIGFyZSB0aGUgb25seSBv
bmVzIHRoYXQgZ2V0IGNvcnJ1cHRlZC4gQWxsIG90aGVyIA0KPiBvdXRwdXQgKGtlcm5lbCBwcmlu
dG91dHMsIGNvbnNvbGUgYW5kIHN0YXJ0dXAgc2NyaXB0cykgYXJlIG5vcm1hbC4NCg==
^ permalink raw reply
* Re: question on symbol exports
From: Chris Friesen @ 2005-02-08 15:36 UTC (permalink / raw)
To: Dan Malek
Cc: linuxppc-dev list, Arjan van de Ven, Linux Kernel list,
linuxppc64-dev
In-Reply-To: <bc4f2e60770528d4934b5a2e69285002@embeddededge.com>
Dan Malek wrote:
>
> On Feb 7, 2005, at 4:35 PM, Benjamin Herrenschmidt wrote:
>
>> Interesting... more than no swap, you must also make sure you have no
>> r/w mmap'ed file (which are technically equivalent to swap).
>
>
> Yeah, I kinda had a similar thought. Just because you aren't
> swapping doesn't mean the VM subsystem isn't looking at dirty bits,
> too. It could potentially steal a page that it thinks can be replaced
> from either a zero-fill or reading again from persistent storage.
In our existing case, the app also mlock()s the pages in question. This
should get around these two possible sources of inaccuracy.
Chris
^ permalink raw reply
* linux kernel PPC 405GP stucked after running init
From: Octavian Purdila @ 2005-02-08 14:56 UTC (permalink / raw)
To: linuxppc-embedded
Hi list,
I am playing with an embedded system based on an IBM PPC 405GP. So far I made
the kernel boot, but it gets stuck after running the the init process
(busybox). Any hints?
I notice that ShowRegs does not output anything, and I traced this behavior to
pt_regs passed as NULL in the serial irq routine. Is this normal?
Thank you,
tavi
SysRq : Show Regs
SysRq : Show State
sibling
task PC pid father child younger older
busybox R running 0 1 0 2 (NOTLB)
ksoftirqd/0 S 00000000 0 2 1 3 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c001a228] ksoftirqd+0xa4/0xc8
[c00281e8] kthread+0xb8/0xc0
[c000594c] kernel_thread+0x44/0x60
events/0 S 00000000 0 3 1 4 8 2 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c0023a40] worker_thread+0x1fc/0x220
[c00281e8] kthread+0xb8/0xc0
[c000594c] kernel_thread+0x44/0x60
khelper S 00000000 0 4 3 5 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c0023a40] worker_thread+0x1fc/0x220
[c00281e8] kthread+0xb8/0xc0
[c000594c] kernel_thread+0x44/0x60
kblockd/0 S 00000000 0 5 3 6 4 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c0023a40] worker_thread+0x1fc/0x220
[c00281e8] kthread+0xb8/0xc0
[c000594c] kernel_thread+0x44/0x60
pdflush S 00000000 0 6 3 7 5 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c0030f44] __pdflush+0xb0/0x1e4
[c0031098] pdflush+0x20/0x30
[c00281e8] kthread+0xb8/0xc0
[c000594c] kernel_thread+0x44/0x60
pdflush S 00000000 0 7 3 9 6 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c0030f44] __pdflush+0xb0/0x1e4
[c0031098] pdflush+0x20/0x30
[c00281e8] kthread+0xb8/0xc0
[c000594c] kernel_thread+0x44/0x60
aio/0 S 00000000 0 9 3 7 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c0023a40] worker_thread+0x1fc/0x220
[c00281e8] kthread+0xb8/0xc0
[c000594c] kernel_thread+0x44/0x60
kswapd0 S 00000000 0 8 1 10 3 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c00375cc] kswapd+0x84/0xa0
[c000594c] kernel_thread+0x44/0x60
mtdblockd S 00000000 0 10 1 8 (L-TLB)
Call trace:
[c0005a70] __switch_to+0x48/0x70
[c00a4928] schedule+0x2e8/0x684
[c009885c] mtd_blktrans_thread+0x18c/0x1c4
[c000594c] kernel_thread+0x44/0x60
SysRq : Show Memory
Mem-info:
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages: 14240kB (0kB HighMem)
Active:1 inactive:173 dirty:0 writeback:0 unstable:0 free:3560 slab:57
mapped:14 pagetables:2
DMA free:14240kB min:512kB low:640kB high:768kB active:4kB inactive:692kB
present:16384kB pages_scanned:0 all_unreclaimable? no
protections[]: 0 0 0
Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB
pages_scanned:0 all_unreclaimable? no
protections[]: 0 0 0
HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB
present:0kB pages_scanned:0 all_unreclaimable? no
protections[]: 0 0 0
DMA: 6*4kB 3*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB 1*512kB 1*1024kB
0*2048kB 3*4096kB = 14240kB
Normal: empty
HighMem: empty
Free swap: 0kB
4096 pages of RAM
0 pages of HIGHMEM
3576 free pages
265 reserved pages
14 pages shared
0 pages swap cached
^ permalink raw reply
* driver needed for ISP 1301 usb transceiver?
From: Peter Asemann @ 2005-02-08 14:51 UTC (permalink / raw)
To: linuxppc-embedded
I'm not sure if there is a driver needed for the isp1301 usb transceiver
that accompanies my MPC875 cpu (I guess not) and if otherwise there is a
driver needed for the mpc's built-in usb controller, and if yes, which one.
Thanks for reading,
Peter Asemann
^ permalink raw reply
* AW: Microwindows on Icecube/CoralP
From: Martin Krause @ 2005-02-08 14:39 UTC (permalink / raw)
To: linuxppc-embedded
> > I have similar problems with an MPC5200 board and a Silicon Motion
> > SM501 (Voyager) grafic controller. The controller has a PCI and a
> > local bus interface. We use the local bus interface to connect it
> > with the 5200. In 32 bit truecolor mode everything works fine, but
> > in 16 bit mode bytes are swapped: 0x12345678 =3D> 0x34127856.
> > I'm not sure, if this problem has something to do with the CoralP
> > problem, but it is likely too similar to be completely independent.
>=20
> Two questions: Is your local bus set up as 32 bits wide, and are
> you writing 32 bits at a time? The little/big endian issue only
Yes, the bus is 32 bits wide and there should be only 32 bit wide=20
accesses. The SM501 configuration registers are always accessed 32
bit wide (I checked the fb driver). But I couldn't tell how the=20
linux console driver accesses the framebuffer. But the Problem even
occours, if I use my BDI2000 or U-Boot to write directly to the=20
framebuffer. It makes no difference, if I read or write bytes, halfs
or words. A hexdump of the framebuffer allways looks correct, but=20
the SM501 swapps Pixels in 16 bpp mode. Example:
In 16 bpp mode the color of a pixel is composed like this:
MSB LSB
rrrrrggggggbbbbb
I wrote 0xF000 to the start of the framebuffer (in U-Boot, but with
BDI2000 it is the same):
=3D> mw.w e0000000 f000
=3D> md.l e0000000 8
e0000000: f0000000 00000000 00000000 00000000 ................
e0000010: 00000000 00000000 00000000 00000000 ................
=3D>
This sets a red Pixel -> OK
Then I write 0x001F to the next pixel position
=3D> mw.b e0000003 1f
=3D> md.l e0000000 8
e0000000: f000001f 00000000 00000000 00000000 ................
e0000010: 00000000 00000000 00000000 00000000 ................
A blue pixel should be set right beside the red pixel. But the
blue Pixel is set left besides the red pixel.
Then the next pixel:
=3D> mw.w e0000004 f000
=3D> md.l e0000000 8
e0000000: f000001f f0000000 00000000 00000000 ................
e0000010: 00000000 00000000 00000000 00000000 ................
=3D> md.w e0000000 8
e0000000: f000 001f f000 0000 0000 0000 0000 0000 ................
=3D>
This prints a red pixel right besides the other red pixel, but
with a black pixle between it.=20
Then again a blue pixel to the next postion:
=3D> mw.w e0000006 001f
=3D> md e0000000
e0000000: f000001f f000001f 00000000 00000000 ................
e0000010: 00000000 00000000 00000000 00000000 ................
=3D>
This sets a blue pixle between the two red pixels
The screen now looks like this:
brbr
And it sould be:
rbrb
In the examples above I mixed byte, word and long accesses
to show, that this has no impact.=20
> shows up when writing smaller values than the width of the
> interface. In other words, an x86 and a PPC will write a 32bit
> word to 32bit memory in exactly the same way. The difference
> comes in how they address bytes or words within that 32bit data
> lane. So if you, for instance, are writing longs in truecolor mode
> and bytes in 16 bit mode that could explain what you are seeing.
>=20
> On the 5200 you've got two issues to deal with: You've got
> the byte/short addressing mismatches that might show up, then
> you've also got to take into account that 5200 swaps the
> byte lanes around.
The Bytes are swapped in combinations of two:
12345678 -> 34127856
This means in 16 bpp mode the colors are displayed correct, but=20
the pixel positions are swapped.
In 32 bpp mode there seems to bee no byte swapping. At least the
colors of the resulting Images look good. If bytes were swapped
like in 16 bpp mode, then the colours should be wrong.
I wonder if someone else ever used a SM501 with 16 bpp in local
bus mode?
regards,
Martin Krause
^ permalink raw reply
* Re: Microwindows on Icecube/CoralP
From: Mark Chambers @ 2005-02-08 13:12 UTC (permalink / raw)
To: Martin Krause; +Cc: linuxppc-embedded
In-Reply-To: <DE2CC66C40EAB74EA6D66AC71BF98E1E03055B6E@TQ-MAILSRV-1>
>> > This will not work. Microwindows can only use a plain framebuffer
>> > interface, but the Coral-P does not allow for such a driver
>> > because of the fact that it has a little-endian register interface.
>>
>> Or is it because 5200 swaps bytes around on PCI.
>I have similar problems with an MPC5200 board and a Silicon Motion
>SM501 (Voyager) grafic controller. The controller has a PCI and a
>local bus interface. We use the local bus interface to connect it
>with the 5200. In 32 bit truecolor mode everything works fine, but
>in 16 bit mode bytes are swapped: 0x12345678 => 0x34127856.
>I'm not sure, if this problem has something to do with the CoralP
>problem, but it is likely too similar to be completely independent.
Two questions: Is your local bus set up as 32 bits wide, and are
you writing 32 bits at a time? The little/big endian issue only
shows up when writing smaller values than the width of the
interface. In other words, an x86 and a PPC will write a 32bit
word to 32bit memory in exactly the same way. The difference
comes in how they address bytes or words within that 32bit data
lane. So if you, for instance, are writing longs in truecolor mode
and bytes in 16 bit mode that could explain what you are seeing.
On the 5200 you've got two issues to deal with: You've got
the byte/short addressing mismatches that might show up, then
you've also got to take into account that 5200 swaps the
byte lanes around.
Mark
^ permalink raw reply
* Re: Creating a configuration for my custom MPC875 board
From: Wolfgang Denk @ 2005-02-08 13:00 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-embedded
In-Reply-To: <42079D4D.9090904@eircom.net>
In message <42079D4D.9090904@eircom.net> Bryan O'Donoghue wrote:
>
> You'll definately need to find out what _your_ IMAP_ADDR is, that is
> something which is almost certainly going to be unique to your own PCB.
Actually the location of the IMMR area i just a part of the system's
memory map, which you just make up yourself - i. e. you can chose it
pretty freely, and in many cases you just copy te mapping of some
existing, similar board.
Of course you have to understand what you are doing, but this is
always the case, isn't it?
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
To understand a program you must become both the machine and the
program.
^ permalink raw reply
* Re: Creating a configuration for my custom MPC875 board
From: Bryan O'Donoghue @ 2005-02-07 16:54 UTC (permalink / raw)
To: Peter Asemann; +Cc: linuxppc-embedded
In-Reply-To: <420780F6.70209@web.de>
Peter Asemann wrote:
> Some days ago I was told on this mailinglist I needed to create a custom
> configuration in order to get linux running on my custom hardware.
>
> So I did as I was told and created an own <name>_defconfig and entries
> in the menu via editing arch/ppc/config.in and so on.
>
> Well, every board seems to include it's custom header file from
> platforms/<NAME>.h in the include/asm/mpc8xx.h header file.
> Now I'm curious if I also need to include something?
>
> It seems there usually isn't much stuff in the <name>.h file, only an
> IMAP_ADDR define and the definition of struct bd_info.
>
> Do I need this stuff - or how do I find out?
>
> Best regards,
>
> Peter Asemann
You'll definately need to find out what _your_ IMAP_ADDR is, that is
something which is almost certainly going to be unique to your own PCB.
Aside from that depending on what bootloader you are using, you may or
may not have to do things to enumerate a bd structure.
In the case of Redboot, you would probably have to take the board
descriptor given by redboot and parse it, else, with u-boot, I think you
have _less_ maintenance on that front.
Do you have a working bootloader for your board, something that will try
to execute a *image ? If you do, then getting Linux booting should be
relatively trivial.
Bod
^ permalink raw reply
* Re: AW: Microwindows on Icecube/CoralP
From: Geert Uytterhoeven @ 2005-02-08 12:23 UTC (permalink / raw)
To: Jarno Manninen; +Cc: linuxppc-embedded, Martin Krause
In-Reply-To: <Pine.LNX.4.58.0502081323590.17665@mozart.cc.tut.fi>
On Tue, 8 Feb 2005, Jarno Manninen wrote:
> On Tue, 8 Feb 2005, Martin Krause wrote:
> > Hm, the SM501 has 8 MB internal RAM. The framebuffer lies within this
> > memory. The SM501 is connected with the MPC5200 over the local bus
> > interface (not over PCI) and mapped with CS1 to address range
> > 0xE0000000-0xE3FFFFFF. The SM501 configuration registers are within
> > the mapped memory area at 0xE3E00000. I can't imagine, why the byte
> > swapping should only affect accesses to the famebuffer memory and not
> > to the configuration registers (where also single bits at the right
> > position must be set correctly). I could configure CS1 to do byte
> > swapping, but then access to the SM501 configuration registers does
> > not work any longer, because this bytes are swapped, too.
>
> Um. Have you written a kernel FB driver? If so then the write/read macros
> do this swapping for you. Assuming that you use those for accessing the
> device registers. At least SM722 requires those writes to be swapped too.
Indeed.
> > Geert, I've seen, you have done much of the fb stuff in the linux
> > kernel (thank you for that!). Could you please point me to the best
> > place, where byte swapping should be done if I want to use the linux
> > text console in 16 bit mode with the MPC5200?
>
> Perhaps the pseudopalette would suffice here, I guess? And supposing that
Yep, text console is simple: setcolreg() must fill in the correct pixel value
in the pseudo palette. If you swap it there, it will just work.
Logo is more difficult, you need your own imageblit().
> you have written a FB driver. If not then you have to do the patching at
> the gfx-library level.
And userspace needs to do swapping as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re : RTAI+ELDK Compile Problems
From: grave @ 2005-02-08 11:35 UTC (permalink / raw)
To: Björn Östby; +Cc: linuxppc-embedded
In-Reply-To: <004B1D7A5257174C9044A1B7BD0E60ED0178CBE7@ratatosk.combitechsystems.com>
Le 08.02.2005 12:09:07, Bj=F6rn =D6stby a =E9crit=A0:
> I've got a major problem trying to compile RTAI using the ELDK cross
> compiler.
> I'm using ELDK version 3.1, and my target is ppc_8xx (823). I have
> followed the instructions given at =20
> ftp://ftp.denx.de/pub/RTAI/24.1.12/README.install,
> using the
> linuxppc_2_4_devel kernel (2004_04_30_1320) and rtai-24.1.12-denx.
>=20
> Now, the rtai patch works fine, and the kernel compiles, but when I
> try to compile rtai
> The following error occurs:
>=20
> /opt/eldk-3.1/ppc_8xx/usr/src/rtai-24.1.12/include/asm/rtai_srq.h:
> In function `rtai_srq':
> /opt/eldk-3.1/ppc_8xx/usr/src/rtai-24.1.12/include/asm/rtai_srq.h:32:
> error: asm-specifier for variable `__sc_3' conflicts with asm clobber
> list
Hi,
I had a similar problem, can you check your gcc version ?
I had to compile rtai with gcc2.95 if I remember well...
xavier
^ permalink raw reply
* Re: AW: Microwindows on Icecube/CoralP
From: Jarno Manninen @ 2005-02-08 11:28 UTC (permalink / raw)
To: Martin Krause; +Cc: Geert Uytterhoeven, linuxppc-embedded
In-Reply-To: <DE2CC66C40EAB74EA6D66AC71BF98E1E03055B71@TQ-MAILSRV-1>
On Tue, 8 Feb 2005, Martin Krause wrote:
> Hm, the SM501 has 8 MB internal RAM. The framebuffer lies within this
> memory. The SM501 is connected with the MPC5200 over the local bus
> interface (not over PCI) and mapped with CS1 to address range
> 0xE0000000-0xE3FFFFFF. The SM501 configuration registers are within
> the mapped memory area at 0xE3E00000. I can't imagine, why the byte
> swapping should only affect accesses to the famebuffer memory and not
> to the configuration registers (where also single bits at the right
> position must be set correctly). I could configure CS1 to do byte
> swapping, but then access to the SM501 configuration registers does
> not work any longer, because this bytes are swapped, too.
Um. Have you written a kernel FB driver? If so then the write/read macros
do this swapping for you. Assuming that you use those for accessing the
device registers. At least SM722 requires those writes to be swapped too.
> Geert, I've seen, you have done much of the fb stuff in the linux
> kernel (thank you for that!). Could you please point me to the best
> place, where byte swapping should be done if I want to use the linux
> text console in 16 bit mode with the MPC5200?
Perhaps the pseudopalette would suffice here, I guess? And supposing that
you have written a FB driver. If not then you have to do the patching at
the gfx-library level.
- Jarno
^ permalink raw reply
* RTAI+ELDK Compile Problems
From: Björn Östby @ 2005-02-08 11:09 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
I've got a major problem trying to compile RTAI using the ELDK cross compiler.
I'm using ELDK version 3.1, and my target is ppc_8xx (823). I have followed the instructions given at ftp://ftp.denx.de/pub/RTAI/24.1.12/README.install, using the
linuxppc_2_4_devel kernel (2004_04_30_1320) and rtai-24.1.12-denx.
Now, the rtai patch works fine, and the kernel compiles, but when I try to compile rtai
The following error occurs:
/opt/eldk-3.1/ppc_8xx/usr/src/rtai-24.1.12/include/asm/rtai_srq.h:
In function `rtai_srq':
/opt/eldk-3.1/ppc_8xx/usr/src/rtai-24.1.12/include/asm/rtai_srq.h:32:
error: asm-specifier for variable `__sc_3' conflicts with asm clobber list
I have also tried other versions of rtai (3.0 and 3.1) but these give the same result.
I may also mention that when trying to compile any kernel except the one shipped with eldk and ppc_devel label_2004_04_30_1320, similar errors occur:
compile example from ppc_2_4_devel (label_2003_10_11_0005)
using "make ARCH=ppc CROSS_COMPILE=ppc_8xx- uImage"
/opt/eldk-3.1/ppc_8xx/usr/src/linuxppc_2_4_devel/include/asm/unistd.h: In function `init':
/opt/eldk-3.1/ppc_8xx/usr/src/linuxppc_2_4_devel/include/asm/unistd.h:439: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list
I have exported the CROSS_COMPILE variable and added the eldk-3.1/usr/bin and eldk-3.1/bin
directories to the path.
Can anyone tell me what's going on here or, better yet, how to solve it?.
Best regards,
Bjorn Ostby
[-- Attachment #2: Type: text/html, Size: 2959 bytes --]
^ permalink raw reply
* AW: Microwindows on Icecube/CoralP
From: Martin Krause @ 2005-02-08 11:09 UTC (permalink / raw)
To: Geert Uytterhoeven, Jarno Manninen; +Cc: linuxppc-embedded
On Tue, 8 Feb 2005, Geert Uytterhoeven wrote:
> > > I have similar problems with an MPC5200 board and a Silicon Motion
> > > SM501 (Voyager) grafic controller. The controller has a PCI and a
> > > local bus interface. We use the local bus interface to connect it
> > > with the 5200. In 32 bit truecolor mode everything works fine, but
> > > in 16 bit mode bytes are swapped: 0x12345678 =3D> 0x34127856.
> > > I'm not sure, if this problem has something to do with the CoralP
> > > problem, but it is likely too similar to be completely
> > > independent. Does anyone use an SM501 in 16 bit mode?
> >=20
> > This is the problem with big-endian systems with PCI bus. I've seen
> > this on sparc and on MPC5200 too. There is no other solution, but
> > to swap the bytes in SW.
>=20
> Yep, the Cybervision graphics cards on Amiga (S3 Trio or ViRGE)
> suffer from the same problem.
>=20
> > The problem is that the PCI bus and CPU must agree when thinking of
> > arithmetic context. For example when talking about adresses, both
> > parties have to see address numbers in the same way. Problem is
> > that with graphics formats we are talking about bit masks, not
> > actual numbers. So inner byte order _does_ have meaning while with
> > plain numbers it does _not_, right?=20
>=20
> If your graphics chip has separate apertures for big and little
> endian (and a control register to `fix' swapping depending on the
> color depth), you may be able to find a configuration that doesn't
> need any swapping on the CPU.=20
Hm, the SM501 has 8 MB internal RAM. The framebuffer lies within this
memory. The SM501 is connected with the MPC5200 over the local bus=20
interface (not over PCI) and mapped with CS1 to address range
0xE0000000-0xE3FFFFFF. The SM501 configuration registers are within=20
the mapped memory area at 0xE3E00000. I can't imagine, why the byte=20
swapping should only affect accesses to the famebuffer memory and not
to the configuration registers (where also single bits at the right=20
position must be set correctly). I could configure CS1 to do byte=20
swapping, but then access to the SM501 configuration registers does=20
not work any longer, because this bytes are swapped, too.
Geert, I've seen, you have done much of the fb stuff in the linux=20
kernel (thank you for that!). Could you please point me to the best=20
place, where byte swapping should be done if I want to use the linux=20
text console in 16 bit mode with the MPC5200?
regards,
Martin Krause
^ permalink raw reply
* Re: AW: Microwindows on Icecube/CoralP
From: Geert Uytterhoeven @ 2005-02-08 9:17 UTC (permalink / raw)
To: Jarno Manninen; +Cc: linuxppc-embedded, Martin Krause
In-Reply-To: <Pine.LNX.4.58.0502080941400.7250@amadeus.cc.tut.fi>
On Tue, 8 Feb 2005, Jarno Manninen wrote:
> On Tue, 8 Feb 2005, Martin Krause wrote:
> > linuxppc-embedded-bounces@ozlabs.org wrote on :
> > > > This will not work. Microwindows can only use a plain framebuffer
> > > > interface, but the Coral-P does not allow for such a driver
> > > > because of the fact that it has a little-endian register interface.
> > >
> > > Or is it because 5200 swaps bytes around on PCI. It sure looks to me
> > > like Freescale has made a major screwup in their implementation of
> > > PCI on the 5200. I'd love for somebody to prove me wrong about this,
> > > but I'm afraid I'm right. I was under the impression that
> > > CoralP worked
> > > nicely on 5200, but now I see that it also requires software
> > > tweaks to work
> > > on 5200.
> >
> > I have similar problems with an MPC5200 board and a Silicon Motion
> > SM501 (Voyager) grafic controller. The controller has a PCI and a
> > local bus interface. We use the local bus interface to connect it
> > with the 5200. In 32 bit truecolor mode everything works fine, but
> > in 16 bit mode bytes are swapped: 0x12345678 => 0x34127856.
> > I'm not sure, if this problem has something to do with the CoralP
> > problem, but it is likely too similar to be completely independent.
> > Does anyone use an SM501 in 16 bit mode?
>
> This is the problem with big-endian systems with PCI bus. I've seen this
> on sparc and on MPC5200 too. There is no other solution, but to swap the
> bytes in SW.
Yep, the Cybervision graphics cards on Amiga (S3 Trio or ViRGE) suffer from the
same problem.
> The problem is that the PCI bus and CPU must agree when thinking of
> arithmetic context. For example when talking about adresses, both parties
> have to see address numbers in the same way. Problem is that with graphics
> formats we are talking about bit masks, not actual numbers. So inner byte
> order _does_ have meaning while with plain numbers it does _not_, right?
If your graphics chip has separate apertures for big and little endian (and a
control register to `fix' swapping depending on the color depth), you may be
able to find a configuration that doesn't need any swapping on the CPU.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: AW: Microwindows on Icecube/CoralP
From: Jarno Manninen @ 2005-02-08 8:17 UTC (permalink / raw)
To: Martin Krause; +Cc: linuxppc-embedded
In-Reply-To: <DE2CC66C40EAB74EA6D66AC71BF98E1E03055B6E@TQ-MAILSRV-1>
On Tue, 8 Feb 2005, Martin Krause wrote:
> linuxppc-embedded-bounces@ozlabs.org wrote on :
> > > This will not work. Microwindows can only use a plain framebuffer
> > > interface, but the Coral-P does not allow for such a driver
> > > because of the fact that it has a little-endian register interface.
> >
> > Or is it because 5200 swaps bytes around on PCI. It sure looks to me
> > like Freescale has made a major screwup in their implementation of
> > PCI on the 5200. I'd love for somebody to prove me wrong about this,
> > but I'm afraid I'm right. I was under the impression that
> > CoralP worked
> > nicely on 5200, but now I see that it also requires software
> > tweaks to work
> > on 5200.
>
> I have similar problems with an MPC5200 board and a Silicon Motion
> SM501 (Voyager) grafic controller. The controller has a PCI and a
> local bus interface. We use the local bus interface to connect it
> with the 5200. In 32 bit truecolor mode everything works fine, but
> in 16 bit mode bytes are swapped: 0x12345678 => 0x34127856.
> I'm not sure, if this problem has something to do with the CoralP
> problem, but it is likely too similar to be completely independent.
> Does anyone use an SM501 in 16 bit mode?
This is the problem with big-endian systems with PCI bus. I've seen this
on sparc and on MPC5200 too. There is no other solution, but to swap the
bytes in SW.
The problem is that the PCI bus and CPU must agree when thinking of
arithmetic context. For example when talking about adresses, both parties
have to see address numbers in the same way. Problem is that with graphics
formats we are talking about bit masks, not actual numbers. So inner byte
order _does_ have meaning while with plain numbers it does _not_, right?
- Jarno
^ permalink raw reply
* Re: [PATCH] Heartbeat LED for iBook
From: Nico Schottelius @ 2005-02-08 7:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Joerg Dorchain; +Cc: linuxppc-dev list
In-Reply-To: <1106746946.6250.56.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
Good morning!
Benjamin Herrenschmidt [Thu, Jan 27, 2005 at 12:42:26AM +1100]:
> One can always control the led by sending PMU command directly
> via /dev/adb :) Ok, that sort-of sucks, especially since the command is
> only supported by some versions of the PMU. On the other hand, I dislike
> cluttering /dev ... maybe I can find some better mecanism via sysfs...
Well, if /dev would fit best, imho, as it represents a device.
And I don't think 'not having enough major/minor numbers' is an argument
not to implement something. We have udev (and before devfs), which
should clear the old problem.
Btw, howto control it via /dev/adb? Can you point me to a document
which explains that?
Joerg Dorchain [Thu, Jan 27, 2005 at 05:36:06PM +0100]:
> On Wed, Jan 26, 2005 at 12:35:54PM +0100, Nico Schottelius wrote:
> > Joerg Dorchain [Tue, Jan 18, 2005 at 10:42:16AM +0100]:
> > > [heartbeat blink patch]
> >
> > Well, wouldn't it make much more sense to write a
> > /dev/frontled to access it via userspace?
>
> Well, only some hardware supports something that can be used as a HB
> LED, so IMHO yet another (misc-) device node is not completely
> justified.
Imho it would be a nice feature, for testing and for fun.
If someone gives me some pointers on howto do that, I would try to
write a driver/interface to it.
Nico
--
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* AW: Microwindows on Icecube/CoralP
From: Martin Krause @ 2005-02-08 7:33 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
linuxppc-embedded-bounces@ozlabs.org wrote on :
> > This will not work. Microwindows can only use a plain framebuffer
> > interface, but the Coral-P does not allow for such a driver
> > because of the fact that it has a little-endian register interface.
>=20
> Or is it because 5200 swaps bytes around on PCI. It sure looks to me
> like Freescale has made a major screwup in their implementation of
> PCI on the 5200. I'd love for somebody to prove me wrong about this,
> but I'm afraid I'm right. I was under the impression that
> CoralP worked
> nicely on 5200, but now I see that it also requires software
> tweaks to work
> on 5200.
I have similar problems with an MPC5200 board and a Silicon Motion
SM501 (Voyager) grafic controller. The controller has a PCI and a
local bus interface. We use the local bus interface to connect it
with the 5200. In 32 bit truecolor mode everything works fine, but
in 16 bit mode bytes are swapped: 0x12345678 =3D> 0x34127856.
I'm not sure, if this problem has something to do with the CoralP
problem, but it is likely too similar to be completely independent.
Does anyone use an SM501 in 16 bit mode?
regards,
Martin Krause
^ permalink raw reply
* Re: question on symbol exports
From: Dan Malek @ 2005-02-07 23:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, linuxppc64-dev, Chris Friesen,
Linux Kernel list, Arjan van de Ven
In-Reply-To: <1107812101.7734.42.camel@gaston>
On Feb 7, 2005, at 4:35 PM, Benjamin Herrenschmidt wrote:
> Interesting... more than no swap, you must also make sure you have no
> r/w mmap'ed file (which are technically equivalent to swap).
Yeah, I kinda had a similar thought. Just because you aren't
swapping doesn't mean the VM subsystem isn't looking at dirty bits,
too. It could potentially steal a page that it thinks can be replaced
from either a zero-fill or reading again from persistent storage.
-- Dan
^ permalink raw reply
* Re: question on symbol exports
From: Chris Friesen @ 2005-02-07 23:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc64-dev, Arjan van de Ven, Linux Kernel list,
linuxppc-dev list
In-Reply-To: <1107812101.7734.42.camel@gaston>
Benjamin Herrenschmidt wrote:
> Interesting... more than no swap, you must also make sure you have no
> r/w mmap'ed file (which are technically equivalent to swap).
Ah...thanks for the warning.
We want to eventually make it work with swap as well, but that's
substantially more complicated.
> I'm not too fan about exporting those symbols, but I'll talk to paulus,
> it should be possible at least to EXPORT_SYMBOL_GPL them...
I understand the reluctance. I'm perfectly willing to export it GPL in
my private branch as long as you guys don't consider it evil--the module
is going to be GPL anyways.
The alternative would be for me to build my code directly in to the
kernel...just makes it harder for me to debug.
Chris
^ permalink raw reply
* Re: question on symbol exports
From: Benjamin Herrenschmidt @ 2005-02-07 21:35 UTC (permalink / raw)
To: Chris Friesen
Cc: linuxppc64-dev, Arjan van de Ven, Linux Kernel list,
linuxppc-dev list
In-Reply-To: <42077EE0.2060505@nortel.com>
On Mon, 2005-02-07 at 08:44 -0600, Chris Friesen wrote:
> Benjamin Herrenschmidt wrote:
> >>It turns out that to call ptep_clear_flush_dirty() on ppc64 from a
> >>module I needed to export the following symbols:
> >>
> >>__flush_tlb_pending
> >>ppc64_tlb_batch
> >>hpte_update
> >
> >
> > Any reason why you need to call that from a module ? Is the module
> > GPL'd ?
>
> I explained this at the beginning of the thread, but I'll do so again.
> The module will be released under the GPL.
>
> The basic idea is that we want to be able to track pages dirtied by a
> userspace process. The system has no swap, so we use the dirty bit for
> this. On demand we look up the page tables for an address range
> specified by the caller, store the addresses of any dirty pages, then
> mark them clean so that the next write causes them to get marked dirty
> again. It is this act of marking them clean that requires the
> additional exports.
>
> I've included the current code below. If there is any way to accomplish
> this without the additional exports, I'd love to hear about it.
Interesting... more than no swap, you must also make sure you have no
r/w mmap'ed file (which are technically equivalent to swap).
I'm not too fan about exporting those symbols, but I'll talk to paulus,
it should be possible at least to EXPORT_SYMBOL_GPL them...
Ben.
^ permalink raw reply
* Re: Edge Interrupts (Virtex-II Pro)
From: Joshua Lamorie @ 2005-02-07 20:29 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <42035D27.50901@ru.mvista.com>
Andrei Konovalov wrote:
> As this code is not board specific at all,
> I would move it to arch/ppc/syslib/xilinx_pic.c:ppc4xx_pic_init().
> Does it sound reasonable (I'll prepare the patch this weekend then)?
This sounds useful, since I am using a custom developed board using the
Virtex-II Pro. Unfortunately, the patch wouldn't help me much because I
am doing my interrupt setup for most of my custom devices within
modules. You see my hardware has a Virtex-II Pro and a Virtex-II with a
shared (logically) address space (OPB). I have cascaded interrupt
controllers (ask me if anyone wants the code). So it is quite often that
I have a changed hardware and therefore require different drivers.
Rather than downloading to flash the 700k kernel each time while I am
developing, I just download the 6k - 20k modules. Then I store them in
onboard NOR flash.
That's a long way of saying YES, isn't it?
Joshua
--
Xiphos Technologies
(514) 848-9640 x227
(514) 848-9644 fax
www.xiplink.com
_______________________________________________
The information transmitted is intended only for the
person or entity to which it is addressed and may contain
confidential and/or privileged material. If you have
received this in error, please contact the sender and delete
this communication and any copy immediately. Thank you.
^ permalink raw reply
* Re: Microwindows on Icecube/CoralP
From: Mark Chambers @ 2005-02-07 20:30 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <20050207195520.D8B4DC108D@atlas.denx.de>
>
> This will not work. Microwindows can only use a plain framebuffer
> interface, but the Coral-P does not allow for such a driver because
> of the fact that it has a little-endian register interface.
Or is it because 5200 swaps bytes around on PCI. It sure looks to me
like Freescale has made a major screwup in their implementation of
PCI on the 5200. I'd love for somebody to prove me wrong about this,
but I'm afraid I'm right. I was under the impression that CoralP worked
nicely on 5200, but now I see that it also requires software tweaks to work
on 5200.
Mark Chambers
^ 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