* RE: Watchdog on MPC82xx [SOLVED]
From: Bastos Fernandez Alexandre @ 2006-04-21 10:33 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <1145528816.444761f0a9962@webmail.televes.com:443>
Hi,
As suggested by Rune, problem was concerning to the RTC on time_init().
As I don't have a RTC on the board, the solution for me was setting
the ppc_md.get_rtc_time to NULL, which prevents time_init() from
doing the loop which tries to set the next second boundary. So
void __init
m82xx_board_setup(void)
{
[...]
ppc_md.get_rtc_time = NULL;
ppc_md.set_rtc_time = NULL;
}
Thanks to all.
Alex BASTOS
> Rune,
>
> > On our 8265/8280 board, the max timeout of the watchdog timer was ~1.3
> > seconds, so it kept resetting before the heartbeat function got called
> > on boot.
> >
> > I had to add a watchdog reset to time_init() because it woud pause there
> > for about 2 secondfs trying to see if there was a realtime clock.
> >
>
> I think that you are OK. Using the while(1) test suggested by Paul Bilke,
> I could verify that time_init() is the cause for the reset. In fact, I have
> no RTC on my board (so I suppose the delay looking for it will be maximum).
>
> Thanks
>
> Alex Bastos
^ permalink raw reply
* fix oops due to i2c-keylarge -> i2c-powermac rename
From: Guido Guenther @ 2006-04-21 8:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi,
the i2c-keywest module has been renamed to i2c-powermac during the
2.6.16 development cycle. This fixes the corresponding request_module
calls so the module gets loaded again and we don't oops on i2c accesses.
Patch applies against current Linus git. Please apply:
Singend-Off-By: Guido Guenther <agx@sigxcpu.org>
--- orig/linux-2.6.16.7/sound/ppc/tumbler.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16.7/sound/ppc/tumbler.c 2006-04-19 23:15:20.000000000 +0200
@@ -1314,7 +1314,7 @@
#ifdef CONFIG_KMOD
if (current->fs->root)
- request_module("i2c-keywest");
+ request_module("i2c-powermac");
#endif /* CONFIG_KMOD */
mix = kmalloc(sizeof(*mix), GFP_KERNEL);
--- orig/linux-2.6.16.7/sound/ppc/daca.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16.7/sound/ppc/daca.c 2006-04-19 23:14:33.000000000 +0200
@@ -256,7 +256,7 @@
#ifdef CONFIG_KMOD
if (current->fs->root)
- request_module("i2c-keywest");
+ request_module("i2c-powermac");
#endif /* CONFIG_KMOD */
mix = kmalloc(sizeof(*mix), GFP_KERNEL);
--- orig/linux-2.6.16.7/sound/oss/dmasound/tas_common.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16.7/sound/oss/dmasound/tas_common.c 2006-04-20 20:46:55.000000000 +0200
@@ -195,8 +195,8 @@
printk(KERN_INFO "tas driver [%s])\n", driver_name);
-#ifndef CONFIG_I2C_KEYWEST
- request_module("i2c-keywest");
+#ifndef CONFIG_I2C_POWERMAC
+ request_module("i2c-powermac");
#endif
tas_node = find_devices("deq");
if (tas_node == NULL)
--- orig/linux-2.6.16.7/drivers/macintosh/therm_adt746x.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16.7/drivers/macintosh/therm_adt746x.c 2006-04-20 20:45:32.000000000 +0200
@@ -627,8 +627,8 @@
if(therm_type == ADT7460)
device_create_file(&of_dev->dev, &dev_attr_sensor2_fan_speed);
-#ifndef CONFIG_I2C_KEYWEST
- request_module("i2c-keywest");
+#ifndef CONFIG_I2C_POWERMAC
+ request_module("i2c-powermac");
#endif
return i2c_add_driver(&thermostat_driver);
Cheers,
-- Guido
^ permalink raw reply
* Re: [PATCH] sys_vmsplice
From: Arnd Bergmann @ 2006-04-21 10:41 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Jens Axboe, linuxppc-dev, torvalds, Paul Mackerras,
davem
In-Reply-To: <20060421022555.2d460805.akpm@osdl.org>
On Friday 21 April 2006 11:25, Andrew Morton wrote:
> It might be better to just stick the new entry into the spufs table, make
> sure that the powerpc guys see it go in. That way, ppc64 people (Linus,
> maybe you?) can test it.
>
> I guess mapping it onto sys_ni_syscall would be safest.
>
> (It's been broken since sys_tee went in, btw).
The BUILD_BUG_ON in there was just overkill. How about if we just add a
small comment to the systbl on powerpc to remind people about the fact
that there is another file to edit? Patch follows.
Arnd <><
^ permalink raw reply
* [PATCH] fix spu_callbacks BUILD_BUG_ON
From: Arnd Bergmann @ 2006-04-21 10:45 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Jens Axboe, linuxppc-dev, torvalds, Paul Mackerras,
davem
In-Reply-To: <200604211241.36596.arnd@arndb.de>
Every time a new syscall gets added, a BUILD_BUG_ON in
arch/powerpc/platforms/cell/spu_callbacks.c gets triggered.
Since the addition of a new syscall is rather harmless,
the error should just be removed.
While we're here, add sys_tee to the list and add a comment
to systbl.S to remind people that there is another list
on powerpc.
Signed-of-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--- linus-2.6.orig/arch/powerpc/platforms/cell/spu_callbacks.c
+++ linus-2.6/arch/powerpc/platforms/cell/spu_callbacks.c
@@ -317,17 +317,16 @@ void *spu_syscall_table[] = {
[__NR_ppoll] sys_ni_syscall, /* sys_ppoll */
[__NR_unshare] sys_unshare,
[__NR_splice] sys_splice,
+ [__NR_tee] sys_tee,
};
long spu_sys_callback(struct spu_syscall_block *s)
{
long (*syscall)(u64 a1, u64 a2, u64 a3, u64 a4, u64 a5, u64 a6);
- BUILD_BUG_ON(ARRAY_SIZE(spu_syscall_table) != __NR_syscalls);
-
syscall = spu_syscall_table[s->nr_ret];
- if (s->nr_ret >= __NR_syscalls) {
+ if (s->nr_ret >= ARRAY_SIZE(spu_syscall_table)) {
pr_debug("%s: invalid syscall #%ld", __FUNCTION__, s->nr_ret);
return -ENOSYS;
}
Index: linus-2.6/arch/powerpc/kernel/systbl.S
===================================================================
--- linus-2.6.orig/arch/powerpc/kernel/systbl.S
+++ linus-2.6/arch/powerpc/kernel/systbl.S
@@ -324,3 +324,8 @@ COMPAT_SYS(ppoll)
SYSCALL(unshare)
SYSCALL(splice)
SYSCALL(tee)
+
+/*
+ * please add new calls to arch/powerpc/platforms/cell/spu_callbacks.c
+ * as well when appropriate.
+ */
^ permalink raw reply
* Re: [PATCH 1/2] tickless idle cpus: core patch - v2
From: Paul Mackerras @ 2006-04-21 10:49 UTC (permalink / raw)
To: vatsa; +Cc: linuxppc-dev
In-Reply-To: <20060410121847.GB5564@in.ibm.com>
Srivatsa Vaddagiri writes:
> This is the v2 of the core patch to skip ticks when a CPU is idle.
...
> +/* Returns 1 if this CPU was set in the mask */
> +static inline int clear_hzless_mask(void)
> +{
> + int cpu = smp_processor_id();
> + int rc = 0;
> +
> + if (unlikely(cpu_isset(cpu, nohz_cpu_mask))) {
> + cpu_clear(cpu, nohz_cpu_mask);
Is the nohz_cpu_mask accessed by other cpus? I wonder if using a
1-byte per-cpu variable for this, or even a bit in the thread_info
struct, might be better because it would reduce the number of atomic
bit set/clear operations we have to do.
> +#define MAX_DEC_COUNT UINT_MAX /* Decrementer is 32-bit */
The decrementer value should be restricted to INT_MAX. I think some
implementations will take a decrementer interrupt if you set the
decrementer to a negative value.
> +static void account_ticks(struct pt_regs *regs)
> +{
> + int next_dec;
> + int cpu = smp_processor_id();
> + unsigned long ticks;
> +
> while ((ticks = tb_ticks_since(per_cpu(last_jiffy, cpu)))
> >= tb_ticks_per_jiffy) {
> /* Update last_jiffy */
This is just the loop body from timer_interrupt, right? Why do we
have to loop around N times after we skipped N ticks? What we're
doing inside the loop is:
- account_process_time, but we know we were in the idle task, so the
time is just idle time. If we have the accurate accounting stuff
turned on the first call to account_process_time will account all
the idle time anyway.
- we're not skipping ticks on the boot cpu (yet), so we won't do the
do_timer and timer_recalc_offset calls.
I think we could probably rearrange this code to eliminate the need
for the regs argument - all it's used for is telling whether we were
in user mode, and we know we weren't since we were in the idle task.
That would mean that we maybe could call start_hz_timer from the idle
task body instead of inside do_IRQ etc. The only thing we'd have to
watch out for is updating the decrementer if some interrupt handler
called add_timer/mod_timer etc.
Assuming we make the changes we have discussed to reduce the skewing
of the decrementer interrupts quite small, and allow any cpu to call
do_timer, then how where you thinking that xtime and the NTP stuff
would get updated, in the situation where all cpus are skipping ticks?
By doing N calls to do_timer in a row? Or by adding N-1 to jiffies_64
and then calling do_timer once?
> +#ifdef CONFIG_NO_IDLE_HZ
> + max_skip = __USE_RTC() ? HZ : MAX_DEC_COUNT / tb_ticks_per_jiffy;
> +#endif
If we allow the boot cpu to skip ticks, then we will have to make sure
that at least one cpu wakes up in time to do the updating in
recalc_timer_offset.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Paul Mackerras @ 2006-04-21 11:17 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <644FB6AC-3702-41D0-A9E2-6FDEC52B819D@freescale.com>
Andy Fleming writes:
> So no one chimed in on this. Clearly, 1275 states that it's supposed
> to be local-mac-address or mac-address. We use "address". But I'm
> pretty sure we copied our ethernet node from somewhere else, so which
> one should it be?
It shouldn't be "address". That would normally be the physical
address of the device's registers, if anything.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: avoid crash in PCI code if mem system not up.
From: Paul Mackerras @ 2006-04-21 12:02 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060421004042.GC7242@austin.ibm.com>
Linas Vepstas writes:
> Please apply and forward upstream. And a question: once
> upon a time, the arch PCI subsystem was inited after mem init
> was done; currently, it seems to be happening before mem init.
> Is this intentional?
No, and it is bogus if it is. Do you have the full backtrace from the
crash?
Paul.
^ permalink raw reply
* USB-Hostcontroller-Support for MPC875
From: Josef Angermeier @ 2006-04-21 12:57 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'd like to make use of the MP875 internal USB-Hostcontroller on my
custome board. Such support is not included in official kernel releases,
but theres exists a usbhost-for-mpc8xx patch from brad parker for the
2.4 kernel series. Did ever someone use that one with an MPC875 ?
thanks for every help,
best regards,
Josef
^ permalink raw reply
* Re: USB-Hostcontroller-Support for MPC875
From: Vitaly Bordug @ 2006-04-21 13:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4448D6B7.40509@cs.fau.de>
On Fri, 21 Apr 2006 14:57:27 +0200
Josef Angermeier <Josef.Angermeier@informatik.uni-erlangen.de> wrote:
>
> Hello,
>
> I'd like to make use of the MP875 internal USB-Hostcontroller on my
> custome board. Such support is not included in official kernel releases,
> but theres exists a usbhost-for-mpc8xx patch from brad parker for the
> 2.4 kernel series. Did ever someone use that one with an MPC875 ?
>
Brad Parker's approach is the only I am aware of, and I had no success to bring hci up on my 8xx with those
sources.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] fix spu_callbacks BUILD_BUG_ON
From: Jan Engelhardt @ 2006-04-21 13:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, linux-kernel, Jens Axboe, linuxppc-dev, torvalds,
Paul Mackerras, davem
In-Reply-To: <200604211245.27744.arnd@arndb.de>
>--- linus-2.6.orig/arch/powerpc/platforms/cell/spu_callbacks.c
>+++ linus-2.6/arch/powerpc/platforms/cell/spu_callbacks.c
>@@ -317,17 +317,16 @@ void *spu_syscall_table[] = {
> [__NR_ppoll] sys_ni_syscall, /* sys_ppoll */
> [__NR_unshare] sys_unshare,
> [__NR_splice] sys_splice,
>+ [__NR_tee] sys_tee,
+ [__NR_syscalls] = NULL,
> };
>
> long spu_sys_callback(struct spu_syscall_block *s)
> {
> long (*syscall)(u64 a1, u64 a2, u64 a3, u64 a4, u64 a5, u64 a6);
>
>- BUILD_BUG_ON(ARRAY_SIZE(spu_syscall_table) != __NR_syscalls);
>-
> syscall = spu_syscall_table[s->nr_ret];
>
>- if (s->nr_ret >= __NR_syscalls) {
>+ if (s->nr_ret >= ARRAY_SIZE(spu_syscall_table)) {
+ if(syscall == NULL) {
That way, syscalls could be added in the master table while spu does not
break. Comments?
Jan Engelhardt
--
^ permalink raw reply
* Re: [PATCH] fix spu_callbacks BUILD_BUG_ON
From: Arnd Bergmann @ 2006-04-21 13:52 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Andrew Morton, linux-kernel, Jens Axboe, linuxppc-dev, torvalds,
Paul Mackerras, davem
In-Reply-To: <Pine.LNX.4.61.0604211512370.23180@yvahk01.tjqt.qr>
On Friday 21 April 2006 15:14, Jan Engelhardt wrote:
> + [__NR_syscalls] = NULL,
>
> > };
> >
> >- if (s->nr_ret >= __NR_syscalls) {
> >+ if (s->nr_ret >= ARRAY_SIZE(spu_syscall_table)) {
>
> + if(syscall == NULL) {
>
>
>
> That way, syscalls could be added in the master table while spu does not
> break. Comments?
Hmm, my idea was not having to check for NULL pointers when we know
that they are valid function calls. But you are right that your approach
is more robust. It also means that we might just leave out all
the assignments to sys_ni_syscall in order to make the source a little
shorter.
Arnd <><
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Brent Cook @ 2006-04-21 14:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc
In-Reply-To: <1145594285.28014.12.camel@localhost.localdomain>
On Thursday 20 April 2006 23:38, Benjamin Herrenschmidt wrote:
> On Thu, 2006-04-20 at 14:55 -0700, Eugene Surovegin wrote:
> > On Thu, Apr 20, 2006 at 11:10:55PM +0200, Gerhard Pircher wrote:
> > > Well, Freescale's PPC programming environment manual clearly states
> > > that this will not work on G4 CPUs (74xx). Also Benjamin Herrenschmidt
> > > told me, that this implementation will not work for the reasons I
> > > mentioned before. The approach I'm trying to implement was his idea, so
> > > I have to trust in him.
> >
> > Well, you aren't the first person who tries to run G4 with
> > CONFIG_NOT_COHERENT_CACHE. This was done before and I don't remember
> > that those people had to implement anything as complex as you are
> > trying to do.
> >
> > You can try asking on #mklinux. It always better to ask people who
> > actually _did_ this :).
> >
> > In fact, I just grepped 2.6 and found
> > #ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
> > systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
>
> I think some folks tried ... and failed.
>
> Ben.
I'm not claiming to understand all of the issues here, but I have some
MV64460 / MPC7448-based systems, and they only boot if
CONFIG_NOT_COHERENT_CACHE=y
- Brent
^ permalink raw reply
* kernel access of bad area, sig: 11 ( mpc852t)
From: Akshay Mishra @ 2006-04-21 15:10 UTC (permalink / raw)
To: linuxppc-embedded, kpoole
What processor frequency do you use ? The EP board for 852T uses 10
MHz OSCM and CLKIN. We were trying 66 MHz earlier and 25Mhz after
that. But never got any results. The hardware is clean afaik. and the
memory timing is more critical on the MPC8280 on the same board and it
works very well.
We tried changing the clock source to oscillator/crystal and slowing
the clockout to the SDRAM to verify if memory access were a problem.
But no result there too.
The kernel we have is 2.4.21. Will migrating to 2.6 make lives any better ?
Best,
Akshay
----------Quoting Kenneth
We have been experiencing this same issue with random boards in
production. The exact same version of software will run for months on
other instances of the exact same board design, but a few percent get
'random' trap 300s. When they do occur, it's only after Linux has booted
and address translation and caching are turned on. Examining the oops-es
and memory shows that some location in SDRAM has a bogus value, but I
don't have the tools to trace back how it got that way.
I have ported a rigorous moving-inversions memory test into our
firmware, and have run it extensively across the entire SDRAM address
space (the test code executes from flash). I have let this test run
continuously for hours and hours, but never found a memory problem.
Unfortunately, I do not have test software that enables the MMU address
translation or caching, so as Mark said, I can't test memory using
bursting. Our hardware engineers have reviewed the designs very
carefully and are quite confident that there is plenty of margin in the
memory timing. Signal quality has also been carefully checked.
Our manufacturing people have replaced the CPU on some of these boards,
and the problem went away.
If anyone else on the mailing list has experienced this issue, or has
developed a virtual address memory test, please let us know.
Ken Poole
^ permalink raw reply
* Re: [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: Geoff Levand @ 2006-04-21 15:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17480.5183.958036.533453@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Geoff Levand writes:
>
>> The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
>
> Ummm... why? If procps is assuming that the page size of the kernel
> it's running on is the same as the page size of the kernel it was
> compiled on, it's broken. It should be using sysconf(PAGE_SIZE) at
> runtime.
As it turned out, the procps was out of date, and getting the latest
solved the problem. Sorry for the trouble.
-Geoff
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: avoid crash in PCI code if mem system not up.
From: Linas Vepstas @ 2006-04-21 16:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, johnrose, linux-kernel
In-Reply-To: <17480.51661.41707.53706@cargo.ozlabs.ibm.com>
On Fri, Apr 21, 2006 at 10:02:21PM +1000, Paul Mackerras wrote:
> Linas Vepstas writes:
>
> > Please apply and forward upstream. And a question: once
> > upon a time, the arch PCI subsystem was inited after mem init
> > was done; currently, it seems to be happening before mem init.
> > Is this intentional?
>
> No, and it is bogus if it is. Do you have the full backtrace from the
> crash?
Yes, below.
The relevant bits are this:
start_kernel() {
setup_arch() {
pSeries_setup_arch () {
eeh_init () {
... if err kmalloc()
crash.
}
}
}
mem_init()
// are there other appropriate arch init points
// ater mem_init() where we can do arch-dependent
// i/o bridge initialization ??
}
I also remember there being some nastiness re kmalloc
when initializing dlpar/hot-plug PCI slots before
mem_init was done. Basically, if the hotplug slots
are present at boot time, we can't use kmalloc/kfree
to manage them.
If the arch dependent I/O bridges/subsystem init could
be moved later, maybe this could be fixed as well.
--linas
Linux zImage starting: loaded at 0x00010000-0x00849cbc
(0x0/0x0/0x00c39a48; sp: 0x0181ffd0)
uncompressing ELF header done. (0x00000100 bytes)
Allocated 0x009f9020 bytes for kernel @ 0x02000000
Allocated 0x005f389c bytes for initrd @ 0x029fa000
uncompressing kernel done. (0x0063d538 bytes)
entering kernel at 0x02010000(29fa000/5f389c/00c39a48)
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line:
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000002fee000
alloc_top : 0000000010000000
alloc_top_hi : 00000003b0000000
rmo_top : 0000000010000000
ram_top : 00000003b0000000
Looking for displays
instantiating rtas at 0x000000000f702000 ...RTAS Code version:
bPF060322
rtas_ram_size = 5a1000
fixed_base_addr = f702000
code_base_addr = f99f000
done
0000000000000000 : boot cpu 0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000004 : starting cpu hw idx 0000000000000004... done
0000000000000006 : starting cpu hw idx 0000000000000006... done
0000000000000008 : starting cpu hw idx 0000000000000008... done
000000000000000a : starting cpu hw idx 000000000000000a... done
000000000000000c : starting cpu hw idx 000000000000000c... done
000000000000000e : starting cpu hw idx 000000000000000e... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000002fef000 -> 0x0000000002ff0428
Device tree struct 0x0000000002ff1000 -> 0x000000000300a000
Calling quiesce ...
returning from prom_init
Page orders: linear mapping = 24, others = 12
Found initrd at 0xc0000000029fa000:0xc000000002fed89c
cpu 0x0: Vector: 300 (Data Access) at [c0000000004434d0]
pc: c0000000000c06b4: .kmem_cache_alloc+0x8c/0xf4
lr: c00000000004ad6c: .eeh_send_failure_event+0x48/0xfc
sp: c000000000443750
msr: 8000000000001032
dar: 0
dsisr: 40000000
current = 0xc00000000048e660
paca = 0xc00000000048ee80
pid = 0, comm = swapper
enter ? for help
[c0000000004437e0] c00000000004ad6c .eeh_send_failure_event+0x48/0xfc
[c000000000443880] c000000000049dfc .eeh_dn_check_failure+0x250/0x2a8
[c000000000443930] c00000000001da6c .rtas_read_config+0x100/0x13c
[c0000000004439d0] c0000000000497a8 .early_enable_eeh+0x25c/0x2ac
[c000000000443a90] c00000000002ba4c .traverse_pci_devices+0x84/0x100
[c000000000443b30] c00000000041ae7c .eeh_init+0x1a8/0x204
[c000000000443bd0] c00000000041a308 .pSeries_setup_arch+0x1e8/0x2b8
[c000000000443e60] c00000000040a6a0 .setup_arch+0x20c/0x25c
[c000000000443ef0] c00000000040252c .start_kernel+0x40/0x288
[c000000000443f90] c000000000008594 .start_here_common+0x88/0x8c
^ permalink raw reply
* Choices of 2.4 Kernel for PPC
From: Stephen Williams @ 2006-04-21 16:32 UTC (permalink / raw)
To: linuxppc-embedded
I'd been using the BK tree (I know, old old) but it's been stable
for me for a while. But I'm starting to see so problems and I want
to work with a recent kernel tree. I'm using a PPC405GPr processor.
I downloaded the linux-2.4.32 tree from kernel.org, but it has
none of the Xilinx stuff so I immediately wonder about other things
it lacks for embedded PPC.
I downloaded the linux 2.4 .git tree from Denx, but the makefile
in top says it's based on 2.4.25, which is even older then what
I've got now.
I've looked on the penguinppc.org page, but it points me back
to the kernel.org distribution and possibly the bk repository.
Hmm...
So what tree is most universally accepted as current so far as
embedded PPC goes? And can the penguinppc.org pages be updated
to reflect the consensus?
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Wolfgang Denk @ 2006-04-21 16:55 UTC (permalink / raw)
To: Tolunay Orkun; +Cc: White, linuxppc-embedded
In-Reply-To: <44485B3F.8080308@orkun.us>
In message <44485B3F.8080308@orkun.us> you wrote:
>
> If your bootloader is U-Boot and you are using standard bootm command to
> boot, U-Boot decompresses the initrd image to RAM before passing the
> file system to Linux. So, you are not working with flash copy and
> updating the flash copy is not a problem at all. This applies to ext2,
> cramfs or squashfs based initrd.
But it makes no sense to use cramfs or squashfs on a ramdisk.
You *want* to run these directly from flash.
But then, of course, you need alternate images (or other tricks)
for full image updates.
[Single file updates can be done using overlay file systems; see the
DULG for details.]
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
Just about every computer on the market today runs Unix, except the
Mac (and nobody cares about it). - Bill Joy 6/21/85
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Wolfgang Denk @ 2006-04-21 16:57 UTC (permalink / raw)
To: antonio.dibacco; +Cc: White, linuxppc-embedded
In-Reply-To: <20060421055142.11025.qmail@mx1.aruba.it>
In message <20060421055142.11025.qmail@mx1.aruba.it> you wrote:
> No, I have a cramfs on flash and the kernel uses it directly from flash,
> extracting what it needs to execute. I'm not using initrd then, I have to
> update in situ, while running.
This cannot be done reliably. You have to make the file system idle,
i. e. unmount it.
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
Change is the essential process of all existence.
-- Spock, "Let That Be Your Last Battlefield",
stardate 5730.2
^ permalink raw reply
* Re: [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: Christoph Hellwig @ 2006-04-21 17:03 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4447C3BA.6050709@am.sony.com>
On Thu, Apr 20, 2006 at 10:24:10AM -0700, Geoff Levand wrote:
> The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
> but it is defined inside "#ifdef __KERNEL__".
>
> This moves the PAGE_SIZE definition outside of "#ifdef __KERNEL__".
NACK.
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Wolfgang Denk @ 2006-04-21 20:23 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604210853.32860.david.jander@protonic.nl>
In message <200604210853.32860.david.jander@protonic.nl> you wrote:
>
> What do you mean with "something bad could happen"?
System crashes.
> The only thing I can think of is pulling the power plug while flash is being
> erased or written. What else could go wrong?
The kernel may try to (re-) load some pages of a running executable
or library which is no longer available (at least not at the
addresses where they used to be). The kernel will either stumble over
what it believes to be a corrupted file system, or load the wrong
data -> kaboom.
> We do the following: system running from read-only jffs2 partition. Sometimes
> that partition is remounted read-write and single files are replaced, but in
> some occasions we need to upgrade the whole fs. In that case a CGI lodas the
> image into a ramdisk, and the upgrade process is started. For upgrade,
You *have* to unmount the old file system here.
> partition, and then "dd" again to copy the image. At that point no critical
> flash-read access should be requested since dd is already in cache (it's
The kernel might reload any page of any running executable or library.
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
"Logic and practical information do not seem to apply here."
"You admit that?"
"To deny the facts would be illogical, Doctor"
-- Spock and McCoy, "A Piece of the Action", stardate unknown
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Antonio Di Bacco @ 2006-04-21 21:32 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: David Jander
In-Reply-To: <20060421202308.D508F3526B7@atlas.denx.de>
Little bit off topic:
I decided to adopt a different strategy, the sw download web page will contain
a java applet that will act as a tftp server, then the board will be rebooted
and an environment variable will instruct the u-boot to tftp the new software
from the applet. What do you think? I know that applets cannot read local
files on the PC, unless they have a valid certificate but the user should
trust me.
Bye,
Antonio.
On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
> > What do you mean with "something bad could happen"?
>
> System crashes.
>
> > The only thing I can think of is pulling the power plug while flash is
> > being erased or written. What else could go wrong?
>
> The kernel may try to (re-) load some pages of a running executable
> or library which is no longer available (at least not at the
> addresses where they used to be). The kernel will either stumble over
> what it believes to be a corrupted file system, or load the wrong
> data -> kaboom.
>
> > We do the following: system running from read-only jffs2 partition.
> > Sometimes that partition is remounted read-write and single files are
> > replaced, but in some occasions we need to upgrade the whole fs. In that
> > case a CGI lodas the image into a ramdisk, and the upgrade process is
> > started. For upgrade,
>
> You *have* to unmount the old file system here.
>
> > partition, and then "dd" again to copy the image. At that point no
> > critical flash-read access should be requested since dd is already in
> > cache (it's
>
> The kernel might reload any page of any running executable or library.
>
> Best regards,
>
> Wolfgang Denk
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-21 21:51 UTC (permalink / raw)
To: Brent Cook; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <200604210933.10888.bcook@bpointsys.com>
> not claiming to understand all of the issues here, but I have some
> MV64460 / MPC7448-based systems, and they only boot if
> CONFIG_NOT_COHERENT_CACHE=y
That is strange... Pegasos uses a Marvell bridge and it works with
coherent cache. Do you have some kernel patches in addition to what is
in mainstream to make CONFIG_NOT_COHERENT_CACHE work at all on
CONFIG_6xx ? At the moment, it doesn't do much ...
Ben.
^ permalink raw reply
* [PATCH 1/2]: Spider ethernet driver spinlocks
From: Linas Vepstas @ 2006-04-21 23:29 UTC (permalink / raw)
To: utz.bacher, Arnd Bergmann; +Cc: Maxim Shchetynin, linux-kernel, linuxppc-dev
Please review/apply/ack/forward upstream.
--linas
The spider network driver currently uses hand-rolled spinlocks
in a few places. Replace these with industry standard spinlocks.
In particular, this should add some safety if multiple threads
are touching the tx and rx chain pointers.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/spider_net.c | 18 ++++++++----------
drivers/net/spider_net.h | 4 ++--
2 files changed, 10 insertions(+), 12 deletions(-)
Index: linux-2.6.17-rc1/drivers/net/spider_net.c
===================================================================
--- linux-2.6.17-rc1.orig/drivers/net/spider_net.c 2006-04-20 17:22:04.000000000 -0500
+++ linux-2.6.17-rc1/drivers/net/spider_net.c 2006-04-21 11:52:39.000000000 -0500
@@ -335,8 +335,6 @@ spider_net_init_chain(struct spider_net_
struct spider_net_descr *descr;
dma_addr_t buf;
- atomic_set(&card->rx_chain_refill,0);
-
descr = start_descr;
memset(descr, 0, sizeof(*descr) * no);
@@ -509,15 +507,15 @@ spider_net_refill_rx_chain(struct spider
* and omitting it) is ok. If called by NAPI, we'll be called again
* as spider_net_decode_one_descr is called several times. If some
* interrupt calls us, the NAPI is about to clean up anyway. */
- if (atomic_inc_return(&card->rx_chain_refill) == 1)
+ if (spin_trylock(&card->rx_chain_lock)) {
while (spider_net_get_descr_status(chain->head) ==
SPIDER_NET_DESCR_NOT_IN_USE) {
if (spider_net_prepare_rx_descr(card, chain->head))
break;
chain->head = chain->head->next;
}
-
- atomic_dec(&card->rx_chain_refill);
+ spin_unlock(&card->rx_chain_lock);
+ }
}
/**
@@ -596,10 +594,8 @@ spider_net_release_tx_chain(struct spide
struct spider_net_descr_chain *tx_chain = &card->tx_chain;
enum spider_net_descr_status status;
- if (atomic_inc_return(&card->tx_chain_release) != 1) {
- atomic_dec(&card->tx_chain_release);
+ if (!spin_trylock(&card->tx_chain_lock))
return 1;
- }
for (;;) {
status = spider_net_get_descr_status(tx_chain->tail);
@@ -633,7 +629,7 @@ spider_net_release_tx_chain(struct spide
tx_chain->tail = tx_chain->tail->next;
}
out:
- atomic_dec(&card->tx_chain_release);
+ spin_unlock(&card->tx_chain_lock);
netif_wake_queue(card->netdev);
@@ -2072,7 +2068,9 @@ spider_net_setup_netdev(struct spider_ne
pci_set_drvdata(card->pdev, netdev);
- atomic_set(&card->tx_chain_release,0);
+ spin_lock_init(&card->rx_chain_lock);
+ spin_lock_init(&card->tx_chain_lock);
+
card->rxram_full_tl.data = (unsigned long) card;
card->rxram_full_tl.func =
(void (*)(unsigned long)) spider_net_handle_rxram_full;
Index: linux-2.6.17-rc1/drivers/net/spider_net.h
===================================================================
--- linux-2.6.17-rc1.orig/drivers/net/spider_net.h 2006-04-20 17:22:04.000000000 -0500
+++ linux-2.6.17-rc1/drivers/net/spider_net.h 2006-04-21 11:47:17.000000000 -0500
@@ -451,8 +451,8 @@ struct spider_net_card {
struct spider_net_descr_chain tx_chain;
struct spider_net_descr_chain rx_chain;
- atomic_t rx_chain_refill;
- atomic_t tx_chain_release;
+ spinlock_t rx_chain_lock;
+ spinlock_t tx_chain_lock;
struct net_device_stats netdev_stats;
^ permalink raw reply
* [PATCH 2/2]: Spider ethernet driver -- protect chain head
From: Linas Vepstas @ 2006-04-21 23:45 UTC (permalink / raw)
To: utz.bacher, Arnd Bergmann; +Cc: Maxim Shchetynin, linuxppc-dev, linux-kernel
In-Reply-To: <20060421232942.GG7242@austin.ibm.com>
Please review/apply/ack/forward upstream.
--linas
Prevent a potential race. If two threads are both calling
the transmit routine, both can potentially try to grab the
same dma descriptor. Serialize access to the head of the
tx ring with spinlocks.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/spider_net.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
Index: linux-2.6.17-rc1/drivers/net/spider_net.c
===================================================================
--- linux-2.6.17-rc1.orig/drivers/net/spider_net.c 2006-04-21 18:32:46.000000000 -0500
+++ linux-2.6.17-rc1/drivers/net/spider_net.c 2006-04-21 18:39:12.000000000 -0500
@@ -806,13 +806,19 @@ spider_net_stop(struct net_device *netde
static struct spider_net_descr *
spider_net_get_next_tx_descr(struct spider_net_card *card)
{
+ struct spider_net_descr *descr;
+ spin_lock(&card->tx_chain_lock);
+
+ descr = card->tx_chain.head;
/* check, if head points to not-in-use descr */
if ( spider_net_get_descr_status(card->tx_chain.head) ==
SPIDER_NET_DESCR_NOT_IN_USE ) {
- return card->tx_chain.head;
+ card->tx_chain.head = descr->next;
} else {
- return NULL;
+ descr = NULL;
}
+ spin_unlock(&card->tx_chain_lock);
+ return descr;
}
/**
@@ -932,8 +938,6 @@ spider_net_xmit(struct sk_buff *skb, str
if (result)
goto error;
- card->tx_chain.head = card->tx_chain.head->next;
-
if (spider_net_get_descr_status(descr->prev) !=
SPIDER_NET_DESCR_CARDOWNED) {
/* make sure the current descriptor is in memory. Then
^ permalink raw reply
* Re: [PATCH 2/2]: Spider ethernet driver -- protect chain head
From: Eugene Surovegin @ 2006-04-22 0:11 UTC (permalink / raw)
To: Linas Vepstas; +Cc: Maxim Shchetynin, Arnd Bergmann, linux-kernel, linuxppc-dev
In-Reply-To: <20060421234551.GI7242@austin.ibm.com>
On Fri, Apr 21, 2006 at 06:45:51PM -0500, Linas Vepstas wrote:
> Prevent a potential race. If two threads are both calling
> the transmit routine, both can potentially try to grab the
> same dma descriptor. Serialize access to the head of the
> tx ring with spinlocks.
Two threads cannot be in spider_net_xmit() simultaneosuly because
hard_start_xmit entry point is already protected by net_device
xmit_lock, see Documentation/net/netdevices.txt
--
Eugene
^ 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