* 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
* Re: [PATCH] force stackpointer alignment in 64bit kernel
From: Segher Boessenkool @ 2006-03-04 0:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303232334.GA9577@suse.de>
>> 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.
Yaboot should do it. Of course, it won't hurt if the kernel will
do it itself, too...
Segher
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-04 2:05 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <44087473.6020905@ovro.caltech.edu>
In message <44087473.6020905@ovro.caltech.edu> you wrote:
>
> > 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.
That's what I mean: the physical memory map is usually set up in
software, so it can be changed to your needs.
> 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.
...which usually can be reprogrammed in software.
> 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,
U-Boot usually does not use the MMU.
> What are the basic requirements for a Linux memory map then?
See the FAQ.
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
It is surely a great calamity for a human being to have no ob-
sessions. - Robert Bly
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-04 2:09 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4408A1D3.8010506@ovro.caltech.edu>
In message <4408A1D3.8010506@ovro.caltech.edu> you wrote:
>
> > 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)
>
> 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.
You don't get it. You can map - for example - your flash to physical
address 0x0000 or 0x04000000 or 0x40000000 or 0xFFF00000 as you like
- without any changes to the hardware, and without using the MMU.
Mind: that's all *physical* addresses.
> manual for the 440EP Yosemite board), and then setup U-Boot and
> Linux to program the TLBs to translate to those same addresses.
No. U-Boot does not use the MMU.
> 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.
Wrong again. Linux completely re-initializes the whole memory
management.
> 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?
No, it's wrong.
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
"Language shapes the way we think, and determines what we can think
about." - B. L. Whorf
^ permalink raw reply
* Different Page Size Support in Linux on PPC870
From: atul.sabharwal @ 2006-03-04 2:38 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
On PPC870, does the kernel only support 4K pages? To reduce the size of
page table (level & level 2), would 8M page be a better choice on a
custom=20
board? It's a no swap configuration. Memory load is critical in our
design on this project.
Comments?
Thanks,
Atul
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-04 2:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060304020938.00774352627@atlas.denx.de>
Hi Wolfgang,
> You don't get it.
Ok, I'll read-up and try to 'get it'.
Thanks
Dave
^ permalink raw reply
* Re: boot failure on lite5200b board
From: Sylvain Munaut @ 2006-03-04 9:17 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: haidong_feng, linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D96@mail02.student.main.ntu.edu.sg>
Hi,
#LI JIANGGAN# wrote:
> Thanks John, the Kernel now boots well. However it gives a kernel panic
> while mounting the root file sysem over NFS:
>
> Looking up port of RPC 100003/2 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get nfsd port number from server, using default
>
> I couldn't figure out why error 101 /* Network is unreachable */ is
> given. Below is my current U-boot settings and a snapshot of the booting:
Didn't I told you to try the tree I on http://gitbits.246tnt.com ?
I don't know the tree you're using but it doesn't seem to be mine ...
(nor any of the previous version i published).
I you want to have the most "complete" stuff i publish, clone the
mainstream, pull from my ide branch and then pull from the bestcomm branch.
There is also the denx tree but I don't know it's status.
> Linux version 2.6.11.7 (root@bob) (gcc version 3.3.2) #1 Tue Sep 6
> 22:40:03 UTC 2005
^^^^^^^^^^^^^^^^^^^^^^^^^^
my tree is based on something more recent
> Real-Time Preemption Support (c) Ingo Molnar
> Built 1 zonelists
> Kernel command line: console=ttyS0,115200
^^^^^^^^^^^^^^^^^^^^
You would see nothing with the tree of gitbits.246tNt.com with that
command line. You need ttyPSC0 ...
> nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
> PID hash table entries: 2048 (order: 11, 32768 bytes)
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 256268k available (2336k kernel code, 896k data, 140k init, 0k
> highmem)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> BUG: scheduling while atomic: swapper/0x00000001/0
> caller is schedule+0x50/0xe8
> Call trace:
> [c0006bd8] dump_stack+0x18/0x28
> [c0242818] __sched_text_start+0x69c/0x6a0
> [c024286c] schedule+0x50/0xe8
> [c0003f00] syscall_exit_work+0x108/0x10c
> [c030c578] proc_root_init+0x144/0x150
> [c0320000] 0xc0320000
> [c02fe624] start_kernel+0x180/0x1b8
> [000035fc] 0x35fc
> spawn_desched_task(00000000)
> desched cpu_callback 3/00000000
> ksoftirqd started up.
> softirq RT prio: 24.
> desched cpu_callback 2/00000000
> desched thread 0 started up.
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> SCSI subsystem initialized
> usbcore: registered new driver usbfs
> usbcore: registered new driver hub
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
> ppdev: user-space parallel port driver
> Serial: MPC52xx PSC driver
> ttyS0 at MMIO 0xf0002000 (irq = 39) is a MPC52xx PSC
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
> loop: loaded (max 8 devices)
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ipb=132MHz, set clock period to 7
> GPIO config: 91051024
> ATA invalid: 01000000
> ATA hostcnf: 03000000
> ATA pio1 : 100a0a00
> ATA pio2 : 02040600
> XLB Arb cnf: 0000a366
> mpc52xx_ide: Setting up IDE interface ide0...
> flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x0 in
> 8-bit bank
> flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x1000000
> in 8-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> flash chip on the Lite5200/Lite5200B: CFI does not contain boot bank
> location. Assuming top.
> number of CFI chips: 2
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> Creating 7 MTD partitions on "flash chip on the Lite5200/Lite5200B":
> 0x00000000-0x01000000 : "Filesystem"
> 0x01000000-0x01040000 : "BootLOW"
> 0x01040000-0x01060000 : "EnvLOW"
> 0x01060000-0x01d00000 : "Spare"
> 0x01d00000-0x01f00000 : "Kernel"
> 0x01f00000-0x01f40000 : "BootHIGH"
> 0x01f40000-0x01f60000 : "EnvHIGH"
> ocp-ohci 02: new USB bus registered, assigned bus number 1
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.
> usbcore: registered new driver usbhid
> drivers/usb/input/hid-core.c: v2.0:USB HID core driver
> mice: PS/2 mouse device common for all mice
> i2c /dev entries driver
> i2c-algo-52xx.o: scanning bus Lite5200 I2C module #1 interface...
> ................................................................................................................................
> i2c-lite5200.o: I2C module #1 installed
> i2c-algo-52xx.o: scanning bus Lite5200 I2C module #2 interface...
> ................................................................................(0x50)..............................................(0x7f)
> i2c-lite5200.o: I2C module #2 installed
> Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13
> 09:39:32 2005 UTC).
> ALSA device list:
> No soundcards found.
> NET: Registered protocol family 2
> IP: routing cache hash table of 256 buckets, 16Kbytes
> TCP established hash table entries: 16384 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 16384 (order: 7, 917504 bytes)
> TCP: Hash tables configured (established 16384 bind 16384)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Looking up port of RPC 100003/2 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get nfsd port number from server, using default
> Looking up port of RPC 100005/1 on 10.190.3.103
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get mountd port number from server, using default
> RPC: sendmsg returned error 101
> mount: RPC call returned error 101
> Root-NFS: Server returned error -101 while mounting /opt/eldk-4-0/nfs
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or unknown-block(2,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> <0>Rebooting in 180 seconds..
^ permalink raw reply
* [PATCH] correct cacheflush loop in zImage
From: Olaf Hering @ 2006-03-04 12:15 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Correct the loop for cacheflush. No idea where I copied the code from,
but the original does not work correct. Maybe the flush is not needed.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/boot/crt0.S | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/boot/crt0.S
+++ linux-2.6.16-rc5-olh/arch/powerpc/boot/crt0.S
@@ -45,7 +45,8 @@ _zimage_start:
bdnz 2b
/* Do a cache flush for our text, in case OF didn't */
-3: lis r9,_start@h
+3: lis r9,_start@ha
+ addi r9,r9,_start@l
add r9,r0,r9
lis r8,_etext@ha
addi r8,r8,_etext@l
@@ -53,7 +54,7 @@ _zimage_start:
4: dcbf r0,r9
icbi r0,r9
addi r9,r9,0x20
- cmplwi 0,r9,8
+ cmplw cr0,r9,r8
blt 4b
sync
isync
^ 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