From: David Gibson <hidden> Date: 2007-02-20 02:08:37
Here is a 2nd spin of my patch series adding support for the Ebony
440GP evaluation board to the arch/powerpc tree. Notable changes from
the last spin:
- I no longer use legacy_serial for the serial ports and
console, instead I'm using Arnd's of_serial system.
- Rebased on my recent clean/flexibility patches for the
zImage loader
- Includes a general re-orgranization of the arch/powerpc
Kconfig code for 4xx, allowing a kernel to support multiple
boards at once (well, in theory, Ebony is the only supported
one so far).
- The early serial hacks no longer use an entire 64-bit
constant, so should work on non-64-bit aware assemblers
Again, some of the earlier patches I'm about to push to Paulus or
others, so they could appear in upstream trees.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-02-20 02:12:34
At present calling lmb_reserve() (and hence lmb_add_region()) twice
for exactly the same memory region will cause strange behaviour.
This makes life difficult when booting from a flat device tree with
memory reserve map. Which regions are automatically reserved by the
kernel has changed over time, so it's quite possible a newer kernel
could attempt to auto-reserve a region which is also explicitly listed
in the device tree's reserve map, leading to trouble.
This patch avoids the problem by making lmb_reserve() ignore a call to
reserve a previously reserved region. It also removes a now redundant
test designed to avoid one specific case of the problem noted above.
At present, this patch deals only with duplicate reservations of an
identical region. Attempting to reserve two different, but
overlapping regions will still cause problems. I might post another
patch later dealing with this case, but I'm avoiding it now since it
is substantially more complicated to deal with, less likely to occur
and more likely to indicate a genuine bug elsewhere if it does occur.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/kernel/prom.c | 3 ---
arch/powerpc/mm/lmb.c | 4 ++++
2 files changed, 4 insertions(+), 3 deletions(-)
Index: working-2.6/arch/powerpc/mm/lmb.c
===================================================================
@@ -146,6 +146,10 @@ static long __init lmb_add_region(structunsignedlongrgnbase=rgn->region[i].base;unsignedlongrgnsize=rgn->region[i].size;+if((rgnbase==base)&&(rgnsize==size))+/* Already have this region, so we're done */+return0;+adjacent=lmb_addrs_adjacent(base,size,rgnbase,rgnsize);if(adjacent>0){rgn->region[i].base-=size;
@@ -954,9 +954,6 @@ static void __init early_reserve_mem(voisize=*(reserve_map++);if(size==0)break;-/* skip if the reservation is for the blob */-if(base==self_base&&size==self_size)-continue;DBG("reserving: %llx -> %llx\n",base,size);lmb_reserve(base,size);}
From: David Gibson <hidden> Date: 2007-02-20 02:12:34
At present, when an initrd is passed to the kernel used flat device
tree properties, the memory the initrd occupies must also be reserved
in the flat tree's reserve map, or the kernel may overwrite it. That
makes life more complicated than it could be for the bootwrapper.
This patch makes the kernel automatically reserve the initrd's space.
That in turn requires parsing the initrd parameters earlier than they
are currently, in early_init_dt_scan_chosen() instead of
check_for_initrd().
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/kernel/prom.c | 23 +++++++++++++++++++++++
arch/powerpc/kernel/setup-common.c | 22 ++--------------------
2 files changed, 25 insertions(+), 20 deletions(-)
Index: working-2.6/arch/powerpc/kernel/prom.c
===================================================================
@@ -304,26 +304,8 @@ struct seq_operations cpuinfo_op = {void__initcheck_for_initrd(void){#ifdef CONFIG_BLK_DEV_INITRD-constunsignedint*prop;-intlen;--DBG(" -> check_for_initrd()\n");--if(of_chosen){-prop=get_property(of_chosen,"linux,initrd-start",&len);-if(prop!=NULL){-initrd_start=(unsignedlong)-__va(of_read_ulong(prop,len/4));-prop=get_property(of_chosen,-"linux,initrd-end",&len);-if(prop!=NULL){-initrd_end=(unsignedlong)-__va(of_read_ulong(prop,len/4));-initrd_below_start_ok=1;-}else-initrd_start=0;-}-}+DBG(" -> check_for_initrd() initrd_start=0x%lx initrd_end=0x%lx\n",+initrd_start,initrd_end);/* If we were passed an initrd, set the ROOT_DEV properly if the values*looksensible.Ifnot,clearinitrdreference.
From: David Gibson <hidden> Date: 2007-02-20 02:12:34
At present, the serial core always allows setserial in userspace to
change the port address, irq and base clock of any serial port. That
makes sense for legacy ISA ports, but not for (say) embedded ns16550
compatible serial ports at peculiar addresses. In these cases, the
kernel code configuring the ports must know exactly where they are,
and their clocking arrangements (which can be unusual on embedded
boards). It doesn't make sense for userspace to change these
settings.
Therefore, this patch defines a UPF_FIXED_PORT flag for the uart_port
structure. If this flag is set when the serial port is configured,
any attempts to alter the port's type, io address, irq or base clock
with setserial are ignored.
In addition this patch uses the new flag for on-chip serial ports
probed in arch/powerpc/kernel/legacy_serial.c, and for other
hard-wired serial ports probed by drivers/serial/of_serial.c.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/kernel/legacy_serial.c | 3 ++-
drivers/serial/of_serial.c | 3 ++-
drivers/serial/serial_core.c | 22 +++++++++++++---------
include/linux/serial_core.h | 1 +
4 files changed, 18 insertions(+), 11 deletions(-)
Index: working-2.6/drivers/serial/serial_core.c
===================================================================
@@ -115,7 +115,8 @@ static int __init add_legacy_soc_port(st{u64addr;constu32*addrp;-upf_tflags=UPF_BOOT_AUTOCONF|UPF_SKIP_TEST|UPF_SHARE_IRQ;+upf_tflags=UPF_BOOT_AUTOCONF|UPF_SKIP_TEST|UPF_SHARE_IRQ+|UPF_FIXED_PORT;structdevice_node*tsi=of_get_parent(np);/* We only support ports that have a clock frequency properly
From: David Gibson <hidden> Date: 2007-02-20 02:12:34
At present, various parts of the serial code use unsigned long to
define resource addresses. This is a problem, because some 32-bit
platforms have physical addresses larger than 32-bits, and have mmio
serial uarts located above the 4GB point.
This patch changes the type of mapbase in both struct uart_port and
struct plat_serial8250_port to resource_size_t, which can be
configured to be 64 bits on such platforms. The mapbase in
serial_struct can't safely be changed, because that structure is user
visible.
Signed-off-by: David Gibson <redacted>
---
drivers/serial/8250.c | 5 +++--
drivers/serial/8250_early.c | 16 +++++++++-------
drivers/serial/serial_core.c | 9 +++++----
include/linux/serial_8250.h | 2 +-
include/linux/serial_core.h | 2 +-
5 files changed, 19 insertions(+), 15 deletions(-)
Index: working-2.6/include/linux/serial_core.h
===================================================================
@@ -273,7 +273,7 @@ struct uart_port {conststructuart_ops*ops;unsignedintcustom_divisor;unsignedintline;/* port index */-unsignedlongmapbase;/* for ioremap */+resource_size_tmapbase;/* for ioremap */structdevice*dev;/* parent device */unsignedcharhub6;/* this should be in the 8250 driver */unsignedcharunused[3];
@@ -168,9 +169,10 @@ static int __init parse_options(struct edevice->baud);}-printk(KERN_INFO"Early serial console at %s 0x%lx (options '%s')\n",+printk(KERN_INFO"Early serial console at %s 0x%llx (options '%s')\n",mmio?"MMIO":"I/O port",-mmio?port->mapbase:(unsignedlong)port->iobase,+mmio?(unsignedlonglong)port->mapbase+:(unsignedlonglong)port->iobase,device->options);return0;}
@@ -236,10 +238,10 @@ static int __init early_uart_console_swimmio=(port->iotype==UPIO_MEM);line=serial8250_start_console(port,device->options);if(line<0)-printk("No ttyS device at %s 0x%lx for console\n",+printk("No ttyS device at %s 0x%llx for console\n",mmio?"MMIO":"I/O port",-mmio?port->mapbase:-(unsignedlong)port->iobase);+mmio?(unsignedlonglong)port->mapbase+:(unsignedlonglong)port->iobase);unregister_console(&early_uart_console);if(mmio)
@@ -2550,8 +2550,9 @@ static int __devinit serial8250_probe(stret=serial8250_register_port(&port);if(ret<0){dev_err(&dev->dev,"unable to register port at index %d "-"(IO%lx MEM%lx IRQ%d): %d\n",i,-p->iobase,p->mapbase,p->irq,ret);+"(IO%lx MEM%llx IRQ%d): %d\n",i,+p->iobase,(unsignedlonglong)p->mapbase,+p->irq,ret);}}return0;
From: David Gibson <hidden> Date: 2007-02-20 02:12:35
At present, arch/powerpc/boot/main.c includes a gunzip() function
which is a convenient wrapper around zlib. However, it doesn't
conveniently allow decompressing part of an image to one location,
then the remainder to a different address.
This patch adds a new set of more flexible convenience wrappers around
zlib, moving them to their own file, gunzip_util.c, in the process.
These wrappers allow decompressing sections of the compressed image to
different locations. In addition, they transparently handle
uncompressed data, avoiding special case code to handle uncompressed
vmlinux images.
The patch also converts main.c to use the new wrappers, using the new
flexibility to avoid decompressing the vmlinux's ELF header twice as
we did previously. That in turn means we avoid extending our
allocations for the vmlinux to allow space for the extra copy of the
ELF header.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/boot/Makefile | 3
arch/powerpc/boot/gunzip_util.c | 140 ++++++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/gunzip_util.h | 30 ++++++++
arch/powerpc/boot/main.c | 113 +++++---------------------------
4 files changed, 192 insertions(+), 94 deletions(-)
Index: working-2.6/arch/powerpc/boot/gunzip_util.c
===================================================================
@@ -0,0 +1,140 @@+/*+*Copyright2007DavidGibson,IBMCorporation.+*Basedonearlierwork,Copyright(C)PaulMackerras1997.+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicense,or(atyouroption)anylaterversion.+*/++#include<stddef.h>+#include"string.h"+#include"stdio.h"+#include"ops.h"+#include"gunzip_util.h"++structgunzip_statestate;++#define HEAD_CRC 2+#define EXTRA_FIELD 4+#define ORIG_NAME 8+#define COMMENT 0x10+#define RESERVED 0xe0++voidgunzip_start(structgunzip_state*state,void*src,intsrclen)+{+char*hdr=src;+inthdrlen=0;++memset(state,0,sizeof(*state));++/* Check for gzip magic number */+if((hdr[0]==0x1f)&&(hdr[1]==0x8b)){+/* gzip data, initialize zlib parameters */+intr,flags;++state->s.workspace=state->scratch;+if(zlib_inflate_workspacesize()>sizeof(state->scratch)){+printf("insufficient scratch space for gunzip\n\r");+exit();+}++/* skip header */+hdrlen=10;+flags=hdr[3];+if(hdr[2]!=Z_DEFLATED||(flags&RESERVED)!=0){+printf("bad gzipped data\n\r");+exit();+}+if((flags&EXTRA_FIELD)!=0)+hdrlen=12+hdr[10]+(hdr[11]<<8);+if((flags&ORIG_NAME)!=0)+while(hdr[hdrlen++]!=0)+;+if((flags&COMMENT)!=0)+while(hdr[hdrlen++]!=0)+;+if((flags&HEAD_CRC)!=0)+hdrlen+=2;+if(hdrlen>=srclen){+printf("gunzip_start: ran out of data in header\n\r");+exit();+}++r=zlib_inflateInit2(&state->s,-MAX_WBITS);+if(r!=Z_OK){+printf("inflateInit2 returned %d\n\r",r);+exit();+}+}++state->s.next_in=src+hdrlen;+state->s.avail_in=srclen-hdrlen;+}++intgunzip_partial(structgunzip_state*state,void*dst,intdstlen)+{+intlen;++if(state->s.workspace){+/* gunzipping */+intr;++state->s.next_out=dst;+state->s.avail_out=dstlen;+r=zlib_inflate(&state->s,Z_FULL_FLUSH);+if(r!=Z_OK&&r!=Z_STREAM_END){+printf("inflate returned %d msg: %s\n\r",r,state->s.msg);+exit();+}+len=state->s.next_out-(unsignedchar*)dst;+}else{+/* uncompressed image */+len=min(state->s.avail_in,(unsigned)dstlen);+memcpy(dst,state->s.next_in,len);+state->s.next_in+=len;+state->s.avail_in-=len;+}+returnlen;+}++voidgunzip_exactly(structgunzip_state*state,void*dst,intdstlen)+{+intlen;++len=gunzip_partial(state,dst,dstlen);+if(len<dstlen){+printf("gunzip_block: ran out of data\n\r");+exit();+}+}++voidgunzip_discard(structgunzip_state*state,intlen)+{+staticchardiscard_buf[128];++while(len>sizeof(discard_buf)){+gunzip_exactly(state,discard_buf,sizeof(discard_buf));+len-=sizeof(discard_buf);+}++if(len>0)+gunzip_exactly(state,discard_buf,len);+}++intgunzip_finish(structgunzip_state*state,void*dst,intdstlen)+{+intlen;++if(state->s.workspace){+len=gunzip_partial(state,dst,dstlen);+zlib_inflateEnd(&state->s);+}else{+/* uncompressed image */+len=min(state->s.avail_in,(unsigned)dstlen);+memcpy(dst,state->s.next_in,len);+}++returnlen;+}
@@ -42,71 +44,12 @@ static struct addr_range initrd;staticunsignedlongelfoffset;staticintis_64bit;-/* scratch space for gunzip; 46912 is from zlib_inflate_workspacesize() */-staticcharscratch[46912];staticcharelfheader[256];typedefvoid(*kernel_entry_t)(unsignedlong,unsignedlong,void*);#undef DEBUG-#define HEAD_CRC 2-#define EXTRA_FIELD 4-#define ORIG_NAME 8-#define COMMENT 0x10-#define RESERVED 0xe0--staticvoidgunzip(void*dst,intdstlen,unsignedchar*src,int*lenp)-{-z_streams;-intr,i,flags;--/* skip header */-i=10;-flags=src[3];-if(src[2]!=Z_DEFLATED||(flags&RESERVED)!=0){-printf("bad gzipped data\n\r");-exit();-}-if((flags&EXTRA_FIELD)!=0)-i=12+src[10]+(src[11]<<8);-if((flags&ORIG_NAME)!=0)-while(src[i++]!=0)-;-if((flags&COMMENT)!=0)-while(src[i++]!=0)-;-if((flags&HEAD_CRC)!=0)-i+=2;-if(i>=*lenp){-printf("gunzip: ran out of data in header\n\r");-exit();-}--if(zlib_inflate_workspacesize()>sizeof(scratch)){-printf("gunzip needs more mem\n");-exit();-}-memset(&s,0,sizeof(s));-s.workspace=scratch;-r=zlib_inflateInit2(&s,-MAX_WBITS);-if(r!=Z_OK){-printf("inflateInit2 returned %d\n\r",r);-exit();-}-s.next_in=src+i;-s.avail_in=*lenp-i;-s.next_out=dst;-s.avail_out=dstlen;-r=zlib_inflate(&s,Z_FULL_FLUSH);-if(r!=Z_OK&&r!=Z_STREAM_END){-printf("inflate returned %d msg: %s\n\r",r,s.msg);-exit();-}-*lenp=s.next_out-(unsignedchar*)dst;-zlib_inflateEnd(&s);-}-staticintis_elf64(void*hdr){Elf64_Ehdr*elf64=hdr;
@@ -132,8 +75,8 @@ static int is_elf64(void *hdr)return0;elfoffset=(unsignedlong)elf64ph->p_offset;-vmlinux.size=(unsignedlong)elf64ph->p_filesz+elfoffset;-vmlinux.memsize=(unsignedlong)elf64ph->p_memsz+elfoffset;+vmlinux.size=(unsignedlong)elf64ph->p_filesz;+vmlinux.memsize=(unsignedlong)elf64ph->p_memsz;is_64bit=1;return1;
@@ -164,8 +107,8 @@ static int is_elf32(void *hdr)return0;elfoffset=elf32ph->p_offset;-vmlinux.size=elf32ph->p_filesz+elf32ph->p_offset;-vmlinux.memsize=elf32ph->p_memsz+elf32ph->p_offset;+vmlinux.size=elf32ph->p_filesz;+vmlinux.memsize=elf32ph->p_memsz;return1;}
@@ -177,13 +120,8 @@ static void prep_kernel(unsigned long a1vmlinuz.size=(unsignedlong)(_vmlinux_end-_vmlinux_start);/* gunzip the ELF header of the kernel */-if(*(unsignedshort*)vmlinuz.addr==0x1f8b){-len=vmlinuz.size;-gunzip(elfheader,sizeof(elfheader),-(unsignedchar*)vmlinuz.addr,&len);-}else-memcpy(elfheader,(constvoid*)vmlinuz.addr,-sizeof(elfheader));+gunzip_start(&gzstate,(void*)vmlinuz.addr,vmlinuz.size);+gunzip_exactly(&gzstate,elfheader,sizeof(elfheader));if(!is_elf64(elfheader)&&!is_elf32(elfheader)){printf("Error: not a valid PPC32 or PPC64 ELF file!\n\r");
@@ -192,10 +130,10 @@ static void prep_kernel(unsigned long a1if(platform_ops.image_hdr)platform_ops.image_hdr(elfheader);-/* We need to alloc the memsize plus the file offset since gzip-*willexpandtheheader(fileoffset),thenthekernel,then-*possiblerubbishwedon'tcareabout.Butthekernelbssmust-*beclaimed(itwillbezero'dbythekernelitself)+/* We need to alloc the memsize: gzip will expand the kernel+*text/data,thenpossiblerubbishwedon'tcareabout.But+*thekernelbssmustbeclaimed(itwillbezero'dbythe+*kernelitself)*/printf("Allocating 0x%lx bytes for kernel ...\n\r",vmlinux.memsize);vmlinux.addr=(unsignedlong)malloc(vmlinux.memsize);
@@ -237,24 +175,13 @@ static void prep_kernel(unsigned long a1}/* Eventually gunzip the kernel */-if(*(unsignedshort*)vmlinuz.addr==0x1f8b){-printf("gunzipping (0x%lx <- 0x%lx:0x%0lx)...",-vmlinux.addr,vmlinuz.addr,vmlinuz.addr+vmlinuz.size);-len=vmlinuz.size;-gunzip((void*)vmlinux.addr,vmlinux.memsize,-(unsignedchar*)vmlinuz.addr,&len);-printf("done 0x%lx bytes\n\r",len);-}else{-memmove((void*)vmlinux.addr,(void*)vmlinuz.addr,-vmlinuz.size);-}--/* Skip over the ELF header */-#ifdef DEBUG-printf("... skipping 0x%lx bytes of ELF header\n\r",-elfoffset);-#endif-vmlinux.addr+=elfoffset;+printf("gunzipping (0x%lx <- 0x%lx:0x%0lx)...",+vmlinux.addr,vmlinuz.addr,vmlinuz.addr+vmlinuz.size);+/* discard up to the actual load data */+gunzip_discard(&gzstate,elfoffset-sizeof(elfheader));+len=gunzip_finish(&gzstate,(void*)vmlinux.addr,+vmlinux.memsize);+printf("done 0x%lx bytes\n\r",len);flush_cache((void*)vmlinux.addr,vmlinux.size);}
From: David Gibson <hidden> Date: 2007-02-20 02:12:35
This patch rewrites prep_kernel() in the zImage wrapper code to be
clearer and more flexible. Notable changes:
- Handling of the initrd image from prep_kernel() has moved
into a new prep_initrd() function.
- The address of the initrd image is now added as device tree
properties, as the kernel expects.
- We only copy a packaged initrd image to a new location if it
is in danger of being clobbered when the kernel moves to its final
location, instead of always.
- By default we decompress the kernel directly to address 0,
instead of requiring it to relocate itself. Platforms (such as OF)
where doing this could clobber still-live firmware data structures can
override the vmlinux_alloc hook to provide an alternate place to
decompress the kernel.
- We no longer pass lots of information between functions in
global variables.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/boot/main.c | 171 ++++++++++++++++++++++++++++-------------------
arch/powerpc/boot/of.c | 12 +++
arch/powerpc/boot/ops.h | 1
3 files changed, 116 insertions(+), 68 deletions(-)
Index: working-2.6/arch/powerpc/boot/main.c
===================================================================
@@ -74,15 +71,14 @@ static int is_elf64(void *hdr)if(i>=(unsignedint)elf64->e_phnum)return0;-elfoffset=(unsignedlong)elf64ph->p_offset;-vmlinux.size=(unsignedlong)elf64ph->p_filesz;-vmlinux.memsize=(unsignedlong)elf64ph->p_memsz;+info->loadsize=(unsignedlong)elf64ph->p_filesz;+info->memsize=(unsignedlong)elf64ph->p_memsz;+info->elfoffset=(unsignedlong)elf64ph->p_offset;-is_64bit=1;return1;}-staticintis_elf32(void*hdr)+staticintparse_elf32(void*hdr,structelf_info*info){Elf32_Ehdr*elf32=hdr;Elf32_Phdr*elf32ph;
@@ -98,7 +94,6 @@ static int is_elf32(void *hdr)elf32->e_machine==EM_PPC))return0;-elf32=(Elf32_Ehdr*)elfheader;elf32ph=(Elf32_Phdr*)((unsignedlong)elf32+elf32->e_phoff);for(i=0;i<elf32->e_phnum;i++,elf32ph++)if(elf32ph->p_type==PT_LOAD)
@@ -106,24 +101,26 @@ static int is_elf32(void *hdr)if(i>=elf32->e_phnum)return0;-elfoffset=elf32ph->p_offset;-vmlinux.size=elf32ph->p_filesz;-vmlinux.memsize=elf32ph->p_memsz;+info->loadsize=elf32ph->p_filesz;+info->memsize=elf32ph->p_memsz;+info->elfoffset=elf32ph->p_offset;return1;}-staticvoidprep_kernel(unsignedlonga1,unsignedlonga2)+staticstructaddr_rangeprep_kernel(void){+charelfheader[256];+void*vmlinuz_addr=_vmlinux_start;+unsignedlongvmlinuz_size=_vmlinux_end-_vmlinux_start;+void*addr=0;+structelf_infoei;intlen;-vmlinuz.addr=(unsignedlong)_vmlinux_start;-vmlinuz.size=(unsignedlong)(_vmlinux_end-_vmlinux_start);-/* gunzip the ELF header of the kernel */-gunzip_start(&gzstate,(void*)vmlinuz.addr,vmlinuz.size);+gunzip_start(&gzstate,vmlinuz_addr,vmlinuz_size);gunzip_exactly(&gzstate,elfheader,sizeof(elfheader));-if(!is_elf64(elfheader)&&!is_elf32(elfheader)){+if(!parse_elf64(elfheader,&ei)&&!parse_elf32(elfheader,&ei)){printf("Error: not a valid PPC32 or PPC64 ELF file!\n\r");exit();}
@@ -135,55 +132,92 @@ static void prep_kernel(unsigned long a1*thekernelbssmustbeclaimed(itwillbezero'dbythe*kernelitself)*/-printf("Allocating 0x%lx bytes for kernel ...\n\r",vmlinux.memsize);-vmlinux.addr=(unsignedlong)malloc(vmlinux.memsize);-if(vmlinux.addr==0){-printf("Can't allocate memory for kernel image !\n\r");-exit();+printf("Allocating 0x%lx bytes for kernel ...\n\r",ei.memsize);++if(platform_ops.vmlinux_alloc){+addr=platform_ops.vmlinux_alloc(ei.memsize);+}else{+if((unsignedlong)_start<ei.memsize){+printf("Insufficient memory for kernel at address 0!"+" (_start=%lx)\n\r",_start);+exit();+}}+/* Finally, gunzip the kernel */+printf("gunzipping (0x%p <- 0x%p:0x%p)...",addr,+vmlinuz_addr,vmlinuz_addr+vmlinuz_size);+/* discard up to the actual load data */+gunzip_discard(&gzstate,ei.elfoffset-sizeof(elfheader));+len=gunzip_finish(&gzstate,addr,ei.memsize);+printf("done 0x%lx bytes\n\r",len);++flush_cache(addr,ei.loadsize);++return(structaddr_range){addr,ei.memsize};+}++staticstructaddr_rangeprep_initrd(structaddr_rangevmlinux,+unsignedlonginitrd_addr,+unsignedlonginitrd_size)+{+void*devp;+u32initrd_start,initrd_end;++/* If we have an image attached to us, it overrides anything+*suppliedbytheloader.*/+if(_initrd_end>_initrd_start){+printf("Attached initrd image at 0x%p-0x%p\n\r",+_initrd_start,_initrd_end);+initrd_addr=(unsignedlong)_initrd_start;+initrd_size=_initrd_end-_initrd_start;+}elseif(initrd_size>0){+printf("Using loader supplied ramdisk at 0x%lx-0x%lx\n\r",+initrd_addr,initrd_addr+initrd_size);+}++/* If there's no initrd at all, we're done */+if(!initrd_size)+return(structaddr_range){0,0};+/*-*Nowfindtheinitrd-*-*Firstseeifwehaveanimageattachedtous.Ifso-*allocatememoryforitandcopyitthere.+*Iftheinitrdistoolowitwillbeclobberedwhenthe+*kernelrelocatestoitsfinallocation.Inthiscase,+*allocateasaferplaceandmoveit.*/-initrd.size=(unsignedlong)(_initrd_end-_initrd_start);-initrd.memsize=initrd.size;-if(initrd.size>0){+if(initrd_addr<vmlinux.size){+void*old_addr=(void*)initrd_addr;+printf("Allocating 0x%lx bytes for initrd ...\n\r",-initrd.size);-initrd.addr=(unsignedlong)malloc((u32)initrd.size);-if(initrd.addr==0){+initrd_size);+initrd_addr=(unsignedlong)malloc(initrd_size);+if(!initrd_addr){printf("Can't allocate memory for initial "-"ramdisk !\n\r");+"ramdisk !\n\r");exit();}-printf("initial ramdisk moving 0x%lx <- 0x%lx "-"(0x%lx bytes)\n\r",initrd.addr,-(unsignedlong)_initrd_start,initrd.size);-memmove((void*)initrd.addr,(void*)_initrd_start,-initrd.size);-printf("initrd head: 0x%lx\n\r",-*((unsignedlong*)initrd.addr));-}elseif(a2!=0){-/* Otherwise, see if yaboot or another loader gave us an initrd */-initrd.addr=a1;-initrd.memsize=initrd.size=a2;-printf("Using loader supplied initrd at 0x%lx (0x%lx bytes)\n\r",-initrd.addr,initrd.size);-}--/* Eventually gunzip the kernel */-printf("gunzipping (0x%lx <- 0x%lx:0x%0lx)...",-vmlinux.addr,vmlinuz.addr,vmlinuz.addr+vmlinuz.size);-/* discard up to the actual load data */-gunzip_discard(&gzstate,elfoffset-sizeof(elfheader));-len=gunzip_finish(&gzstate,(void*)vmlinux.addr,-vmlinux.memsize);-printf("done 0x%lx bytes\n\r",len);+printf("Relocating initrd 0x%p <- 0x%p (0x%lx bytes)\n\r",+initrd_addr,old_addr,initrd_size);+memmove((void*)initrd_addr,old_addr,initrd_size);+}++printf("initrd head: 0x%lx\n\r",*((unsignedlong*)initrd_addr));++/* Tell the kernel initrd address via device tree */+devp=finddevice("/chosen");+if(!devp){+printf("Device tree has no chosen node!\n\r");+exit();+}++initrd_start=(u32)initrd_addr;+initrd_end=(u32)initrd_addr+initrd_size;++setprop(devp,"linux,initrd-start",&initrd_start,+sizeof(initrd_start));+setprop(devp,"linux,initrd-end",&initrd_end,sizeof(initrd_end));-flush_cache((void*)vmlinux.addr,vmlinux.size);+return(structaddr_range){(void*)initrd_addr,initrd_size};}/* A buffer that may be edited by tools operating on a zImage binary so as to
@@ -242,7 +277,8 @@ void start(unsigned long a1, unsigned loprintf("\n\rzImage starting: loaded at 0x%p (sp: 0x%p)\n\r",_start,sp);-prep_kernel(a1,a2);+vmlinux=prep_kernel();+initrd=prep_initrd(vmlinux,a1,a2);/* If cmdline came from zimage wrapper or if we can edit the one*inthedt,printitoutandeditit,ifpossible.
@@ -271,8 +307,7 @@ void start(unsigned long a1, unsigned loif(ft_addr)kentry(ft_addr,0,NULL);else-/* XXX initrd addr/size should be passed in properties */-kentry(initrd.addr,initrd.size,promptr);+kentry((unsignedlong)initrd.addr,initrd.size,promptr);/* console closed so printf below may not work */printf("Error: Linux kernel returned to zImage boot wrapper!\n\r");
From: David Gibson <hidden> Date: 2007-02-20 02:12:35
This patch re-organises the way the zImage wrapper code is entered, to
allow more flexibility on platforms with unusual entry conditions.
After this patch, a platform .o file has two options:
1) It can define a _zimage_start, in which case the platform code gets
control from the very beginning of execution. In this case the
platform code is responsible for relocating the zImage if necessary,
clearing the BSS, performing any platform specific initialization, and
finally calling start() to load and enter the kernel.
2) It can define platform_init(). In this case the generic crt0.S
handles initial entry, and calls platform_init() before calling
start(). The signature of platform_init() is changed, however, to
take up to 5 parameters (in r3..r7) as they come from the platform's
initial loader, instead of a fixed set of parameters based on OF's
usage.
When using the generic crt0.S, the platform .o can optionally
supply a custom stack to use, using the BSS_STACK() macro. If this
is not supplied, the crt0.S will assume that the loader has
supplied a usable stack.
In either case, the platform code communicates information to the
generic code (specifically, a PROM pointer for OF systems, and/or an
initrd image address supplied by the bootloader) via a global
structure "loader_info".
In addition the wrapper script is rearranged to ensure that the
platform .o is always linked first. This means that platforms where
the zImage entry point is at a fixed address or offset, rather than
being encoded in the binary header can be supported using option (1).
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/boot/Makefile | 6 +++---
arch/powerpc/boot/crt0.S | 32 +++++++++++++++++++++++++++++---
arch/powerpc/boot/main.c | 18 +++++++-----------
arch/powerpc/boot/of.c | 6 ++++--
arch/powerpc/boot/ops.h | 12 +++++++++++-
arch/powerpc/boot/wrapper | 6 ++++--
arch/powerpc/boot/zImage.coff.lds.S | 3 ++-
arch/powerpc/boot/zImage.lds.S | 1 +
8 files changed, 61 insertions(+), 23 deletions(-)
Index: working-2.6/arch/powerpc/boot/crt0.S
===================================================================
@@ -278,7 +272,8 @@ void start(unsigned long a1, unsigned lo_start,sp);vmlinux=prep_kernel();-initrd=prep_initrd(vmlinux,a1,a2);+initrd=prep_initrd(vmlinux,loader_info.initrd_addr,+loader_info.initrd_size);/* If cmdline came from zimage wrapper or if we can edit the one*inthedt,printitoutandeditit,ifpossible.
@@ -298,7 +293,7 @@ void start(unsigned long a1, unsigned loif(ft_addr)printf(" flat tree at 0x%lx\n\r",ft_addr);else-printf(" using OF tree (promptr=%p)\n\r",promptr);+printf(" using OF tree (promptr=%p)\n\r",loader_info.promptr);if(console_ops.close)console_ops.close();
@@ -307,7 +302,8 @@ void start(unsigned long a1, unsigned loif(ft_addr)kentry(ft_addr,0,NULL);else-kentry((unsignedlong)initrd.addr,initrd.size,promptr);+kentry((unsignedlong)initrd.addr,initrd.size,+loader_info.promptr);/* console closed so printf below may not work */printf("Error: Linux kernel returned to zImage boot wrapper!\n\r");
From: David Gibson <hidden> Date: 2007-02-20 02:12:35
This patch adds support for building a zImage wrapper suitable for the
Ebony (440GP) evaluation board. This supports booting both from uboot
(old versions which don't supply a flattened device tree) and IBM
Openbios (aka "treeboot").
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/boot/Makefile | 33 ++++++++++++++++++++++++++++++++-
arch/powerpc/boot/ebony.c | 32 ++++++++++++++++++++++++++++++++
arch/powerpc/boot/mktree.c | 10 ++++------
arch/powerpc/boot/wrapper | 33 +++++++++++++++++++++++++++++++++
4 files changed, 101 insertions(+), 7 deletions(-)
Index: working-2.6/arch/powerpc/boot/Makefile
===================================================================
@@ -103,6 +109,8 @@ extra-y := $(obj)/wrapper.a $(obj-plat)wrapper:=$(srctree)/$(src)/wrapperwrapperbits:=$(extra-y)$(addprefix$(obj)/,addnotehack-coffmktree)+dtc:=dtc+############## Bits for building various flavours of zImage
@@ -61,10 +61,8 @@ int main(int argc, char *argv[])bt.bb_magic=htonl(0x0052504F);/* If we have the optional entry point parameter, use it */-if(argc==4)-bt.bb_dest=bt.bb_entry_point=htonl(strtoul(argv[3],NULL,0));-else-bt.bb_dest=bt.bb_entry_point=htonl(0x500000);+bt.bb_dest=htonl(strtoul(argv[3],NULL,0));+bt.bb_entry_point=htonl(strtoul(argv[4],NULL,0));/* We know these from the linker command.*...andthenmoveitupintomemoryalittlemoresothe
From: David Gibson <hidden> Date: 2007-02-20 02:12:35
This patch moves the mmu.h definitions which are still relevant for
ARCH=powerpc from include/asm-ppc/mmu.h to their own file,
include/asm-powerpc/mmu_44x.h. The new file is included from
asm-powerpc/mmu.h, and a couple of other tweaks to correct mmu
definitions for 44x are made.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/kernel/head_44x.S | 4 +-
arch/powerpc/mm/44x_mmu.c | 81 ++++++++---------------------------------
arch/powerpc/mm/mmu_decl.h | 2 +
include/asm-powerpc/mmu.h | 4 +-
include/asm-powerpc/mmu_44x.h | 74 +++++++++++++++++++++++++++++++++++++
5 files changed, 98 insertions(+), 67 deletions(-)
Index: working-2.6/include/asm-powerpc/mmu.h
===================================================================
@@ -24,73 +24,35 @@**/-#include<linux/signal.h>-#include<linux/sched.h>-#include<linux/kernel.h>-#include<linux/errno.h>-#include<linux/string.h>-#include<linux/types.h>-#include<linux/ptrace.h>-#include<linux/mman.h>-#include<linux/mm.h>-#include<linux/swap.h>-#include<linux/stddef.h>-#include<linux/vmalloc.h>-#include<linux/init.h>-#include<linux/delay.h>-#include<linux/highmem.h>--#include<asm/pgalloc.h>-#include<asm/prom.h>-#include<asm/io.h>-#include<asm/mmu_context.h>-#include<asm/pgtable.h>#include<asm/mmu.h>-#include<asm/uaccess.h>-#include<asm/smp.h>-#include<asm/bootx.h>-#include<asm/machdep.h>-#include<asm/setup.h>#include"mmu_decl.h"-externcharetext[],_stext[];-/* Used by the 44x TLB replacement exception handler.*Justneededitdeclaredsomeplace.*/-unsignedinttlb_44x_index=0;-unsignedinttlb_44x_hwater=62;+unsignedinttlb_44x_index;/* = 0 */+unsignedinttlb_44x_hwater=PPC44x_TLB_SIZE-1-PPC44x_EARLY_TLBS;/**"Pins"a256MBTLBentryinAS0forkernellowmem*/-staticvoid__init-ppc44x_pin_tlb(intslot,unsignedintvirt,unsignedintphys)+staticvoid__initppc44x_pin_tlb(unsignedintvirt,unsignedintphys){-unsignedlongattrib=0;--__asm____volatile__("\-clrrwi%2,%2,10\n\-ori%2,%2,%4\n\-clrrwi%1,%1,10\n\-li%0,0\n\-ori%0,%0,%5\n\-tlbwe%2,%3,%6\n\-tlbwe%1,%3,%7\n\-tlbwe%0,%3,%8"+__asm____volatile__(+"tlbwe %2,%3,%4\n"+"tlbwe %1,%3,%5\n"+"tlbwe %0,%3,%6\n":-:"r"(attrib),"r"(phys),"r"(virt),"r"(slot),-"i"(PPC44x_TLB_VALID|PPC44x_TLB_256M),-"i"(PPC44x_TLB_SW|PPC44x_TLB_SR|PPC44x_TLB_SX|PPC44x_TLB_G),+:"r"(PPC44x_TLB_SW|PPC44x_TLB_SR|PPC44x_TLB_SX|PPC44x_TLB_G),+"r"(phys),+"r"(virt|PPC44x_TLB_VALID|PPC44x_TLB_256M),+"r"(tlb_44x_hwater--),/* slot for this TLB entry */"i"(PPC44x_TLB_PAGEID),"i"(PPC44x_TLB_XLAT),"i"(PPC44x_TLB_ATTRIB));}-/*-*MMU_init_hwdoesthechip-specificinitializationoftheMMUhardware.-*/void__initMMU_init_hw(void){flush_instruction_cache();
@@ -98,22 +60,13 @@ void __init MMU_init_hw(void)unsignedlong__initmmu_mapin_ram(void){-unsignedintpinned_tlbs=1;-inti;+unsignedlongaddr;-/* Determine number of entries necessary to cover lowmem */-pinned_tlbs=(unsignedint)-(_ALIGN(total_lowmem,PPC_PIN_SIZE)>>PPC44x_PIN_SHIFT);--/* Write upper watermark to save location */-tlb_44x_hwater=PPC44x_LOW_SLOT-pinned_tlbs;--/* If necessary, set additional pinned TLBs */-if(pinned_tlbs>1)-for(i=(PPC44x_LOW_SLOT-(pinned_tlbs-1));i<PPC44x_LOW_SLOT;i++){-unsignedintphys_addr=(PPC44x_LOW_SLOT-i)*PPC_PIN_SIZE;-ppc44x_pin_tlb(i,phys_addr+PAGE_OFFSET,phys_addr);-}+/* Pin in enough TLBs to cover any lowmem not covered by the+*initial256Mmappingestablishedinhead_44x.S*/+for(addr=PPC_PIN_SIZE;addr<total_lowmem;+addr+=PPC_PIN_SIZE)+ppc44x_pin_tlb(addr+PAGE_OFFSET,addr);returntotal_lowmem;}
From: David Gibson <hidden> Date: 2007-02-20 02:12:35
This patch adds support for early serial debugging via the built in
port on IBM/AMCC PowerPC 44x CPUs. It uses a bolted TLB entry in
address space 1 for the UART's mapping, allowing robust debugging both
before and after the initialization of the MMU.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/Kconfig.debug | 23 ++++++++++++++-----
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/head_44x.S | 34 ++++++++++------------------
arch/powerpc/kernel/misc_44x.S | 46 ++++++++++++++++++++++++++++++++++++++
arch/powerpc/kernel/of_platform.c | 1
arch/powerpc/kernel/udbg.c | 3 ++
arch/powerpc/kernel/udbg_16550.c | 24 +++++++++++++++++++
include/asm-powerpc/mmu_44x.h | 7 ++++-
include/asm-powerpc/udbg.h | 1
9 files changed, 112 insertions(+), 28 deletions(-)
Index: working-2.6/arch/powerpc/Kconfig.debug
===================================================================
@@ -130,11 +130,6 @@ config BOOTX_TEXTSayYheretoseeprogressmessagesfromthebootfirmwareintextmode.RequireseitherBootXorOpenFirmware.-configSERIAL_TEXT_DEBUG-bool"Support for early boot texts over serial port"-depends on4xx||LOPEC||MV64X60||PPLUS||PRPMC800||\-PPC_GEN550||PPC_MPC52xx-configPPC_EARLY_DEBUGbool"Early debugging (dangerous)"
@@ -199,6 +194,24 @@ config PPC_EARLY_DEBUG_BEAThelpSelectthistoenableearlydebuggingforCellebwithBeat.+configPPC_EARLY_DEBUG_44x+bool"Early serial debugging for IBM 44x CPUs"+depends on44x+selectPPC_UDBG_16550+help+SelectthistoenableearlydebuggingforIBM44xchipsviathe+inbuiltserialport.+endchoice+configPPC_EARLY_DEBUG_44x_PHYSLOW+hex+dependsPPC_EARLY_DEBUG_44x+default"0x40000200"++configPPC_EARLY_DEBUG_44x_PHYSHIGH+hex+dependsPPC_EARLY_DEBUG_44x+default"0x1"+endmenu
From: David Gibson <hidden> Date: 2007-02-20 02:12:35
Add a device tree for the Ebony evaluation board (440GP based). This
tree is not complete or finalized. This tree needs a very recent
version of dtc to process.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/boot/dts/ebony.dts | 225 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 225 insertions(+)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
From: David Gibson <hidden> Date: 2007-02-20 02:12:35
This patch adds a driver to arch/powerpc/sysdev for the UIC, the
on-chip interrupt controller from IBM/AMCC 4xx chips. It uses the new
irq host mapping infrastructure.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/uic.c | 335 +++++++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/uic.h | 23 ++
3 files changed, 359 insertions(+)
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
@@ -0,0 +1,335 @@+/*+*arch/powerpc/sysdev/uic.c+*+*IBMPowerPC4xxUniversalInterruptController+*+*Copyright2007DavidGibson<dwg@au1.ibm.com>,IBMCorporation.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsoftheGNUGeneralPublicLicenseaspublishedbythe+*FreeSoftwareFoundation;eitherversion2oftheLicense,or(atyour+*option)anylaterversion.+*/+#include<linux/kernel.h>+#include<linux/init.h>+#include<linux/errno.h>+#include<linux/reboot.h>+#include<linux/slab.h>+#include<linux/stddef.h>+#include<linux/sched.h>+#include<linux/signal.h>+#include<linux/sysdev.h>+#include<linux/device.h>+#include<linux/bootmem.h>+#include<linux/spinlock.h>+#include<linux/irq.h>+#include<linux/interrupt.h>+#include<asm/irq.h>+#include<asm/io.h>+#include<asm/prom.h>+#include<asm/dcr.h>++#define NR_UIC_INTS 32++#define UIC_SR 0x0+#define UIC_ER 0x2+#define UIC_CR 0x3+#define UIC_PR 0x4+#define UIC_TR 0x5+#define UIC_MSR 0x6+#define UIC_VR 0x7+#define UIC_VCR 0x8++#define uic_irq_to_hw(virq) (irq_map[virq].hwirq)++structuic*primary_uic;++structuic{+intindex;+intdcrbase;++spinlock_tlock;++/* The remapper for this UIC */+structirq_host*irqhost;++/* For secondary UICs, the cascade interrupt's irqaction */+structirqactioncascade;++/* The device node of the interrupt controller */+structdevice_node*of_node;+};++staticvoiduic_unmask_irq(unsignedintvirq)+{+structuic*uic=get_irq_chip_data(virq);+unsignedintsrc=uic_irq_to_hw(virq);+unsignedlongflags;+u32er;++spin_lock_irqsave(&uic->lock,flags);+er=mfdcr(uic->dcrbase+UIC_ER);+er|=1<<(31-src);+mtdcr(uic->dcrbase+UIC_ER,er);+spin_unlock_irqrestore(&uic->lock,flags);+}++staticvoiduic_mask_irq(unsignedintvirq)+{+structuic*uic=get_irq_chip_data(virq);+unsignedintsrc=uic_irq_to_hw(virq);+unsignedlongflags;+u32er;++spin_lock_irqsave(&uic->lock,flags);+er=mfdcr(uic->dcrbase+UIC_ER);+er&=~(1<<(31-src));+mtdcr(uic->dcrbase+UIC_ER,er);+spin_unlock_irqrestore(&uic->lock,flags);+}++staticvoiduic_ack_irq(unsignedintvirq)+{+structuic*uic=get_irq_chip_data(virq);+unsignedintsrc=uic_irq_to_hw(virq);+unsignedlongflags;++spin_lock_irqsave(&uic->lock,flags);+mtdcr(uic->dcrbase+UIC_SR,1<<(31-src));+spin_unlock_irqrestore(&uic->lock,flags);+}++staticintuic_set_irq_type(unsignedintvirq,unsignedintflow_type)+{+structuic*uic=get_irq_chip_data(virq);+unsignedintsrc=uic_irq_to_hw(virq);+structirq_desc*desc=get_irq_desc(virq);+unsignedlongflags;+inttrigger,polarity;+u32tr,pr,mask;++switch(flow_type&IRQ_TYPE_SENSE_MASK){+caseIRQ_TYPE_NONE:+uic_mask_irq(virq);+return0;++caseIRQ_TYPE_EDGE_RISING:+trigger=1;polarity=1;+break;+caseIRQ_TYPE_EDGE_FALLING:+trigger=1;polarity=0;+break;+caseIRQ_TYPE_LEVEL_HIGH:+trigger=0;polarity=1;+break;+caseIRQ_TYPE_LEVEL_LOW:+trigger=0;polarity=1;+break;+default:+return-EINVAL;+}++mask=~(1<<(31-src));++spin_lock_irqsave(&uic->lock,flags);+tr=mfdcr(uic->dcrbase+UIC_TR);+pr=mfdcr(uic->dcrbase+UIC_PR);+tr=(tr&mask)|(trigger<<(31-src));+pr=(pr&mask)|(polarity<<(31-src));++mtdcr(uic->dcrbase+UIC_PR,pr);+mtdcr(uic->dcrbase+UIC_TR,tr);++desc->status&=~(IRQ_TYPE_SENSE_MASK|IRQ_LEVEL);+desc->status|=flow_type&IRQ_TYPE_SENSE_MASK;+if(trigger)+desc->status|=IRQ_LEVEL;++spin_unlock_irqrestore(&uic->lock,flags);++return0;+}++staticstructirq_chipuic_irq_chip={+.typename=" UIC ",+.unmask=uic_unmask_irq,+.mask=uic_mask_irq,+/* .mask_ack = uic_mask_irq_and_ack, */+.ack=uic_ack_irq,+.set_type=uic_set_irq_type,+};++staticintuic_host_match(structirq_host*h,structdevice_node*node)+{+structuic*uic=h->host_data;+returnuic->of_node==node;+}++staticintuic_host_map(structirq_host*h,unsignedintvirq,+irq_hw_number_thw)+{+structuic*uic=h->host_data;++set_irq_chip_data(virq,uic);+/* Despite the name, handle_level_irq() works for both level+*andedgeirqsonUIC.FIXME:checkthisiscorrect*/+set_irq_chip_and_handler(virq,&uic_irq_chip,handle_level_irq);++/* Set default irq type */+set_irq_type(virq,IRQ_TYPE_NONE);++return0;+}++staticintuic_host_xlate(structirq_host*h,structdevice_node*ct,+u32*intspec,unsignedintintsize,+irq_hw_number_t*out_hwirq,unsignedint*out_type)++{+/* UIC intspecs must have 2 cells */+BUG_ON(intsize!=2);+*out_hwirq=intspec[0];+*out_type=intspec[1];+return0;+}++staticstructirq_host_opsuic_host_ops={+.match=uic_host_match,+.map=uic_host_map,+.xlate=uic_host_xlate,+};++irqreturn_tuic_cascade(intvirq,void*data)+{+structuic*uic=data;+u32msr;+intsrc;+intsubvirq;++msr=mfdcr(uic->dcrbase+UIC_MSR);+src=32-ffs(msr);++subvirq=irq_linear_revmap(uic->irqhost,src);+generic_handle_irq(subvirq);++returnIRQ_HANDLED;+}++void__inituic_init_one(structdevice_node*node)+{+structuic*uic;+constu32*indexp,*dcrreg,*interrupts;+intlen;++uic=alloc_bootmem(sizeof(*uic));+if(!uic)+return;/* FIXME: panic? */++memset(uic,0,sizeof(*uic));+uic->of_node=of_node_get(node);+indexp=get_property(node,"cell-index",&len);+if(!indexp||(len!=sizeof(u32))){+printk(KERN_ERR"uic: Device node %s has missing or invalid "+"cell-index property\n",node->full_name);+return;+}+uic->index=*indexp;++dcrreg=get_property(node,"dcr-reg",&len);+if(!dcrreg||(len!=2*sizeof(u32))){+printk(KERN_ERR"uic: Device node %s has missing or invalid "+"dcr-reg property\n",node->full_name);+return;+}+uic->dcrbase=*dcrreg;++uic->irqhost=irq_alloc_host(IRQ_HOST_MAP_LINEAR,NR_UIC_INTS,+&uic_host_ops,-1);+if(!uic->irqhost){+of_node_put(node);+return;/* FIXME: panic? */+}++uic->irqhost->host_data=uic;++/* Start with all interrupts disable and non-critical */+mtdcr(uic->dcrbase+UIC_ER,0);+mtdcr(uic->dcrbase+UIC_CR,0);++printk("UIC%d (%d IRQ sources) at DCR 0x%x\n",uic->index,+NR_UIC_INTS,uic->dcrbase);++interrupts=get_property(node,"interrupts",&len);++if(!interrupts){+/* This is the top level controller */+primary_uic=uic;+irq_set_default_host(primary_uic->irqhost);+return;+}else{+/* Secondary UIC */+intcascade_virq;+intret;++cascade_virq=irq_of_parse_and_map(node,0);++uic->cascade.handler=uic_cascade;+uic->cascade.name="UIC cascade";+uic->cascade.dev_id=uic;++ret=setup_irq(cascade_virq,&uic->cascade);+if(ret)+printk(KERN_ERR"Failed to setup_irq(%d) for "+"UIC%d cascade\n",cascade_virq,uic->index);++/* FIXME: setup critical cascade?? */+}+}++void__inituic_init_tree(void)+{+constphandle*ic_phandle;+structdevice_node*top,*sub,*prev;+intlen;++ic_phandle=get_property(of_chosen,"interrupt-controller",&len);+if(!ic_phandle||(len!=sizeof(*ic_phandle))){+printk(KERN_CRIT"uic: Couldn't find interrupt-controller property "+"in /chosen\n");+return;+}++top=of_find_node_by_phandle(*ic_phandle);+if(!top){+printk(KERN_CRIT"uic: Couldn't find top-level UIC, phandle=%x\n",+*ic_phandle);+}++uic_init_one(top);++prev=NULL;+while((sub=of_get_next_child(top,prev))!=NULL){+if(prev)+of_node_put(prev);++uic_init_one(sub);++prev=sub;+}++of_node_put(top);+}++/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */+unsignedintuic_get_irq(void)+{+u32msr;+intsrc;++BUG_ON(primary_uic==NULL);++msr=mfdcr(primary_uic->dcrbase+UIC_MSR);+src=32-ffs(msr);++returnirq_linear_revmap(primary_uic->irqhost,src);+}
@@ -17,6 +17,7 @@ obj-$(CONFIG_QUICC_ENGINE) += qe_lib/ifeq ($(CONFIG_PPC_MERGE),y)obj-$(CONFIG_PPC_I8259)+=i8259.oobj-$(CONFIG_PPC_83xx)+=ipic.o+obj-$(CONFIG_4xx)+=uic.oendif# Temporary hack until we have migrated to asm-powerpc
From: David Gibson <hidden> Date: 2007-02-20 02:12:36
Now that we always take a device tree in arch/powerpc, there's no good
reason not to allow a single kernel to support multiple embedded 4xx
boards - the correct platform code can be selected based on the device
tree information.
Therefore, this patch re-arranges the 4xx Kconfig code to allow this.
In addition we:
- use "select" instead of depends to configure the correct
config options for specific 4xx CPUs and workarounds, which
makes the information about specific boards and CPUs less
scattered.
- Some old, unused (in arch/powerpc) config options are
removed: WANT_EARLY_SERIAL, IBM_OCP, etc.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/platforms/4xx/Kconfig | 377 +++++++++++++++----------------------
1 file changed, 153 insertions(+), 224 deletions(-)
Index: working-2.6/arch/powerpc/platforms/4xx/Kconfig
===================================================================
@@ -3,278 +3,207 @@ config 4xxdepends on40x||44xdefaulty-configWANT_EARLY_SERIAL+configBOOKEbool-selectSERIAL_8250-defaultn--menu"AMCC 4xx options"-depends on4xx--choice-prompt"Machine Type"-depends on40x-defaultWALNUT--configBUBINGA-bool"Bubinga"-selectWANT_EARLY_SERIAL-help-ThisoptionenablessupportfortheIBM405EPevaluationboard.--configCPCI405-bool"CPCI405"-help-ThisoptionenablessupportfortheCPCI405board.--configEP405-bool"EP405/EP405PC"-help-ThisoptionenablessupportfortheEP405/EP405PCboards.--configREDWOOD_5-bool"Redwood-5"-help-ThisoptionenablessupportfortheIBMSTB04evaluationboard.--configREDWOOD_6-bool"Redwood-6"-help-ThisoptionenablessupportfortheIBMSTBx25xxevaluationboard.--configSYCAMORE-bool"Sycamore"-help-ThisoptionenablessupportfortheIBMPPC405GPrevaluationboard.--configWALNUT-bool"Walnut"-help-ThisoptionenablessupportfortheIBMPPC405GPevaluationboard.--configXILINX_ML300-bool"Xilinx-ML300"-help-ThisoptionenablessupportfortheXilinxML300evaluationboard.--endchoice--choice-prompt"Machine Type"depends on44x-defaultEBONY--configBAMBOO-bool"Bamboo"-selectWANT_EARLY_SERIAL-help-ThisoptionenablessupportfortheIBMPPC440EPevaluationboard.--configEBONY-bool"Ebony"-selectWANT_EARLY_SERIAL-help-ThisoptionenablessupportfortheIBMPPC440GPevaluationboard.--configLUAN-bool"Luan"-selectWANT_EARLY_SERIAL-help-ThisoptionenablessupportfortheIBMPPC440SPevaluationboard.--configOCOTEA-bool"Ocotea"-selectWANT_EARLY_SERIAL-help-ThisoptionenablessupportfortheIBMPPC440GXevaluationboard.+defaulty-endchoice+menu"AMCC 40x options"+depends on40x-configEP405PC-bool"EP405PC Support"-depends onEP405+#config BUBINGA+# bool "Bubinga"+# depends on 40x+# default n+# select 405EP+# help+# This option enables support for the IBM 405EP evaluation board.++#config CPCI405+# bool "CPCI405"+# depends on 40x+# default n+# select 405GP+# help+# This option enables support for the CPCI405 board.++#config EP405+# bool "EP405/EP405PC"+# depends on 40x+# default n+# select 405GP+# help+# This option enables support for the EP405/EP405PC boards.++#config EP405PC+# bool "EP405PC Support"+# depends on EP405+# default y+# help+# This option enables support for the extra features of the EP405PC board.++#config REDWOOD_5+# bool "Redwood-5"+# depends on 40x+# default n+# select STB03xxx+# help+# This option enables support for the IBM STB04 evaluation board.++#config REDWOOD_6+# bool "Redwood-6"+# depends on 40x+# default n+# select STB03xxx+# help+# This option enables support for the IBM STBx25xx evaluation board.++#config SYCAMORE+# bool "Sycamore"+# depends on 40x+# default n+# select 405GPR+# help+# This option enables support for the IBM PPC405GPr evaluation board.++#config WALNUT+# bool "Walnut"+# depends on 40x+# default y+# select 405GP+# help+# This option enables support for the IBM PPC405GP evaluation board.++#config XILINX_ML300+# bool "Xilinx-ML300"+# depends on 40x+# default y+# select VIRTEX_II_PRO+# help+# This option enables support for the Xilinx ML300 evaluation board.+endmenu-# It's often necessary to know the specific 4xx processor type.-# Fortunately, it is impled (so far) from the board type, so we-# don't need to ask more redundant questions.+# 40x specific CPU modules, selected based on the board above.configNP405Hbool-depends onASH+#depends on ASHdefaulty-config440EP+# OAK doesn't exist but wanted to keep this around for any future 403GCX boards+config403GCXbool-depends onBAMBOO-selectPPC_FPU-defaulty+#depends on OAK+selectIBM405_ERR51-config440GP+config405GPbool-depends onEBONY-defaulty+selectIBM405_ERR77+selectIBM405_ERR51-config440GX+config405EPbool-depends onOCOTEA-defaulty-config440SP+config405GPRbool-depends onLUAN-defaulty-config440+configVIRTEX_II_PRObool-depends on440GP||440SP||440EP-defaulty+selectIBM405_ERR77+selectIBM405_ERR51-config440A+configSTB03xxxbool-depends on440GX-defaulty+selectIBM405_ERR77+selectIBM405_ERR51-configIBM440EP_ERR42-bool-depends on440EP-defaulty+# 40x errata/workaround config symbols, selected by the CPU models above# All 405-based cores up until the 405GPR and 405EP have this errata.configIBM405_ERR77bool-depends on40x&&!403GCX&&!405GPR&&!405EP-defaulty# All 40x-based cores, up until the 405GPR and 405EP have this errata.configIBM405_ERR51bool-depends on40x&&!405GPR&&!405EP-defaulty-configBOOKE-bool+menu"AMCC 44x options"depends on44x-defaulty--configIBM_OCP-bool-depends onASH||BAMBOO||BUBINGA||CPCI405||EBONY||EP405||LUAN||OCOTEA||REDWOOD_5||REDWOOD_6||SYCAMORE||WALNUT-defaulty-configXILINX_OCP-bool-depends onXILINX_ML300-defaulty--configIBM_EMAC4-bool-depends on440GX||440SP-defaulty--configBIOS_FIXUP-bool-depends onBUBINGA||EP405||SYCAMORE||WALNUT-defaulty--# OAK doesn't exist but wanted to keep this around for any future 403GCX boards-config403GCX-bool-depends onOAK-defaulty--config405EP-bool-depends onBUBINGA-defaulty+#config BAMBOO+# bool "Bamboo"+# depends on 44x+# default n+# select 440EP+# help+# This option enables support for the IBM PPC440EP evaluation board.-config405GP-bool-depends onCPCI405||EP405||WALNUT-defaulty--config405GPR-bool-depends onSYCAMORE-defaulty--configVIRTEX_II_PRO-bool-depends onXILINX_ML300-defaulty--configSTB03xxx-bool-depends onREDWOOD_5||REDWOOD_6-defaulty--configEMBEDDEDBOOT-bool-depends onEP405||XILINX_ML300+configEBONY+bool"Ebony"+depends on44xdefaulty+select440GP+help+ThisoptionenablessupportfortheIBMPPC440GPevaluationboard.-configIBM_OPENBIOS-bool-depends onASH||BUBINGA||REDWOOD_5||REDWOOD_6||SYCAMORE||WALNUT-defaulty+#config LUAN+# bool "Luan"+# depends on 44x+# default n+# select 440SP+# help+# This option enables support for the IBM PPC440SP evaluation board.++#config OCOTEA+# bool "Ocotea"+# depends on 44x+# default n+# select 440GX+# help+# This option enables support for the IBM PPC440GX evaluation board.-configPPC4xx_DMA-bool"PPC4xx DMA controller support"-depends on4xx+endmenu-configPPC4xx_EDMA+# 44x specific CPU modules, selected based on the board above.+config440EPbool-depends on!STB03xxx&&PPC4xx_DMA-defaulty+selectPPC_FPU+selectIBM440EP_ERR42-configPPC_GEN550+config440GPbool-depends on4xx-defaulty--choice-prompt"TTYS0 device and default console"-depends on40x-defaultUART0_TTYS0--configUART0_TTYS0-bool"UART0"--configUART0_TTYS1-bool"UART1"+selectIBM_NEW_EMAC_ZMII-endchoice--configSERIAL_SICC-bool"SICC Serial port support"-depends onSTB03xxx--configUART1_DFLT_CONSOLE+config440GXbool-depends onSERIAL_SICC&&UART0_TTYS1-defaulty-configSERIAL_SICC_CONSOLE+config440SPbool-depends onSERIAL_SICC&&UART0_TTYS1-defaulty-endmenu--menu"IBM 40x options"-depends on40x--configSERIAL_SICC-bool"SICC Serial port"-depends onSTB03xxx--configUART1_DFLT_CONSOLE+config440Abool-depends onSERIAL_SICC&&UART0_TTYS1+depends on440GXdefaulty-configSERIAL_SICC_CONSOLE+# 44x errata/workaround config symbols, selected by the CPU models above+configIBM440EP_ERR42bool-depends onSERIAL_SICC&&UART0_TTYS1-defaulty-endmenu+#config XILINX_OCP+# bool+# depends on XILINX_ML300+# default y++#config BIOS_FIXUP+# bool+# depends on BUBINGA || EP405 || SYCAMORE || WALNUT+# default y++#config PPC4xx_DMA+# bool "PPC4xx DMA controller support"+# depends on 4xx++#config PPC4xx_EDMA+# bool+# depends on !STB03xxx && PPC4xx_DMA+# default y
\ No newline at end of file
+obj-$(CONFIG_EBONY) := ebony.o
Index: working-2.6/arch/powerpc/platforms/4xx/ebony.c
===================================================================
On Tue, 2007-02-20 at 13:12 +1100, David Gibson wrote:
-# It's often necessary to know the specific 4xx processor type.
-# Fortunately, it is impled (so far) from the board type, so we
-# don't need to ask more redundant questions.
+# 40x specific CPU modules, selected based on the board above.
config NP405H
bool
- depends on ASH
+ #depends on ASH
default y
This always turns this option on, even for Ebony builds. Should
probably comment out the 'default y' for now as well.
josh
On Tue, 2007-02-20 at 13:08 +1100, David Gibson wrote:
- The early serial hacks no longer use an entire 64-bit
constant, so should work on non-64-bit aware assemblers
Yes, this compiles now with my toolchain. However, I get no output
after this:
Linux/PowerPC load:
Finalizing device tree... flat tree at 0x408568
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
[ 0.000000] Using Ebony machine description
[ 0.000000] Linux version 2.6.20-gc9ce2283-dirty (jwboyer@zod.rchland.ibm.co7
setup_arch: bootmem
arch: exit
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 32768
[ 0.000000] Normal 32768 -> 32768
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 32768
[ 0.000000] Built 1 zonelists. Total pages: 32512
[ 0.000000] Kernel command line: ip=on
[ 0.000000] UIC0 (32 IRQ sources) at DCR 0xc0
[ 0.000000] UIC1 (32 IRQ sources) at DCR 0xd0
[ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
Which probably has something to do with the of_serial driver being used
now. Just an FYI.
josh
On Tuesday 20 February 2007 15:05, Josh Boyer wrote:
Which probably has something to do with the of_serial driver being used
now. =A0Just an FYI.
If you want to use of_serial together with serial console, you need
to make sure that the detection logic in arch/powerpc/kernel/legacy_serial.c
finds the port. It currently finds the serial port on axon, but that
requires that the bus it's on is of type "opb" and the device itself
is listed as "stdout" and has type "serial" and is compatible with
"ns16750" (note: the others look for "ns16550" here).
Arnd <><
From: Sergei Shtylyov <hidden> Date: 2007-02-20 14:44:36
Hello.
David Gibson wrote:
At present, various parts of the serial code use unsigned long to
define resource addresses. This is a problem, because some 32-bit
platforms have physical addresses larger than 32-bits, and have mmio
serial uarts located above the 4GB point.
This patch changes the type of mapbase in both struct uart_port and
struct plat_serial8250_port to resource_size_t, which can be
configured to be 64 bits on such platforms. The mapbase in
serial_struct can't safely be changed, because that structure is user
visible.
Erm, isn't linux-serial@vger.kernel.org more proper list for such patches?
Also, as serial drivers are now unmaintained, this probably needs to go to -mm
tree.
On Tue, 2007-02-20 at 15:16 +0100, Arnd Bergmann wrote:
On Tuesday 20 February 2007 15:05, Josh Boyer wrote:
quoted
Which probably has something to do with the of_serial driver being used
now. Just an FYI.
If you want to use of_serial together with serial console, you need
to make sure that the detection logic in arch/powerpc/kernel/legacy_serial.c
finds the port. It currently finds the serial port on axon, but that
requires that the bus it's on is of type "opb" and the device itself
is listed as "stdout" and has type "serial" and is compatible with
"ns16750" (note: the others look for "ns16550" here).
The ebony dts has the ports as ns16550. That is required for the
bootwrapper to find the port to use for it's output at the moment.
josh
On Tue, 2007-02-20 at 08:46 -0600, Josh Boyer wrote:
On Tue, 2007-02-20 at 15:16 +0100, Arnd Bergmann wrote:
quoted
On Tuesday 20 February 2007 15:05, Josh Boyer wrote:
quoted
Which probably has something to do with the of_serial driver being used
now. Just an FYI.
If you want to use of_serial together with serial console, you need
to make sure that the detection logic in arch/powerpc/kernel/legacy_serial.c
finds the port. It currently finds the serial port on axon, but that
requires that the bus it's on is of type "opb" and the device itself
is listed as "stdout" and has type "serial" and is compatible with
"ns16750" (note: the others look for "ns16550" here).
The ebony dts has the ports as ns16550. That is required for the
bootwrapper to find the port to use for it's output at the moment.
And the ebony dts also has the a bus type of "ibm,opb" as well.
I hacked legacy_serial.c to look for ns16550 compatible devices with a
parent OPB node of type "ibm,opb" and I got serial output on the Ebony
board even with of_serial turned off.
We should look for both "ns16550" and "ns16750" compatible devices in
legacy_serial.c. As for the bus type, we could look for both types or
the ebony.dts could change to use "opb" instead of "ibm,opb".
josh
On Tuesday 20 February 2007 16:03, Josh Boyer wrote:
And the ebony dts also has the a bus type of "ibm,opb" as well.
We should really get a common name for these. I don't remember
what the discussions were, but it seems we came up with different
results for Axon and ppc4xx, which is very bad.
Using type "ibm,opb" rather than just "opb" makes sense to me,
but I don't know if we already have shipping systems that use
"opb" here.
There is probably a similar problem with the nodes for "plb4",
"plb5" and "ebc", as well as the "compatible" property of the
serial port, which, as you noted earlier is "ns16550" on
ebony and "ns16750" on axon, although it is exactly the same
macro.
Arnd <><
On Tue, 2007-02-20 at 13:12 +1100, David Gibson wrote:
quoted hunk
Add a device tree for the Ebony evaluation board (440GP based). This
tree is not complete or finalized. This tree needs a very recent
version of dtc to process.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/boot/dts/ebony.dts | 225 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 225 insertions(+)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
As I pointed out in an earlier email, this breaks working with the
current legacy_serial driver. It's looking for a device_type of "opb".
I'm not sure if we should fix the driver or fix this and the
ebony_of_bus types in arch/powerpc/platforms/4xx/ebony.c
josh
On Tue, 2007-02-20 at 16:07 +0100, Arnd Bergmann wrote:
On Tuesday 20 February 2007 16:03, Josh Boyer wrote:
quoted
And the ebony dts also has the a bus type of "ibm,opb" as well.
We should really get a common name for these. I don't remember
what the discussions were, but it seems we came up with different
results for Axon and ppc4xx, which is very bad.
Yes, using common types would be a very good idea. There's no published
DTS for Axon so we have no idea what has been previously defined.
Using type "ibm,opb" rather than just "opb" makes sense to me,
but I don't know if we already have shipping systems that use
"opb" here.
I would prefer "ibm,xxx" as well if it's possible.
There is probably a similar problem with the nodes for "plb4",
"plb5" and "ebc", as well as the "compatible" property of the
serial port, which, as you noted earlier is "ns16550" on
ebony and "ns16750" on axon, although it is exactly the same
macro.
Right, ebony is currently using "ibm,plb". We haven't defined an EBC
node yet for 4xx.
josh
And the ebony dts also has the a bus type of "ibm,opb" as well.
We should really get a common name for these. I don't remember
what the discussions were, but it seems we came up with different
results for Axon and ppc4xx, which is very bad.
"Very bad"... Well sure it's less than desirable, but
we have to deal with this problem anyway already.
Using type "ibm,opb" rather than just "opb" makes sense to me,
but I don't know if we already have shipping systems that use
"opb" here.
There is probably a similar problem with the nodes for "plb4",
"plb5" and "ebc",
It makes sense for generic code to always if it is asked
to match for "vendor-code,some-name" also to match on
plain "some-name". Well unless people start doing crazy
things like naming something "vendor-code,pci" which
isn't PCI compatible or something -- in that case there
could be a function that matches on exact name only, or
the caller can deal with it itself perhaps.
But in most cases the matching-without-prefix should work
fine.
as well as the "compatible" property of the
serial port, which, as you noted earlier is "ns16550" on
ebony and "ns16750" on axon, although it is exactly the same
macro.
So the "compatible" property should read ns16750, ns16550,
ns16450, i8250. The kernel really only needs the device
to be compatible to the 8250; but since lots of device trees
mention only the newer UART types, you have to match on those
too.
Segher
On Tuesday 20 February 2007 16:25, Segher Boessenkool wrote:
quoted
quoted
And the ebony dts also has the a bus type of "ibm,opb" as well.
We should really get a common name for these. I don't remember
what the discussions were, but it seems we came up with different
results for Axon and ppc4xx, which is very bad.
"Very bad"... Well sure it's less than desirable, but
we have to deal with this problem anyway already.
quoted
Using type "ibm,opb" rather than just "opb" makes sense to me,
but I don't know if we already have shipping systems that use
"opb" here.
There is probably a similar problem with the nodes for "plb4",
"plb5" and "ebc",
It makes sense for generic code to always if it is asked
to match for "vendor-code,some-name" also to match on
plain "some-name". Well unless people start doing crazy
things like naming something "vendor-code,pci" which
isn't PCI compatible or something -- in that case there
could be a function that matches on exact name only, or
the caller can deal with it itself perhaps.
But in most cases the matching-without-prefix should work
fine.
but is it really the right thing to call it "ibm,plb"
when the identical macro is used on amcc based systems?
I think that was our reasoning when we introduced the
code in linux to scan for "plb5", "plb4" and "opb" buses.
Changing the "device-type" now would result in the final
product to not work on the 2.6.20 kernel, which was released
with the code only scanning for the short names.
Still, it's probably a good idea to list both variants
in compatible, e.g.
type="plb4", compatible="ibm,plb\0ibm,plb4\0plb"
on CAB/axon, and
type="ibm,plb", compatible="ibm,plb4\0plb4\0plb"
on ebony and others. Do you think it makes sense to do it this
way, or should we rather adopt the axon style on the 440 boards?
quoted
as well as the "compatible" property of the
serial port, which, as you noted earlier is "ns16550" on
ebony and "ns16750" on axon, although it is exactly the same
macro.
So the "compatible" property should read ns16750, ns16550,
ns16450, i8250. The kernel really only needs the device
to be compatible to the 8250; but since lots of device trees
mention only the newer UART types, you have to match on those
too.
Right, that sounds completely correct. I think I've done the
right thing in of_serial already. Christian, please check
what the firmware does today, and make sure to change it
accordingly.
We probably also need a volunteer to clean up the legacy_serial
code for this, it's grown pretty messy by now.
Arnd <><
Since UIC1 is cascaded off UIC0 in the interrupt tree,
UIC1 should have an interrupt-parent pointing to UIC0
so the interrupt tree can be traversed to the root.
I know this was beaten to death last week, but I would
still argue that in the device tree UIC0 and UIC1 should
be siblings. (In the interrupt tree the cascade relationship
is described through interrupt-parent).
I thought there was agreement (last week) that interrupt-controller
would no longer be under /chosen. I submitted a patch to
booting-without-of.txt to make this obsolete. The kernel
does not use the property, and we can find a different place for
it in the future if we need it.
Stuart
but is it really the right thing to call it "ibm,plb"
when the identical macro is used on amcc based systems?
I think that was our reasoning when we introduced the
code in linux to scan for "plb5", "plb4" and "opb" buses.
Yes, the vendor-code is there only as a unique marker
so different vendors won't have clashing namespaces.
Seen from that viewpoint, if a company buys stuff from
another company, or the whole company is bought or something,
it makes sense to keep the original name.
Changing the "device-type" now would result in the final
product to not work on the 2.6.20 kernel, which was released
with the code only scanning for the short names.
If it's important for you to support .20, you obviously
shouldn't change this in the device tree anymore.
Unfortunate.
Still, it's probably a good idea to list both variants
in compatible, e.g.
type="plb4", compatible="ibm,plb\0ibm,plb4\0plb"
No, that's a very bad idea.
Do you think it makes sense to do it this
way, or should we rather adopt the axon style on the 440 boards?
Like I said, it is probably best to have the device_is_compatible()
function return true if it is asked for "some-vendor,some-name"
and the actual property contains just "some-name". The device
tree isn't more specific in that case, so any matcher can easily
be hurt by a namespace clash -- too bad, nothing the kernel
can do about it, but at least it can do the right thing for
device trees that *do* comply to best practice.
quoted
So the "compatible" property should read ns16750, ns16550,
quoted
ns16450, i8250. The kernel really only needs the device
quoted
to be compatible to the 8250; but since lots of device trees
quoted
mention only the newer UART types, you have to match on those
quoted
too.
Right, that sounds completely correct. I think I've done the
right thing in of_serial already.
Yeah I think so.
Christian, please check
what the firmware does today, and make sure to change it
accordingly.
Note that it doesn't matter much for Linux if you change the
"compatible" property for serial now; the kernel will have to
support ns16550, ns16750 for ever since there are device
trees in the wild that don't include the more generic devices
in their "compatible" property. Not only Axon etc. device
trees, don't get me wrong :-)
We probably also need a volunteer to clean up the legacy_serial
code for this, it's grown pretty messy by now.
Since UIC1 is cascaded off UIC0 in the interrupt tree,
UIC1 should have an interrupt-parent pointing to UIC0
so the interrupt tree can be traversed to the root.
Not necessary if UIC0 is the device tree parent of UIC1.
(And in fact it would be "bad style"). But...
I know this was beaten to death last week, but I would
still argue that in the device tree UIC0 and UIC1 should
be siblings. (In the interrupt tree the cascade relationship
is described through interrupt-parent).
... that is my opinion as well (as I'm sure you know ;-) ),
and then of course you _do_ need the interrupt-parent property.
Segher
On Tue, 2007-02-20 at 20:51 +0100, Segher Boessenkool wrote:
quoted
We probably also need a volunteer to clean up the legacy_serial
code for this, it's grown pretty messy by now.
I nominate you :-)
In the absence of someone actually cleaning up the code, the following
ugly patch should work for both Axon and 4xx until we can settle on
settle on something. It booted on my Ebony board with David's
FIXED_PORT flag patch also applied anyway.
josh
Make legacy_serial look for multiple compatible serial types on the OBP bus.
Signed-off-by: Josh Boyer <redacted>
--
@@ -339,14 +346,19 @@ void __init find_legacy_serial_ports(void)}/* First fill our array with opb bus ports */-for(np=NULL;(np=of_find_compatible_node(np,"serial","ns16750"))!=NULL;){-structdevice_node*opb=of_get_parent(np);-if(opb&&!strcmp(opb->type,"opb")){-index=add_legacy_soc_port(np,np);-if(index>=0&&np==stdout)-legacy_serial_console=index;+for(i=0;compat[i]!=NULL;i++){+for(np=NULL;+(np=of_find_compatible_node(np,"serial",compat[i]))!=NULL;){++structdevice_node*opb=of_get_parent(np);+if(opb&&+(!strcmp(opb->type,"opb")||!strcmp(opb->type,"ibm,opb"))){+index=add_legacy_soc_port(np,np);+if(index>=0&&np==stdout)+legacy_serial_console=index;+}+of_node_put(opb);}-of_node_put(opb);}#ifdef CONFIG_PCI
From: David Gibson <hidden> Date: 2007-02-21 00:19:18
On Tue, Feb 20, 2007 at 05:44:26PM +0300, Sergei Shtylyov wrote:
Hello.
David Gibson wrote:
quoted
At present, various parts of the serial code use unsigned long to
define resource addresses. This is a problem, because some 32-bit
platforms have physical addresses larger than 32-bits, and have mmio
serial uarts located above the 4GB point.
This patch changes the type of mapbase in both struct uart_port and
struct plat_serial8250_port to resource_size_t, which can be
configured to be 64 bits on such platforms. The mapbase in
serial_struct can't safely be changed, because that structure is user
visible.
Erm, isn't linux-serial@vger.kernel.org more proper list for
such patches? Also, as serial drivers are now unmaintained, this
probably needs to go to -mm tree.
I've also sent this to rmk, akpm and lkml for inclusion in -mm. It's
just copied here so that all the patches necessary for Ebony are
convenient in one place.
@@ -633,7 +633,7 @@ static int uart_get_info(struct uart_statmp.hub6=port->hub6;tmp.io_type=port->iotype;tmp.iomem_reg_shift=port->regshift;-tmp.iomem_base=(void*)port->mapbase;+tmp.iomem_base=(void*)(unsignedlong)port->mapbase;
For 32-bit kernels this may result in a meaningless address. Have you
considered also changing iomem_base's type?
Impossible; that's the serial_struct, which is userland visible. Yes,
it will result in a meaningless address, but I don't see what else can
be done.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-02-21 00:20:32
On Tue, Feb 20, 2007 at 02:26:05PM +0100, Segher Boessenkool wrote:
quoted
+config PPC_EARLY_DEBUG_44x
+ bool "Early serial debugging for IBM 44x CPUs"
Change this to IBM/AMCC 44x, like the patch description
says?
Done.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-02-21 00:32:42
On Tue, Feb 20, 2007 at 07:51:29AM -0600, Josh Boyer wrote:
On Tue, 2007-02-20 at 13:12 +1100, David Gibson wrote:
quoted
-# It's often necessary to know the specific 4xx processor type.
-# Fortunately, it is impled (so far) from the board type, so we
-# don't need to ask more redundant questions.
+# 40x specific CPU modules, selected based on the board above.
config NP405H
bool
- depends on ASH
+ #depends on ASH
default y
This always turns this option on, even for Ebony builds. Should
probably comment out the 'default y' for now as well.
Oops, yes. Fixed.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-02-21 00:32:43
On Tue, Feb 20, 2007 at 09:09:51AM -0600, Josh Boyer wrote:
On Tue, 2007-02-20 at 13:12 +1100, David Gibson wrote:
quoted
Add a device tree for the Ebony evaluation board (440GP based). This
tree is not complete or finalized. This tree needs a very recent
version of dtc to process.
Signed-off-by: David Gibson <redacted>
---
arch/powerpc/boot/dts/ebony.dts | 225 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 225 insertions(+)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
As I pointed out in an earlier email, this breaks working with the
current legacy_serial driver. It's looking for a device_type of "opb".
I'm not sure if we should fix the driver or fix this and the
ebony_of_bus types in arch/powerpc/platforms/4xx/ebony.c
That's kind of deliberate. The idea is to use the of_serial stuff
instead of legacy_serial. legacy_serial was really meant for *legacy*
(i.e. ISA) serial ports, not these on chip things.
The revised version of ebony.c already scans ibm,plb and ibm,opb
busses for OF devices.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-02-21 00:35:58
On Tue, Feb 20, 2007 at 03:16:24PM +0100, Arnd Bergmann wrote:
On Tuesday 20 February 2007 15:05, Josh Boyer wrote:
quoted
Which probably has something to do with the of_serial driver being used
now. Just an FYI.
If you want to use of_serial together with serial console, you need
to make sure that the detection logic in arch/powerpc/kernel/legacy_serial.c
finds the port. It currently finds the serial port on axon, but that
requires that the bus it's on is of type "opb" and the device itself
is listed as "stdout" and has type "serial" and is compatible with
"ns16750" (note: the others look for "ns16550" here).
Err.. no. On my system legacy_serial doesn't touch the ports, but I'm
getting console output via of_serial just fine. The console is
initialized rather later than would be ideal, but it works.
I know that BenH has expressed the strong preference that
legacy_serial should be reverted to only handling legacy ISA ports,
not SoC and other hardwired ports.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-02-21 00:42:37
On Tue, Feb 20, 2007 at 09:03:26AM -0600, Josh Boyer wrote:
On Tue, 2007-02-20 at 08:46 -0600, Josh Boyer wrote:
quoted
On Tue, 2007-02-20 at 15:16 +0100, Arnd Bergmann wrote:
quoted
On Tuesday 20 February 2007 15:05, Josh Boyer wrote:
quoted
Which probably has something to do with the of_serial driver being used
now. Just an FYI.
If you want to use of_serial together with serial console, you need
to make sure that the detection logic in arch/powerpc/kernel/legacy_serial.c
finds the port. It currently finds the serial port on axon, but that
requires that the bus it's on is of type "opb" and the device itself
is listed as "stdout" and has type "serial" and is compatible with
"ns16750" (note: the others look for "ns16550" here).
The ebony dts has the ports as ns16550. That is required for the
bootwrapper to find the port to use for it's output at the moment.
And the ebony dts also has the a bus type of "ibm,opb" as well.
I hacked legacy_serial.c to look for ns16550 compatible devices with a
parent OPB node of type "ibm,opb" and I got serial output on the Ebony
board even with of_serial turned off.
No, the idea is that Ebony *should not* be using legacy_serial. It
uses of_serial instead.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-02-21 00:42:38
On Tue, Feb 20, 2007 at 02:29:25PM -0600, Josh Boyer wrote:
On Tue, 2007-02-20 at 20:51 +0100, Segher Boessenkool wrote:
quoted
quoted
We probably also need a volunteer to clean up the legacy_serial
code for this, it's grown pretty messy by now.
I nominate you :-)
In the absence of someone actually cleaning up the code, the following
ugly patch should work for both Axon and 4xx until we can settle on
settle on something. It booted on my Ebony board with David's
FIXED_PORT flag patch also applied anyway.
josh
Make legacy_serial look for multiple compatible serial types on the OBP bus.
Again: legacy_serial is not necessary for Ebony console support with
the current patches.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: David Gibson <hidden> Date: 2007-02-21 00:44:51
On Tue, Feb 20, 2007 at 04:07:32PM +0100, Arnd Bergmann wrote:
On Tuesday 20 February 2007 16:03, Josh Boyer wrote:
quoted
And the ebony dts also has the a bus type of "ibm,opb" as well.
We should really get a common name for these. I don't remember
what the discussions were, but it seems we came up with different
results for Axon and ppc4xx, which is very bad.
Using type "ibm,opb" rather than just "opb" makes sense to me,
but I don't know if we already have shipping systems that use
"opb" here.
There is probably a similar problem with the nodes for "plb4",
"plb5" and "ebc", as well as the "compatible" property of the
serial port, which, as you noted earlier is "ns16550" on
ebony and "ns16750" on axon, although it is exactly the same
macro.
Yes, we should have some common names. I didn't like using bare
"plb", because I was worried that, being such a bland generic name,
some other vendor might apply the same name to their own "processor
local bus" which could be something entirely different. But, if we
have things in the wild that use "plb" and "opb", then I'll change it
over.
That said, this doesn't actually break anything at present.
legacy_serial is not supposed to find any ports on Ebony, and ebony.c
specifies the bus types to be probed for of_platform devices,
including of_serial.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
This patch adds a new set of more flexible convenience wrappers around
zlib, moving them to their own file, gunzip_util.c, in the process.
These wrappers allow decompressing sections of the compressed image to
different locations. In addition, they transparently handle
uncompressed data, avoiding special case code to handle uncompressed
vmlinux images.
I tested this on on PS3 without trouble.
Acked-by: Geoff Levand <redacted>
This patch re-organises the way the zImage wrapper code is entered, to
allow more flexibility on platforms with unusual entry conditions.
After this patch, a platform .o file has two options:
I tested this on on PS3 without trouble.
Acked-by: Geoff Levand <redacted>
On Wed, Feb 21, 2007 at 11:38:56AM +1100, David Gibson wrote:
On Tue, Feb 20, 2007 at 02:29:25PM -0600, Josh Boyer wrote:
quoted
On Tue, 2007-02-20 at 20:51 +0100, Segher Boessenkool wrote:
quoted
quoted
We probably also need a volunteer to clean up the legacy_serial
code for this, it's grown pretty messy by now.
I nominate you :-)
In the absence of someone actually cleaning up the code, the following
ugly patch should work for both Axon and 4xx until we can settle on
settle on something. It booted on my Ebony board with David's
FIXED_PORT flag patch also applied anyway.
josh
Make legacy_serial look for multiple compatible serial types on the OBP bus.
Again: legacy_serial is not necessary for Ebony console support with
the current patches.
Ok, that's fine. But we should select of_serial from the Ebony Kconfig entry
if that's the one you'd like to use.
josh
From: David Gibson <hidden> Date: 2007-02-21 04:57:56
On Tue, Feb 20, 2007 at 08:56:04PM +0100, Segher Boessenkool wrote:
quoted
Since UIC1 is cascaded off UIC0 in the interrupt tree,
UIC1 should have an interrupt-parent pointing to UIC0
so the interrupt tree can be traversed to the root.
Not necessary if UIC0 is the device tree parent of UIC1.
(And in fact it would be "bad style"). But...
quoted
I know this was beaten to death last week, but I would
still argue that in the device tree UIC0 and UIC1 should
be siblings. (In the interrupt tree the cascade relationship
is described through interrupt-parent).
... that is my opinion as well (as I'm sure you know ;-) ),
and then of course you _do_ need the interrupt-parent property.
Ok, there are enough people of this opinion (including Paul), that
I've changed to representing the UICs as siblings.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
On Wednesday 21 February 2007 01:35, David Gibson wrote:
Err.. no. =A0On my system legacy_serial doesn't touch the ports, but I'm
getting console output via of_serial just fine. =A0The console is
initialized rather later than would be ideal, but it works.
=20
I know that BenH has expressed the strong preference that
legacy_serial should be reverted to only handling legacy ISA ports,
not SoC and other hardwired ports.
Ok, my impression on this was that of_serial is the right solution
in general, but it often gets initialized too late to debug some
of the interesting parts of the boot sequence.
Unless we take handling of soc serial ports completely out of
legacy_serial, I think it should handle ebony just like the other
boards.
Because of the way the serial layer works, it does exactly the
right thing if you have both drivers enabled, i.e. it starts
out using the first port when legacy_serial detects it, but later
of_serial finds it as well, and wires up all the logic to connect
both the serial ports to the right device tree nodes.
Arnd <><
Not really. The 440GP user manual refers to the bridge (as opposed to
the bus) as POB0. The label is meant to reflect that.
The device node represents both the bridge _and_ the bus
behind it, so you could use OPB just as well as POB, and
it probably would be less confusing ;-)
But it's just a label, who cares.
Segher
Since UIC1 is cascaded off UIC0 in the interrupt tree,
UIC1 should have an interrupt-parent pointing to UIC0
so the interrupt tree can be traversed to the root.
Not necessary if UIC0 is the device tree parent of UIC1.
For the archives: this is wrong, all interrupt controllers
(except the root one) are required to have an "interrupt-parent"
property -- this is how the root interrupt controller is
determined.
Segher
From: David Gibson <hidden> Date: 2007-02-25 23:57:48
On Wed, Feb 21, 2007 at 10:06:58AM +0100, Arnd Bergmann wrote:
On Wednesday 21 February 2007 01:35, David Gibson wrote:
quoted
Err.. no. On my system legacy_serial doesn't touch the ports, but I'm
getting console output via of_serial just fine. The console is
initialized rather later than would be ideal, but it works.
I know that BenH has expressed the strong preference that
legacy_serial should be reverted to only handling legacy ISA ports,
not SoC and other hardwired ports.
Ok, my impression on this was that of_serial is the right solution
in general, but it often gets initialized too late to debug some
of the interesting parts of the boot sequence.
Unless we take handling of soc serial ports completely out of
legacy_serial, I think it should handle ebony just like the other
boards.
Well, Ben has said to me that he'd like to remove handling of SoC
serial ports (indeed everything excepy legacy ISA) from
legacy_serial.c.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson