* Re: openpic/mac-io
From: Benjamin Herrenschmidt @ 2005-10-19 10:35 UTC (permalink / raw)
To: i2a; +Cc: linuxppc-dev
In-Reply-To: <20051018191029.M22134@quicknet.nl>
On Tue, 2005-10-18 at 21:22 +0200, i2a wrote:
> Hi,
>
> I am searching for documentation about the OpenPIC interrupt-controller in mac
> systems. I found this site but most of the links are dead or give no hope on
> real technical documentation :).
> http://www.macbsd.com/openmac/refs.html
>
> Could someone give any pointers or files?
>
> I am also searching for any related documentation on the mac-io device (this
> could be a combo document).
>
> I am trying to do a port as a masters project, and my biggest problem is:
> documentation :(.
Another interesting bit of docs is MacTech.pdf (google for it) which
documents an early version of the mac-io chip that was used on some CHRP
machines.
In general, there is no complete documentation. I would say that the
linux source code is probably the best you can get in this regard.
Feel free to ask me questions about details
Ben.
^ permalink raw reply
* Re: jffs2 robustness against powerfailure
From: David Woodhouse @ 2005-10-19 9:50 UTC (permalink / raw)
To: David Jander; +Cc: linux-mtd, linuxppc-embedded
In-Reply-To: <200510191010.47799.david.jander@protonic.nl>
On Wed, 2005-10-19 at 10:10 +0200, David Jander wrote:
> 2.6 is not an option yet for mpc8xx architecture, so I'll have to stick with
> either what I have now or 2.4.31, but I fear the tradeoff of using vanilla
> 2.4.31 jffs2 will be much slower fs, prohibitively long mount-times, etc...
> am I right?
If it's all running perfectly for you and you have no work to do, then
yes, perhaps you're right. But since that's evidently _not_ the case,
then no, I would disagree.
If I were you, the first thing I'd do would be to get a current kernel
working. It should only take a week or so -- porting from 2.4 to 2.6
really isn't that difficult.
> I am still busy doing experiments, please have a little patience.
> Until now I have turned on debug info in the same kernel as before, and get
> literally tons of log info. My monitor script had a bug, so the board was
> reset a little to soon in several occasions (shouldn't harm, should it), so
> now I have an image of jffs2 which on boot of the system produces a BUG() in
> gc.c line 139.
That should never happen, regardless of when the board is reset.
Assuming it still happens with JFFS2 code I care about (either 2.4 or
2.6), please could I have a copy of this image?
The problem you first reported doesn't seem too worrying to me. Writes
aren't always atomic -- in fact the Linux VFS¹ _guarantees_ that writes
larger than a page are _not_ atomic, because it splits pages up to call
prepare_write() and commit_write() on each one.
JFFS2 will mostly write each page out in a single node, but when there
is only a small amount of space at the end of an eraseblock it will
split writes still further, filling the eraseblock with as much data as
possible before writing the remainder of the page into a new eraseblock.
I suspect that's what happened in the case you showed.
--
dwmw2
¹ Assuming you use generic_file_write()
^ permalink raw reply
* Re: openpic/mac-io
From: Geert Uytterhoeven @ 2005-10-19 9:22 UTC (permalink / raw)
To: i2a; +Cc: Linux/PPC Development
In-Reply-To: <20051018191029.M22134@quicknet.nl>
On Tue, 18 Oct 2005, i2a wrote:
> I am searching for documentation about the OpenPIC interrupt-controller in mac
> systems. I found this site but most of the links are dead or give no hope on
> real technical documentation :).
> http://www.macbsd.com/openmac/refs.html
>
> Could someone give any pointers or files?
http://www.printk.net/pub/docs/openpic/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: jffs2 robustness against powerfailure
From: David Jander @ 2005-10-19 8:10 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd, linuxppc-embedded
In-Reply-To: <1129552672.3830.249.camel@baythorne.infradead.org>
On Monday 17 October 2005 14:37, David Woodhouse wrote:
> On Fri, 2005-10-14 at 11:35 +0200, David Jander wrote:
> > We have a custom embedded linux board, based on a MPC852T processor,
> > running 2.4.25 kernel from denx. Jffs2 has certain backported patches
> > after cvs from 03/2005.
>
> That sounds like a recipe for pain. March 2005 wasn't a good time to
> take a snapshot from CVS; that just happens to be the time that we
> stopped bothering to make it build in obsolete kernels.
That's why I posted to the linuxppc-embedded list, because I know there are
quite some people using the same version (denx CVS kernel), and might have
had issues of this kind also, although I mostly hear that it seems pretty
stable and doesn't give problems.
> If you want _stable_ JFFS2 code, you should use the code which is in the
> 2.4.31 kernel, or use the code which is in the 2.6 kernel (perhaps
> updated from current CVS).
2.6 is not an option yet for mpc8xx architecture, so I'll have to stick with
either what I have now or 2.4.31, but I fear the tradeoff of using vanilla
2.4.31 jffs2 will be much slower fs, prohibitively long mount-times, etc...
am I right?
>[...]
> Please could you reproduce on a sane kernel and show the output of the
> checkfs program during your test just before the power down, and also if
> possible take an image of the contents of the flash _before_ mounting it
> again after the power cycle. I'd like to see precisely the log nodes
> which were present on the flash. If it's difficult to take a snapshot
> before remounting, then running with CONFIG_JFFS2_FS_DEBUG=1 and
> capturing all the KERN_DEBUG output via a serial console would suffice.
I am still busy doing experiments, please have a little patience.
Until now I have turned on debug info in the same kernel as before, and get
literally tons of log info. My monitor script had a bug, so the board was
reset a little to soon in several occasions (shouldn't harm, should it), so
now I have an image of jffs2 which on boot of the system produces a BUG() in
gc.c line 139. This is not what I am looking for right now, and I still have
to discard any possibilities that this could have happened due to other
problems (RAM issues, etc). Once I finish sorting this out, I'd be glad to
send you a few megabytes of debug output along with a "broken" jffs2 image if
you like. Actually I'd be very grateful if you could take some time to look
at it and give me your opinion, because I am still slightly clueless about
jffs2.
Greetings,
--
David Jander
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: Kalle Pokki @ 2005-10-19 6:37 UTC (permalink / raw)
To: David H. Lynch Jr; +Cc: linuxppc-embedded
In-Reply-To: <4355D6C1.4030004@comcast.net>
David H. Lynch Jr wrote:
> Alright I have RAM at physical 0x0 now. I throw a copy of a
> compressed linux image into RAM (anywhere special ?) load the assorted
> registers with the appropriate values, fill the board info struct.,
> and just jump to the start of the image and pray that load text starts
> coming out my serial port ?
Basically, but the exact thing to do depends which image you take. The
build process results in a few different image files. I usually just
take the vmlinux ELF file, and then my own scripts objcopy it to binary,
compress, objcopy to an object file, and link the compressed image
directly to the boot loader. The boot loader is then, of course,
responsible of uncompressing the image to RAM to 0x00000000.
I think the kernel build can also create some "self-extracting" images,
but I have never tried those. Maybe they don't even work anymore, as
many (most?) people just use the U-boot images.
^ permalink raw reply
* Parameter RAM Conflict of SCC1 SPI & Ethernet
From: shrisha.prasad @ 2005-10-19 5:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
Hi all,
The MPC862 UM Errata mentions that there is possiblity to solve
ParameterRAM Conflict without a Microcode patch .
I am working on a SerialEEPROM SPI Driver for mpc862
my driver needs to do is read the chip number from SPROM and calculate
the MAC address
The SPI mpc8xx is interfaced to 9346 eeprom for this and I want to
retrieve the MAC address
The errata tells that no patch required for relocation ,but using some
trick you can avoid it
I am using the UBoot SPI Driver code for MPC8xx ,Do I need to modify the
code in order to suit my requirements
Since I am a newbie in kernel programming ,some help is requested .
Regards
[-- Attachment #2: Type: text/html, Size: 1064 bytes --]
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: David H. Lynch Jr @ 2005-10-19 5:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <435557A0.8090505@iki.fi>
Kalle Pokki wrote:
> David H. Lynch Jr. wrote:
>
>> Kalle Pokki wrote:
>>
>>> 1. Put RAM to 0x0000000 and flash to some location it mirrors to
>>> your boot vector. Linux always expects your physical memory to be at
>>> zero. It is then mapped to virtual address 0xC0000000.
>>
>>
>> In both this list and elsewhere I have seen several references to
>> the difficulty setting up Linux with a physical RAM base other than
>> 0x0. I was hoping that I could bypass that by re-arranging physical
>> memory using the BAT's or MMU.
>> I am gathering that while this is possible, that it not sufficient.
>> That if memory is re-arranged after power-on it has to be done by
>> something Linux is not aware of.
>
>
> I'm afraid you cannot fool Linux that way... it will take control of
> the BATs and MMU. Even as a concept, you cannot re-arrange physical
> memory with the MMU at all - it's virtual memory when you do the
> address translation. The only way to arrange physical memory is to
> program the memory controller. I don't know how flexible the OCM
> controller in ppc405 is, but I'd be surprised if one couldn't freely
> set the addresses to whatever suits best.
>
>
I have built a Kernel - that is something I am pretty compitent at.
My system is fairly similar to an abreviated xilinx ml-300, and I have
added it to the Linux configuration and made what adjustments I beleive
were needed (mostly eliminating hardware I do not have or want). The
resulting Kernel is configured and successfully built.
Alright I have RAM at physical 0x0 now. I throw a copy of a compressed
linux image into RAM (anywhere special ?) load the assorted registers
with the appropriate values, fill the board info struct., and just jump
to the start of the image and pray that load text starts coming out my
serial port ?
Once this sucker gets through the code in head_4xx.S I should be in
business, or atleast to a point where I can deal with whatever crops up.
^ permalink raw reply
* [PATCH] ppc32: replace use of _GLOBAL with .globl for ppc32
From: Kumar Gala @ 2005-10-18 22:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc-embedded
The _GLOBAL() macro is for text symbols only. Changed to using
.globl for .data symbols. This is also needed in ppc32 land
to allow FSL Book-E, 40x, and 44x to work.
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
---
commit ca6e6d7a599f8e8a5976c044910b98ef30258e30
tree d220cd916c8bdb6bb9c5ddbdfc2ecbfa5004cf89
parent a2084dccc9e9b0ccc5c40ed2f1273c82b23369d2
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 18 Oct 2005 17:40:56 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 18 Oct 2005 17:40:56 -0500
arch/ppc/kernel/head_44x.S | 18 +++++++++++-------
arch/ppc/kernel/head_4xx.S | 16 +++++++++++-----
arch/ppc/kernel/head_fsl_booke.S | 17 +++++++++++------
3 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S
+++ b/arch/ppc/kernel/head_44x.S
@@ -743,14 +743,18 @@ _GLOBAL(set_context)
* goes at the beginning of the data segment, which is page-aligned.
*/
.data
-_GLOBAL(sdata)
-_GLOBAL(empty_zero_page)
+ .align 12
+ .globl sdata
+sdata:
+ .globl empty_zero_page
+empty_zero_page:
.space 4096
/*
* To support >32-bit physical addresses, we use an 8KB pgdir.
*/
-_GLOBAL(swapper_pg_dir)
+ .globl swapper_pg_dir
+swapper_pg_dir:
.space 8192
/* Reserved 4k for the critical exception stack & 4k for the machine
@@ -759,13 +763,15 @@ _GLOBAL(swapper_pg_dir)
.align 12
exception_stack_bottom:
.space BOOKE_EXCEPTION_STACK_SIZE
-_GLOBAL(exception_stack_top)
+ .globl exception_stack_top
+exception_stack_top:
/*
* This space gets a copy of optional info passed to us by the bootstrap
* which is used to pass parameters into the kernel like root=/dev/sda1, etc.
*/
-_GLOBAL(cmd_line)
+ .globl cmd_line
+cmd_line:
.space 512
/*
@@ -774,5 +780,3 @@ _GLOBAL(cmd_line)
*/
abatron_pteptrs:
.space 8
-
-
diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S
--- a/arch/ppc/kernel/head_4xx.S
+++ b/arch/ppc/kernel/head_4xx.S
@@ -988,10 +988,14 @@ _GLOBAL(set_context)
* goes at the beginning of the data segment, which is page-aligned.
*/
.data
-_GLOBAL(sdata)
-_GLOBAL(empty_zero_page)
+ .align 12
+ .globl sdata
+sdata:
+ .globl empty_zero_page
+empty_zero_page:
.space 4096
-_GLOBAL(swapper_pg_dir)
+ .globl swapper_pg_dir
+swapper_pg_dir:
.space 4096
@@ -1001,12 +1005,14 @@ _GLOBAL(swapper_pg_dir)
exception_stack_bottom:
.space 4096
critical_stack_top:
-_GLOBAL(exception_stack_top)
+ .globl exception_stack_top
+exception_stack_top:
/* This space gets a copy of optional info passed to us by the bootstrap
* which is used to pass parameters into the kernel like root=/dev/sda1, etc.
*/
-_GLOBAL(cmd_line)
+ .globl cmd_line
+cmd_line:
.space 512
/* Room for two PTE pointers, usually the kernel and current user pointers
diff --git a/arch/ppc/kernel/head_fsl_booke.S b/arch/ppc/kernel/head_fsl_booke.S
--- a/arch/ppc/kernel/head_fsl_booke.S
+++ b/arch/ppc/kernel/head_fsl_booke.S
@@ -1028,10 +1028,14 @@ _GLOBAL(set_context)
* goes at the beginning of the data segment, which is page-aligned.
*/
.data
-_GLOBAL(sdata)
-_GLOBAL(empty_zero_page)
+ .align 12
+ .globl sdata
+sdata:
+ .globl empty_zero_page
+empty_zero_page:
.space 4096
-_GLOBAL(swapper_pg_dir)
+ .globl swapper_pg_dir
+swapper_pg_dir:
.space 4096
/* Reserved 4k for the critical exception stack & 4k for the machine
@@ -1040,13 +1044,15 @@ _GLOBAL(swapper_pg_dir)
.align 12
exception_stack_bottom:
.space BOOKE_EXCEPTION_STACK_SIZE * NR_CPUS
-_GLOBAL(exception_stack_top)
+ .globl exception_stack_top
+exception_stack_top:
/*
* This space gets a copy of optional info passed to us by the bootstrap
* which is used to pass parameters into the kernel like root=/dev/sda1, etc.
*/
-_GLOBAL(cmd_line)
+ .globl cmd_line
+cmd_line:
.space 512
/*
@@ -1055,4 +1061,3 @@ _GLOBAL(cmd_line)
*/
abatron_pteptrs:
.space 8
-
^ permalink raw reply
* [PATCH] powerpc: Some more fixes to allow building for a Book-E processor
From: Kumar Gala @ 2005-10-18 22:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Some minor fixes that are needed if we are building for a book-e
processor.
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
---
commit a2084dccc9e9b0ccc5c40ed2f1273c82b23369d2
tree f1799fd89588a066ca5210d5dd65ff795ba0af0d
parent 77f543cb467c44960bafa6c91f5af75919d693e4
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 18 Oct 2005 17:38:53 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 18 Oct 2005 17:38:53 -0500
arch/powerpc/kernel/Makefile | 3 ++-
arch/powerpc/mm/Makefile | 5 ++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -25,13 +25,14 @@ extra-$(CONFIG_40x) := head_4xx.o
extra-$(CONFIG_44x) := head_44x.o
extra-$(CONFIG_FSL_BOOKE) := head_fsl_booke.o
extra-$(CONFIG_8xx) := head_8xx.o
+extra-$(CONFIG_6xx) += idle_6xx.o
extra-$(CONFIG_PPC64) += entry_64.o
extra-$(CONFIG_PPC_FPU) += fpu.o
extra-y += vmlinux.lds
obj-y += process.o init_task.o \
prom.o systbl.o traps.o
-obj-$(CONFIG_PPC32) += entry_32.o idle_6xx.o setup_32.o misc_32.o
+obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
obj-$(CONFIG_PPC64) += setup_64.o misc_64.o
obj-$(CONFIG_PPC_OF) += prom_init.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -7,14 +7,13 @@ EXTRA_CFLAGS += -mno-minimal-toc
endif
obj-y := fault.o mem.o lmb.o
-obj-$(CONFIG_PPC32) += init_32.o pgtable_32.o mmu_context_32.o \
- tlb_32.o
+obj-$(CONFIG_PPC32) += init_32.o pgtable_32.o mmu_context_32.o
hash-$(CONFIG_PPC_MULTIPLATFORM) := hash_native_64.o
obj-$(CONFIG_PPC64) += init_64.o pgtable_64.o mmu_context_64.o \
hash_utils_64.o hash_low_64.o tlb_64.o \
slb_low.o slb.o stab.o mmap.o imalloc.o \
$(hash-y)
-obj-$(CONFIG_PPC_STD_MMU_32) += ppc_mmu_32.o hash_low_32.o
+obj-$(CONFIG_PPC_STD_MMU_32) += ppc_mmu_32.o hash_low_32.o tlb_32.o
obj-$(CONFIG_40x) += 4xx_mmu.o
obj-$(CONFIG_44x) += 44x_mmu.o
obj-$(CONFIG_FSL_BOOKE) += fsl_booke_mmu.o
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: Kalle Pokki @ 2005-10-18 20:14 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <435549C2.1000106@dlasys.net>
David H. Lynch Jr. wrote:
> Kalle Pokki wrote:
>
>> 1. Put RAM to 0x0000000 and flash to some location it mirrors to your
>> boot vector. Linux always expects your physical memory to be at zero.
>> It is then mapped to virtual address 0xC0000000.
>
> In both this list and elsewhere I have seen several references to
> the difficulty setting up Linux with a physical RAM base other than
> 0x0. I was hoping that I could bypass that by re-arranging physical
> memory using the BAT's or MMU.
> I am gathering that while this is possible, that it not sufficient.
> That if memory is re-arranged after power-on it has to be done by
> something Linux is not aware of.
I'm afraid you cannot fool Linux that way... it will take control of the
BATs and MMU. Even as a concept, you cannot re-arrange physical memory
with the MMU at all - it's virtual memory when you do the address
translation. The only way to arrange physical memory is to program the
memory controller. I don't know how flexible the OCM controller in
ppc405 is, but I'd be surprised if one couldn't freely set the addresses
to whatever suits best.
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
From: Dan Malek @ 2005-10-18 19:46 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <20051018142411.GA14065@logos.cnet>
On Oct 18, 2005, at 10:24 AM, Marcelo Tosatti wrote:
> For 8xx, I was wondering if the PARTNUM field of the IMMR
> (section 10.4.1 of MPC860UM.pdf) does have meaningful
> information which could be used to identify the CPU.
It has meaningful information, but not the way you want
to use it :-) The PARTNUM/MASKNUM is only useful
once you know the type of processor (like 823, 850, 885, etc)
The PARTNUM is only useful within the "family." For
example, the 860 and 880 are two different families, and
will contain the similar PARTNUM values through their life.
I believe it's tied to the fabrication process.
You may as well stop looking for an easy (or possibly
any) way to differentiate these parts in software, but
due to they way they are fabricated, I don't think that's
ever going to happen. :-)
-- Dan
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: David H. Lynch Jr. @ 2005-10-18 19:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4354B707.6060002@iki.fi>
Kalle Pokki wrote:
> David H. Lynch Jr wrote:
>
>> What exactly is the minimal startup system state the Linux 2.6.13
>> Kernel expects ?
>
>
> It's pretty hard to describe the system state fully, as there are so
> many registers it may depend on. However, I can point out a few things
> from your setup:
>
> 1. Put RAM to 0x0000000 and flash to some location it mirrors to your
> boot vector. Linux always expects your physical memory to be at zero.
> It is then mapped to virtual address 0xC0000000.
In both this list and elsewhere I have seen several references to
the difficulty setting up Linux with a physical RAM base other than 0x0.
I was hoping that I could bypass that by re-arranging physical memory
using the BAT's or MMU.
I am gathering that while this is possible, that it not sufficient. That
if memory is re-arranged after power-on it has to be done by something
Linux is not aware of.
>
> 2. You don't need to have MMU enabled.
There is a god. I am a compitent developer with lots of low level
experience, but I have thus far completely missed out on both PPC
assembler and memory management.
>
> 3. Make sure your boot arguments are passed properly to the kernel.
> This includes the settings in registers r3 ... r7 and the bd_info
> structure . There are many variants of that structure, make sure you
> use the same ones in the boot loader and in Linux.
That I should have no problem with.
>
>
Thank You very much
^ permalink raw reply
* openpic/mac-io
From: i2a @ 2005-10-18 19:22 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am searching for documentation about the OpenPIC interrupt-controller in mac
systems. I found this site but most of the links are dead or give no hope on
real technical documentation :).
http://www.macbsd.com/openmac/refs.html
Could someone give any pointers or files?
I am also searching for any related documentation on the mac-io device (this
could be a combo document).
I am trying to do a port as a masters project, and my biggest problem is:
documentation :(.
Thanks
Ingmar.
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
From: Marcelo Tosatti @ 2005-10-18 14:24 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <434BC424.50700@ru.mvista.com>
Hi Vitaly,
> This patch fixes a numbers of issues regarding to that both 8xx and 82xx
> began to use ppc_sys model:
> - Platform is now identified by default deviceless SOC, if no
> BOARD_CHIP_NAME is specified in the bard-specific header. For the list
> of supported names refer to (arch/ppc/syslib/) mpc8xx_sys.c and
> mpc82xx_sys.c for 8xx and 82xx respectively.
> - Fixed a bug in identification by name - if the name was not found,
> it returned -1 instead of default deviceless ppc_spec.
> - fixed devices amount in the 8xx platform system descriptions
Patch looks good.
For 8xx, I was wondering if the PARTNUM field of the IMMR
(section 10.4.1 of MPC860UM.pdf) does have meaningful
information which could be used to identify the CPU.
^ permalink raw reply
* Re: Announce: MPC8272ADS platform support added to mpc8260sar project.
From: Mark A. Greer @ 2005-10-18 18:22 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linux-atm-general, linuxppc-embedded
In-Reply-To: <20051018094730.36aa7b99.ajz@cambridgebroadband.com>
On Tue, Oct 18, 2005 at 09:47:30AM +0100, Alex Zeffertt wrote:
> On Mon, 17 Oct 2005 11:44:41 -0700
> "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> > On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote:
> > > Hi lists,
> > >
> > > I'm writing to let anybody (who may be interested) know that I've
> > > added support for the MPC8272ADS platform to the mpc8260sar ATM
> > > device driver:
> > >
> > > http://mpc8260sar.sourceforge.net
> >
> > There is already an ads8272_defconfig in the kernel.org tree and
> > AFAIK it works. Did you add some functionality or change something?
> > Or am I missing something?
> >
>
> I've added support for this platform to the ATM driver.
> ^^^^^^^^^^^^^^^^^
Oh, duh. Sorry 'bout that.
Mark
^ permalink raw reply
* Re: flash for lite5200
From: White @ 2005-10-18 15:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051017164253.GA21936@mail.gnudd.com>
The Lite5200 has an official Port to 2.6 by Sylvain Munaut
<tnt@246tNt.com>
There is an Mapping MTD driver ready.
if it's not in vanilla, you found a patchset on Mailign archive or
on Sylvain's HP.
Am Mon, 17 Oct 2005 18:42:53 +0200 schrieb Alessandro Rubini
<rubini@gnudd.com> :
>
> Hello.
>
> I'm using linux-2.6.14-rc3-g4c234921 from denx, and I need to access
> the flash device. While in 2.4 there is drivers/mtd/maps/icecube.c
> (by Wolfgang Denk himself, it seems), I managed to see the flash
> using the physmap driver and cmdline partitions.
>
> Does it make sense to add the correct MTD settings to
> arch/ppc/configs/lite5200_defconfig (and some hints in
> Documentation/powerpc/mpc52xx.txt) without porting the whole of
> maps/icecube.c or is there a specific advantage in add a file in maps?
> -- well, besides having sensible partitions already ported from 2.4?
>
> In either case, I'm willing to contribute the patch.
>
> These are the winning settings for me, but it doesn't cope with
> lite5200 speciments with 8MBi of flash (are there any still around?)
> [there's more than strictly needed, actually]
>
> CONFIG_MTD=y
> CONFIG_MTD_PARTITIONS=y
> CONFIG_MTD_CMDLINE_PARTS=y
> CONFIG_MTD_CHAR=y
> CONFIG_MTD_CFI=y
> CONFIG_MTD_GEN_PROBE=y
> CONFIG_MTD_MAP_BANK_WIDTH_1=y
> CONFIG_MTD_MAP_BANK_WIDTH_2=y
> CONFIG_MTD_MAP_BANK_WIDTH_4=y
> CONFIG_MTD_CFI_I1=y
> CONFIG_MTD_CFI_I2=y
> CONFIG_MTD_CFI_INTELEXT=y
> CONFIG_MTD_CFI_AMDSTD=y
> CONFIG_MTD_CFI_AMDSTD_RETRY=0
> CONFIG_MTD_CFI_UTIL=y
>
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_START=0xff000000
> CONFIG_MTD_PHYSMAP_LEN=0x1000000
> CONFIG_MTD_PHYSMAP_BANKWIDTH=1
>
>
> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: 2.6.13 ati (ibook) frambuffer problem
From: Joerg Dorchain @ 2005-10-18 8:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1129585466.7620.90.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Tue, Oct 18, 2005 at 07:44:26AM +1000, Benjamin Herrenschmidt wrote:
> > The 2.6.12 version worked. Would it make sense to post the complete
> > .config?
I got 2.6.13.4 booting. The last change I did was deselecting
CONFIG_FB_TILEBLITTING. Unfortunately, I have no idea how this actually
affects the ATI frambebuffer.
To make it even more strange, after reenabling CONFIG_FB_TILEBLITTING,
it still boots up cleanly. Obviously, I missed out on something.
Besides, I have the impression that the disk reacts slower. As hdparm
does not tell a difference, it might be due the coffein, tough.
>
> Nope. What may help is a bit more debugging. For example, does the
> kernel actually boots if you add "video=ofonly" to the kernel command
> line.
No effect.
Well, the good point is, it works again. The bad point, I do not know
why. Anyway, thanks for the support.
Bye,
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: Kalle Pokki @ 2005-10-18 8:49 UTC (permalink / raw)
To: David H. Lynch Jr; +Cc: linuxppc-embedded
In-Reply-To: <4354AC78.5080206@comcast.net>
David H. Lynch Jr wrote:
> What exactly is the minimal startup system state the Linux 2.6.13
> Kernel expects ?
It's pretty hard to describe the system state fully, as there are so
many registers it may depend on. However, I can point out a few things
from your setup:
1. Put RAM to 0x0000000 and flash to some location it mirrors to your
boot vector. Linux always expects your physical memory to be at zero. It
is then mapped to virtual address 0xC0000000.
2. You don't need to have MMU enabled.
3. Make sure your boot arguments are passed properly to the kernel. This
includes the settings in registers r3 ... r7 and the bd_info structure .
There are many variants of that structure, make sure you use the same
ones in the boot loader and in Linux.
^ permalink raw reply
* Re: Announce: MPC8272ADS platform support added to mpc8260sar project.
From: Alex Zeffertt @ 2005-10-18 8:47 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linux-atm-general, linuxppc-embedded
In-Reply-To: <20051017184441.GC1245@mag.az.mvista.com>
On Mon, 17 Oct 2005 11:44:41 -0700
"Mark A. Greer" <mgreer@mvista.com> wrote:
> On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote:
> > Hi lists,
> >
> > I'm writing to let anybody (who may be interested) know that I've
> > added support for the MPC8272ADS platform to the mpc8260sar ATM
> > device driver:
> >
> > http://mpc8260sar.sourceforge.net
>
> There is already an ads8272_defconfig in the kernel.org tree and
> AFAIK it works. Did you add some functionality or change something?
> Or am I missing something?
>
I've added support for this platform to the ATM driver.
^^^^^^^^^^^^^^^^^
Alex
^ permalink raw reply
* Need help Understanding initial memory conditions.
From: David H. Lynch Jr @ 2005-10-18 8:04 UTC (permalink / raw)
To: linuxppc-embedded
What exactly is the minimal startup system state the Linux 2.6.13
Kernel expects ?
I am trying to bring up a xilinx V4 ppc 405 board.
It has flash based at 0x0 and DRAM based at ox98000000.
I already have a working monitor/program loader and a filesystem of
the flash. I can fairly easily compile and load onto the filesystem and
run standalone PPC apps on the board.
All memory is as configured by the base hardware. The MMU, BAT, ...
are all at their powerup state.
I have put together a Linux config based heavily on an abbreviated
version of the Xilinx ML-300 config.
If I try to load it it just goes bye-bye.
I am trying to decipher the initial machine state Linux 2.6.13 expects.
u-boot seems to completely setup the MMU, but also seems to expect
to start execution from flash or ROM.
scanning the Linux code seems to indicate that the only entry that
needs to be setup for the MMU is the one for block Linux starts
executing out of.
I am also being somewhat confused by references to physical address
0 and virtual address 0xc000000.
I thought Linux executed from virtual address 0, and the actual
physical address was a function of the hardware.
^ permalink raw reply
* RE: fs_enet driver - me too
From: Schaefer-Hutter, Peter @ 2005-10-18 7:51 UTC (permalink / raw)
To: linuxppc-embedded
Rune Torgersen wrote:
> Does anybody have a working patchset for fs_enet for 2.6.12?
>=20
> The patches I've found on this list (and on ozlab's patch list) I
> cannot get to compile.
Any news?
Regards,
=20
Peter
^ permalink raw reply
* Re: Newbie... in mailing lists...
From: David Woodhouse @ 2005-10-18 7:53 UTC (permalink / raw)
To: Nathael PAJANI; +Cc: linuxppc-embedded
In-Reply-To: <43539813.8010809@cpe.fr>
On Mon, 2005-10-17 at 14:24 +0200, Nathael PAJANI wrote:
> I tried to reply to this thread:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-October/020555.html
> But it created a new one..... not good.
That's a problem with the archives; it's not your fault. If you look at
the mailto: link at the top of that page, you see it looks like this:
mailto:linuxppc-embedded%40ozlabs.org?Subject=eldk%203.1.1%20ramdisk%20image%20problem&In-Reply-To=
Although it _attempts_ to set the In-Reply-To: header which would make
your message appear to be a reply to the mail in the archive, it seems
to be missing the actual message-id of that mail; it's just empty.
> I tried to look for advices on posting and replying on the mailling list...
> but the links given there:
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> for the rules (http://lists.linuxppc.org/rules.html) and posting
> guidlines (http://lists.linuxppc.org/guidelines.html) are down.
The rules are fairly much the same everywhere -- not only for mailing
lists but for email in general. Try http://david.woodhou.se/email.html
if you think you need to read about it, perhaps.
--
dwmw2
^ permalink raw reply
* Re: merge progress
From: Geert Uytterhoeven @ 2005-10-18 7:50 UTC (permalink / raw)
To: Simon Richter
Cc: Linux/PPC Development, Linux/PPC on APUS development,
linuxppc64-dev
In-Reply-To: <4354235B.8090608@hogyros.de>
On Tue, 18 Oct 2005, Simon Richter wrote:
> Paul Mackerras schrieb:
> > Hmmm, probably should work off the merge tree.
>
> Good, then I'll fast-forward them there.
>
> > However, we decided at
> > OLS that platforms would require a device tree before being merged.
> > Have you looked at creating a suitable flattened device tree blob with
> > dtc? (If not, you can continue to compile with ARCH=ppc for now.)
>
> In fact my current plan is to move away from m68k bootinfo (which APUS
> borrows so you can use the same bootloader) towards a flattened dev tree
Is requiring a flattened device tree really the right approach to take, for
APUS? APUS borrows from/shares with m68k a lot of code.
BTW, why do you want to move away from m68k bootinfo (apart from using a
flattened device tree)?
> passed in from the bootloader. For that, however, we need a new
> bootloader first, which is dependant on AmigaOS binutils/gcc.
>
> So I guess it will be ARCH=ppc until the new bootloader is ready.
Happy hacking!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: merge progress
From: Kumar Gala @ 2005-10-17 22:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <17235.33942.754076.419504@cargo.ozlabs.ibm.com>
> Hmmm, probably should work off the merge tree. However, we decided at
> OLS that platforms would require a device tree before being merged.
> Have you looked at creating a suitable flattened device tree blob with
> dtc? (If not, you can continue to compile with ARCH=ppc for now.)
That would assume the ARCH=ppc builds in the merge tree. Paul, stop
breaking ARCH=ppc just because your annoyed at me for killing 970 and
POWER4 in the cputable :)
syscalls has issues in ARCH=ppc.
- kumar
^ permalink raw reply
* Re: merge progress
From: Simon Richter @ 2005-10-17 22:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17235.33942.754076.419504@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
Hi,
Paul Mackerras schrieb:
> Hmmm, probably should work off the merge tree.
Good, then I'll fast-forward them there.
> However, we decided at
> OLS that platforms would require a device tree before being merged.
> Have you looked at creating a suitable flattened device tree blob with
> dtc? (If not, you can continue to compile with ARCH=ppc for now.)
In fact my current plan is to move away from m68k bootinfo (which APUS
borrows so you can use the same bootloader) towards a flattened dev tree
passed in from the bootloader. For that, however, we need a new
bootloader first, which is dependant on AmigaOS binutils/gcc.
So I guess it will be ARCH=ppc until the new bootloader is ready.
Should APUS still get a special treatment then, or should I try to
emulate enough of OF in the bootloader so it is possible to build CHRP
images that work on APUS?
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 374 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox