* Re: kernel 2.6.15: cpm_uart driver broken?
From: David Jander @ 2006-04-18 14:05 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060418172244.25eefcd3@vitb.ru.mvista.com>
On Tuesday 18 April 2006 15:22, Vitaly Bordug wrote:
>[..]
> Well, existing code works just fine on 885ads and 866ads, that use SMC1 and
> SMC2 as UARTs.
Interesting.
> > I'm pretty sure the following is wrong, but I can't seem to fix it
> > either. This seems to apply for both PQ and PQ2 type uarts:
> > from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190):
>
> That's wrong - cpm_uart_cpm1.c applies to PQ only...
I know. cpm_uart_cpm2.c contains the same code, so it should be as broken as
the cpm_uart_cpm1.c.
>[...]
> Well, since it works on other boards, and kmalloc stuff seems to sorta work
> as well, then I guess reason is screwed DMA thing for your board.
> Check/alter CONFIG_CONSISTENT_* things and see if it will help.
I did not touch de defaults. What are the rules to change them? What do I have
to look out for?
CONFIG_CONSISTENT_START = 0xff100000 and I suspect a problem here if I was
using MTD (currently disabled) since flash is at physical adress
0xfe000000-0xffffffff on my board. Isn't MTD going to io_remap that area to
that same virtual adress? How's that supposed to work then?
I changed CONFIG_CONSISTENT_START to 0xfd100000 and now the system freezes
when I write to the serial port :-(
> And, try to just replace dma_alloc_.. with kmalloc (not changing rx_buf
> etc.) and reproduce the same behavior you had. BTW, rx_buf and tx_buf are
> never used actually in the code, hereby there is no difference what values
> they contain...
Argh. Code looks obviously broken, but since it isn't used, it just works.
That is not good! We should fix that either way then.
Thanks,
--
David Jander
^ permalink raw reply
* scc in hdlc mode linux-2.4 device driver for MPC8247
From: Nethi venkata Subbarao @ 2006-04-18 14:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am new to embedded systems software and planning
to write a scc device driver for MPC8247 processor. It
will be very useful if someone can provide me sample
scc driver code for MPC8247. currently using denk's
linuxppc-2.4.20. I had written test driver but it was
hanging SMC1 console.
Thanks in advance
nethi.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: Vitaly Bordug @ 2006-04-18 14:21 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604181605.40642.david.jander@protonic.nl>
On Tue, 18 Apr 2006 16:05:40 +0200
David Jander <david.jander@protonic.nl> wrote:
> On Tuesday 18 April 2006 15:22, Vitaly Bordug wrote:
> >[..]
> > Well, existing code works just fine on 885ads and 866ads, that use SMC1 and
> > SMC2 as UARTs.
>
> Interesting.
>
And for PQ2 I can add 8260 , PQ2fads and 8272ads that had no issues with current driver
> > > I'm pretty sure the following is wrong, but I can't seem to fix it
> > > either. This seems to apply for both PQ and PQ2 type uarts:
> > > from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190):
> >
> > That's wrong - cpm_uart_cpm1.c applies to PQ only...
>
> I know. cpm_uart_cpm2.c contains the same code, so it should be as broken as
> the cpm_uart_cpm1.c.
pq2 are cache-coherent, so there are no such troubles in there. And allocation routine is different of course.
>
> >[...]
> > Well, since it works on other boards, and kmalloc stuff seems to sorta work
> > as well, then I guess reason is screwed DMA thing for your board.
> > Check/alter CONFIG_CONSISTENT_* things and see if it will help.
>
> I did not touch de defaults. What are the rules to change them? What do I have
> to look out for?
> CONFIG_CONSISTENT_START = 0xff100000 and I suspect a problem here if I was
> using MTD (currently disabled) since flash is at physical adress
> 0xfe000000-0xffffffff on my board. Isn't MTD going to io_remap that area to
> that same virtual adress? How's that supposed to work then?
> I changed CONFIG_CONSISTENT_START to 0xfd100000 and now the system freezes
> when I write to the serial port :-(
>
Unfortunately, I know nothing where the correct thing should be pulled from...
But the problem lies in dma stuff from what I can say.
> > And, try to just replace dma_alloc_.. with kmalloc (not changing rx_buf
> > etc.) and reproduce the same behavior you had. BTW, rx_buf and tx_buf are
> > never used actually in the code, hereby there is no difference what values
> > they contain...
>
> Argh. Code looks obviously broken, but since it isn't used, it just works.
> That is not good! We should fix that either way then.
The overhaul is on the way, I'll put the cleanup of the unused stuff together with other changes.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-18 14:56 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev list, Michael Schmitz, debian-powerpc, Becky Bruce
In-Reply-To: <17476.34830.897083.360572@cargo.ozlabs.ibm.com>
On Tue, Apr 18, 2006 at 04:32:46PM +1000, Paul Mackerras wrote:
> > understand now why you were talking about putting the code in the exit
> > path on irc ... I don't like it that way.... Also, if you want to keep
> > it, maybe use a separate CONFIG_PPC_970STYLE_NAP or something that gets
> > selected by platforms that can do it ?
>
> The config option makes sense.
How about a CPU feature bit instead? That way it's possible to build a
multiplatform kernel without getting the overhead on other platforms.
4 nops should be manageable?
-Olof
^ permalink raw reply
* MCC 8260 problem
From: Abas Javadtalab @ 2006-04-18 15:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: gianfranco.morandi
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi
I have downloaded mcc source code from Source forge site. However, this source unable to execute because the Rules.make file is not found. in addition it seems that this package is incomplete source It would be glad for me if you help me about it.
Best regards
Abbas
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
[-- Attachment #2: Type: text/html, Size: 926 bytes --]
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-18 16:03 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev list, Michael Schmitz, debian-powerpc,
Paul Mackerras, Becky Bruce
In-Reply-To: <20060418145600.GE20234@pb15.lixom.net>
On Tue, Apr 18, 2006 at 09:56:00AM -0500, Olof Johansson wrote:
> On Tue, Apr 18, 2006 at 04:32:46PM +1000, Paul Mackerras wrote:
>
> > > understand now why you were talking about putting the code in the exit
> > > path on irc ... I don't like it that way.... Also, if you want to keep
> > > it, maybe use a separate CONFIG_PPC_970STYLE_NAP or something that gets
> > > selected by platforms that can do it ?
> >
> > The config option makes sense.
>
> How about a CPU feature bit instead? That way it's possible to build a
> multiplatform kernel without getting the overhead on other platforms.
> 4 nops should be manageable?
DOH! I'm going blind, that's already there. So, Ben, you're unhappy
with nopping it out?
-Olof
^ permalink raw reply
* [PATCH] Remove stale iseries global
From: Olof Johansson @ 2006-04-18 16:25 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev, paulus
Hi,
Not even the iSeries maintainer seems to have access to this legendary
piranha simulator. It adds a bit of ugliness in the common time init
code, and if it's no longer used we might as well be done with it and
remove the bloat.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6/arch/powerpc/kernel/time.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/time.c
+++ 2.6/arch/powerpc/kernel/time.c
@@ -76,7 +76,6 @@
/* keep track of when we need to update the rtc */
time_t last_rtc_update;
-extern int piranha_simulator;
#ifdef CONFIG_PPC_ISERIES
unsigned long iSeries_recal_titan = 0;
unsigned long iSeries_recal_tb = 0;
@@ -1010,10 +1009,7 @@ void __init time_init(void)
tb_to_ns_scale = scale;
tb_to_ns_shift = shift;
-#ifdef CONFIG_PPC_ISERIES
- if (!piranha_simulator)
-#endif
- tm = get_boot_time();
+ tm = get_boot_time();
write_seqlock_irqsave(&xtime_lock, flags);
Index: 2.6/arch/powerpc/platforms/iseries/mf.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/iseries/mf.c
+++ 2.6/arch/powerpc/platforms/iseries/mf.c
@@ -45,7 +45,6 @@
#include "setup.h"
-extern int piranha_simulator;
static int mf_initialized;
/*
@@ -658,7 +657,7 @@ static void mf_clear_src(void)
void __init mf_display_progress(u16 value)
{
- if (piranha_simulator || !mf_initialized)
+ if (!mf_initialized)
return;
if (0xFFFF == value)
@@ -1295,9 +1294,6 @@ __initcall(mf_proc_init);
*/
void iSeries_get_rtc_time(struct rtc_time *rtc_tm)
{
- if (piranha_simulator)
- return;
-
mf_get_rtc(rtc_tm);
rtc_tm->tm_mon--;
}
@@ -1316,9 +1312,6 @@ unsigned long iSeries_get_boot_time(void
{
struct rtc_time tm;
- if (piranha_simulator)
- return 0;
-
mf_get_boot_rtc(&tm);
return mktime(tm.tm_year + 1900, tm.tm_mon, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec);
Index: 2.6/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/iseries/setup.c
+++ 2.6/arch/powerpc/platforms/iseries/setup.c
@@ -80,9 +80,6 @@ extern void iSeries_pci_final_fixup(void
static void iSeries_pci_final_fixup(void) { }
#endif
-/* Global Variables */
-int piranha_simulator;
-
extern int rd_size; /* Defined in drivers/block/rd.c */
extern unsigned long embedded_sysmap_start;
extern unsigned long embedded_sysmap_end;
@@ -339,8 +336,6 @@ static void __init iSeries_init_early(vo
#ifdef CONFIG_SMP
smp_init_iSeries();
#endif
- if (itLpNaca.xPirEnvironMode == 0)
- piranha_simulator = 1;
/* Associate Lp Event Queue 0 with processor 0 */
HvCallEvent_setLpEventQueueInterruptProc(0, 0);
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jon Loeliger @ 2006-04-18 16:48 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev@ozlabs.org, Michael Neuling
In-Reply-To: <1144938844.7777.16.camel@localhost.localdomain>
On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
> On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
> > Actually, is this even an issue? can the LMB handle repeated
> > reservations?
>
> It can, but we were thinking about adding code to check and warn if
> reservations overlap, because it usually indicates a bug. Although
> that's probably ok in this case, as long as dtc gets fixed eventually.
> Another option would be to not warn for identical reservations.
> > >>>>> NOTE: that the dtc must also not generate the blob reservation
> > >>>>> entry.
> > >> looking passed my own world I see:
> > >> - iSeries: not reserving the blob at all
> > >
> > > That sounds right. I think having the kernel do it is definitely the
> > > right option.
OK, I'm back to reading the list and beginning to catch
up some here...
Let me see if I understand the consensus and direction:
1) DTC should NOT reserve its own blob space in the
memory map, as it does for generated ASM code now,
2) Kernel should reserve the blob space early so as
not to step on itself later,
3a) Kernel LMB handling should be modified to warn
for overlapping LMB reservations,
Except that Ben says:
3b) We should make lmb_reserve() of redudant/overlapping
entries become harmless I think. We need to be
backward compatible with earlier blobs that do
contain themselves in the reserve map.
I think we should interpret "harmless" to be "warn" and not
cause an error at this point in time.
I do not think we should have the blob generate its own
reservation because it is possible that some post-processing
(like U-Boot) can modify and extend it. Only after that can
the blob's true size be determined. (Sure, it could update
on the fly too... but double blah).
In all of this, I'm on deck for step 1) above.
jdl
^ permalink raw reply
* Re: [PATCH] Remove stale iseries global
From: Will Schmidt @ 2006-04-18 17:31 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060418162553.GC26746@pb15.lixom.net>
On Tue, 2006-04-18 at 11:25 -0500, Olof Johansson wrote:
> Hi,
>
> Not even the iSeries maintainer seems to have access to this legendary
> piranha simulator. It adds a bit of ugliness in the common time init
> code, and if it's no longer used we might as well be done with it and
> remove the bloat.
>
Yes, the piranha tools are no longer used with linux. I see no reason
why this needs to stay.
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
Acked-by: Will Schmidt willschm@us.ibm.com
^ permalink raw reply
* Re: [PATCH] Remove stale iseries global
From: Michael Ellerman @ 2006-04-18 17:54 UTC (permalink / raw)
To: will_schmidt; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <1145381474.20493.5.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Tue, 2006-04-18 at 12:31 -0500, Will Schmidt wrote:
> On Tue, 2006-04-18 at 11:25 -0500, Olof Johansson wrote:
> > Hi,
> >
> > Not even the iSeries maintainer seems to have access to this legendary
> > piranha simulator. It adds a bit of ugliness in the common time init
> > code, and if it's no longer used we might as well be done with it and
> > remove the bloat.
>
> Yes, the piranha tools are no longer used with linux. I see no reason
> why this needs to stay.
So can we get rid of this from head_64.S as well? Or is that a different
debugger?
/*
* At offset 0x28 and 0x30 are offsets to the mschunks_map
* array (used by the iSeries LPAR debugger to do translation
* between physical addresses and absolute addresses) and
* to the pidhash table (also used by the debugger)
*/
.llong mschunks_map-KERNELBASE
.llong 0 /* pidhash-KERNELBASE SFRXXX */
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Michael Ellerman @ 2006-04-18 18:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Michael Neuling
In-Reply-To: <1145378886.5314.57.camel@cashmere.sps.mot.com>
[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]
On Tue, 2006-04-18 at 11:48 -0500, Jon Loeliger wrote:
> On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
> > On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
> > > Actually, is this even an issue? can the LMB handle repeated
> > > reservations?
> >
> > It can, but we were thinking about adding code to check and warn if
> > reservations overlap, because it usually indicates a bug. Although
> > that's probably ok in this case, as long as dtc gets fixed eventually.
> > Another option would be to not warn for identical reservations.
>
> > > >>>>> NOTE: that the dtc must also not generate the blob reservation
> > > >>>>> entry.
>
> > > >> looking passed my own world I see:
> > > >> - iSeries: not reserving the blob at all
> > > >
> > > > That sounds right. I think having the kernel do it is definitely the
> > > > right option.
>
>
> OK, I'm back to reading the list and beginning to catch
> up some here...
>
> Let me see if I understand the consensus and direction:
>
> 1) DTC should NOT reserve its own blob space in the
> memory map, as it does for generated ASM code now,
>
> 2) Kernel should reserve the blob space early so as
> not to step on itself later,
>
> 3a) Kernel LMB handling should be modified to warn
> for overlapping LMB reservations,
>
> Except that Ben says:
>
> 3b) We should make lmb_reserve() of redudant/overlapping
> entries become harmless I think. We need to be
> backward compatible with earlier blobs that do
> contain themselves in the reserve map.
>
> I think we should interpret "harmless" to be "warn" and not
> cause an error at this point in time.
>
> I do not think we should have the blob generate its own
> reservation because it is possible that some post-processing
> (like U-Boot) can modify and extend it. Only after that can
> the blob's true size be determined. (Sure, it could update
> on the fly too... but double blah).
>
> In all of this, I'm on deck for step 1) above.
Nice summary :)
I'm up for 3a, we should make redundant/overlapping reserves "harmless",
by which I mean "not an error", but there should definitely be a warning
in the dmesg - as it will _usually_ indicate a bug.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Andy Fleming @ 2006-04-18 18:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev Development
In-Reply-To: <17476.55180.340464.351828@cargo.ozlabs.ibm.com>
On Apr 18, 2006, at 07:11, Paul Mackerras wrote:
> Linus,
>
> Please do a pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
>
> to get the following powerpc bug-fixes.
What happened to the 85xx merge patches?
^ permalink raw reply
* [PATCH] powerpc: Make rtas console _much_ faster
From: Michael Ellerman @ 2006-04-18 18:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
Currently the hvc_rtas driver is painfully slow to use. Our "benchmark" is
ls -R /etc, which spits out about 27866 characters. The theoretical maximum
speed would be about 2.2 seconds, the current code takes ~50 seconds.
The core of the problem is that sometimes when the tty layer asks us to push
characters the firmware isn't able to handle some or all of them, and so
returns an error. The current code sees this and just returns to the tty code
with the buffer half sent.
There's the khvcd thread which will eventually wake up and try to push more
characters, that will usually work because the firmware's had time to push
the characters out. But the thread only wakes up every 10 milliseconds, which
isn't fast enough.
There's already code in the hvc_console driver to make the khvcd thread do
a "quick" loop, where it just calls yield() instead of sleeping. The only code
that triggered that behaviour was recently removed though, which I don't
quite understand.
Still, if we set HVC_POLL_QUICK whenever the push hvc_push() doesn't push all
characters (ie. RTAS blocks), we can get good performance out of the hvc_rtas
backend. With this patch the "benchmark" takes ~2.8 seconds.
I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
Thoughts?
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
drivers/char/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: cell/drivers/char/hvc_console.c
===================================================================
--- cell.orig/drivers/char/hvc_console.c
+++ cell/drivers/char/hvc_console.c
@@ -570,7 +570,7 @@ static int hvc_poll(struct hvc_struct *h
hvc_push(hp);
/* Reschedule us if still some write pending */
if (hp->n_outbuf > 0)
- poll_mask |= HVC_POLL_WRITE;
+ poll_mask |= HVC_POLL_WRITE | HVC_POLL_QUICK;
/* No tty attached, just skip */
tty = hp->tty;
^ permalink raw reply
* kernel 2.6.15: cpm_uart driver broken?
From: Kenneth Poole @ 2006-04-18 19:19 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]
For David Jander and Vitaly Bordug:
Regarding DMA allocation for CPM uarts, we had a similar issue with our
MPC857T and MPC885 boards. I think the real problem is that
bus_to_virt() and virt_to_bus() don't work on 8xx platforms for
addresses allocated using dma_alloc_coherent(). We had a previous
discussion Pantelis Antoniou and he agreed that the use of bus_to_virt()
and virt_to_bus() should be deprecated. This is also recommended in the
whitepaper series that discussed porting device drivers from 2.4 to 2.6.
What we did was use dma_alloc_coherent() in cpm_uart_cpm1.c, saving
dma_addr in the pinfo structure. The in cpm_uart_core.c, we use dma_addr
as the base address for the cbd_bufaddr values in each of the
descriptors. The software, when accessing the DMA buffers, uses mem_addr
as the base, applying the same offset computed previously for the dma
addresses. This technique is used in other drivers all over 2.6.
This avoids the configuration dependencies on the conversion functions.
Ken Poole
kpoole@bos.mrv.com
[-- Attachment #2: Type: text/html, Size: 5214 bytes --]
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jimi Xenidis @ 2006-04-18 18:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev@ozlabs.org, Michael Neuling
In-Reply-To: <1145383451.20176.9.camel@localhost.localdomain>
ok, to accept (1) means to accept (2).
AFAICT LMB is already handling overlaps.
So the first rough patch I sent should be sufficient.
On Apr 18, 2006, at 2:04 PM, Michael Ellerman wrote:
> On Tue, 2006-04-18 at 11:48 -0500, Jon Loeliger wrote:
>> On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
>>> On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
>>>> Actually, is this even an issue? can the LMB handle repeated
>>>> reservations?
>>>
>>> It can, but we were thinking about adding code to check and warn if
>>> reservations overlap, because it usually indicates a bug. Although
>>> that's probably ok in this case, as long as dtc gets fixed
>>> eventually.
>>> Another option would be to not warn for identical reservations.
>>
>>>>>>>>> NOTE: that the dtc must also not generate the blob reservation
>>>>>>>>> entry.
>>
>>>>>> looking passed my own world I see:
>>>>>> - iSeries: not reserving the blob at all
>>>>>
>>>>> That sounds right. I think having the kernel do it is
>>>>> definitely the
>>>>> right option.
>>
>>
>> OK, I'm back to reading the list and beginning to catch
>> up some here...
>>
>> Let me see if I understand the consensus and direction:
>>
>> 1) DTC should NOT reserve its own blob space in the
>> memory map, as it does for generated ASM code now,
>>
>> 2) Kernel should reserve the blob space early so as
>> not to step on itself later,
>>
>> 3a) Kernel LMB handling should be modified to warn
>> for overlapping LMB reservations,
>>
>> Except that Ben says:
>>
>> 3b) We should make lmb_reserve() of redudant/overlapping
>> entries become harmless I think. We need to be
>> backward compatible with earlier blobs that do
>> contain themselves in the reserve map.
>>
>> I think we should interpret "harmless" to be "warn" and not
>> cause an error at this point in time.
>>
>> I do not think we should have the blob generate its own
>> reservation because it is possible that some post-processing
>> (like U-Boot) can modify and extend it. Only after that can
>> the blob's true size be determined. (Sure, it could update
>> on the fly too... but double blah).
>>
>> In all of this, I'm on deck for step 1) above.
>
> Nice summary :)
> I'm up for 3a, we should make redundant/overlapping reserves
> "harmless",
> by which I mean "not an error", but there should definitely be a
> warning
> in the dmesg - as it will _usually_ indicate a bug.
>
> cheers
>
> --
> Michael Ellerman
> IBM OzLabs
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Becky Bruce @ 2006-04-18 19:29 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, schmitz, debian-powerpc
Paul,
This new version of the patch breaks 32-bit arch/ppc builds. The changes
to the idle_6xx code are shared between architectures, but the entry.S
code and asm-offsets.c are not.
Here's a patch that puts the changes in arch/ppc as well. Builds and
boots on 834x (which is CONFIG_6xx).
-B
ppc: Fix powersave on arch/ppc
Fix asm_offsets.c and entry.S to work with the new power save code.
Changes in arch/powerpc needed to exist in arch/ppc as well since the
idle code is shared by both ppc and powerpc..
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
commit c9b42c4b6ad17aea51066604b70ea7ec399d2e45
tree 38642212d6396ecad721efca967ae1fc8924e096
parent c85f35d06479bf7cb5cfc7cda0ea218a23ed2dc4
author Becky Bruce <becky.bruce@freescale.com> Tue, 18 Apr 2006 14:12:03 -0500
committer Becky Bruce <becky.bruce@freescale.com> Tue, 18 Apr 2006 14:12:03 -0500
arch/ppc/kernel/asm-offsets.c | 1 +
arch/ppc/kernel/entry.S | 33 ++++++++++++++++-----------------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/ppc/kernel/asm-offsets.c b/arch/ppc/kernel/asm-offsets.c
index 77e4dc7..cc7c4ae 100644
--- a/arch/ppc/kernel/asm-offsets.c
+++ b/arch/ppc/kernel/asm-offsets.c
@@ -134,6 +134,7 @@ main(void)
DEFINE(TI_TASK, offsetof(struct thread_info, task));
DEFINE(TI_EXECDOMAIN, offsetof(struct thread_info, exec_domain));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
+ DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, flags));
DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
index 5891ecb..1adc914 100644
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -128,29 +128,26 @@ transfer_to_handler:
stw r12,4(r11)
#endif
b 3f
+
2: /* if from kernel, check interrupted DOZE/NAP mode and
* check for stack overflow
*/
+ lwz r9,THREAD_INFO-THREAD(r12)
+ cmplw r1,r9 /* if r1 <= current->thread_info */
+ ble- stack_ovf /* then the kernel stack overflowed */
+5:
#ifdef CONFIG_6xx
- mfspr r11,SPRN_HID0
- mtcr r11
-BEGIN_FTR_SECTION
- bt- 8,4f /* Check DOZE */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
-BEGIN_FTR_SECTION
- bt- 9,4f /* Check NAP */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
+ tophys(r9,r9) /* check local flags */
+ lwz r12,TI_LOCAL_FLAGS(r9)
+ mtcrf 0x01,r12
+ bt- 31-TLF_NAPPING,4f
#endif /* CONFIG_6xx */
.globl transfer_to_handler_cont
transfer_to_handler_cont:
- lwz r11,THREAD_INFO-THREAD(r12)
- cmplw r1,r11 /* if r1 <= current->thread_info */
- ble- stack_ovf /* then the kernel stack overflowed */
3:
mflr r9
lwz r11,0(r9) /* virtual address of handler */
lwz r9,4(r9) /* where to go when done */
- FIX_SRR1(r10,r12)
mtspr SPRN_SRR0,r11
mtspr SPRN_SRR1,r10
mtlr r9
@@ -158,7 +155,9 @@ transfer_to_handler_cont:
RFI /* jump to handler, enable MMU */
#ifdef CONFIG_6xx
-4: b power_save_6xx_restore
+4: rlwinm r12,r12,0,~_TLF_NAPPING
+ stw r12,TI_LOCAL_FLAGS(r9)
+ b power_save_6xx_restore
#endif
/*
@@ -167,10 +166,10 @@ transfer_to_handler_cont:
*/
stack_ovf:
/* sometimes we use a statically-allocated stack, which is OK. */
- lis r11,_end@h
- ori r11,r11,_end@l
- cmplw r1,r11
- ble 3b /* r1 <= &_end is OK */
+ lis r12,_end@h
+ ori r12,r12,_end@l
+ cmplw r1,r12
+ ble 5b /* r1 <= &_end is OK */
SAVE_NVGPRS(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
lis r1,init_thread_union@ha
^ permalink raw reply related
* Re: [PATCH] powerpc: Make rtas console _much_ faster
From: Olof Johansson @ 2006-04-18 19:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <20060418185534.B1ADF679F0@ozlabs.org>
On Tue, Apr 18, 2006 at 08:55:29PM +0200, Michael Ellerman wrote:
> I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
> Thoughts?
I have an out-of-tree HVC backend here for a simple simulator console
(will never make it in-tree since it's never going to see other users). So
not that it really matters, but the patch is OK for that environment.
The only other case I can think of is if the backend really needs some
time to clear out data, if we end up spinning too much in the yield()
loop. POWER4 with HVC console is a possible candidate there, since all
partitions share a 19200bps line for consoles.
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Assuming it's not an issue on POWER4 LPAR:
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: Port Linux w/ mbxboot to PPCBoot system
From: Jessica Chen @ 2006-04-18 19:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060415001224.D1551353A56@atlas.denx.de>
Thank you for your reply Wolfgang!
In u-boot-1.1.4 README "Where we come from" section, it says u-boot "provide
extended interface to Linux boot loader". Does it mean that there is still
some sort of boot loader in arch/ppc/coffboot/vmlinux.gz ? If yes, when
does it start? Does it boot the kernel?
To build u-boot, I will need to get the manual for MPC852 and check the
configurations in include/configs/TQM860L.h file.
I am trying to find the machine specific header file in linux-2.4.25
(include/asm-ppc/tqm8xx.h file in linux-2.4.4) which should have the same
definition of structure bd_info as in include/asm-ppc/u-boot.h. And you
recommend using linux-2.4 instead of linux-2.6 on your website.
So am I heading the right directions here? Because the u-boot README
doesn't have the new directories and filenames, I am a little confused.
Thanks again,
Jessica
> > I am new to embedded system, I am studying ppcboot-1.1.5 and linux
> > kernel-2.4.4 that comes with an mpc852 base board, we want to modify it
in
>
> Both PPCBoot and Linux 2.4.4 are *hoplessly* obsolete. It may be ok
> to study this to understand the workings, but please don't even dream
> of using it for any current work.
>
> > the future. In the build process, they use the zImage.initrd
> > (arch/ppc/mbxboot/zvmlinux.initrd) instead of the raw Linux kernel image
>
> Somebody didn't know what he was doing, it seems.
>
> > since ppcboot is already running, what happens when I boot the kernel
that
> > has old boot loader code in arch/ppc/mbxboot? Will some parameters be
> > overwritten? If not, why?
>
> The Linux bootstrap loader code (arch/ppc/mbxboot) will ignore the
> parameteres passed by U-Boot, will set up is own (hardwired), and
> duplicate some of the things that PPCboot did or would do.
>
> > I am very tempted to follow the README to re-build the kernel with
only
> > vmlinux.gz and port it, but I don't want to create any un-recoverable
> > results. So I am here to seek advice, maybe this is something obvious
to
> > many people.
>
> Don't change anything. Look at it, then drop it. Start using current
> code, i. e. a recent version of U-Boot and a recent Linux kernel.
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V3
From: Jack Steiner @ 2006-04-18 19:56 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060418130015.28928.10163.sendpatchset@skynet>
On Tue, Apr 18, 2006 at 02:00:15PM +0100, Mel Gorman wrote:
> This is V3 of the patchset to size zones and memory holes in an
...
FYI, I applied the patches to a recent kernel & booted on a large
SGI system. No problem aside from what I assume is a very large number
of debug messages.
------
Linux version 2.6.17-tony (steiner@attica) (gcc version 4.1.0 (SUSE Linux)) #5 SMP PREEMPT Tue Apr 18 14:01:54 CDT 2006
EFI v1.10 by INTEL: SALsystab=0x6002c51df0 ACPI 2.0=0x6002c51ee0
Number of logical nodes in system = 512
Number of memory chunks in system = 512
SAL 2.9: SGI SN2 version 1.10
SAL Platform features: ITC_Drift
SAL: AP wakeup using external interrupt vector 0x12
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
ACPI: Error parsing MADT - no IOSAPIC entries
register_intr: No IOSAPIC for GSI 52
512 CPUs available, 512 CPUs total
MCA related initialization done
SGI SAL version 1.10
add_active_range(0, 25168900, 25235456): New
add_active_range(0, 25236375, 25419776): New
add_active_range(0, 27262976, 27516927): New
add_active_range(0, 29360128, 29614080): New
add_active_range(1, 92277760, 92528640): New
...
add_active_range(511, 34322242024, 34322242047): New
add_active_range(511, 34322243072, 34322243417): New
add_active_range(511, 34322243432, 34322243460): New
add_active_range(511, 34322243488, 34322243500): New
Virtual mem_map starts at 0xa0007e407d270000
free_area_init_nodes(68719476736, 68719476736, 34322243584, 34322243584)
free_area_init_nodes(): find_min_pfn = 25168900
Dumping sorted node map
entry 0: 0 25168900 -> 25235456
entry 1: 0 25236375 -> 25419776
entry 2: 0 27262976 -> 27516927
entry 3: 0 29360128 -> 29614080
entry 4: 1 92277760 -> 92528640
entry 5: 1 94371840 -> 94625792
entry 6: 1 96468992 -> 96722944
...
entry 1536: 511 34321989632 -> 34322242001
entry 1537: 511 34322242016 -> 34322242022
entry 1538: 511 34322242024 -> 34322242047
entry 1539: 511 34322243072 -> 34322243417
entry 1540: 511 34322243432 -> 34322243460
entry 1541: 511 34322243488 -> 34322243500
__absent_pages_in_range(0, 25168900, 68719476736) = 3687320
__absent_pages_in_range(0, 68719476736, 68719476736) = 0
__absent_pages_in_range(0, 68719476736, 34322243584) = 0
__absent_pages_in_range(0, 34322243584, 34322243584) = 0
__absent_pages_in_range(0, 25168900, 68719476736) = 3687320
...
__absent_pages_in_range(511, 34322243584, 34322243584) = 0
__absent_pages_in_range(511, 25168900, 68719476736) = 3687485
__absent_pages_in_range(511, 68719476736, 68719476736) = 0
__absent_pages_in_range(511, 68719476736, 34322243584) = 0
__absent_pages_in_range(511, 34322243584, 34322243584) = 0
Built 512 zonelists
Kernel command line: BOOT_IMAGE=net0:jfs/tonys ro hashdist=1 dhash_entries=2097152 ihash_entries=2097152 rhash_entries=2097152 thash_entries=2097152 console=ttySG0,38400n8 kdb=on noprobe root=/dev/sda5
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour dummy device 80x25
Memory: 4639378784k/4655642784k available (7021k code, 16279040k reserved, 4361k data, 736k init)
(essentially the same numbers as with a kernel w/o the patches)
McKinley Errata 9 workaround not needed; disabling it
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V3
From: Mel Gorman @ 2006-04-18 20:27 UTC (permalink / raw)
To: Jack Steiner
Cc: davej, tony.luck, Linux Memory Management List, ak, bob.picco,
Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20060418195644.GA30911@sgi.com>
On Tue, 18 Apr 2006, Jack Steiner wrote:
> On Tue, Apr 18, 2006 at 02:00:15PM +0100, Mel Gorman wrote:
>> This is V3 of the patchset to size zones and memory holes in an
> ...
>
>
>
> FYI, I applied the patches to a recent kernel & booted on a large
> SGI system.
Very cool, thanks for testing. I'm glad to see the assumptions related to
the size of node_map held up for a large machine.
> No problem aside from what I assume is a very large number
> of debug messages.
>
The debug messages are all in patch 7/7 and will be dropped before I try
and push this to -mm. The patch was included here in case a machine failed
to boot so I could figure out what went wrong.
>
> ------
> Linux version 2.6.17-tony (steiner@attica) (gcc version 4.1.0 (SUSE Linux)) #5 SMP PREEMPT Tue Apr 18 14:01:54 CDT 2006
> EFI v1.10 by INTEL: SALsystab=0x6002c51df0 ACPI 2.0=0x6002c51ee0
> Number of logical nodes in system = 512
> Number of memory chunks in system = 512
> SAL 2.9: SGI SN2 version 1.10
> SAL Platform features: ITC_Drift
> SAL: AP wakeup using external interrupt vector 0x12
> No logical to physical processor mapping available
> ACPI: Local APIC address c0000000fee00000
> ACPI: Error parsing MADT - no IOSAPIC entries
> register_intr: No IOSAPIC for GSI 52
> 512 CPUs available, 512 CPUs total
> MCA related initialization done
> SGI SAL version 1.10
> add_active_range(0, 25168900, 25235456): New
> add_active_range(0, 25236375, 25419776): New
> add_active_range(0, 27262976, 27516927): New
> add_active_range(0, 29360128, 29614080): New
> add_active_range(1, 92277760, 92528640): New
> ...
> add_active_range(511, 34322242024, 34322242047): New
> add_active_range(511, 34322243072, 34322243417): New
> add_active_range(511, 34322243432, 34322243460): New
> add_active_range(511, 34322243488, 34322243500): New
> Virtual mem_map starts at 0xa0007e407d270000
> free_area_init_nodes(68719476736, 68719476736, 34322243584, 34322243584)
> free_area_init_nodes(): find_min_pfn = 25168900
> Dumping sorted node map
> entry 0: 0 25168900 -> 25235456
> entry 1: 0 25236375 -> 25419776
> entry 2: 0 27262976 -> 27516927
> entry 3: 0 29360128 -> 29614080
> entry 4: 1 92277760 -> 92528640
> entry 5: 1 94371840 -> 94625792
> entry 6: 1 96468992 -> 96722944
> ...
> entry 1536: 511 34321989632 -> 34322242001
> entry 1537: 511 34322242016 -> 34322242022
> entry 1538: 511 34322242024 -> 34322242047
> entry 1539: 511 34322243072 -> 34322243417
> entry 1540: 511 34322243432 -> 34322243460
> entry 1541: 511 34322243488 -> 34322243500
> __absent_pages_in_range(0, 25168900, 68719476736) = 3687320
> __absent_pages_in_range(0, 68719476736, 68719476736) = 0
> __absent_pages_in_range(0, 68719476736, 34322243584) = 0
> __absent_pages_in_range(0, 34322243584, 34322243584) = 0
> __absent_pages_in_range(0, 25168900, 68719476736) = 3687320
> ...
> __absent_pages_in_range(511, 34322243584, 34322243584) = 0
> __absent_pages_in_range(511, 25168900, 68719476736) = 3687485
> __absent_pages_in_range(511, 68719476736, 68719476736) = 0
> __absent_pages_in_range(511, 68719476736, 34322243584) = 0
> __absent_pages_in_range(511, 34322243584, 34322243584) = 0
> Built 512 zonelists
> Kernel command line: BOOT_IMAGE=net0:jfs/tonys ro hashdist=1 dhash_entries=2097152 ihash_entries=2097152 rhash_entries=2097152 thash_entries=2097152 console=ttySG0,38400n8 kdb=on noprobe root=/dev/sda5
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Console: colour dummy device 80x25
> Memory: 4639378784k/4655642784k available (7021k code, 16279040k reserved, 4361k data, 736k init)
> (essentially the same numbers as with a kernel w/o the patches)
> McKinley Errata 9 workaround not needed; disabling it
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] Remove stale iseries global
From: Will Schmidt @ 2006-04-18 19:02 UTC (permalink / raw)
To: michael; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <1145382862.20176.5.camel@localhost.localdomain>
On Tue, 2006-04-18 at 19:54 +0200, Michael Ellerman wrote:
> On Tue, 2006-04-18 at 12:31 -0500, Will Schmidt wrote:
> > On Tue, 2006-04-18 at 11:25 -0500, Olof Johansson wrote:
> > > Hi,
> > >
> > > Not even the iSeries maintainer seems to have access to this legendary
> > > piranha simulator. It adds a bit of ugliness in the common time init
> > > code, and if it's no longer used we might as well be done with it and
> > > remove the bloat.
> >
> > Yes, the piranha tools are no longer used with linux. I see no reason
> > why this needs to stay.
>
> So can we get rid of this from head_64.S as well? Or is that a different
> debugger?
It's likely the same (piranha) debugger. I'm not aware of any other
debuggers that would be involved here.
What I dont know is if this offset to the mschunks_map array is also
used by the hypervisor for some non debug purposes. If iSeries
continues to work without it, then it can probably go too.
Just be sure that PPC_EARLY_DEBUG_ISERIES will continue to work for
getting info out of the system. :-)
> /*
> * At offset 0x28 and 0x30 are offsets to the mschunks_map
> * array (used by the iSeries LPAR debugger to do translation
> * between physical addresses and absolute addresses) and
> * to the pidhash table (also used by the debugger)
> */
> .llong mschunks_map-KERNELBASE
> .llong 0 /* pidhash-KERNELBASE SFRXXX */
>
> cheers
>
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5, 4 -- no sound?")
From: Paul Collins @ 2006-04-19 4:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: [ATR]Dj-Death, linuxppc-dev, Michael Schmitz, debian-powerpc,
Paul Mackerras
In-Reply-To: <1145397523.4705.94.camel@localhost.localdomain>
Hi Ben,
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2006-04-18 at 17:20 +0200, Michael Schmitz wrote:
>> > > Here a trace at boot from the sound driver :
>> >
>> > I think that bug happens if the sound driver loads before i2c-powermac.
>>
>> i2c-keywest is still request-module()d in 2.6.17-rc1, FWIW.
>>
>> Regarding other sound breakage with 2.6.17-rc1, I traced that to
>>
>> machine_is(powermac)
>>
>> returning zero in sound/ppc/pmac.c:snd_pmac_detect() when loading
>> snd-powermac. The OSS driver spits -ENODEV as well on loading so I'd
>> suspect the same thing here.
>>
>> machine_is boils down to a comparison machine_id == &mach_powermac, is
>> that sort of thing illegal after kernel init?
>
> Totally untested patch, please let me know if it helps:
Results in the following.
arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
make[1]: *** [arch/powerpc/platforms/powermac] Error 2
make: *** [arch/powerpc/platforms] Error 2
It looks like the EXPORT_SYMBOL() needs to be after the definition.
However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
define_machine(powermac) and now sound works for me with my original
I2C_POWERMAC=y SND_POWERMAC=m configuration.
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5,4 -- no sound?")
From: Benjamin Herrenschmidt @ 2006-04-19 5:19 UTC (permalink / raw)
To: Paul Collins
Cc: [ATR]Dj-Death, linuxppc-dev, Michael Schmitz, debian-powerpc,
Paul Mackerras
In-Reply-To: <87r73u19b1.fsf@briny.internal.ondioline.org>
> arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
> arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
> make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
> make[1]: *** [arch/powerpc/platforms/powermac] Error 2
> make: *** [arch/powerpc/platforms] Error 2
>
> It looks like the EXPORT_SYMBOL() needs to be after the definition.
>
> However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
> define_machine(powermac) and now sound works for me with my original
> I2C_POWERMAC=y SND_POWERMAC=m configuration.
Yup, Paul has a working patch already, will be in 2.6.17 soonish.
Cheers,
Ben.
^ permalink raw reply
* I want to use SCC3 as ethernet with SMC1 as console(mpc8xx)
From: 김영남 @ 2006-04-19 6:40 UTC (permalink / raw)
To: linuxppc-embedded
First of all, I am sorry for my poor english.
I have mpc850 custom board with followings:
SMC1 - console
SMC2 - uart
SCC2 - ethernet
I want to use SCC2 and SCC3 as ethernet(two ethernet interfaces).
As many web sites and mailing lists describe, I knew that SMC patch is
required because SMC1 and SCC3 share parameter ram.
I have DENX 2.4.25 kernel and this kernel works fine except using SCC3
as ethernet.
When apply "USE_SMC_PATCH" in arch/ppc/8xx_io/micropatch.c, kernel hang
and reset without any messages.(using u-boot 1.1.4)
I want to know that when I use "USE_SMC_PATCH", which source file is
modified and how to modify source file to use SMC1 as console.
Could you tell me useful information about that?
^ permalink raw reply
* Re: Upgrading cramfs root file system
From: Wojciech Kromer @ 2006-04-19 7:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200604062238.17972.antonio.dibacco@aruba.it>
Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
> Hi,
>
> how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that receives
> the new rootfs from a web interface and then tries to write it in the flash.
> While overwriting the old cramfs, the CGI will continue to work? something
> weird could happen?
>
Generally it's not a good idea to override working filesystem ( I've
tried to do it once).
You can have two separate copies of filesystem, one to work with, and
another to overwrite, it requires more flash.
Another way is working in initrd, it requires more RAM.
You can also use jffs2 or jffs3 (experimental) to have read-write
filesystem, and change applications only, not whole filesystem (be
carefull with changing busybox or libraries!)
^ 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