* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-03 16:00 UTC (permalink / raw)
To: nreddy; +Cc: linuxppc-embedded
In-Reply-To: <2611.61.95.208.2.1141362572.squirrel@61.95.208.2>
In message <2611.61.95.208.2.1141362572.squirrel@61.95.208.2> you wrote:
>
> 1. You can use u-boot as a boot loader.
> 2. You can choose any standard linux kernel but you may have to do some
> R&D on it to port to your board.
> Insted you can buy Montavista Linux, so that you can get support also.
Commercial support is available not only from MV, but also from many
other companies.
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 one who says it cannot be done should never interrupt the one who
is doing it.
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-03 16:04 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4407CFD3.4060206@ovro.caltech.edu>
In message <4407CFD3.4060206@ovro.caltech.edu> you wrote:
>
> If the vendor provided the VxWorks BSP, then hopefully they
> also provided you with the physical memory map of the board.
> This is what you really need to get another bootloader (eg. U-Boot)
This is *NOT* corect, and actually dangerous.
> Step 1. Get the memory map of the board.
Never use any given memory map unreflected. At least *check* if it's
usable with Linux.
Many memory maps (especially those provides with some eval boards for
demonstration purpose) will NOT work with Linux. Remember that the
memory map is usually not cast in silicon, but implemented in
software, so you can change it as needed.
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
C++ was an interesting and valuable experiment, but we've learned its
lessons and it's time to move on.
- Peter Curran in <DCqM4z.BxB@isgtec.com>
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Jerry Van Baren @ 2006-03-03 16:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060303135717.GA5707@suse.de>
Olaf Hering wrote:
> Some G5 and pSeries models dont boot with recent kernels. The reason is
> likely the casting of pointers of stack variables to u32. One example is
> the prom_getprop() call in prom_init_stdout().
>
> sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> address is casted to u32, which changes it to 0x0023e7f8. The firmware
> writes to the wrong addres and things go downhill very quick.
>
> c00000000040baa8: 3b 21 00 78 addi r25,r1,120
> ..
> c00000000040baf4: 57 28 00 38 rlwinm r8,r25,0,0,28
> ..
> c00000000040bb10: 4b ff d3 3d bl c000000000408e4c <.call_prom>
>
> If I remove the casts and pass the pointer as is, everything starts to
> work as expected? Why is all this (u32)(unsigned long) casting in
> arch/powerpc/kernel/prom_init.c required?
>
> Does -Os vs -O2 make a difference here?
Hi Olaf, me again...
<http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/RS_002f6000-and-PowerPC-Options.html>
Looks like you should use -malign-natural to make it do what you want it
to do:
-malign-natural
-malign-power
On AIX, 32-bit Darwin, and 64-bit PowerPC GNU/Linux, the option
-malign-natural overrides the ABI-defined alignment of larger types,
such as floating-point doubles, on their natural size-based boundary.
The option -malign-power instructs GCC to follow the ABI-specified
alignment rules. GCC defaults to the standard alignment defined in the ABI.
On 64-bit Darwin, natural alignment is the default, and
-malign-power is not supported.
gvb
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Jerry Van Baren @ 2006-03-03 15:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060303135717.GA5707@suse.de>
Olaf Hering wrote:
> Some G5 and pSeries models dont boot with recent kernels. The reason is
> likely the casting of pointers of stack variables to u32. One example is
> the prom_getprop() call in prom_init_stdout().
>
> sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> address is casted to u32, which changes it to 0x0023e7f8. The firmware
> writes to the wrong addres and things go downhill very quick.
>
> c00000000040baa8: 3b 21 00 78 addi r25,r1,120
> ..
> c00000000040baf4: 57 28 00 38 rlwinm r8,r25,0,0,28
> ..
> c00000000040bb10: 4b ff d3 3d bl c000000000408e4c <.call_prom>
>
> If I remove the casts and pass the pointer as is, everything starts to
> work as expected? Why is all this (u32)(unsigned long) casting in
> arch/powerpc/kernel/prom_init.c required?
>
> Does -Os vs -O2 make a difference here?
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi Olaf,
The casting is 8-byte aligning the address because it is a 64 bit
variable and it is frowned on (and on some processors, fatal) to have an
8-byte variable misaligned (not on a 8 byte boundary).
In your example above, the variable is named "sp"... the sp is suppose
to be on a 8 byte boundary per the EABI (quoted below... note that the
ABI requires it to be on a 16 byte boundary):
----
The Stack Frame
Unlike the SVR4 ABI, the stack pointer (GPR1) shall maintain 8-byte
alignment, from initialization through all routine calls and dynamic
stack space allocation.
----
In the instance above, the proper solution (but I don't know if it is a
realistic solution :-/) is to properly align the stack pointer on a 8
byte boundary. I also don't know if there are other, non sp variable,
problems. It sounds like the prom isn't 64 bit clean. What are our
options to make it 64 bit clean?
Disclaimer: Yeah, I know most PPCs handle misaligned longs, but that
doesn't make it _right_ and it definitely doesn't make it efficient.
gvb
^ permalink raw reply
* fbdev_drv/xfree86 getting rid of /dev/tty0 console
From: Arun @ 2006-03-03 16:27 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: RASS Arun
[-- Attachment #1: Type: text/plain, Size: 138 bytes --]
Hello Sir
I am also getting the same error with ELDK 3.1 ppc_7xx, so please help us if u are able to solve it.
Regards
Arun Kumar
[-- Attachment #2: Type: text/html, Size: 737 bytes --]
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-03 16:53 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060303160434.3886335261F@atlas.denx.de>
>>If the vendor provided the VxWorks BSP, then hopefully they
>>also provided you with the physical memory map of the board.
>>This is what you really need to get another bootloader (eg. U-Boot)
>
> This is *NOT* corect, and actually dangerous.
Thanks Wolfgang!
I did start the email with "I'm not an expert on this ...".
>>Step 1. Get the memory map of the board.
>
> Never use any given memory map unreflected. At least *check* if it's
> usable with Linux.
>
> Many memory maps (especially those provides with some eval boards for
> demonstration purpose) will NOT work with Linux. Remember that the
> memory map is usually not cast in silicon, but implemented in
> software, so you can change it as needed.
Right, thats I made sure to say; Physical Memory Map.
For example, on the Artesyn manual on their PrPMC they give a
physical memory map, and in the Yosemite board, there is a
physical memory map. I know many of the memory areas can be
redefined in hardware to have a different memory location, but
its still a physical address.
Now, when the bootloader loads, eg. U-Boot, it sets up the
memory management. Now this is where my understanding gets
shakey, since I haven't looked at much of the code, so perhaps
you can clarify. The translation unit (TLB) maps virtual addresses
(or should that be MMU output addresses) into physical addresses,
and for the Yosemite port the default translation
addresses appear to be identical to the physical addresses,
though obviously this doesn't have to be the case. Then on
top of that there is virtual memory addresses generated by
the core (input to the MMU if its enabled?), that then go
through the MMU/TLB and get mapped to physical addresses. If
I was going to do a port, obviously I'd take the time to
understand this fully :) (I think the Linux Kernel Internals
book has a description, but its usually meaningless to me until
I play with the code).
What are the basic requirements for a Linux memory map then?
Cheers
Dave
^ permalink raw reply
* [PATCH] Workaround gcc bug #26549 which causes pointers to be truncated.
From: Olaf Hering @ 2006-03-03 16:52 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackeras
In-Reply-To: <20060303135717.GA5707@suse.de>
Workaround gcc bug #26549 which causes pointers to be truncated.
The address of variable val in prom_init_stdout is passed to prom_getprop.
prom_getprop casts the pointer to u32 and passes it to call_prom in the hope
that OpenFirmware stores something there.
But the pointer is truncated in the lower bits and the expected value is
stored somewhere else.
This gcc bug does not exist in SLES9 gcc33 toolchain, but it is present in
gcc4.0+, likely also in gcc3.4. Compiling a testcase without any -O produces
also correct code.
In my testing I had a stackpointer of 0x0023e6b4. val was at offset 120,
wich has address 0x0023e72c. But the value passed to OF was 0x0023e728.
c00000000040b710: 3b 01 00 78 addi r24,r1,120
...
c00000000040b754: 57 08 00 38 rlwinm r8,r24,0,0,28
...
c00000000040b784: 80 01 00 78 lwz r0,120(r1)
...
c00000000040b798: 90 1b 00 0c stw r0,12(r27)
...
simple testcase:
int f(unsigned);
void g(void)
{
unsigned a;
unsigned int b = (unsigned long)(void*)(&a);
f(b);
}
asm should look like this:
c: 38 61 00 70 addi r3,r1,112
10: 78 63 00 20 clrldi r3,r3,32
14: 48 00 00 01 bl 14 <.g+0x14>
But instead it looks like:
c: 38 61 00 70 addi r3,r1,112
10: 54 63 00 36 rlwinm r3,r3,0,0,27
14: 48 00 00 01 bl 14 <.g+0x14>
So just uninline prom_getprop to workaround this gcc bug.
c000000000409034 <.prom_getprop>:
c000000000409054: 7c bc 2b 78 mr r28,r5
c000000000409074: 7b 88 00 20 clrldi r8,r28,32
...
c00000000040b29c <.prom_init>:
...
c00000000040b3d0: 3b 41 00 74 addi r26,r1,116
...
c00000000040b3f8: e8 82 a4 a8 ld r4,-23384(r2)
c00000000040b3fc: 7f 45 d3 78 mr r5,r26
c00000000040b404: 80 7d 00 04 lwz r3,4(r29)
c00000000040b408: 38 c0 00 04 li r6,4
c00000000040b410: 4b ff dc 25 bl c000000000409034 <.prom_getprop>
...
c00000000040b424: 80 01 00 74 lwz r0,116(r1)
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/prom_init.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
@@ -422,7 +422,8 @@ static int __init prom_next_node(phandle
}
}
-static int inline prom_getprop(phandle node, const char *pname,
+/* do not mark as inline to work around gcc bug #26549 */
+static int __init prom_getprop(phandle node, const char *pname,
void *value, size_t valuelen)
{
return call_prom("getprop", 4, 1, node, ADDR(pname),
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Olaf Hering @ 2006-03-03 17:24 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev
In-Reply-To: <44086B5E.60201@smiths-aerospace.com>
On Fri, Mar 03, Jerry Van Baren wrote:
> Looks like you should use -malign-natural to make it do what you want it
Same story.
c00000000040b924: 3b 01 00 78 addi r24,r1,120
c00000000040b968: 57 08 00 38 rlwinm r8,r24,0,0,28
c00000000040b984: 4b ff d6 01 bl c000000000408f84 <.call_prom>
c00000000040b998: 80 01 00 78 lwz r0,120(r1)
,28 is even worse.
^ permalink raw reply
* [PATCH] mark a few functions as __init
From: Olaf Hering @ 2006-03-03 17:34 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Mark a few functions as __init.
IFF gcc does not inline them, they end up in .text.
Make 2 local functions static.
Mark fake_elf as initdata.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/prom_init.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
@@ -435,7 +435,7 @@ static int inline prom_getproplen(phandl
return call_prom("getproplen", 2, 1, node, ADDR(pname));
}
-static void add_string(char **str, const char *q)
+static void __init add_string(char **str, const char *q)
{
char *p = *str;
@@ -445,7 +445,7 @@ static void add_string(char **str, const
*str = p;
}
-static char *tohex(unsigned int x)
+static char __init *tohex(unsigned int x)
{
static char digits[] = "0123456789abcdef";
static char result[9];
@@ -492,7 +492,7 @@ static int __init prom_setprop(phandle n
#define islower(c) ('a' <= (c) && (c) <= 'z')
#define toupper(c) (islower(c) ? ((c) - 'a' + 'A') : (c))
-unsigned long prom_strtoul(const char *cp, const char **endp)
+static unsigned long __init prom_strtoul(const char *cp, const char **endp)
{
unsigned long result = 0, base = 10, value;
@@ -517,7 +517,7 @@ unsigned long prom_strtoul(const char *c
return result;
}
-unsigned long prom_memparse(const char *ptr, const char **retptr)
+static unsigned long __init prom_memparse(const char *ptr, const char **retptr)
{
unsigned long ret = prom_strtoul(ptr, retptr);
int shift = 0;
@@ -659,7 +659,7 @@ static struct fake_elf {
u32 ignore_me;
} rpadesc;
} rpanote;
-} fake_elf = {
+} fake_elf __initdata = {
.elfhdr = {
.e_ident = { 0x7f, 'E', 'L', 'F',
ELFCLASS32, ELFDATA2MSB, EV_CURRENT },
@@ -891,7 +891,7 @@ static unsigned long __init prom_next_ce
* If problems seem to show up, it would be a good start to track
* them down.
*/
-static void reserve_mem(u64 base, u64 size)
+static void __init reserve_mem(u64 base, u64 size)
{
u64 top = base + size;
unsigned long cnt = RELOC(mem_reserve_cnt);
^ permalink raw reply
* RE: INIT:
From: Patil, Pankaj P. @ 2006-03-03 18:58 UTC (permalink / raw)
To: linuxppc-embedded
I do have /dev/console in my file system. In fact , i used ethereal on =
the host to see how far the INIT goes.
I saw all the usual NFS Lookup calls like /lib, /ld-2.3.1.so ..... =
/libc-2.31.so
The last NFS lookup call looks like DH:0xbea72a4a/tty0
There are bunch of read replys after that but no more NFS lookups. Is it =
normal to see a NFS Lookup that looks like 0xbea72a4a/tty0 ??
What should be the next NFS Lookup call?
I did some searching from previous posts but haven't found exactly what =
i am looking for. I am attaching a link to something that looks similar =
to my problem. Just in case, someone's having trouble understanding my =
issue.
http://ozlabs.org/pipermail/linuxppc-embedded/2004-August/015250.html
Thanks
pankaj
-----Original Message-----
From: atul.sabharwal@exgate.tek.com
[mailto:atul.sabharwal@exgate.tek.com]
Sent: Tuesday, February 28, 2006 6:03 PM
To: Patil, Pankaj P.
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: INIT:
Easy answer is do you have /dev/console in your file system. Glibc
opens
/dev/console and the kernel uses /dev/ttyS0 as specified on the command
line. There should not be any app calling uart_close as the console
deriver
should be opening it.=20
--
Atul
Hi,
I am running u-boot & linux2.6.12 on a custom ppc board(functional HW).
I can get to the point where u-boot loads the kernel, kernel does all
the initialization, loads the Root File System over NFS & calls the
Init process.
Next, i am expecting to see a shell prompt. I am not sure where in the
Init process i am failing. I have written my own serial driver(Philips
SC28L194 Quad UART--under development-possible culprit). The printks
work just fine.
All i see is the kernel calling the Init process & after a minute or so
i see uart_close call.
The kernel runs just fine & responds to ping.
What can trigger a uart_close??(tty_release calls release_dev calls
uart_close) I have a JTAG debugger. What's the best way to debug once
Init process is running??
I am attaching a dump of my console:
U-Boot 1.1.3 (Dec 16 2005 - 16:00:23), Build: 0.4.1
SysClock =3D 120Mhz , TClock =3D 120Mhz=20
CPU: MPC7447A v1.1 @ 960 MHz
CPU bus mode : 60x
DRAM: SPD Checksum ok!
-- DIMM1 has 2 banks
-- DIMM2 has 0 banks
ECC Initialization of Bank 0: Done
CAS Latency =3D 2 tRP =3D 3 tRAS =3D 6 tRCD=3D3
Total SDRAM memory is 1024 MB
Now running in RAM - U-Boot at: 00fc0000
Remapped Internal SRAM to 0xf2000000
Remapped Flash Card to 0xffc00000
FLASH: 4 MB
Addresses 32M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (32M - 16M): Done
Internal SRAM ECC Initialization: Done
***Phy Reset***
Phy Auto-Negotiation Bit ReEnabled in SW
Net: , mv_enet1 [PRIME]
Hit any key to stop autoboot: 0=20
Ethernet status port 1: Link up, Full Duplex, Speed 100 Mbps
Using mv_enet1 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.2
Filename 'uImage'.
Load address: 0x400000
Loading:
#################################################################
=20
#################################################################
=20
#################################################################
########################
done
Bytes transferred =3D 1119847 (111667 hex)
### Network statistics: ###
--------------------------
Packets received: 2192
Packets send: 2191
Received bytes: 2347583
Send bytes: 100803
## Booting image at 00400000 ...
Image Name: Linux-2.6.12
Created: 2006-02-14 0:37:17 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1119783 Bytes =3D 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## cmdline at 0x007FFF00 ... 0x007FFF98
memstart =3D 0x00000000
memsize =3D 0x40000000
flashstart =3D 0xFFC00000
flashsize =3D 0x00400000
flashoffset =3D 0x00000000
sramstart =3D 0xF8000000
sramsize =3D 0x00400000
bootflags =3D 0x00000001
intfreq =3D 960 MHz
busfreq =3D 120 MHz
ethaddr =3D 64:00:00:00:00:00
IP addr =3D 192.168.1.2
baudrate =3D 115200 bps
tclk =3D 0 MHz
uboot_ver =3D 0.4.1a=20
L3 was init =3D 0
Total memory =3D 768MB; using 2048kB for hash table (at c0400000)
Linux version 2.6.12 (root@RHEL40) (gcc version 3.3.3 (DENX ELDK 3.1.1
3.3.3-10)) #154 Mon Feb 13 17:36:35 MST 2006
System Identification:=20
Freescale 74XX port=20
Built 1 zonelists =20
Kernel command line: console=3DttyS0,115200 root=3D/dev/nfs rw
nfsroot=3D192.168.1.1:/target/chestnut/rootfs
ip=3D192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:DB64xxx:eth0:non
e
PID hash table entries: 4096 (order: 12, 65536 bytes)
time_init: decrementer frequency =3D 30.000000 MHz =20
Console: colour dummy device 80x25 =20
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) =20
Memory: 774400k available (1596k kernel code, 556k data, 344k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16=20
PCI: Probing PCI hardware =20
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Generic RTC Driver v1.07 =20
Serial: SC28L194 driver 4 ports
ttyS0 at MMIO 0x0 (irq =3D 17) is a PHILIPS SC28L194
ttyS1 at MMIO 0x0 (irq =3D 17) is a PHILIPS SC28L194
ttyS2 at MMIO 0x0 (irq =3D 17) is a PHILIPS SC28L194
ttyS3 at MMIO 0x0 (irq =3D 17) is a PHILIPS SC28L194
io scheduler noop registered =20
io scheduler anticipatory registered
io scheduler deadline registered =20
io scheduler cfq registered =20
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices) =20
MV-643xx 10/100/1000 Ethernet Driver
eth0: port 1 with MAC address 00:11:85:da:0b:02
eth0: RX NAPI Enabled =20
physmap flash device: 400000 at ffc00000
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2 =20
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes) =20
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1 =20
NET: Registered protocol family 17
IP-Config: Complete: =20
device=3Deth0, addr=3D192.168.1.2, mask=3D255.255.255.0, =
gw=3D192.168.1.1,
host=3DDB64xxx, domain=3D, nis-domain=3D(none), =
=20
bootserver=3D192.168.1.1, rootserver=3D192.168.1.1, rootpath=3D
Looking up port of RPC 100003/2 on 192.168.1.1 =20
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem). =20
Freeing unused kernel memory: 344k init
Any help appreceated.
Thanks
pankaj
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] force stackpointer alignment in 64bit kernel
From: Olaf Hering @ 2006-03-03 19:16 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackeras
In-Reply-To: <20060303165253.GA6494@suse.de>
Fix gcc "bug" #26549 which causes pointers to be truncated.
The address of variable val in prom_init_stdout is passed to prom_getprop.
prom_getprop casts the pointer to u32 and passes it to call_prom in the hope
that OpenFirmware stores something there.
But the pointer is truncated in the lower bits and the expected value is
stored somewhere else.
In my testing I had a stackpointer of 0x0023e6b4. val was at offset 120,
wich has address 0x0023e72c. But the value passed to OF was 0x0023e728.
c00000000040b710: 3b 01 00 78 addi r24,r1,120
...
c00000000040b754: 57 08 00 38 rlwinm r8,r24,0,0,28
...
c00000000040b784: 80 01 00 78 lwz r0,120(r1)
...
c00000000040b798: 90 1b 00 0c stw r0,12(r27)
...
The stackpointer came from 32bit code, which appearently has different
alignment rules than 64bit code. The chain was yaboot -> zImage -> vmlinux
Force the stackpointer to be 16 byte aligned.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/head_64.S | 2 ++
1 files changed, 2 insertions(+)
Index: linux-2.6.16-rc5-olh/arch/powerpc/kernel/head_64.S
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/kernel/head_64.S
+++ linux-2.6.16-rc5-olh/arch/powerpc/kernel/head_64.S
@@ -1547,6 +1547,8 @@ _STATIC(__boot_from_prom)
mr r27,r7
/* Make sure we are running in 64 bits mode */
+ addi r1,r1,16
+ rlwinm r1,r1,0,0,28
bl .enable_64b_mode
/* put a relocation offset into r3 */
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Olaf Hering @ 2006-03-03 19:23 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackeras
In-Reply-To: <20060303191633.GA7792@suse.de>
On Fri, Mar 03, Olaf Hering wrote:
> + addi r1,r1,16
Guess that should be -16 ...
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Segher Boessenkool @ 2006-03-03 19:29 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303191633.GA7792@suse.de>
> The stackpointer came from 32bit code, which appearently has different
> alignment rules than 64bit code. The chain was yaboot -> zImage ->
> vmlinux
> Force the stackpointer to be 16 byte aligned.
The stack pointer is required to be 16-byte aligned when the
client program is started, on 32-bit as well.
> /* Make sure we are running in 64 bits mode */
> + addi r1,r1,16
> + rlwinm r1,r1,0,0,28
> bl .enable_64b_mode
Not addi +16, not -16, just no addi at all...
Segher
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Segher Boessenkool @ 2006-03-03 19:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <3E10742C-61F9-417C-A191-C0C8C46A4529@kernel.crashing.org>
>> /* Make sure we are running in 64 bits mode */
>> + addi r1,r1,16
>> + rlwinm r1,r1,0,0,28
>> bl .enable_64b_mode
>
> Not addi +16, not -16, just no addi at all...
Not rlwinm either, GPR1 can potentially be at >= 4GB
(of course we'd probably hit other problems then, but hey).
So please use rldicr or similar.
Segher
^ permalink raw reply
* VLAN support on TSEC
From: Bizhan Gholikhamseh (bgholikh) @ 2006-03-03 19:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
Hi All,
We are using custom board 8541 based processor, running Linux version
2.6.11.
In our board, the TSEC interface is connected to a BCM switch chip. We
need to configure the interface to support VLAN . The TSEC hardware has
no VLAN support and the current driver, gianfar.c, has no support for
VLAN either. Are there any implementation of gianfar.c which supports
VLAN?
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1211 bytes --]
^ permalink raw reply
* RE: Linux on PPC
From: Rune Torgersen @ 2006-03-03 19:39 UTC (permalink / raw)
To: David Hawkins, Wolfgang Denk; +Cc: linuxppc-embedded
=20
> From: David Hawkins
> Sent: Friday, March 03, 2006 10:53
> To: Wolfgang Denk
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on PPC
>=20
> Right, thats I made sure to say; Physical Memory Map.
>=20
> For example, on the Artesyn manual on their PrPMC they give a
> physical memory map, and in the Yosemite board, there is a
> physical memory map. I know many of the memory areas can be
> redefined in hardware to have a different memory location, but
> its still a physical address.
>=20
Still not right. Even the physical memory is software settable. What
matters is what chip-select things are hooked up to, and then map those
chip selects correctly (size, base address, access with and so on)
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-03 20:06 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B8595AC@ismail.innsys.innovsys.com>
>>Right, thats I made sure to say; Physical Memory Map.
>>
>>For example, on the Artesyn manual on their PrPMC they give a
>>physical memory map, and in the Yosemite board, there is a
>>physical memory map. I know many of the memory areas can be
>>redefined in hardware to have a different memory location, but
>>its still a physical address.
>>
>
> Still not right. Even the physical memory is software settable. What
> matters is what chip-select things are hooked up to, and then map those
> chip selects correctly (size, base address, access with and so on)
Hi Rune,
Thanks for responding.
Thats what I meant with 'redefined in hardware'. But yes, redefined
up to the limit of the wiring on the board of course (chip-selects
and bus widths). That's where having the board schematic is
invaluable.
But ok, I'm pretty sure I get the point, and hopefully the
original poster understands a bit more too.
Given a board that you expect to run Linux on, I would imagine
you would select hardware settings consistent with making
Linux happy, i.e., defining 'in software' (the bootloader)
the physical address map (eg. like the Embedded Planet reference
manual for the 440EP Yosemite board), and then setup U-Boot and
Linux to program the TLBs to translate to those same addresses.
When looking at the Yosemite board, I booted U-Boot and compared
device dcr settings to the recommended ones in the EP manual. Then
when I booted Linux, I took a look and found that on the whole, Linux
didn't touch too much of the things setup by U-Boot, i.e., the
responsibility for setting up the Linux environment was mainly
the job of the bootloader.
So, if I had a board with a custom bootloader, I would be
concerned that the bootloader might not know enough about
Linux, to setup the hardware correctly.
Does that sound right?
Dave
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Olaf Hering @ 2006-03-03 20:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <3E10742C-61F9-417C-A191-C0C8C46A4529@kernel.crashing.org>
On Fri, Mar 03, Segher Boessenkool wrote:
> >The stackpointer came from 32bit code, which appearently has different
> >alignment rules than 64bit code. The chain was yaboot -> zImage ->
> >vmlinux
> >Force the stackpointer to be 16 byte aligned.
>
> The stack pointer is required to be 16-byte aligned when the
> client program is started, on 32-bit as well.
So the magic word is yaboot.
^ permalink raw reply
* powerpc: set ARCH_KMALLOC_MINALIGN if CONFIG_NOT_COHERENT_CACHE=y
From: Dale Farnsworth @ 2006-03-03 20:09 UTC (permalink / raw)
To: linuxppc-dev
From: Dale Farnsworth <dale@farnsworth.org>
Ensure that buffers returned by kmalloc do not share a cache
line with other data when doing non-cache-coherent I/O.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
Without this patch, when CONFIG_SLAB_DEBUG=y, the buffer
allocated by kmalloc shares a cache line with the redzone1 area.
This can cause false messages of this type:
slab error in cache_free_debugcheck(): cache `size-2048':
double free, or memory outside object was overwritten
We could work around it in each driver, but ARCH_KMALLOC_MINALIGN
is provided for this purpose, so use it.
include/asm-powerpc/cache.h | 4 ++++
1 file changed, 4 insertions(+)
Index: linux-2.6-mv643xx_enet/include/asm-powerpc/cache.h
===================================================================
--- linux-2.6-mv643xx_enet.orig/include/asm-powerpc/cache.h
+++ linux-2.6-mv643xx_enet/include/asm-powerpc/cache.h
@@ -20,6 +20,10 @@
#define SMP_CACHE_BYTES L1_CACHE_BYTES
+#ifdef CONFIG_NOT_COHERENT_CACHE
+#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
+#endif
+
#if defined(__powerpc64__) && !defined(__ASSEMBLY__)
struct ppc64_caches {
u32 dsize; /* L1 d-cache size */
^ permalink raw reply
* RE: Linux on PPC
From: Rune Torgersen @ 2006-03-03 20:31 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
> From: David Hawkins [mailto:dwh@ovro.caltech.edu]=20
> Sent: Friday, March 03, 2006 14:07
> To: Rune Torgersen
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on PPC
>=20
>=20
> >>Right, thats I made sure to say; Physical Memory Map.
> >>
> >>For example, on the Artesyn manual on their PrPMC they give a
> >>physical memory map, and in the Yosemite board, there is a
> >>physical memory map. I know many of the memory areas can be
> >>redefined in hardware to have a different memory location, but
> >>its still a physical address.
> >>
> >=20
> > Still not right. Even the physical memory is software settable. What
> > matters is what chip-select things are hooked up to, and=20
> then map those
> > chip selects correctly (size, base address, access with and so on)
>=20
> Hi Rune,
>=20
> Thanks for responding.
>=20
> Thats what I meant with 'redefined in hardware'. But yes, redefined
> up to the limit of the wiring on the board of course (chip-selects
> and bus widths). That's where having the board schematic is
> invaluable.
> Does that sound right?
Yes.
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Olaf Hering @ 2006-03-03 20:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20060303200920.GA8177@suse.de>
On Fri, Mar 03, Olaf Hering wrote:
> So the magic word is yaboot.
sp was 0x0023e6b4 when entering zImage.
yaboot_start has 64 bytes
yaboot_main has 304 bytes
This would mean the stackpointer for yaboot was 0x0023e824.
Will check on Monday.
^ permalink raw reply
* RE: Linux on PPC
From: Steve Strublic @ 2006-03-03 20:28 UTC (permalink / raw)
To: David Hawkins, Rune Torgersen; +Cc: linuxppc-embedded
> -----Original Message-----
> From: linuxppc-embedded-bounces+sstrublic=3Dhypercom.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+sstrublic=3Dhypercom.com@ozlabs.org]
On
> Behalf Of David Hawkins
> Sent: Friday, March 03, 2006 1:07 PM
> To: Rune Torgersen
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on PPC
>=20
>=20
> >>Right, thats I made sure to say; Physical Memory Map.
> >>
> >>For example, on the Artesyn manual on their PrPMC they give a
> >>physical memory map, and in the Yosemite board, there is a
> >>physical memory map. I know many of the memory areas can be
> >>redefined in hardware to have a different memory location, but
> >>its still a physical address.
> >>
> >
> > Still not right. Even the physical memory is software settable. What
> > matters is what chip-select things are hooked up to, and then map
those
> > chip selects correctly (size, base address, access with and so on)
>=20
> Hi Rune,
>=20
> Thanks for responding.
>=20
> Thats what I meant with 'redefined in hardware'. But yes, redefined
> up to the limit of the wiring on the board of course (chip-selects
> and bus widths). That's where having the board schematic is
> invaluable.
>=20
> But ok, I'm pretty sure I get the point, and hopefully the
> original poster understands a bit more too.
>=20
> Given a board that you expect to run Linux on, I would imagine
> you would select hardware settings consistent with making
> Linux happy, i.e., defining 'in software' (the bootloader)
> the physical address map (eg. like the Embedded Planet reference
> manual for the 440EP Yosemite board), and then setup U-Boot and
> Linux to program the TLBs to translate to those same addresses.
>=20
> When looking at the Yosemite board, I booted U-Boot and compared
> device dcr settings to the recommended ones in the EP manual. Then
> when I booted Linux, I took a look and found that on the whole, Linux
> didn't touch too much of the things setup by U-Boot, i.e., the
> responsibility for setting up the Linux environment was mainly
> the job of the bootloader.
>=20
> So, if I had a board with a custom bootloader, I would be
> concerned that the bootloader might not know enough about
> Linux, to setup the hardware correctly.
The boot loader should, ideally, NOT know anything about Linux except
for knowing that since a Linux is being loaded, it requires some
information at boot time, and the format in which to provide said
information.
Steve
>=20
> Does that sound right?
>=20
> Dave
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: powerpc: set ARCH_KMALLOC_MINALIGN if CONFIG_NOT_COHERENT_CACHE=y
From: Dale Farnsworth @ 2006-03-03 21:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060303200928.GA29099@xyzzy.farnsworth.org>
In article <20060303200928.GA29099@xyzzy.farnsworth.org> you write:
> Ensure that buffers returned by kmalloc do not share a cache
> line with other data when doing non-cache-coherent I/O.
Eugene Surovegin points out that ARCH_KMALLOC_MINALIGN
doesn't work as avertised.
This patch doesn't work.
Thanks,
-Dale
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Olaf Hering @ 2006-03-03 23:23 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <3E10742C-61F9-417C-A191-C0C8C46A4529@kernel.crashing.org>
On Fri, Mar 03, Segher Boessenkool wrote:
> > The stackpointer came from 32bit code, which appearently has different
> > alignment rules than 64bit code. The chain was yaboot -> zImage ->
> > vmlinux
> > Force the stackpointer to be 16 byte aligned.
>
> The stack pointer is required to be 16-byte aligned when the
> client program is started, on 32-bit as well.
See http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021342.html
Either yaboot and/or zImage need to force a stack alignment, or we apply
the 2 liner.
^ permalink raw reply
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Paul Nasrat @ 2006-03-03 23:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303232334.GA9577@suse.de>
On Sat, 2006-03-04 at 00:23 +0100, Olaf Hering wrote:
> On Fri, Mar 03, Segher Boessenkool wrote:
>
> > > The stackpointer came from 32bit code, which appearently has different
> > > alignment rules than 64bit code. The chain was yaboot -> zImage ->
> > > vmlinux
> > > Force the stackpointer to be 16 byte aligned.
> >
> > The stack pointer is required to be 16-byte aligned when the
> > client program is started, on 32-bit as well.
>
> See http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021342.html
>
> Either yaboot and/or zImage need to force a stack alignment, or we apply
> the 2 liner.
Happy to look at/receive patches for yaboot. I'll look on Monday.
Paul
^ 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