* [PATCH] powerpc: rheap allocator should honour alignment parameter
From: Marcelo Tosatti @ 2006-01-31 22:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Pantelis Antoniou, linux-ppc-embedded
From: Pantelis Antoniou <pantelis@embeddedalley.com>
Honour alignment parameter in the rheap allocator.
Signed-off-by: Pantelis Antoniou <pantelis@embeddedalley.com>
diff --git a/arch/ppc/lib/rheap.c b/arch/ppc/lib/rheap.c
--- a/arch/ppc/lib/rheap.c
+++ b/arch/ppc/lib/rheap.c
@@ -425,17 +425,21 @@ void *rh_detach_region(rh_info_t * info,
return (void *)s;
}
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc_align(rh_info_t * info, int size, int alignment, const char *owner)
{
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
void *start;
- /* Validate size */
- if (size <= 0)
+ /* Validate size, (must be power of two) */
+ if (size <= 0 || (alignment & (alignment - 1)) != 0)
return ERR_PTR(-EINVAL);
+ /* given alignment larger that default rheap alignment */
+ if (alignment > info->alignment)
+ size += alignment - 1;
+
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -478,9 +482,21 @@ void *rh_alloc(rh_info_t * info, int siz
attach_taken_block(info, newblk);
+ /* for larger alignment return fixed up pointer */
+ /* this is no problem with the deallocator since */
+ /* we scan for pointers that lie in the blocks */
+ if (alignment > info->alignment)
+ start = (void *)(((unsigned long)start + alignment - 1) &
+ ~(alignment - 1));
+
return start;
}
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+ return rh_alloc_align(info, size, info->alignment, owner);
+}
+
/* allocate at precisely the given address */
void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
{
diff --git a/arch/ppc/syslib/cpm2_common.c b/arch/ppc/syslib/cpm2_common.c
--- a/arch/ppc/syslib/cpm2_common.c
+++ b/arch/ppc/syslib/cpm2_common.c
@@ -148,8 +148,7 @@ uint cpm_dpalloc(uint size, uint align)
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc(&cpm_dpmem_info, size, "commproc");
+ start = rh_alloc_align(&cpm_dpmem_info, size, align, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
return (uint)start;
@@ -170,13 +169,12 @@ int cpm_dpfree(uint offset)
EXPORT_SYMBOL(cpm_dpfree);
/* not sure if this is ever needed */
-uint cpm_dpalloc_fixed(uint offset, uint size, uint align)
+uint cpm_dpalloc_fixed(uint offset, uint size)
{
void *start;
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
start = rh_alloc_fixed(&cpm_dpmem_info, (void *)offset, size, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -74,7 +74,7 @@ static inline long IS_DPERR(const uint o
extern cpm8xx_t *cpmp; /* Pointer to comm processor */
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -112,7 +112,7 @@ extern cpm_cpm2_t *cpmp; /* Pointer to
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/rheap.h b/include/asm-ppc/rheap.h
--- a/include/asm-ppc/rheap.h
+++ b/include/asm-ppc/rheap.h
@@ -62,6 +62,10 @@ extern int rh_attach_region(rh_info_t *
/* Detach a free region */
extern void *rh_detach_region(rh_info_t * info, void *start, int size);
+/* Allocate the given size from the remote heap (with alignment) */
+extern void *rh_alloc_align(rh_info_t * info, int size, int alignment,
+ const char *owner);
+
/* Allocate the given size from the remote heap */
extern void *rh_alloc(rh_info_t * info, int size, const char *owner);
^ permalink raw reply
* [PATCH] powerpc: Fix Kernel FP unavail exception for BookE
From: Becky Bruce @ 2006-01-31 23:52 UTC (permalink / raw)
To: linuxppc-dev, galak
powerpc: Correct BookE FP unavailable exception
Updated FP unavailable exception to refer to the correct
function in traps.c. head_booke.h was using the old name, KernelFP,
instead of kernel_fp_unavailable_exception.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
commit 6e481b074a1cbe44dd5ccc29fe74857986a41e14
tree 5e3d59136176a927dae2f42ce83b393b17fc86e6
parent 2a68349345a9bf292d06a8baaa8182b946c7056c
author Becky Bruce <becky.bruce@freescale.com> Tue, 31 Jan 2006 17:41:00 -0600
committer Becky Bruce <becky.bruce@freescale.com> Tue, 31 Jan 2006 17:41:00 -0600
arch/powerpc/kernel/head_booke.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 5827c27..8536e76 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -358,6 +358,6 @@ label:
NORMAL_EXCEPTION_PROLOG; \
bne load_up_fpu; /* if from user, just load it up */ \
addi r3,r1,STACK_FRAME_OVERHEAD; \
- EXC_XFER_EE_LITE(0x800, KernelFP)
+ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
#endif /* __HEAD_BOOKE_H__ */
^ permalink raw reply related
* Re: Getting started with Xilinx V4 PPC?
From: David Summers @ 2006-01-31 21:17 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <43DF4D6F.6090402@dlasys.net>
Thanks for all of the great advice.
I think my plan is to stick with the 2.4 kernel for now until I run
into a compelling reason to switch to 2.6. It sounds like the 2.6
support is getting very close to maturity and if I get some free time
I would love to pitch in and help.
Is anyone out there using JFFS2 on a NAND flash device in 2.4? If
this works in 2.4 then I should be OK. My dev board only has 4MB of
NOR flash so this is one part of the processor subsystem that I cannot
test.
-David Summers
On 1/31/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
> David;
>
> I just completed a port of 2.6 to the Pico E-12 which is a Xilinx
> Virtex-4 with very little hardware.
>
> I had the advantage of a system that already had a elf loader (not
> U-Boot), but not a Linux loader.
> If I could load Linux as an elf file then I did not need another loader.
> In the end I had to make some very trivial modifications to Pico's
> loader to pass a board information structure. But otherwise the decision
> to use the existing loader saved me having to port u-boot.
>
> I also chose to boot into a ramdisk. Using the existing loader precluded
> having the ramdisk as a separate file.
> the intramfs feature of 2.6 allowed me to wrap the ramdisk into the same
> file as the kernel. Documentation on initramfs is spartan, and somewhat
> opaque. The good news was that despite the documentation initramfs
> proved trivially easy to use.
>
> After that I took the 2.6 kernel source, and litterally went through
> looking for all references to the xilinx ml300.
> Wherever there was an ml300 specific file I created an new one for the
> pico_e12. Wherever there was an ml300 configuration option I created a
> PICO_E12 one.
>
> The E-12 had substatnitially less hardware than the ml300 (or the ml403)
> so mostly I just ended up ripping code out of my private version of the
> ml300 code that was transmuting into the pico_e12 code.
>
> The next obstacle I bumped into was that the e-12 had two devices
> suitable for a console - a highspeed fifo interface to a host
> development system called the keyhole port, and the xilinx uartlite
> serial port. Neither are supported in 2.6. I looked at the Xilinx
> Uartlite 2.4 driver and it was coded substantially different from other
> serial drivers. I decided not to try to port it to 2.6. I started from
> scratch using the 8250 code as a base. I picked the 8250 because:
> It must be the most heavily used linux serial driver and therefore I
> hoped the most uptodate and well debugged.
> The 8250 had boot through console IO support. Most other serial devices
> require getting fairly far into the boot process before you get any outpu=
t.
>
> The really early IO proved fairly simple. Implimenting xxxx_dbg.c and
> xxxx_tty.c for both the uartlite and the keyhole was fairly trivial.
>
> Additionally the keyhole port had a "debug" feature where if you output
> a single 32 bit word to one of the fifo ports it would be displayed in
> hex on the host. As this could be done in an assembler macro that proved
> indispensiable early on.
>
> I was stalled for about 3 weeks trying to get the sucker into virtual
> mode. In the end I had to disable Machine Check exceptions to make the
> transition to virtual mode. Pico claims there is not a hardware problem,
> but if I do nto disable machine checks on the e-12 it will never make
> the tansition to virtual mode.
>
> The full serial driver for the Uartlite (and Keyhole) proved more
> daunting than anything else. In some ways the 8250 proved a bad choice
> as a template there as there are more permutations, busses, etc
> associated with the 8250 than anything else. I ended up stripping out
> huge hunks of code. Eventually, I used the m32r_sio as a simpler
> template. The driver was much simpler, and it had the critical features
> I needed - both interupt driven and polled IO support - some
> implimentations of the E12 do not include a PIC. The serial drivers took
> much longer than the whole rest of the port combined - including the
> machine check detour.
>
> Just as I was finishing up the E12 port, Grant posted a set of patches
> for the ml403. There were some fundimental differences at a fairly low
> level between Grant's approach and mine. And I think Grant's Virtex-4
> code appears to reflect more of the direction things are going, so I am
> in the process of remodeling my port for the E12 on his for the ml403.
> But I have not completed that.
>
> Absent the machine check issue and having to write serial drivers thus
> was atmost 2 weeks work.
>
>
> BTW while you appear to be a hardware guy with alot of software
> experience, I am a software guy with alot of hardware experience.
>
>
> The E-12 has flash, but it uses a proprietary flash file system, and
> using it would have required writing a filesystem driver - which I would
> be happy to do if I got paid for it. Write performance on flash can be
> extremely slow. If you are recording a significant amount of data in
> realtime, you may want to skip the flash and just use a ramdisk. However
> the ramdisk will not survive the system loosing power - which might be
> an issue in a rocket.
>
> If you are going to start with the 2.6 Kernel, I would get git. use it
> to DL Linus's current 2.6 git repository, adn apply all of Grant's ml403
> patches from the mailing list to it.
> Then I would start an approach somewhat similar to what I described
> above - except using Grant's ml403 as the base to create your own board
> spec from instead of the ml300 that I used.
> How tightly constrained are you for gates in the FPGA ?
> If you are not tight, use the Xilinx 16550 serial IP and then you can
> use standard Kernel 8250 dirvers (making Grant's patches work with
> Uartlite is one of the things I am having trouble with) It would be my
> guess that if you use the 16550 serial IP, you may be able to use
> Grant's ml403 stuff asis.
>
>
>
>
>
> David Summers wrote:
>
> >I am starting a new project where I need to have a flash file system
> >and an ethenet interface (HTTP and FTP). The project is a solar
> >physics experiment that will be launched on a sub-orbital rocket
> >flight this fall. The idea is that the experiment will write data
> >files to the flash file system while in flight, and then I can
> >download the data using ethernet after the experiment returns to
> >earth.
> >
> >I think that Linux is the way to go for this project because of the
> >JFFS2 filesystem and the strong networking support. The only problem
> >is that I am totally new to embedded linux.
> >
> >I am prototyping my system on an Avnet FX12 development board ( Specs
> >here: http://tinyurl.com/4gfdv ) which is pretty similar to the Xilinx
> >ML403 board except with less memory and no SystemACE slot.
> >
> >I will eventually build my own custom board with the same Xilinx
> >Virtex 4 FX12 FPGA and additional flash memory and some custom
> >interface hardware. My background is primarily as a hardware designer,
> >and I am very confortable with the FPGA part of this project. I am
> >comfortable as a Linux user, and I am a pretty good C coder (for a
> >hardware guy anyway :). I have never built a linux system (embedded
> >or desktop) before, and I need some help getting started with embedded
> >linux.
> >
> >I have already found the following websites which have been a big help s=
o far:
> >
> >http://www.klingauf.de/v2p/index.phtml
> >http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm
> >http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html#=
toc1
> >
> >I have a few questions that I hope someone can help me with:
> >
> >1. What is the best linux distribution to start out with? I am
> >currently working with the 2.4 kernel code from
> >ppc.bkbits.net/linuxppc_2_4_devel, but I'm not sure that this version
> >be being updated. (MontaVista also seems to be making it rather
> >difficult to download their free Linux Preview Kit, so I wouldn't mind
> >finding another distribution) Does the DENX distribution have good
> >PPC support? Are there any others that I should look at, or should I
> >just download the kernel source directly from kernel.org?
> >
> >
> >2. kernel 2.4 or 2.6?
> >
> >It is my understanding that the latest version of MTD and JFFS2 have
> >dropped support for kernel 2.4. I would like to use JFFS2 on a NAND
> >flash device, so it seems like I should use 2.6. (Can I use JFFS2 on
> >a NAND device with kernel v 2.4?)
> >
> >Being a complete newbie, am I biting off more that I can handle by
> >trying to use 2.6?
> >
> >I have been lurking on the mailing list for a while, and I know that
> >there are several people working on 2.6.x patches for the Xilinx
> >virtex 4 parts. Could someone point me to a list of the patches that
> >I need to get me started? I think that the ML403 patches should work
> >with my board, but I don't know which ones I need to download.
> >
> >
> >Thank you for your help,
> >
> >David Summers
> >University of Colorado
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
>
> --
> Dave Lynch DLA Systems
> Software Development: Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net:8888
>
>
^ permalink raw reply
* Re: Entry Point Address
From: Wolfgang Denk @ 2006-01-31 21:13 UTC (permalink / raw)
To: Mustafa Çayır; +Cc: linuxppc-embedded
In-Reply-To: <000e01c62669$f7c3be60$9e01120a@bilisim.local>
In message <000e01c62669$f7c3be60$9e01120a@bilisim.local> you wrote:
>
> does entry point adress defined uboot image header correspond to adress of which function in linux kernel ?
It corresponds to the kernel's entry point, "_start".
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Cigarette, n.: A fire at one end, a fool at the other, and a bit of
tobacco in between.
^ permalink raw reply
* Re: SPI flash kernel 2.4 driver
From: Wolfgang Denk @ 2006-01-31 21:11 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <ITYDSI$4F4F62D0FA98B587B7D4335807D29D19@libero.it>
In message <ITYDSI$4F4F62D0FA98B587B7D4335807D29D19@libero.it> you wrote:
>
> do you know if is there a "spi flash" driver included in 2.4 kernel?
> I have an AT45DB081D (8 MBit Atmel chip) on a MPC875 spi bus.
The Katix SPI framework is integrated with our 2.4 kernel; see
drivers/spi
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What was sliced bread the greatest thing since?
^ permalink raw reply
* Re: Getting started with Xilinx V4 PPC?
From: David Summers @ 2006-01-31 21:07 UTC (permalink / raw)
To: Frank Bennett; +Cc: linuxppc-embedded
In-Reply-To: <43DE76DE.2080306@digis.net>
> Interesting dev board. What is the low volume price/power consumption
> is for the Virtex-4?
The price for a Virtex 4 FX12 FPGA (10K flip flops, 648Kb Block RAM,
1 PPC405 core, dual 10/100/1G ethernet MACs, etc) close to $200 each.
Expensive if all you need is a processor, but I already have a lot of
custom interface logic in the FPGA so adding a few $$ extra for the
PPC core isn't a problem. I also have the luxury of extremely small
production volumes, so component cost is dwarfed by the cost of
development.
Power is going to depend on what you put into the FPGA and how fast
you clock it. Xilinx quotes 0.45mW/Mhz for the PPC only. That equals
135mW at 300 Mhz. My design will probably top out at 2W for the FPGA.
>
> If you are a C coder then I assume you would use Verilog I hope....VHDL i=
s
> for ADA programmers!
I use both, but this project will be in VHDL. VHDL has some nice
features and seems to actually be gaining strength over Verilog.
-David
^ permalink raw reply
* Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
From: Jon Loeliger @ 2006-01-31 20:40 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <87slr4b0lf.fsf@48ers.dk>
On Tue, 2006-01-31 at 14:31, Peter Korsgaard wrote:
> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
>
> Tom> I would suggest either Linus' current git tree or 2.6.16-rc1 if
> Tom> you don't use git. But please bear in mind that since this is a
> Tom> new feature (a new board) it won't be submitted to Linus' tree
> Tom> until 2.6.17-rc1 opens up (and if in that time, it becomes much
> Tom> easier to put this board under arch/powerpc it should be done
> Tom> under there, instead).
>
> I only recently moved from 2.4 to 2.6, so this may be a FAQ, but a
> quick googling around didn't find anything.
>
> What is this arch/ppc -> arch/powerpc about? Some kind of
> consolidation of ppc and ppc64?
Exactly.
> What's the reason behind it
Eliminate duplicate code. Share good code.
Improved modularity. Leverage. All the Good Stuff (tm).
Eliminate the bd_t mess. You know.
> and what kind of time frame are we talking about?
In progress now. All of the PPC64 ports are now officially
part of the "powerpc" arch. There are two published PPC32
ports (MPC8349SYS and MPC8540ADS) that have been posted to
the list as being "merged" into the powerpc arch. They are
still evolving a bit, though.
> Is it related to the bd_t ->
> flattened OF tree change?
Yes. New World Order says all arch/powerpc ports will
use a common flat dev tree interface from boot loaders
unless honest OF is available. The bd_t is obsolete.
> Could someone post a few pointers to more information?
Read the "booting without open firmware" spec recently
patched from the DTC code tree to the linux doc directory
on the PPC64 list by Dave Gibson.
Read the Device Tree Compiler code itself too.
jdl
^ permalink raw reply
* Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
From: Peter Korsgaard @ 2006-01-31 20:31 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded, Dan Malek
In-Reply-To: <20060131142433.GN22672@smtp.west.cox.net>
>>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
Tom> I would suggest either Linus' current git tree or 2.6.16-rc1 if
Tom> you don't use git. But please bear in mind that since this is a
Tom> new feature (a new board) it won't be submitted to Linus' tree
Tom> until 2.6.17-rc1 opens up (and if in that time, it becomes much
Tom> easier to put this board under arch/powerpc it should be done
Tom> under there, instead).
I only recently moved from 2.4 to 2.6, so this may be a FAQ, but a
quick googling around didn't find anything.
What is this arch/ppc -> arch/powerpc about? Some kind of
consolidation of ppc and ppc64? What's the reason behind it and what
kind of time frame are we talking about? Is it related to the bd_t ->
flattened OF tree change?
Could someone post a few pointers to more information?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH] Merge Embedded Planet board information parsers into a single function
From: Laurent Pinchart @ 2006-01-31 16:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
Hi everybody,
arch/ppc/boot/simple/embed_config.c has duplicate board information parsing
code. This patch merges the parsers into a single function.
This is the first time I use git, so please point out the mistakes I probably
did. I didn't include EP8248 support in this patch, as Tom Rini pointed out
that it would have to wait for 2.6.17-rc1.
Laurent Pinchart
[-- Attachment #2: ep-parser.patch --]
[-- Type: text/x-diff, Size: 8222 bytes --]
Merge Embedded Planet board information parsers into a single function.
The Embedded Planet boot loader passes board information as a text string
which must be parsed. This patch merges the multiple parser implementations
into a single one.
Signed-off-by: Laurent Pinchart <laurent.pinchart@tbox.biz>
---
arch/ppc/boot/simple/embed_config.c | 236 +++++++++++------------------------
arch/ppc/platforms/rpx8260.h | 2
2 files changed, 73 insertions(+), 165 deletions(-)
1ea98a415a76c902314014e17a3b76fec3dbedf8
diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
index 491a691..9ab2851 100644
--- a/arch/ppc/boot/simple/embed_config.c
+++ b/arch/ppc/boot/simple/embed_config.c
@@ -147,7 +147,6 @@ rpx_eth(bd_t *bd, u_char *cp)
}
}
-#ifdef CONFIG_RPX8260
static uint
rpx_baseten(u_char *cp)
{
@@ -162,26 +161,9 @@ rpx_baseten(u_char *cp)
}
return(retval);
}
-#endif
#if defined(CONFIG_RPXLITE) || defined(CONFIG_RPXCLASSIC)
static void
-rpx_brate(bd_t *bd, u_char *cp)
-{
- uint rate;
-
- rate = 0;
-
- while (*cp != '\n') {
- rate *= 10;
- rate += (*cp) - '0';
- cp++;
- }
-
- bd->bi_baudrate = rate * 100;
-}
-
-static void
rpx_cpuspeed(bd_t *bd, u_char *cp)
{
uint num, den;
@@ -217,69 +199,11 @@ rpx_cpuspeed(bd_t *bd, u_char *cp)
}
#endif
-#if defined(CONFIG_RPXLITE) || defined(CONFIG_RPXCLASSIC) || defined(CONFIG_EP405)
-static void
-rpx_memsize(bd_t *bd, u_char *cp)
-{
- uint size;
-
- size = 0;
-
- while (*cp != '\n') {
- size *= 10;
- size += (*cp) - '0';
- cp++;
- }
-
- bd->bi_memsize = size * 1024 * 1024;
-}
-#endif /* LITE || CLASSIC || EP405 */
-#if defined(CONFIG_EP405)
static void
-rpx_nvramsize(bd_t *bd, u_char *cp)
-{
- uint size;
-
- size = 0;
-
- while (*cp != '\n') {
- size *= 10;
- size += (*cp) - '0';
- cp++;
- }
-
- bd->bi_nvramsize = size * 1024;
-}
-#endif /* CONFIG_EP405 */
-
-#endif /* Embedded Planet boards */
-
-#if defined(CONFIG_RPXLITE) || defined(CONFIG_RPXCLASSIC)
-
-/* Read the EEPROM on the RPX-Lite board.
-*/
-void
-embed_config(bd_t **bdp)
+ep_parse_keyvals(bd_t *bd, u_char *keyvals)
{
- u_char eebuf[256], *cp;
- bd_t *bd;
+ u_char *cp = keyvals;
- /* Read the first 256 bytes of the EEPROM. I think this
- * is really all there is, and I hope if it gets bigger the
- * info we want is still up front.
- */
- bd = &bdinfo;
- *bdp = bd;
-
-#if 1
- iic_read(0xa8, eebuf, 0, 128);
- iic_read(0xa8, &eebuf[128], 128, 128);
-
- /* We look for two things, the Ethernet address and the
- * serial baud rate. The records are separated by
- * newlines.
- */
- cp = eebuf;
for (;;) {
if (*cp == 'E') {
cp++;
@@ -288,20 +212,28 @@ embed_config(bd_t **bdp)
rpx_eth(bd, cp);
}
}
+#if defined(CONFIG_RPXLITE) || defined(CONFIG_RPXCLASSIC) || \
+ defined(CONFIG_RPX8260)
if (*cp == 'S') {
cp++;
if (*cp == 'B') {
cp += 2;
- rpx_brate(bd, cp);
+#if defined(CONFIG_RPX8260)
+ bd->bi_baudrate = rpx_baseten(cp);
+#else
+ bd->bi_baudrate = rpx_baseten(cp) * 100;
+#endif
}
}
+#endif
if (*cp == 'D') {
cp++;
if (*cp == '1') {
cp += 2;
- rpx_memsize(bd, cp);
+ bd->bi_memsize = rpx_baseten(cp) * 1024 * 1024;
}
}
+#if defined(CONFIG_RPXLITE) || defined(CONFIG_RPXCLASSIC)
if (*cp == 'H') {
cp++;
if (*cp == 'Z') {
@@ -309,6 +241,29 @@ embed_config(bd_t **bdp)
rpx_cpuspeed(bd, cp);
}
}
+#endif
+#if defined(CONFIG_EP405) || defined(CONFIG_RPX8260)
+ if (*cp == 'N') {
+ cp++;
+ if (*cp == 'V') {
+ cp += 2;
+#if defined(CONFIG_EP405)
+ bd->bi_nvramsize = rpx_baseten(cp) * 1024;
+#else
+ bd->bi_nvramsize = rpx_baseten(cp) * 1024 * 1024;
+#endif
+ }
+ }
+#endif
+#if defined(CONFIG_RPX8260)
+ if (*cp == 'X') {
+ cp++;
+ if (*cp == 'T') {
+ cp += 2;
+ bd->bi_busfreq = rpx_baseten(cp);
+ }
+ }
+#endif
/* Scan to the end of the record.
*/
@@ -317,10 +272,42 @@ embed_config(bd_t **bdp)
/* If the next character is a 0 or ff, we are done.
*/
+
cp++;
if ((*cp == 0) || (*cp == 0xff))
break;
}
+}
+
+#endif /* Embedded Planet boards */
+
+#if defined(CONFIG_RPXLITE) || defined(CONFIG_RPXCLASSIC)
+
+/* Read the EEPROM on the RPX-Lite board.
+*/
+void
+embed_config(bd_t **bdp)
+{
+ u_char eebuf[256];
+ bd_t *bd;
+
+ /* Read the first 256 bytes of the EEPROM. I think this
+ * is really all there is, and I hope if it gets bigger the
+ * info we want is still up front.
+ */
+ bd = &bdinfo;
+ *bdp = bd;
+
+#if 1
+ iic_read(0xa8, eebuf, 0, 128);
+ iic_read(0xa8, &eebuf[128], 128, 128);
+
+ /* We look for two things, the Ethernet address and the
+ * serial baud rate. The records are separated by
+ * newlines.
+ */
+ ep_parse_keyvals(bd, eebuf);
+
bd->bi_memstart = 0;
#else
/* For boards without initialized EEPROM.
@@ -588,12 +575,11 @@ embed_config(bd_t **bdp)
}
#endif /* SBS8260 */
-#ifdef CONFIG_RPX8260
+#if defined(CONFIG_RPX8260)
void
embed_config(bd_t **bdp)
{
- u_char *cp, *keyvals;
- int i;
+ u_char *keyvals;
bd_t *bd;
keyvals = (u_char *)*bdp;
@@ -606,55 +592,8 @@ embed_config(bd_t **bdp)
* function in a string, but the format of all of the fields
* is slightly different.
*/
- cp = keyvals;
- for (;;) {
- if (*cp == 'E') {
- cp++;
- if (*cp == 'A') {
- cp += 2;
- rpx_eth(bd, cp);
- }
- }
- if (*cp == 'S') {
- cp++;
- if (*cp == 'B') {
- cp += 2;
- bd->bi_baudrate = rpx_baseten(cp);
- }
- }
- if (*cp == 'D') {
- cp++;
- if (*cp == '1') {
- cp += 2;
- bd->bi_memsize = rpx_baseten(cp) * 1024 * 1024;
- }
- }
- if (*cp == 'X') {
- cp++;
- if (*cp == 'T') {
- cp += 2;
- bd->bi_busfreq = rpx_baseten(cp);
- }
- }
- if (*cp == 'N') {
- cp++;
- if (*cp == 'V') {
- cp += 2;
- bd->bi_nvsize = rpx_baseten(cp) * 1024 * 1024;
- }
- }
+ ep_parse_keyvals(bd, keyvals);
- /* Scan to the end of the record.
- */
- while ((*cp != '\n') && (*cp != 0xff))
- cp++;
-
- /* If the next character is a 0 or ff, we are done.
- */
- cp++;
- if ((*cp == 0) || (*cp == 0xff))
- break;
- }
bd->bi_memstart = 0;
/* The memory size includes both the 60x and local bus DRAM.
@@ -673,7 +612,7 @@ embed_config(bd_t **bdp)
*/
bd->bi_intfreq = 200000000;
}
-#endif /* RPX6 for testing */
+#endif /* CONFIG_RXP8260 */
#ifdef CONFIG_ADS8260
void
@@ -853,7 +792,6 @@ void
embed_config(bd_t **bdp)
{
u32 chcr0;
- u_char *cp;
bd_t *bd;
/* Different versions of the PlanetCore firmware vary in how
@@ -882,38 +820,8 @@ embed_config(bd_t **bdp)
bd = &bdinfo;
*bdp = bd;
#if 1
- cp = (u_char *)0xF0000EE0;
- for (;;) {
- if (*cp == 'E') {
- cp++;
- if (*cp == 'A') {
- cp += 2;
- rpx_eth(bd, cp);
- }
- }
-
- if (*cp == 'D') {
- cp++;
- if (*cp == '1') {
- cp += 2;
- rpx_memsize(bd, cp);
- }
- }
-
- if (*cp == 'N') {
- cp++;
- if (*cp == 'V') {
- cp += 2;
- rpx_nvramsize(bd, cp);
- }
- }
- while ((*cp != '\n') && (*cp != 0xff))
- cp++;
+ ep_parse_keyvals(bd, (u_char*)0xF0000EE0);
- cp++;
- if ((*cp == 0) || (*cp == 0xff))
- break;
- }
bd->bi_intfreq = 200000000;
bd->bi_busfreq = 100000000;
bd->bi_pci_busfreq= 33000000 ;
diff --git a/arch/ppc/platforms/rpx8260.h b/arch/ppc/platforms/rpx8260.h
index 843494a..e8d8fe3 100644
--- a/arch/ppc/platforms/rpx8260.h
+++ b/arch/ppc/platforms/rpx8260.h
@@ -15,7 +15,7 @@
typedef struct bd_info {
unsigned int bi_memstart; /* Memory start address */
unsigned int bi_memsize; /* Memory (end) size in bytes */
- unsigned int bi_nvsize; /* NVRAM size in bytes (can be 0) */
+ unsigned int bi_nvramsize; /* NVRAM size in bytes (can be 0) */
unsigned int bi_intfreq; /* Internal Freq, in Hz */
unsigned int bi_busfreq; /* Bus Freq, in MHz */
unsigned int bi_cpmfreq; /* CPM Freq, in MHz */
^ permalink raw reply related
* LTT and 2.6.15 kernel
From: Frank @ 2006-01-31 16:05 UTC (permalink / raw)
To: linuxppc-embedded
Is there a patch available for the 2.6.15 kernel and LTT. I
tried to apply the 0.9.6 patch for 2.6.10 to 2.6.15 and it
failed miserably.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
From: Tom Rini @ 2006-01-31 14:24 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <200601310947.32463.laurent.pinchart@tbox.biz>
On Tue, Jan 31, 2006 at 09:47:32AM +0100, Laurent Pinchart wrote:
> > No, that's good. If you can cleanly merge the existing parsing code, by
> > all means please do so. Thanks.
>
> Ok I will. On which kernel tree should I base my patches on ?
I would suggest either Linus' current git tree or 2.6.16-rc1 if you don't
use git. But please bear in mind that since this is a new feature (a new
board) it won't be submitted to Linus' tree until 2.6.17-rc1 opens up (and
if in that time, it becomes much easier to put this board under arch/powerpc
it should be done under there, instead).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Entry Point Address
From: Mustafa Çayır @ 2006-01-31 13:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
=20
does entry point adress defined uboot image header correspond to adress =
of which function in linux kernel ?
file :/common/cmd_bootm.c=20
function : do_bootm_linux
kernel =3D (void (*)(bd_t *, ulong, ulong, ulong, =
ulong))hdr->ih_ep;
Thanks,
^ permalink raw reply
* RE: devboards
From: Martin Krause @ 2006-01-31 12:36 UTC (permalink / raw)
To: Peter Fercher; +Cc: linuxppc-embedded
Hi Peter,
linuxppc-embedded-bounces@ozlabs.org wrote on Tuesday, January 31, 2006
1:20 PM:=20
> hi there,
>=20
> does anybody know where to get a nice MPC8548 devboard/devkit from ?
I think TQ-Components (www.tqc.de) is working on a TQM8548 module +=20
development kit. But I don't think it already will be announced on=20
their homepage. Please contact them directly for more detailed=20
information.
Regards,
Martin
^ permalink raw reply
* devboards
From: Peter Fercher @ 2006-01-31 12:19 UTC (permalink / raw)
To: 'linux-ppc-embedded'
hi there,
does anybody know where to get a nice MPC8548 devboard/devkit from ?
cheers, peter
^ permalink raw reply
* Re: Getting started with Xilinx V4 PPC?
From: David H. Lynch Jr. @ 2006-01-31 11:43 UTC (permalink / raw)
To: David Summers, linuxppc-embedded
In-Reply-To: <e4619cf30601301111u269d7842j42a8ef88623cfdf8@mail.gmail.com>
David;
I just completed a port of 2.6 to the Pico E-12 which is a Xilinx
Virtex-4 with very little hardware.
I had the advantage of a system that already had a elf loader (not
U-Boot), but not a Linux loader.
If I could load Linux as an elf file then I did not need another loader.
In the end I had to make some very trivial modifications to Pico's
loader to pass a board information structure. But otherwise the decision
to use the existing loader saved me having to port u-boot.
I also chose to boot into a ramdisk. Using the existing loader precluded
having the ramdisk as a separate file.
the intramfs feature of 2.6 allowed me to wrap the ramdisk into the same
file as the kernel. Documentation on initramfs is spartan, and somewhat
opaque. The good news was that despite the documentation initramfs
proved trivially easy to use.
After that I took the 2.6 kernel source, and litterally went through
looking for all references to the xilinx ml300.
Wherever there was an ml300 specific file I created an new one for the
pico_e12. Wherever there was an ml300 configuration option I created a
PICO_E12 one.
The E-12 had substatnitially less hardware than the ml300 (or the ml403)
so mostly I just ended up ripping code out of my private version of the
ml300 code that was transmuting into the pico_e12 code.
The next obstacle I bumped into was that the e-12 had two devices
suitable for a console - a highspeed fifo interface to a host
development system called the keyhole port, and the xilinx uartlite
serial port. Neither are supported in 2.6. I looked at the Xilinx
Uartlite 2.4 driver and it was coded substantially different from other
serial drivers. I decided not to try to port it to 2.6. I started from
scratch using the 8250 code as a base. I picked the 8250 because:
It must be the most heavily used linux serial driver and therefore I
hoped the most uptodate and well debugged.
The 8250 had boot through console IO support. Most other serial devices
require getting fairly far into the boot process before you get any output.
The really early IO proved fairly simple. Implimenting xxxx_dbg.c and
xxxx_tty.c for both the uartlite and the keyhole was fairly trivial.
Additionally the keyhole port had a "debug" feature where if you output
a single 32 bit word to one of the fifo ports it would be displayed in
hex on the host. As this could be done in an assembler macro that proved
indispensiable early on.
I was stalled for about 3 weeks trying to get the sucker into virtual
mode. In the end I had to disable Machine Check exceptions to make the
transition to virtual mode. Pico claims there is not a hardware problem,
but if I do nto disable machine checks on the e-12 it will never make
the tansition to virtual mode.
The full serial driver for the Uartlite (and Keyhole) proved more
daunting than anything else. In some ways the 8250 proved a bad choice
as a template there as there are more permutations, busses, etc
associated with the 8250 than anything else. I ended up stripping out
huge hunks of code. Eventually, I used the m32r_sio as a simpler
template. The driver was much simpler, and it had the critical features
I needed - both interupt driven and polled IO support - some
implimentations of the E12 do not include a PIC. The serial drivers took
much longer than the whole rest of the port combined - including the
machine check detour.
Just as I was finishing up the E12 port, Grant posted a set of patches
for the ml403. There were some fundimental differences at a fairly low
level between Grant's approach and mine. And I think Grant's Virtex-4
code appears to reflect more of the direction things are going, so I am
in the process of remodeling my port for the E12 on his for the ml403.
But I have not completed that.
Absent the machine check issue and having to write serial drivers thus
was atmost 2 weeks work.
BTW while you appear to be a hardware guy with alot of software
experience, I am a software guy with alot of hardware experience.
The E-12 has flash, but it uses a proprietary flash file system, and
using it would have required writing a filesystem driver - which I would
be happy to do if I got paid for it. Write performance on flash can be
extremely slow. If you are recording a significant amount of data in
realtime, you may want to skip the flash and just use a ramdisk. However
the ramdisk will not survive the system loosing power - which might be
an issue in a rocket.
If you are going to start with the 2.6 Kernel, I would get git. use it
to DL Linus's current 2.6 git repository, adn apply all of Grant's ml403
patches from the mailing list to it.
Then I would start an approach somewhat similar to what I described
above - except using Grant's ml403 as the base to create your own board
spec from instead of the ml300 that I used.
How tightly constrained are you for gates in the FPGA ?
If you are not tight, use the Xilinx 16550 serial IP and then you can
use standard Kernel 8250 dirvers (making Grant's patches work with
Uartlite is one of the things I am having trouble with) It would be my
guess that if you use the 16550 serial IP, you may be able to use
Grant's ml403 stuff asis.
David Summers wrote:
>I am starting a new project where I need to have a flash file system
>and an ethenet interface (HTTP and FTP). The project is a solar
>physics experiment that will be launched on a sub-orbital rocket
>flight this fall. The idea is that the experiment will write data
>files to the flash file system while in flight, and then I can
>download the data using ethernet after the experiment returns to
>earth.
>
>I think that Linux is the way to go for this project because of the
>JFFS2 filesystem and the strong networking support. The only problem
>is that I am totally new to embedded linux.
>
>I am prototyping my system on an Avnet FX12 development board ( Specs
>here: http://tinyurl.com/4gfdv ) which is pretty similar to the Xilinx
>ML403 board except with less memory and no SystemACE slot.
>
>I will eventually build my own custom board with the same Xilinx
>Virtex 4 FX12 FPGA and additional flash memory and some custom
>interface hardware. My background is primarily as a hardware designer,
>and I am very confortable with the FPGA part of this project. I am
>comfortable as a Linux user, and I am a pretty good C coder (for a
>hardware guy anyway :). I have never built a linux system (embedded
>or desktop) before, and I need some help getting started with embedded
>linux.
>
>I have already found the following websites which have been a big help so far:
>
>http://www.klingauf.de/v2p/index.phtml
>http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm
>http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html#toc1
>
>I have a few questions that I hope someone can help me with:
>
>1. What is the best linux distribution to start out with? I am
>currently working with the 2.4 kernel code from
>ppc.bkbits.net/linuxppc_2_4_devel, but I'm not sure that this version
>be being updated. (MontaVista also seems to be making it rather
>difficult to download their free Linux Preview Kit, so I wouldn't mind
>finding another distribution) Does the DENX distribution have good
>PPC support? Are there any others that I should look at, or should I
>just download the kernel source directly from kernel.org?
>
>
>2. kernel 2.4 or 2.6?
>
>It is my understanding that the latest version of MTD and JFFS2 have
>dropped support for kernel 2.4. I would like to use JFFS2 on a NAND
>flash device, so it seems like I should use 2.6. (Can I use JFFS2 on
>a NAND device with kernel v 2.4?)
>
>Being a complete newbie, am I biting off more that I can handle by
>trying to use 2.6?
>
>I have been lurking on the mailing list for a while, and I know that
>there are several people working on 2.6.x patches for the Xilinx
>virtex 4 parts. Could someone point me to a list of the patches that
>I need to get me started? I think that the ML403 patches should work
>with my board, but I don't know which ones I need to download.
>
>
>Thank you for your help,
>
>David Summers
>University of Colorado
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net:8888
^ permalink raw reply
* SPI flash kernel 2.4 driver
From: dibacco @ 2006-01-31 10:43 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
do you know if is there a "spi flash" driver included in 2.4 kernel?
I have an AT45DB081D (8 MBit Atmel chip) on a MPC875 spi bus.
Sincerely,
Antonio Di Bacco.
^ permalink raw reply
* Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
From: Laurent Pinchart @ 2006-01-31 8:47 UTC (permalink / raw)
To: Tom Rini; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <20060130172851.GF22672@smtp.west.cox.net>
> No, that's good. If you can cleanly merge the existing parsing code, by
> all means please do so. Thanks.
Ok I will. On which kernel tree should I base my patches on ?
Laurent Pinchart
^ permalink raw reply
* Re: Getting started with Xilinx V4 PPC?
From: Paula Saameño @ 2006-01-31 7:44 UTC (permalink / raw)
To: linuxppc-embedded, bennett78
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
Hi!!
I was pretty new to embedded linux as well, but I can recommend you using
2.4 kernel. The 2.6 version is not fully adapted to V4 yet, since the
ethernet drivers for the Xilinx EMAC hasn't been released, neither the ones
for other specific devices.
I used 2.4_devel, and it works fine for me. My design for the FPGA is
composed by an uart, the ethernet mac, i2c, ddr memory and interrupt
controller, and the kernel 2.4 is ok making the corresponding modifications
(adding xparameters.h and the other drivers generated by EDK).
However, here are some patches for the kernel 2.6 on the ml403 and the
Xilinx reference design:
http://patchwork.ozlabs.org/linuxppc/
See January and there are 9 patches that maybe are useful for you. I got it
running on my ml403 board, but there is no network support for Xilinx yet,
and that's why I recommended you the 2.4.
Hope being helpful!
Paula
[-- Attachment #2: Type: text/html, Size: 1023 bytes --]
^ permalink raw reply
* Re: Getting started with Xilinx V4 PPC?
From: Peter Ryser @ 2006-01-31 5:59 UTC (permalink / raw)
To: David Summers; +Cc: linuxppc-embedded
In-Reply-To: <e4619cf30601301111u269d7842j42a8ef88623cfdf8@mail.gmail.com>
Hi David,
you might want to have a look at the following documents beside the ones you mention in your email:
- XAPP765 (http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). This document describes on how to get started with EDK and the ML300 board. The approach for the ML403 board is the same as is for the Avnet board.
- UG080, pg. 37 (http://www.xilinx.com/bvdocs/userguides/ug082.pdf). This document contains a brief description on how to rebuild the Linux kernel for the ML403 board.
Start with rebuilding the reference design and Linux kernel for the ML403/Avnet board. All the necessary information can be found in the documents above and on
http://www.xilinx.com/products/boards/ml403/reference_designs.htm (for the ML403 board)
At this time I recommend staying with the 2.4 Linux kernel as the support for ML300 (and the ML403 and the Avnet board) in the 2.6 kernel is very basic (UART only).
Since you only need Ethernet once the "project" returns from its flight you might want to consider to develop two hardware designs. The first one does not have Ethernet and is for the flight. The second one contains Ethernet but not some of the additional control logic and is for retrieving the data upon return. This might get you into a smaller device and I assume that size matters.
- Peter
David Summers wrote:
>I am starting a new project where I need to have a flash file system
>and an ethenet interface (HTTP and FTP). The project is a solar
>physics experiment that will be launched on a sub-orbital rocket
>flight this fall. The idea is that the experiment will write data
>files to the flash file system while in flight, and then I can
>download the data using ethernet after the experiment returns to
>earth.
>
>I think that Linux is the way to go for this project because of the
>JFFS2 filesystem and the strong networking support. The only problem
>is that I am totally new to embedded linux.
>
>I am prototyping my system on an Avnet FX12 development board ( Specs
>here: http://tinyurl.com/4gfdv ) which is pretty similar to the Xilinx
>ML403 board except with less memory and no SystemACE slot.
>
>I will eventually build my own custom board with the same Xilinx
>Virtex 4 FX12 FPGA and additional flash memory and some custom
>interface hardware. My background is primarily as a hardware designer,
>and I am very confortable with the FPGA part of this project. I am
>comfortable as a Linux user, and I am a pretty good C coder (for a
>hardware guy anyway :). I have never built a linux system (embedded
>or desktop) before, and I need some help getting started with embedded
>linux.
>
>I have already found the following websites which have been a big help so far:
>
>http://www.klingauf.de/v2p/index.phtml
>http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm
>http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html#toc1
>
>I have a few questions that I hope someone can help me with:
>
>1. What is the best linux distribution to start out with? I am
>currently working with the 2.4 kernel code from
>ppc.bkbits.net/linuxppc_2_4_devel, but I'm not sure that this version
>be being updated. (MontaVista also seems to be making it rather
>difficult to download their free Linux Preview Kit, so I wouldn't mind
>finding another distribution) Does the DENX distribution have good
>PPC support? Are there any others that I should look at, or should I
>just download the kernel source directly from kernel.org?
>
>
>2. kernel 2.4 or 2.6?
>
>It is my understanding that the latest version of MTD and JFFS2 have
>dropped support for kernel 2.4. I would like to use JFFS2 on a NAND
>flash device, so it seems like I should use 2.6. (Can I use JFFS2 on
>a NAND device with kernel v 2.4?)
>
>Being a complete newbie, am I biting off more that I can handle by
>trying to use 2.6?
>
>I have been lurking on the mailing list for a while, and I know that
>there are several people working on 2.6.x patches for the Xilinx
>virtex 4 parts. Could someone point me to a list of the patches that
>I need to get me started? I think that the ML403 patches should work
>with my board, but I don't know which ones I need to download.
>
>
>Thank you for your help,
>
>David Summers
>University of Colorado
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
^ permalink raw reply
* Re: Question on USB gadget device driver for mpc 8272 on linux 2.6.14.
From: Vitaly Bordug @ 2006-01-31 1:23 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <43DDF76D.1070501@compulab.co.il>
On Mon, 30 Jan 2006 13:24:29 +0200
Mike Rapoport <mike@compulab.co.il> wrote:
> Vitaly,
> Can you send me this patch?
>
Heh, if there is such a interest, I guess the driver worths to be slightly scrubbed and rebased against current kernel git. Then you could make it available in sf.net for others that are concerned.
But you need to wait a little...
>
> Vitaly Bordug wrote:
>
> >Jonathan,
> >
> >I have implemented the PQ2 usb-serial functionality a while ago, but the code needs a lot of cleanup, which is sometimes very tricky due to the tight timings required by this device. If you are interested, I can try to find the patch...
> >
> >On Fri, 27 Jan 2006 11:45:39 +1100
> >"Jonathan Qiang" <jonathan@haliplex.com.au> wrote:
> >
> >
> >
> >>Hi, all
> >>
> >>Currently, I am doing on the USB gadget device driver for mpc8272, I
> >>already got some packets on interruption route when my board in which
> >>mpc82xx settled connect to Host.
> >>But the SOF is always generated as the first interruption source. When
> >>plugged USB cable in HOST, the USB controller will be set to reset
> >>(USBER is [0x308]), and after reset, the interruption source event
> >>changes its status to [0x108], which means running on IDLE and SOF. Why
> >>It is not IN token?
> >>I already disabled Frame timer when I probe the USB gadget controller.
> >>
> >>
> >
> >
> >
> >
>
> --
> Sincerely yours,
> Mike Rapoport
>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* m82xx usb host error
From: Dubb, Benjamin @ 2006-01-31 0:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]
Folks,
I'm seeing the following with 2.4.20 kernel running on mpc8270. The host never shows any activity when I plug usb devices. What's the best way to debug this? Thanks,
- Ben
hub.c: port 1, portstatus 101, change 1, 12 Mb/s
hub.c: port 1 connection change
hub.c: port 1, portstatus 101, change 1, 12 Mb/s
Looking up port of RPC 100003/2 on 10.0.0.1
Looking up port of RPC 100005/1 on 10.0.0.1
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 88k init
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 103, change 0, 12 Mb/s
hub.c: new USB device m82xxhci-1, assigned address 2
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=2 (error=-110)
hub.c: port 1, portstatus 103, change 0, 12 Mb/s
hub.c: new USB device m82xxhci-1, assigned address 3
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=3 (error=-110)
DISCLAIMER:
Important Notice *************************************************
This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.
[-- Attachment #2: Type: text/html, Size: 2973 bytes --]
^ permalink raw reply
* Re: [PATCH] Add support for lite5200b board.
From: Sylvain Munaut @ 2006-01-30 23:45 UTC (permalink / raw)
To: John Rigby; +Cc: Linuxppc-embedded
In-Reply-To: <4b73d43f0601301422m1315e6b7s11655acb8ba8a54d@mail.gmail.com>
John Rigby wrote:
> and the arch/ppc/bestcomm directory as well
>
> looks like maybe you didn't do a git-update-index?
Damned ... I was just passing by my laptop in a hurry when I made that
post and I should have took the time to do it properly ...
I just did a cg-diff that I piped directly into the file, hoping it
would work. I forgot about the new files.
Check the file again, it should be ok this time. Sorry for the delay.
Sylvain
> On 1/30/06, John Rigby <jcrigby@gmail.com> wrote:
>
>>Ok checked out the git tree and applied the patch.
>>The drivers/net/fec_mpc52xxx directory seems to be missing.
>>
>>On 1/30/06, John Rigby <jcrigby@gmail.com> wrote:
>>
>>>Thanks, I had tried stripping off the http: and adding the .git but
>>>not just adding the .git.
>>>
>>>
>>>On 1/30/06, Sylvain Munaut <tnt@246tnt.com> wrote:
>>>
>>>>Ooops,
>>>>
>>>>git clone http://gitbits.246tnt.com/gitbits/linux-2.6-mpc52xx.git
>>>>
>>>>(notice the previously missing .git at the end)
>>>>
>>>>
>>>> Sylvain
>>>>
>>>>John Rigby wrote:
>>>>
>>>>>I tried:
>>>>>git clone http://gitbits.246tnt.com/gitbits/linux-2.6-mpc52xx
>>>>>and got:
>>>>>defaulting to local storage area
>>>>>Cannot get remote repository information.
>>>>>Perhaps git-update-server-info needs to be run there?
>>>>>
>>>>>
>>>>>
>>>>>On 1/29/06, Sylvain Munaut <tnt@246tnt.com> wrote:
>>>>>
>>>>>
>>>>>>John Rigby wrote:
>>>>>>
>>>>>>
>>>>>>>On 1/25/06, *Sylvain Munaut* <tnt@246tnt.com <mailto:tnt@246tnt.com>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Should apply fine on vanilla. My suggestion for now is take vanilla,
>>>>>>> apply this patch, then the 2-3 patch from Andrey for BestComm and stuff.
>>>>>>>
>>>>>>>
>>>>>>>I was working on getting bestcomm and fec working, but forward porting
>>>>>>>my old 2.6.10 code to current is turning out to be more difficult than I
>>>>>>>expected.
>>>>>>>If you already have working code then I'll stop working on them.
>>>>>>>
>>>>>>>Where are these patches? I'm new to this list so I don't have much
>>>>>>>history.
>>>>>>>Would I find these patches in the archive?
>>>>>>
>>>>>>Checkout (with git)
>>>>>>
>>>>>>http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx
>>>>>>
>>>>>>then apply
>>>>>>
>>>>>>http://gitbits.246tNt.com/patches/bcomm-to-split.diff
>>>>>>
>>>>>>(I haven't cleanly splitted it up yet and right now I must go, so it's
>>>>>>probably gonna be in the git tree this week, under the 'bestcomm' head ;)
>>>>>>
>>>>>>
>>>>>>Please report if it works fine on your board (both lite5200 and
>>>>>>lite5200b reports are welcome). I only did quick tests.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sylvain
>>>>>>
>>>>>
>>>>>
>>>>
>
^ permalink raw reply
* RE: HELP! Memory mapping and address space doubts
From: Jose França (Ext_GTBC) @ 2006-01-30 23:29 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
Vml0YWx5LA0KIA0KICAgICBJJ20gdXNpbmcgYSBsaW51eCAyLjQuMzEga2VybmVsLiBJbiB0aGUg
cHJlc2VudCBzaXR1YXRpb24gSSBoYXZlIEJSeC9PUnggd2VsbCBjb25maWd1cmVkIGFuZCBpIGNh
biBib290IHUtYm9vdCBub3JtYWxseSBhbmQgd2l0aG91dCBwcm9ibGVtcy4gSSBoYXZlIGEgZmxh
c2ggZXByb20gd2l0aCBiYXNlIGFkZHJlc3MgMHhEMDAwMDAwMCBhbmQgYSBGUEdBIGluIDB4RTAw
MDAwMDAuIEluIGxpbnV4LCBpIGhhdmUgdGhlIG10ZCBkcml2ZXIgc2ltaWxhciB0byB0aGUgcnB4
bGl0ZSBib2FyZC4gY2ZpX3Byb2JlIGRvZXNuJ3QgZmluZCBteSBmbGFzaCBlcHJvbS4gTXkgY29s
bGVhZ3VlIGRldmVsb3BwZWQgYW4gZnBnYSBkcml2ZXIsIGJ1dCBoZSBjYW4ndCBhY2Nlc3MgaXQg
ZWl0aGVyLi4uIEl0IHNlZW0ncyB0aGF0IGFsbCB0aGUgYWRkcmVzc2VzIHRoYXQgd2UgdHJ5IHRv
IGFjY2VzcyBhcmUgYWxsIG1peGVkLXVwLiBJbiBwcGNfbWQubWFwX2lvLCBpJ20gZG9pbmcgaW9f
YmxvY2tfbWFwcGluZyBmb3IgdGhlIENQTSAoZnJvbSAweGYwMDAwMDAwIHRvIHRoZSBlbmQgb2Yg
bWVtb3J5KSAsIDB4ODAwMDAwMDAgYW5kIDB4YTAwMDAwMDAgZm9yIFBDSSBhZGRyZXNzIHNwYWNl
LCBib3RoIHdpdGggMjU2TUIgb2YgbGVuZ3RoLiBXZSBhcmUgYSBiaXQgbG9zdC4uLiBJdCBzZWVt
cyB0aGF0IHdlIGZvcmdvdCBzb21ldGhpbmcgdG8gZG8uIENhbiB5b3UgaGVscCBtZSBvbiB0aGlz
Pw0KIA0KIA0KQmVzdCByZWdhcmRzLA0KRmlsaXBlLg0KDQoJLS0tLS1NZW5zYWdlbSBvcmlnaW5h
bC0tLS0tIA0KCURlOiBsaW51eHBwYy1lbWJlZGRlZC1ib3VuY2VzQG96bGFicy5vcmcgZW0gbm9t
ZSBkZSBWaXRhbHkgQm9yZHVnIA0KCUVudmlhZGE6IHNleCAyNy0wMS0yMDA2IDEzOjM3IA0KCVBh
cmE6IEpvc2UgRnJhbsOnYSAoRXh0X0dUQkMpIA0KCUNjOiBsaW51eHBwYy1lbWJlZGRlZEBvemxh
YnMub3JnIA0KCUFzc3VudG86IFJlOiBIRUxQISBNZW1vcnkgbWFwcGluZyBhbmQgYWRkcmVzcyBz
cGFjZSBkb3VidHMNCgkNCgkNCg0KCUpvc2UsDQoJQ2FuIHlvdSBwbGVhc2UgYmUgYSBiaXQgbW9y
ZSBzcGVjaWZpYyBpbiB0YXJnZXRzIHlvdSB3YW50IHRvIGFjaGlldmU/DQoJDQoJQW4gZXhhbXBs
ZSBob3cgdG8gc2V0dXAgYnIvb3IgYW5kIHVzZSB0aGUgZGV2aWNlIGNvdWxkIGJlIGZvdW5kIGFz
IGEgcGFydCBvZiBQUTIgUENJIHN1cHBvcnQsDQoJd2hlcmUgaW50ZXJydXB0IGNvbnRyb2xsZXIg
aXMgaW1wbGVtZW50ZWQgYXMgYSBDUExEIGRldmljZSAoYXJjaC9wcGMvc3lzbGliL204Mnh4X3Bj
aS57YyxofSkuDQoJDQoJDQoJT24gVGh1LCAyNiBKYW4gMjAwNiAxNDowNDo0OSAtMDAwMA0KCUpv
c2UgRnJhbsOnYSAoRXh0X0dUQkMpIDxKb3NlLkZyYW5jYS5FeHRAc2llbWVucy5jb20+IHdyb3Rl
Og0KCQ0KCT4gSGVsbG8gdSBhbGwhDQoJPg0KCT4gICAgICAgSSBuZWVkIHRvIGNsYXJpZnkgc29t
ZSBhc3BlY3RzIG9mIHRoZSBtZW1vcnkgbWFuYWdlbWVudCBpbiBwcGMgbGludXggYW5kIGkgaG9w
ZSB0aGF0IHlvdSBjb3VsZCBoZWxwIG1lLg0KCT4gICAgICAgTGV0cyBpbWFnaW5lIHdlIGhhdmUg
YSBtcGM4MjcyIGJhc2VkIGJvYXJkIHdpdGggMyBkZXZpY2VzIEEsIEIgYW5kIEMuSW4gdGhlIGJv
b3Rsb2FkZXIgKGluIG15IGNhc2UsIGkgdXNlIHUtYm9vdCksIGkgY29uZmlndXJlZCB0aGUgQlJ4
IGFuZCBPcnggc28gdGhhdCBBIGhhcyBiYXNlIGFkZHJlc3MgWCwgQiBoYXMgYmFzZSBhZGRyZXNz
IFkgYW5kIEMgaGFzIGJhc2UgYWRkcmVzcyBaLiBNeSBmaXJzdCBkb3VidCBhcnJpc2VzIGhlcmU6
IHdoYXQgYWRkcmVzcyBzaG91bGQgaSB1c2U/IEJlaW5nIFNEUkFNIGJhc2UgYWRkcmVzcyAweDAw
MDAwMDAwIGFuZCBrZXJuZWwgYmFzZSBhZGRyZXNzIDB4QzAwMDAwMDAsIHdoZXJlIHdpbGwgaSBw
dXQgdGhlc2UgZGV2aWNlcyBtYXBwZWQgb24/IEFib3ZlIDB4QzAwMDAwMDAgb3IgaW4gYmV0d2Vl
biB0aGUgZW5kIG9mIHBoeXNpY2FsIG1lbW9yeSBhbmQgMHhDMDAwMDAwMD8gRG8gaSByZWFsbHkg
bmVlZCB0byBjb25maWd1cmUgdGhlIEJBVCByZWdpc3RlcnMgaW4gdSBib290Pw0KCT4gICAgICAg
SW4gbGludXggMi40IGtlcm5lbCwgd2UgaGF2ZSBwcGNfbWQuc2V0dXBfaW9fbWFwcGluZ3MgdG8g
bWFwIGFkZHJlc3MgYmxvY2tzIGludG8gdGhlIEJBVCByZWdpc3RlcnMuLi4gQXMgaSBvYnNlcnZl
ZCBpbiB0aGUga2VybmVsIHNvdXJjZSB0cmVlIGV4YW1wbGVzLCB3ZSBtdXN0IG1hcCBDUE0gKHdo
eT8pLiBBbmQgd2hhdCBhYm91dCB0aGUgb3RoZXIgZGV2aWNlcyBBLCBCIGFuZCBDPyBIb3cgd2ls
bCBpIHNldHVwIHRoZW0gaW4gdGhpcyBjYXNlIGFuZCB3aGF0IGFkZHJlc3NlcyBpIGNhbiB1c2U/
IEFib3ZlIDB4QzAwMDAwMDAgb3IgaW4gYmV0d2VlbiB0aGUgZW5kIG9mIHBoeXNpY2FsIG1lbW9y
eSBhbmQgMHhDMDAwMDAwMD8gSXMgdGhlIFNEUkFNIGluY2x1ZGVkPw0KCT4NCgk+ICAgICAgIFRo
YW5rcyBpbiBhZHZhbmNlIHRvIGFsbCBjb250cmlidXRpb25zISBBbGwgb2YgdGhlbSB3aWxsIGJl
IG1vc3Qgd2VsY29tZWQhDQoJPg0KCT4NCgk+DQoJPg0KCT4NCgk+IEJlc3QgcmVnYXJkcywNCgk+
IEZpbGlwZQ0KCT4NCgk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoJPiBMaW51eHBwYy1lbWJlZGRlZCBtYWlsaW5nIGxpc3QNCgk+IExpbnV4cHBjLWVt
YmVkZGVkQG96bGFicy5vcmcNCgk+IGh0dHBzOi8vb3psYWJzLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2xpbnV4cHBjLWVtYmVkZGVkDQoJPg0KCT4NCgkNCgkNCgktLQ0KCVNpbmNlcmVseSwNCglWaXRh
bHkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCUxp
bnV4cHBjLWVtYmVkZGVkIG1haWxpbmcgbGlzdA0KCUxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5v
cmcNCglodHRwczovL296bGFicy5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eHBwYy1lbWJlZGRl
ZCANCg0K
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: David S. Miller @ 2006-01-30 23:02 UTC (permalink / raw)
To: sdbrady
Cc: linux-mips, linux-m68k, linux-ia64, spyro, ak, dhowells,
linuxppc-dev, gerg, sparclinux, uclinux-v850, ysato, takata,
linuxsh-shmedia-dev, grundler, torvalds, ink, mita, chris,
dev-etrax, ultralinux, linux-kernel, ralf, linuxsh-dev, linux390,
parisc-linux
In-Reply-To: <20060130195004.GA25860@miranda.arrow>
From: Stuart Brady <sdbrady@ntlworld.com>
Date: Mon, 30 Jan 2006 19:50:04 +0000
> Shame about popc on SPARC. However, ffz is cheese, regardless of pops.
> (On sparc64, ffs is too.) I'll wait for the generic bitops patches to
> be dealt with (or not) and then submit a patch fixing this if needed.
I'm happy with any improvement you might make here, for sure.
The sparc64 ffz() implementation was done so dog stupid like that
so that the code would be small since this gets inlined all over
the place.
So if you can keep it small and improve it, or make it a bit larger
and uninline it, that's great.
^ permalink raw reply
* Re: MPC5200 - Problem with PSC mode
From: Zeitler, Nathan @ 2006-01-30 22:34 UTC (permalink / raw)
To: linuxppc-embedded
Allann,
Hmm, yes. In addition, these lines looks suspect:
> val32 =3D in_be32(&gpio->port_config);
> val32 &=3D ~0x700;
> val32 |=3D 0x600;
> out_be32(&gpio->port_config, val32);
I don't have the register's header file in front of me, but I'm
pretty sure this refers to MBAR+0xb00. If that's the case,=20
you seem to be configuring the port to be in CODEC mode=20
and not UART mode. Try this instead:
val32 =3D in_be32(&gpio->port_config);
val32 &=3D ~0xf00;
val32 |=3D 0x400;
out_be32(&gpio->port_config, val32);
You may want to refer to the MPC5200 manual. Page 15-43
has a nice sequence you can go through to configure a port
to be a UART.
Open Systems International, Inc.=20
Nathan Zeitler
Hardware Engineer
3600 Holly Lane North, Suite 40
Minneapolis, MN 55447-1286
Phone: 763 551 0559
Fax: 763 551 0750
E-mail: nzeitler@osii.com
^ 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