* Re: Build failure on treeboot-walnut.c
From: Timur Tabi @ 2007-10-09 14:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <E83F8EDA-95EF-4116-A214-D008BA70135D@kernel.crashing.org>
Kumar Gala wrote:
> What's the actual compile line? Want to see the flags to assembler of
> -Wa to the compiler.
How do I modify the makefiles to spit out that command line?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 00/15] [POWERPC] TQM5200, CM5200 and Motion-PRO support
From: Grant Likely @ 2007-10-09 14:38 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <470B450E.4020708@semihalf.com>
On 10/9/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> All,
>
> Thanks for the review, will process all the comments and resend
> updated patches soon.
Make sure you take a look at the 6 patches I posted yesterday. They
will probably go in before your changes and will cause conflicts.
Kumar, once I respin the ROOT_DEV patch, how does it look for merging
my patch set?
Cheers,
g.
>
> Marian
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/6] Platforms shouldn't mess with ROOT_DEV
From: Grant Likely @ 2007-10-09 14:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <E82FBA5B-61A0-4A0A-886B-0FCDD6AFC255@kernel.crashing.org>
On 10/9/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 8, 2007, at 5:25 PM, Grant Likely wrote:
>
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > There is no good reason for board platform code to mess with the
> > ROOT_DEV.
> > Remove it from all in-tree platforms except powermac
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > arch/powerpc/platforms/52xx/efika.c | 9 ---------
> > arch/powerpc/platforms/52xx/lite5200.c | 12 ------------
> > arch/powerpc/platforms/8xx/mpc86xads_setup.c | 2 --
> > arch/powerpc/platforms/cell/setup.c | 5 -----
> > arch/powerpc/platforms/celleb/setup.c | 5 -----
> > arch/powerpc/platforms/chrp/setup.c | 10 ----------
> > arch/powerpc/platforms/pseries/setup.c | 5 -----
> > 7 files changed, 0 insertions(+), 48 deletions(-)
>
> I'd drop mpc86xads_setup since I think Scott's rework will deal with it.
Okay, will do. I wasn't sure since you hadn't explicitly mentioned it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/6] Platforms shouldn't mess with ROOT_DEV
From: Kumar Gala @ 2007-10-09 13:53 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20071008222503.25840.37660.stgit@trillian.cg.shawcable.net>
On Oct 8, 2007, at 5:25 PM, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> There is no good reason for board platform code to mess with the
> ROOT_DEV.
> Remove it from all in-tree platforms except powermac
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/powerpc/platforms/52xx/efika.c | 9 ---------
> arch/powerpc/platforms/52xx/lite5200.c | 12 ------------
> arch/powerpc/platforms/8xx/mpc86xads_setup.c | 2 --
> arch/powerpc/platforms/cell/setup.c | 5 -----
> arch/powerpc/platforms/celleb/setup.c | 5 -----
> arch/powerpc/platforms/chrp/setup.c | 10 ----------
> arch/powerpc/platforms/pseries/setup.c | 5 -----
> 7 files changed, 0 insertions(+), 48 deletions(-)
I'd drop mpc86xads_setup since I think Scott's rework will deal with it.
- k
^ permalink raw reply
* Re: Build failure on treeboot-walnut.c
From: Kumar Gala @ 2007-10-09 13:30 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Paul Mackerras, Timur Tabi
In-Reply-To: <fa686aa40710082100h29c1d2a8hf939ca3306562fac@mail.gmail.com>
On Oct 8, 2007, at 11:00 PM, Grant Likely wrote:
> On 10/8/07, Timur Tabi <timur@freescale.com> wrote:
>> Looks like the problem is back:
>>
>> BOOTCC arch/powerpc/boot/treeboot-walnut.o
>> Assembler messages:
>> Error: Internal assembler error for instruction icbt
>> Internal error, aborting at
>> /tmp/crosstool/crosstool-0.42/build/powerpc-unknown-linux-gnu/
>> gcc-4.0.2_e300-enabled-glibc-2.3.6/binutils-2.16.1-complete/gas/
>> config/tc-ppc.c
>> line 1314 in ppc_setup_opcodes
>> Please report this bug.
>> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
>> make: *** [uImage] Error 2
>
> No; this is something different. The assember itself is failing
> internally. What version of binutils are you running?
>
2.61.1 if we believe his path :)
the assembler is failing because 'icbt' has several possible
different instruction encodings and I'm guessing he's getting a
conflict set.
What's the actual compile line? Want to see the flags to assembler
of -Wa to the compiler.
- k
^ permalink raw reply
* crash on shutdown on rs/6000 powerpc
From: Paul Mackerras @ 2007-10-09 13:00 UTC (permalink / raw)
To: torvalds, lkml, linuxppc-dev
I have just seen a crash at shutdown with 2.6.23-rc9 on an RS/6000
powerpc box (POWER3, 64-bit). It crashed immediately after printing
"Disabling non-boot CPUs", so I tried reverting 4047727e and that
fixed it. It's unfortunate that that commit added the
disable_nonboot_cpus for all architectures, when only x86[-64] needs
it. (At least it sounds like only x86[-64] needs it; the commit
message seems quite x86-centric.)
In case anyone on the linuxppc-dev list wants to chase this further,
the crash looks like this:
Disabling non-boot CPUs ...
cpu 0x1: Vector: 300 (Data Access) at [c00000003f923950]
pc: c00000000003bf98: .xics_set_cpu_priority+0x58/0x78
lr: c00000000003bff4: .xics_migrate_irqs_away+0x3c/0x20c
sp: c00000003f923bd0
msr: a000000000001032
dar: 4
dsisr: 42000000
current = 0xc0000000bfb6b060
paca = 0xc00000000071c600
pid = 2610, comm = kstopmachine
enter ? for help
[c00000003f923c40] c00000000003bff4 .xics_migrate_irqs_away+0x3c/0x20c
[c00000003f923d00] c000000000040d54 .pseries_cpu_disable+0x98/0xb4
[c00000003f923d80] c000000000028e4c .__cpu_disable+0x44/0x58
[c00000003f923df0] c00000000007e204 .take_cpu_down+0x34/0x60
[c00000003f923e70] c00000000008ba3c .do_stop+0x144/0x1e4
[c00000003f923f00] c00000000006fd74 .kthread+0x78/0xc4
[c00000003f923f90] c0000000000272a8 .kernel_thread+0x4c/0x68
I don't have time tonight or tomorrow to track this down further. I'm
taking the kids to the coast tommorow. :)
Paul.
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Ranulf Doswell @ 2007-10-09 12:23 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0710091135240.6961@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
On 09/10/2007, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> On Mon, 8 Oct 2007, Ranulf Doswell wrote:
> > However, in this case the only data required is a single identifier used
> to
> > identify one PS3 from another, and in fact this single 64-bit token can
> be
> > shared amongst many other applications that require the same function -
> > certainly I intend to expose it in a common way in my games library's
> API
> > for all users of the library.
>
> MAC address?
>
Indeed, that's perfect! That solution also just occurred to me whilst
walking back from lunch and when I come back to check my e-mail you've
already suggested it! Funny how I've been ignoring the most obvious answer
for weeks!
Cheers,
Ralf.
[-- Attachment #2: Type: text/html, Size: 1078 bytes --]
^ permalink raw reply
* Re: [patch v2] PS3: Add os-area database routines
From: Geert Uytterhoeven @ 2007-10-09 11:38 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <470AD44C.5080305@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2048 bytes --]
On Mon, 8 Oct 2007, Geoff Levand wrote:
> o Add a KERN_WARNING message when flash driver is not available.
> --- a/arch/powerpc/platforms/ps3/os-area.c
> +++ b/arch/powerpc/platforms/ps3/os-area.c
> +static void update_flash_db(void)
> +{
> + int result;
> + int file;
> + off_t offset;
> + ssize_t count;
> + static const unsigned int buf_len = 8 * OS_AREA_SEGMENT_SIZE;
> + const struct os_area_header *header;
> + struct os_area_db* db;
> +
> + /* Read in header and db from flash. */
> +
> + file = sys_open("/dev/ps3flash", O_RDWR, 0);
> +
> + if (file < 0) {
> + pr_debug("%s:%d sys_open failed\n", __func__, __LINE__);
^^^^^^^^
pr_warn?
If the ps3flash module is not loaded, you want to see the warning.
> @@ -264,6 +664,12 @@ static void os_area_queue_work_handler(s
> pr_debug("%s:%d of_find_node_by_path failed\n",
> __func__, __LINE__);
>
> +#if defined(CONFIG_PS3_FLASH) || defined(CONFIG_PS3_FLASH_MODULE)
> + update_flash_db();
> +#else
> + printk(KERN_WARNING "%s:%d: No flash rom driver configured.\n",
> + __func__, __LINE__);
> +#endif
> pr_debug(" <- %s:%d\n", __func__, __LINE__);
> }
Alternatively:
#if defined(CONFIG_PS3_FLASH) || defined(CONFIG_PS3_FLASH_MODULE)
static int update_flash_db(void)
{
...
return error;
}
#else
static inline int update_flash_db(void)
{
return -Exxx;
}
#endif
if (update_flash_db())
printk(KERN_WARNING ...);
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add AMCC Kilauea eval board support to platforms/40x
From: Stefan Roese @ 2007-10-09 11:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson
In-Reply-To: <20071008193404.GA10348@lixom.net>
Hi Olof,
On Monday 08 October 2007, Olof Johansson wrote:
> > +config KILAUEA
> > + bool "Kilauea"
> > + depends on 40x
> > + default y
> > + select 405EX
> > + help
> > + This option enables support for the AMCC PPC405EX evaluation board.
> > +
> > #config REDWOOD_5
> > # bool "Redwood-5"
> > # depends on 40x
> > @@ -89,14 +97,17 @@ config 403GCX
> > #depends on OAK
> > select IBM405_ERR51
> >
> > +config 405EP
> > + bool
> > +
> > +config 405EX
> > + bool
> > +
>
> Do you really need config options for 405EP/EX? I don't seem them used
> anywhere else in the code (and it's also contradictory to the whole new
> multiplatform way of looking at stuff :).
>
> I know the 405/440 is still somewhat #ifdef:ed on the cpu here and there,
> but since this doesn't add any such code I don't see a need for the config
> options?
Yes, I'm still used to needing these defines from arch/ppc (for example for
the 4xx EMAC driver). But its possible, that we really don't need it at all
in arch/powerpc with all the device tree information. Not sure though.
Josh, what do you think? Should I remove the 405EX define completely?
Best regards,
Stefan
^ permalink raw reply
* reboot of mpc8270 sometimes fails
From: Theo Gjaltema @ 2007-10-09 10:23 UTC (permalink / raw)
To: linux-ppc-embedded
hi,
I have an MPC8270 based board with linux 2.4.25 kernel (denx) and
ramdisk (subset of ELDK3.1.1).
The system works fine, but sometimes after performing a reboot the
system hangs after terminating the kernel and uboot doesn't come up.
Does someone have a clue about this?
Thanks,
Theo.
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Geert Uytterhoeven @ 2007-10-09 9:35 UTC (permalink / raw)
To: Ranulf Doswell; +Cc: linuxppc-dev
In-Reply-To: <18a15270710081559m3236126r85f797718300756f@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1442 bytes --]
On Mon, 8 Oct 2007, Ranulf Doswell wrote:
> On 08/10/2007, Geoff Levand <geoffrey.levand@am.sony.com> wrote:
> > > How do we go about claiming one of these OS_AREA_DB_OWNER_ keys? I'd
> > > very much like to use this functionality in my python-ps3 games library.
> >
> > It sounds like you should be storing your info in the file system like
> > all other applications do.
>
>
> I'd agree that for large amounts of application specific data, the
> filesystem is the correct approach.
>
> However, in this case the only data required is a single identifier used to
> identify one PS3 from another, and in fact this single 64-bit token can be
> shared amongst many other applications that require the same function -
> certainly I intend to expose it in a common way in my games library's API
> for all users of the library.
MAC address?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 00/15] [POWERPC] TQM5200, CM5200 and Motion-PRO support
From: Marian Balakowicz @ 2007-10-09 9:08 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47075FA7.3030108@semihalf.com>
All,
Thanks for the review, will process all the comments and resend
updated patches soon.
Marian
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Jan-Bernd Themann @ 2007-10-09 8:21 UTC (permalink / raw)
To: paulus, jeff
Cc: Thomas Q Klein, Arnd Bergmann, Paul Mackerras, Roland Dreier,
Joachim Fenkes, LKML, LinuxPPC-Dev, Christoph Raisch,
Stefan Roscher
In-Reply-To: <adave9odqfb.fsf@cisco.com>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
Roland Dreier <rdreier@cisco.com> wrote on 03.10.2007 20:05:44:
> > > Replace struct ibmebus_dev and struct ibmebus_driver with
> struct of_device
> > > and struct of_platform_driver, respectively. Match the external
ibmebus
> > > interface and drivers using it.
> > >
> > > Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> >
> > If not, then you need to get an Acked-by and an agreement that this
> > change can go via the powerpc.git tree from Roland Dreier and Jeff
> > Garzik.
>
> I don't see anything objectionable in the infiniband parts of the
> patch -- I don't have any way to test the changes but it all looks
> like a straightforward conversion to a new platform API. So:
>
> Acked-by: Roland Dreier <rolandd@cisco.com>
>
> - R.
Looks good from eHEA driver perspective.
Acked-by: Jan-Bernd Themann <themann@de.ibm.com>
[-- Attachment #2: Type: text/html, Size: 1211 bytes --]
^ permalink raw reply
* Re: [UNTESTED PATCH v2] 8xx: Convert mpc866ads to the new device binding.
From: Vitaly Bordug @ 2007-10-09 7:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071008224847.GA4053@loki.buserror.net>
Hello Scott,
On Mon, 8 Oct 2007 17:48:47 -0500
Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
ok, will give it a try shortly.
patch looks good after a quick glance.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Detecting power cycle on lite5200
From: Babarovic Ivica @ 2007-10-09 7:23 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <470B2142.8080106@asist.si>
Ehh ... we found a register called CDM Bread Crumb Register.
We'll use it since it's not reset.
Babarovic Ivica wrote:
> Hi!
>
> I was wondering if there is a way to detect power cycle
> on lite5200 board. I need this information for statistics and
> some other stuff.
> I need to know when the device was powered down and
> somehow read/get this information on bootup.
>
> Best regards
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* [PATCH] [POWERPC] Align the sys_call_table
From: Stephen Rothwell @ 2007-10-09 7:03 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Our _GLOBAL macro does a ".align 2" so the alignment is fine for 32
bit, but on 64 bit it is possible for it to end up only 4 byte aligned.
I don't know if it matters, but it can't hurt to 8 byte align it.
It also means that when we build with --emit_relocs, none of our 64 bit
relocations are to misaligned places.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/systbl.S | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 579de70..93219c3 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -39,6 +39,8 @@
#ifdef CONFIG_PPC64
#define sys_sigpending sys_ni_syscall
#define sys_old_getrlimit sys_ni_syscall
+
+ .p2align 3
#endif
_GLOBAL(sys_call_table)
--
1.5.3.4
^ permalink raw reply related
* Detecting power cycle on lite5200
From: Babarovic Ivica @ 2007-10-09 6:35 UTC (permalink / raw)
To: ppcembed
Hi!
I was wondering if there is a way to detect power cycle
on lite5200 board. I need this information for statistics and
some other stuff.
I need to know when the device was powered down and
somehow read/get this information on bootup.
Best regards
^ permalink raw reply
* Re: [UNTESTED PATCH] 8xx: Convert mpc866ads to the new device binding.
From: Stephen Rothwell @ 2007-10-09 4:49 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071008223806.GA2210@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
On Mon, 8 Oct 2007 17:38:06 -0500 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
>
> -#include <asm/prom.h>
Still needed for of_flat_dt_is_compatible()
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] MPC52xx: Trim includes on mpc5200 platform support code
From: Stephen Rothwell @ 2007-10-09 4:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20071008222517.25840.46075.stgit@trillian.cg.shawcable.net>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
On Mon, 08 Oct 2007 16:25:18 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> -#include <asm/prom.h>
> +#include <linux/of.h>
You should keep asm/prom.h if you are using any of the flat device tree
accessors (which thses files do).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Build failure on treeboot-walnut.c
From: Grant Likely @ 2007-10-09 4:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <470AA224.7050709@freescale.com>
On 10/8/07, Timur Tabi <timur@freescale.com> wrote:
> Looks like the problem is back:
>
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> Assembler messages:
> Error: Internal assembler error for instruction icbt
> Internal error, aborting at
> /tmp/crosstool/crosstool-0.42/build/powerpc-unknown-linux-gnu/gcc-4.0.2_e300-enabled-glibc-2.3.6/binutils-2.16.1-complete/gas/config/tc-ppc.c
> line 1314 in ppc_setup_opcodes
> Please report this bug.
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> make: *** [uImage] Error 2
No; this is something different. The assember itself is failing
internally. What version of binutils are you running?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Build failure on treeboot-walnut.cg
From: David Gibson @ 2007-10-09 3:07 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <470AA224.7050709@freescale.com>
On Mon, Oct 08, 2007 at 04:33:24PM -0500, Timur Tabi wrote:
> Looks like the problem is back:
>
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> Assembler messages:
> Error: Internal assembler error for instruction icbt
> Internal error, aborting at
> /tmp/crosstool/crosstool-0.42/build/powerpc-unknown-linux-gnu/gcc-4.0.2_e300-enabled-glibc-2.3.6/binutils-2.16.1-complete/gas/config/tc-ppc.c
> line 1314 in ppc_setup_opcodes
> Please report this bug.
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> make: *** [uImage] Error 2
I thought that got fixed already, did the CFLAGS override fall out
somehow?
> Question: I'm building a kernel for the 8610. Why is treeboot-walnut.c being
> compiled at all?
Policy. Compiling everything means build bugs - like this one - can
be found by everybody, not just those building for the specific
obscure platform.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Geoff Levand @ 2007-10-09 1:12 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, paulus
In-Reply-To: <Pine.LNX.4.62.0710081412260.31455@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
> On Sat, 6 Oct 2007 geoffrey.levand@am.sony.com wrote:
>> --- a/arch/powerpc/platforms/ps3/os-area.c
>> +++ b/arch/powerpc/platforms/ps3/os-area.c
>
>> +static int db_get_video_mode(const struct os_area_db *db,
>> + unsigned int *video_mode)
> ^^^^^^^^^^^^^^
>> +{
>> + return db_get_64(db, &os_area_db_id_video_mode, (uint64_t*)video_mode);
> ^^^^^^^^^^^
>> +}
>
> Woops, memory corruption, when writing a 64-bit value to a 32-bit variable.
Whoa! That routines is not even used, so I removed it.
-Geoff
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Geoff Levand @ 2007-10-09 1:08 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, paulus
In-Reply-To: <Pine.LNX.4.62.0710081019030.21197@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
> On Sat, 6 Oct 2007 geoffrey.levand@am.sony.com wrote:
>> --- a/arch/powerpc/platforms/ps3/os-area.c
>> +++ b/arch/powerpc/platforms/ps3/os-area.c
>> @@ -112,10 +114,91 @@ struct os_area_params {
>> u8 _reserved_5[8];
>> };
>>
>> +/**
>> + * struct os_area_db - Shared flash memory database.
>> + * @magic_num: Always '-db-' = 0x2d64622d.
> ^^^^^^^^^^
> #define?
Well, this is a comment, and when debugging it is handy to
know the value.
>> @@ -242,6 +325,303 @@ static int __init verify_header(const st
>> return 0;
>> }
>>
>> +static int db_verify(const struct os_area_db *db)
>> +{
>> + if (db->magic_num != 0x2d64622dU) {
> ^^^^^^^^^^^
> #define?
Sure, it is OK here.
>> +static void os_area_db_init(struct os_area_db *db)
>> +{
>> + /*
>> + * item | start | size
>> + * ----------+-------+-------
>> + * header | 0 | 24
>> + * index_64 | 24 | 64
>> + * values_64 | 88 | 57*8 = 456
>> + * index_32 | 544 | 64
>> + * values_32 | 609 | 57*4 = 228
>> + * index_16 | 836 | 64
>> + * values_16 | 900 | 57*2 = 114
>> + * end | 1014 | -
>> + */
>
> Lots of #defines and calculations?
OK.
>> +
>> + memset(db, 0, sizeof(struct os_area_db));
>> +
>> + db->magic_num = 0x2d64622dU;
> ^^^^^^^^^^^
> #define?
>
>> + db->version = 1;
>> + db->index_64 = 24;
> ^^
>> + db->count_64 = 57;
> ^^
>> + db->index_32 = 544;
> ^^^
>> + db->count_32 = 57;
> ^^
>> + db->index_16 = 836;
> ^^^
>> + db->count_16 = 57;
> ^^
> #defines?
>
>> +static void update_flash_db(void)
>> +{
>> + int result;
>> + int file;
>> + off_t offset;
>> + ssize_t count;
>> + static const unsigned int buf_len = 8 * OS_AREA_SEGMENT_SIZE;
>> + const struct os_area_header *header;
>> + struct os_area_db* db;
>> +
>> + /* Read in header and db from flash. */
>> +
>> + file = sys_open("/dev/ps3flash", O_RDWR, 0);
>
> Ah, file operations from kernel space...
Yes. I was thinking we could make an interface to the flash driver.
>> @@ -264,6 +644,9 @@ static void os_area_queue_work_handler(s
>> pr_debug("%s:%d of_find_node_by_path failed\n",
>> __func__, __LINE__);
>>
>> +#if defined(CONFIG_PS3_FLASH) || defined(CONFIG_PS3_FLASH_MODULE)
>> + update_flash_db();
>> +#endif
>
> Is this #ifdef needed? You don't reference ps3flash symbols directly, only by
> opening /dev/ps3flash. If you always call update_flash_db(), you can print an
> error message and the user will notice things haven't been written to flash.
My thinking was that the file I/O code would be removed by the optimizer
when not needed. I added a message.
^ permalink raw reply
* [patch v2] PS3: Add os-area database routines
From: Geoff Levand @ 2007-10-09 1:07 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071006213542.954029915@am.sony.com>
Subject: PS3: Add os-area database routines
Add support for a simple tagged database in the PS3 flash rom
os-area. The database allows the flash rom os-area to be shared
between a bootloader and installed operating systems. The
application ps3-flash-util or the library libps3-utils from the
ps3-utils package can be used for userspace database operations.
The latest ps3-utils package is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-utils.git
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
v2: Address Geert's comments:
o Replace numeric initializers with symbols, calculations and
BUILD_BUG_ON() checks.
o Add a KERN_WARNING message when flash driver is not available.
o Remove the unused (and incorrect) routine db_get_video_mode().
arch/powerpc/platforms/ps3/os-area.c | 445 +++++++++++++++++++++++++++++++++--
1 file changed, 431 insertions(+), 14 deletions(-)
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -21,6 +21,8 @@
#include <linux/kernel.h>
#include <linux/io.h>
#include <linux/workqueue.h>
+#include <linux/fs.h>
+#include <linux/syscalls.h>
#include <asm/lmb.h>
@@ -39,7 +41,7 @@ enum os_area_ldr_format {
* struct os_area_header - os area header segment.
* @magic_num: Always 'cell_ext_os_area'.
* @hdr_version: Header format version number.
- * @os_area_offset: Starting segment number of os image area.
+ * @db_area_offset: Starting segment number of other os database area.
* @ldr_area_offset: Starting segment number of bootloader image area.
* @ldr_format: HEADER_LDR_FORMAT flag.
* @ldr_size: Size of bootloader image in bytes.
@@ -53,7 +55,7 @@ enum os_area_ldr_format {
struct os_area_header {
u8 magic_num[16];
u32 hdr_version;
- u32 os_area_offset;
+ u32 db_area_offset;
u32 ldr_area_offset;
u32 _reserved_1;
u32 ldr_format;
@@ -112,10 +114,95 @@ struct os_area_params {
u8 _reserved_5[8];
};
+enum {
+ OS_AREA_DB_MAGIC_NUM = 0x2d64622dU,
+};
+
+/**
+ * struct os_area_db - Shared flash memory database.
+ * @magic_num: Always '-db-' = 0x2d64622d.
+ * @version: os_area_db format version number.
+ * @index_64: byte offset of the database id index for 64 bit variables.
+ * @count_64: number of usable 64 bit index entries
+ * @index_32: byte offset of the database id index for 32 bit variables.
+ * @count_32: number of usable 32 bit index entries
+ * @index_16: byte offset of the database id index for 16 bit variables.
+ * @count_16: number of usable 16 bit index entries
+ *
+ * Flash rom storage for exclusive use by guests running in the other os lpar.
+ * The current system configuration allocates 1K (two segments) for other os
+ * use.
+ */
+
+struct os_area_db {
+ u32 magic_num;
+ u16 version;
+ u16 _reserved_1;
+ u16 index_64;
+ u16 count_64;
+ u16 index_32;
+ u16 count_32;
+ u16 index_16;
+ u16 count_16;
+ u32 _reserved_2;
+ u8 _db_data[1000];
+};
+
+/**
+ * enum os_area_db_owner - Data owners.
+ */
+
+enum os_area_db_owner {
+ OS_AREA_DB_OWNER_ANY = -1,
+ OS_AREA_DB_OWNER_NONE = 0,
+ OS_AREA_DB_OWNER_PROTOTYPE = 1,
+ OS_AREA_DB_OWNER_LINUX = 2,
+ OS_AREA_DB_OWNER_PETITBOOT = 3,
+ OS_AREA_DB_OWNER_MAX = 32,
+};
+
+enum os_area_db_key {
+ OS_AREA_DB_KEY_ANY = -1,
+ OS_AREA_DB_KEY_NONE = 0,
+ OS_AREA_DB_KEY_RTC_DIFF = 1,
+ OS_AREA_DB_KEY_VIDEO_MODE = 2,
+ OS_AREA_DB_KEY_MAX = 8,
+};
+
+struct os_area_db_id {
+ int owner;
+ int key;
+};
+
+static const struct os_area_db_id os_area_db_id_empty = {
+ .owner = OS_AREA_DB_OWNER_NONE,
+ .key = OS_AREA_DB_KEY_NONE
+};
+
+static const struct os_area_db_id os_area_db_id_any = {
+ .owner = OS_AREA_DB_OWNER_ANY,
+ .key = OS_AREA_DB_KEY_ANY
+};
+
+static const struct os_area_db_id os_area_db_id_rtc_diff = {
+ .owner = OS_AREA_DB_OWNER_LINUX,
+ .key = OS_AREA_DB_KEY_RTC_DIFF
+};
+
+static const struct os_area_db_id os_area_db_id_video_mode = {
+ .owner = OS_AREA_DB_OWNER_LINUX,
+ .key = OS_AREA_DB_KEY_VIDEO_MODE
+};
+
#define SECONDS_FROM_1970_TO_2000 946684800LL
/**
* struct saved_params - Static working copies of data from the PS3 'os area'.
+ *
+ * The order of preference we use for the rtc_diff source:
+ * 1) The database value.
+ * 2) The game os value.
+ * 3) The number of seconds from 1970 to 2000.
*/
struct saved_params {
@@ -182,17 +269,17 @@ static void __init os_area_get_property(
static void _dump_header(const struct os_area_header *h, const char *func,
int line)
{
- pr_debug("%s:%d: h.magic_num: '%s'\n", func, line,
+ pr_debug("%s:%d: h.magic_num: '%s'\n", func, line,
h->magic_num);
- pr_debug("%s:%d: h.hdr_version: %u\n", func, line,
+ pr_debug("%s:%d: h.hdr_version: %u\n", func, line,
h->hdr_version);
- pr_debug("%s:%d: h.os_area_offset: %u\n", func, line,
- h->os_area_offset);
+ pr_debug("%s:%d: h.db_area_offset: %u\n", func, line,
+ h->db_area_offset);
pr_debug("%s:%d: h.ldr_area_offset: %u\n", func, line,
h->ldr_area_offset);
- pr_debug("%s:%d: h.ldr_format: %u\n", func, line,
+ pr_debug("%s:%d: h.ldr_format: %u\n", func, line,
h->ldr_format);
- pr_debug("%s:%d: h.ldr_size: %xh\n", func, line,
+ pr_debug("%s:%d: h.ldr_size: %xh\n", func, line,
h->ldr_size);
}
@@ -222,7 +309,7 @@ static void _dump_params(const struct os
p->dns_secondary[2], p->dns_secondary[3]);
}
-static int __init verify_header(const struct os_area_header *header)
+static int verify_header(const struct os_area_header *header)
{
if (memcmp(header->magic_num, "cell_ext_os_area", 16)) {
pr_debug("%s:%d magic_num failed\n", __func__, __LINE__);
@@ -234,7 +321,7 @@ static int __init verify_header(const st
return -1;
}
- if (header->os_area_offset > header->ldr_area_offset) {
+ if (header->db_area_offset > header->ldr_area_offset) {
pr_debug("%s:%d offsets failed\n", __func__, __LINE__);
return -1;
}
@@ -242,6 +329,319 @@ static int __init verify_header(const st
return 0;
}
+static int db_verify(const struct os_area_db *db)
+{
+ if (db->magic_num != OS_AREA_DB_MAGIC_NUM) {
+ pr_debug("%s:%d magic_num failed\n", __func__, __LINE__);
+ return -1;
+ }
+
+ if (db->version != 1) {
+ pr_debug("%s:%d version failed\n", __func__, __LINE__);
+ return -1;
+ }
+
+ return 0;
+}
+
+struct db_index {
+ uint8_t owner:5;
+ uint8_t key:3;
+};
+
+struct db_iterator {
+ const struct os_area_db *db;
+ struct os_area_db_id match_id;
+ struct db_index *idx;
+ struct db_index *last_idx;
+ union {
+ uint64_t *value_64;
+ uint32_t *value_32;
+ uint16_t *value_16;
+ };
+};
+
+static unsigned int db_align_up(unsigned int val, unsigned int size)
+{
+ return (val + (size - 1)) & (~(size - 1));
+}
+
+/**
+ * db_for_each_64 - Iterator for 64 bit entries.
+ *
+ * A NULL value for id can be used to match all entries.
+ * OS_AREA_DB_OWNER_ANY and OS_AREA_DB_KEY_ANY can be used to match all.
+ */
+
+static int db_for_each_64(const struct os_area_db *db,
+ const struct os_area_db_id *match_id, struct db_iterator *i)
+{
+next:
+ if (!i->db) {
+ i->db = db;
+ i->match_id = match_id ? *match_id : os_area_db_id_any;
+ i->idx = (void *)db + db->index_64;
+ i->last_idx = i->idx + db->count_64;
+ i->value_64 = (void *)db + db->index_64
+ + db_align_up(db->count_64, 8);
+ } else {
+ i->idx++;
+ i->value_64++;
+ }
+
+ if (i->idx >= i->last_idx) {
+ pr_debug("%s:%d: reached end\n", __func__, __LINE__);
+ return 0;
+ }
+
+ if (i->match_id.owner != OS_AREA_DB_OWNER_ANY
+ && i->match_id.owner != (int)i->idx->owner)
+ goto next;
+ if (i->match_id.key != OS_AREA_DB_KEY_ANY
+ && i->match_id.key != (int)i->idx->key)
+ goto next;
+
+ return 1;
+}
+
+static int db_delete_64(struct os_area_db *db, const struct os_area_db_id *id)
+{
+ struct db_iterator i;
+
+ for (i.db = NULL; db_for_each_64(db, id, &i); ) {
+
+ pr_debug("%s:%d: got (%d:%d) %llxh\n", __func__, __LINE__,
+ i.idx->owner, i.idx->key,
+ (unsigned long long)*i.value_64);
+
+ i.idx->owner = 0;
+ i.idx->key = 0;
+ *i.value_64 = 0;
+ }
+ return 0;
+}
+
+static int db_set_64(struct os_area_db *db, const struct os_area_db_id *id,
+ uint64_t value)
+{
+ struct db_iterator i;
+
+ pr_debug("%s:%d: (%d:%d) <= %llxh\n", __func__, __LINE__,
+ id->owner, id->key, (unsigned long long)value);
+
+ if (!id->owner || id->owner == OS_AREA_DB_OWNER_ANY
+ || id->key == OS_AREA_DB_KEY_ANY) {
+ pr_debug("%s:%d: bad id: (%d:%d)\n", __func__,
+ __LINE__, id->owner, id->key);
+ return -1;
+ }
+
+ db_delete_64(db, id);
+
+ i.db = NULL;
+ if (db_for_each_64(db, &os_area_db_id_empty, &i)) {
+
+ pr_debug("%s:%d: got (%d:%d) %llxh\n", __func__, __LINE__,
+ i.idx->owner, i.idx->key,
+ (unsigned long long)*i.value_64);
+
+ i.idx->owner = id->owner;
+ i.idx->key = id->key;
+ *i.value_64 = value;
+
+ pr_debug("%s:%d: set (%d:%d) <= %llxh\n", __func__, __LINE__,
+ i.idx->owner, i.idx->key,
+ (unsigned long long)*i.value_64);
+ return 0;
+ }
+ pr_debug("%s:%d: database full.\n",
+ __func__, __LINE__);
+ return -1;
+}
+
+static int db_get_64(const struct os_area_db *db,
+ const struct os_area_db_id *id, uint64_t *value)
+{
+ struct db_iterator i;
+
+ i.db = NULL;
+ if (db_for_each_64(db, id, &i)) {
+ *value = *i.value_64;
+ pr_debug("%s:%d: found %lld\n", __func__, __LINE__,
+ (long long int)*i.value_64);
+ return 0;
+ }
+ pr_debug("%s:%d: not found\n", __func__, __LINE__);
+ return -1;
+}
+
+static int db_get_rtc_diff(const struct os_area_db *db, int64_t *rtc_diff)
+{
+ return db_get_64(db, &os_area_db_id_rtc_diff, (uint64_t*)rtc_diff);
+}
+
+#define dump_db(a) _dump_db(a, __func__, __LINE__)
+static void _dump_db(const struct os_area_db *db, const char *func,
+ int line)
+{
+ pr_debug("%s:%d: db.magic_num: '%s'\n", func, line,
+ (const char*)&db->magic_num);
+ pr_debug("%s:%d: db.version: %u\n", func, line,
+ db->version);
+ pr_debug("%s:%d: db.index_64: %u\n", func, line,
+ db->index_64);
+ pr_debug("%s:%d: db.count_64: %u\n", func, line,
+ db->count_64);
+ pr_debug("%s:%d: db.index_32: %u\n", func, line,
+ db->index_32);
+ pr_debug("%s:%d: db.count_32: %u\n", func, line,
+ db->count_32);
+ pr_debug("%s:%d: db.index_16: %u\n", func, line,
+ db->index_16);
+ pr_debug("%s:%d: db.count_16: %u\n", func, line,
+ db->count_16);
+}
+
+static void os_area_db_init(struct os_area_db *db)
+{
+ enum {
+ HEADER_SIZE = offsetof(struct os_area_db, _db_data),
+ INDEX_64_COUNT = 64,
+ VALUES_64_COUNT = 57,
+ INDEX_32_COUNT = 64,
+ VALUES_32_COUNT = 57,
+ INDEX_16_COUNT = 64,
+ VALUES_16_COUNT = 57,
+ };
+
+ memset(db, 0, sizeof(struct os_area_db));
+
+ db->magic_num = OS_AREA_DB_MAGIC_NUM;
+ db->version = 1;
+ db->index_64 = HEADER_SIZE;
+ db->count_64 = VALUES_64_COUNT;
+ db->index_32 = HEADER_SIZE
+ + INDEX_64_COUNT * sizeof(struct db_index)
+ + VALUES_64_COUNT * sizeof(u64);
+ db->count_32 = VALUES_32_COUNT;
+ db->index_16 = HEADER_SIZE
+ + INDEX_64_COUNT * sizeof(struct db_index)
+ + VALUES_64_COUNT * sizeof(u64)
+ + INDEX_32_COUNT * sizeof(struct db_index)
+ + VALUES_32_COUNT * sizeof(u32);
+ db->count_16 = VALUES_16_COUNT;
+
+ /* Rules to check db layout. */
+
+ BUILD_BUG_ON(sizeof(struct db_index) != 1);
+ BUILD_BUG_ON(sizeof(struct os_area_db) != 2 * OS_AREA_SEGMENT_SIZE);
+ BUILD_BUG_ON(INDEX_64_COUNT & 0x7);
+ BUILD_BUG_ON(VALUES_64_COUNT > INDEX_64_COUNT);
+ BUILD_BUG_ON(INDEX_32_COUNT & 0x7);
+ BUILD_BUG_ON(VALUES_32_COUNT > INDEX_32_COUNT);
+ BUILD_BUG_ON(INDEX_16_COUNT & 0x7);
+ BUILD_BUG_ON(VALUES_16_COUNT > INDEX_16_COUNT);
+ BUILD_BUG_ON(HEADER_SIZE
+ + INDEX_64_COUNT * sizeof(struct db_index)
+ + VALUES_64_COUNT * sizeof(u64)
+ + INDEX_32_COUNT * sizeof(struct db_index)
+ + VALUES_32_COUNT * sizeof(u32)
+ + INDEX_16_COUNT * sizeof(struct db_index)
+ + VALUES_16_COUNT * sizeof(u16)
+ > sizeof(struct os_area_db));
+}
+
+/**
+ * update_flash_db - Helper for os_area_queue_work_handler.
+ *
+ */
+
+static void update_flash_db(void)
+{
+ int result;
+ int file;
+ off_t offset;
+ ssize_t count;
+ static const unsigned int buf_len = 8 * OS_AREA_SEGMENT_SIZE;
+ const struct os_area_header *header;
+ struct os_area_db* db;
+
+ /* Read in header and db from flash. */
+
+ file = sys_open("/dev/ps3flash", O_RDWR, 0);
+
+ if (file < 0) {
+ pr_debug("%s:%d sys_open failed\n", __func__, __LINE__);
+ goto fail_open;
+ }
+
+ header = kmalloc(buf_len, GFP_KERNEL);
+
+ if (!header) {
+ pr_debug("%s:%d kmalloc failed\n", __func__, __LINE__);
+ goto fail_malloc;
+ }
+
+ offset = sys_lseek(file, 0, SEEK_SET);
+
+ if (offset != 0) {
+ pr_debug("%s:%d sys_lseek failed\n", __func__, __LINE__);
+ goto fail_header_seek;
+ }
+
+ count = sys_read(file, (char __user *)header, buf_len);
+
+ result = count < OS_AREA_SEGMENT_SIZE || verify_header(header)
+ || count < header->db_area_offset * OS_AREA_SEGMENT_SIZE;
+
+ if (result) {
+ pr_debug("%s:%d verify_header failed\n", __func__, __LINE__);
+ dump_header(header);
+ goto fail_header;
+ }
+
+ /* Now got a good db offset and some maybe good db data. */
+
+ db = (void*)header + header->db_area_offset * OS_AREA_SEGMENT_SIZE;
+
+ result = db_verify(db);
+
+ if (result) {
+ printk(KERN_NOTICE "%s:%d: Verify of flash database failed, "
+ "formatting.\n", __func__, __LINE__);
+ dump_db(db);
+ os_area_db_init(db);
+ }
+
+ /* Now got good db data. */
+
+ db_set_64(db, &os_area_db_id_rtc_diff, saved_params.rtc_diff);
+
+ offset = sys_lseek(file, header->db_area_offset * OS_AREA_SEGMENT_SIZE,
+ SEEK_SET);
+
+ if (offset != header->db_area_offset * OS_AREA_SEGMENT_SIZE) {
+ pr_debug("%s:%d sys_lseek failed\n", __func__, __LINE__);
+ goto fail_db_seek;
+ }
+
+ count = sys_write(file, (const char __user *)db,
+ sizeof(struct os_area_db));
+
+ if (count < sizeof(struct os_area_db)) {
+ pr_debug("%s:%d sys_write failed\n", __func__, __LINE__);
+ }
+
+fail_db_seek:
+fail_header:
+fail_header_seek:
+ kfree(header);
+fail_malloc:
+ sys_close(file);
+fail_open:
+ return;
+}
+
/**
* os_area_queue_work_handler - Asynchronous write handler.
*
@@ -264,6 +664,12 @@ static void os_area_queue_work_handler(s
pr_debug("%s:%d of_find_node_by_path failed\n",
__func__, __LINE__);
+#if defined(CONFIG_PS3_FLASH) || defined(CONFIG_PS3_FLASH_MODULE)
+ update_flash_db();
+#else
+ printk(KERN_WARNING "%s:%d: No flash rom driver configured.\n",
+ __func__, __LINE__);
+#endif
pr_debug(" <- %s:%d\n", __func__, __LINE__);
}
@@ -278,11 +684,15 @@ static void os_area_queue_work(void)
/**
* ps3_os_area_save_params - Copy data from os area mirror to @saved_params.
*
- * For the convenience of the guest, the HV makes a copy of the os area in
+ * For the convenience of the guest the HV makes a copy of the os area in
* flash to a high address in the boot memory region and then puts that RAM
- * address and the byte count into the repository for retreval by the guest.
+ * address and the byte count into the repository for retrieval by the guest.
* We copy the data we want into a static variable and allow the memory setup
* by the HV to be claimed by the lmb manager.
+ *
+ * The os area mirror will not be available to a second stage kernel, and
+ * the header verify will fail. In this case, the saved_params values will
+ * be set from flash memory or the passed in device tree in ps3_os_area_init().
*/
void __init ps3_os_area_save_params(void)
@@ -292,6 +702,7 @@ void __init ps3_os_area_save_params(void
unsigned int size;
struct os_area_header *header;
struct os_area_params *params;
+ struct os_area_db *db;
pr_debug(" -> %s:%d\n", __func__, __LINE__);
@@ -311,16 +722,22 @@ void __init ps3_os_area_save_params(void
if (result) {
/* Second stage kernels exit here. */
-
pr_debug("%s:%d verify_header failed\n", __func__, __LINE__);
dump_header(header);
return;
}
+ db = (struct os_area_db *)__va(lpar_addr
+ + header->db_area_offset * OS_AREA_SEGMENT_SIZE);
+
dump_header(header);
dump_params(params);
+ dump_db(db);
- saved_params.rtc_diff = params->rtc_diff;
+ result = db_verify(db) || db_get_rtc_diff(db, &saved_params.rtc_diff);
+ if (result)
+ saved_params.rtc_diff = params->rtc_diff ? params->rtc_diff
+ : SECONDS_FROM_1970_TO_2000;
saved_params.av_multi_out = params->av_multi_out;
saved_params.valid = 1;
^ permalink raw reply
* Re: [PATCH] Prevent decrementer clockevents from firing early
From: Benjamin Herrenschmidt @ 2007-10-09 0:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18186.50261.275896.847277@cargo.ozlabs.ibm.com>
On Tue, 2007-10-09 at 09:59 +1000, Paul Mackerras wrote:
> On old powermacs, we sometimes set the decrementer to 1 in order to
> trigger a decrementer interrupt, which we use to handle an interrupt
> that was pending at the time when it was re-enabled. This was causing
> the decrementer clock event device to call the event function for the
> next event early, which was causing problems when high-res timers were
> not enabled.
>
> This fixes the problem by recording the timebase value at which the
> next event should occur, and checking the current timebase against the
> recorded value in timer_interrupt. If it isn't time for the next
> event, it just reprograms the decrementer and returns.
>
> This also subtracts 1 from the value stored into the decrementer,
> which is appropriate because the decrementer interrupts on the
> transition from 0 to -1, not when the decrementer reaches 0.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
Do we also need to handle lost ticks ? That is loop & do multiple events
like we used to do with the previous implementation ?
Cheers,
Ben.
^ 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