* Discuss: Adding OF Flat Dev Tree to ppc32
From: Jon Loeliger @ 2005-06-03 17:19 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org, linuxppc64-dev
In-Reply-To: <1117783104.31082.151.camel@gaston>
Ben and Folks,
I've read through ppc64/kernel/prom.c and done some minor
call-chain analysis rooted at the two functions:
early_init_devtree()
unflatten_device_tree()
as they are apparently the only two referenced in the
initial early boot up process.
My notion was to take the portion of prom.c rooted at
these two functions and add them to the ppc32 line.
First, what portions of pp64/kernel/prom.c are obsolete?
Anything? You alluded to cleaning this up some, but I
am not too familiar with it to know where that was headed.
Second, there is already a fairly similar prom.c file
hanging out over in ppc32 land. I _think_ it houses
roughly the complementary code out of ppc64's prom.c
that is NOT derived from the call chain derived from
the above two functions.
Which leads me to the questions: Is there, or should
we create, a plan to factor the flat-dev-tree handling
code into common or shared ppc code? I am reluctant
to just outright clone and copy that code if it will
ultimately "be the same" or even "mostly the same".
It seems that the early_init_devtree() might then need
to be refactored or duplicated for ppc32-land.
Are you anticipating the same r3,r4,r5 interface outlined
in your 0.4 rev of the ppc4 OF spec to be used by the
ppc32 world as well? Seems like it just might...
Naturally, I'm willing to jump in here, just looking
for a bit of global-direction from you. :-)
jdl
^ permalink raw reply
* Re: [PATCH] Fix PPC440 pagetable attributes
From: Geoff Levand @ 2005-06-03 16:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <134a0b6339320a60ba2a868931a3aed4@freescale.com>
Kumar Gala wrote:
> On Jun 2, 2005, at 6:00 PM, Geoff Levand wrote:
>
>
>>This patch fixes a bug in the PPC440 pagetable attributes that breaks
>>swap support. It also adds some notes on the PPC440 attribute fields.
>>
>> *
>> * Note that these bits preclude future use of a page size
>> * less than 4KB.
>>+ *
>>+ *
>>+ * PPC 440 core has following TLB attribute fields;
>>+ *
>>+ * TLB1:
>>+ * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
>>31
>>+ * RPN................................. - - - - - -
>>ERPN.......
>>+ *
>>+ * TLB2:
>>+ * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
>>31
>>+ * - - - - - - U0 U1 U2 U3 W I M G E - UX UW UR SX SW
>>SR
>>+ *
>>+ * There are some constrains and options, to decide mapping software
>>bits
>>+ * into TLB entry.
>>+ *
>>+ * - PRESENT *must* be in the bottom three bits because swap cache
>>+ * entries use the top 29 bits for TLB2.
>>+ *
>>+ * - FILE *must* be in the bottom three bits because swap cache
>>+ * entries use the top 29 bits for TLB2.
>>+ *
>>+ * - CACHE COHERENT bit (M) has no effect on PPC440 core, because it
>>+ * doesn't support SMP. So we can use this as software bit, like
>>+ * DIRTY.
>>+ *
>>+ * PPC Book-E Linux implementation uses PPC HW PTE bit field
>>definition,
>>+ * even it doesn't have HW PTE. 0-11th LSB of PTE stand for memory
>>+ * protection-related function. (See PTE structure in
>>include/asm-ppc/mmu.h)
>>+ * Definition of _PAGE_XXX in "include/asm-ppc/pagetable.h" stands for
>>+ * above bits. Note that those bits values are CPU dependent, not
>>+ * architecture.
>>+ *
>
> I disagree with this comment. PPC Book-E PTE format has nothing to do
> with PPC HW PTE format.
>
OK, is this more agreeable?
* With the PPC Book-E Linux implementation, 0-11th LSB of PTE stand for memory
* protection-related function. (See PTE structure in include/asm-ppc/mmu.h)
* Definition of _PAGE_XXX here stands for above bits. Note that those bits
* values are CPU dependent, not architecture.
If not, could you be more specific.
-Geoff
^ permalink raw reply
* Re: Réf. : Re: starting RAM adress for linux kernel
From: Wolfgang Denk @ 2005-06-03 15:58 UTC (permalink / raw)
To: scarayol; +Cc: ctrichet, linuxppc-embedded
In-Reply-To: <OFF1C6B550.9120AF42-ONC1257015.004EFCD3@brime.fr>
Dear Sphie,
in message <OFF1C6B550.9120AF42-ONC1257015.004EFCD3@brime.fr> you wrote:
>
> we need to have the start of Ram at 0x0300 0000 because we use the command
> mem=40M (for uboot) to force Linux
> in the low part of memory and to reserve the high part of memory (218M
> exactly ) for ioremap (for our application) but we keep
I don't see any reason why this would prevent you from mapping the
RAM at physical address 0.
> the same flash mapping (to avoid more problems).
I don't know which problems you want to avoid by your chosen memory
map, but I guess that the problems you *cause* by this choice are
more, and more severe.
> Is the only solution is to inverse the mapping with Ram from 0 to 258M and
> the flash above ?
Yes.
> Finally, will Busybox work with Ram starting at 0x03000000 ?
No, it will not, as BB is application code which requires a running
kernel, and your kernel will not run with such a mapping.
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
"It may be that our role on this planet is not to worship God but to
create him." - Arthur C. Clarke
^ permalink raw reply
* Re: [RFC] PlatformDevice definitions for 82xx
From: Kumar Gala @ 2005-06-03 15:26 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <42A0758D.5040000@ru.mvista.com>
On Jun 3, 2005, at 10:21 AM, Vitaly Bordug wrote:
> Kumar Gala wrote:
>
>>
>> On Jun 2, 2005, at 11:16 AM, Vitaly Bordug wrote:
>>
>>> Hi!
>>> This adds platform definition files for 82xx, while the
>>> platform_info is
>>> filled in board-specific .C file residing in platforms/82xx. Another
>>> disputable thing I did - I moved m8260_setup.c from the syslib/ up to
>>> platforms/82xx/. The file was slightly changed - added 2 prototypes
>>> from the cpm2_pic.h and removed the respective include.
>>
>>
>> Why the move of m8260_setup.c? Also, if this is required can we do
>> this as two different patches so we can see clearly any changes also
>> maded to m8260_setup.c
>>
> To my opinion platforms/82xx/m8260_setup.c is more relevant than in
> syslib. This is not a vital requirement though, I just want to know
> whether someone considers the same.
Let's leave it where it is for now.
>> mpc82xx_devices.c need a bit of work we need to at least cover the
>> same set of devices that 85xx does for the CPM:
>> SPI, I2C, USB, SCC1-4, FCC1-3, MCC1-2, SMC1-2
>>
> OK. These stuff is not there yet because I wasn't sure what should come
> first - the platform stuff or driver that will utilize it. So, the
> correct way is to define PD first, than add drivers.
>
>> Additionally, the device name can not me FS_ENET_NAME, which assumes
>> that FCC is only used for enet.
>>
> OK
>
>> mpc82xx_sys.c: what is the .value field? is this the IMMR and if so
>> why bother shifting it?
>
> Because I want only partnum & masknum (RM, Fig. 4.26), remaining part
> is
> HRCW-dependent and can be written so couldn't be used as a device
> identification.
Ok, but is there any need to shift it? Just setup the mask up
correctly.
>> Also there are a whole bunch of variants that need to be captured
>>
> What exactly do you mean by this? Enumerate all the 82xx boards in
> mpc82xx_sys.c identifying them by immr, or?
Not boards, but chips. Yes, enumerating the various IMMRs, I will ask
one of our engineers to help with this.
- kumar
^ permalink raw reply
* Re: [RFC] PlatformDevice definitions for 82xx
From: Vitaly Bordug @ 2005-06-03 15:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
In-Reply-To: <81bbf71b42314c9168681be6ef2725e1@freescale.com>
Kumar Gala wrote:
>
> On Jun 2, 2005, at 11:16 AM, Vitaly Bordug wrote:
>
>> Hi!
>> This adds platform definition files for 82xx, while the platform_info is
>> filled in board-specific .C file residing in platforms/82xx. Another
>> disputable thing I did - I moved m8260_setup.c from the syslib/ up to
>> platforms/82xx/. The file was slightly changed - added 2 prototypes
>> from the cpm2_pic.h and removed the respective include.
>
>
> Why the move of m8260_setup.c? Also, if this is required can we do
> this as two different patches so we can see clearly any changes also
> maded to m8260_setup.c
>
To my opinion platforms/82xx/m8260_setup.c is more relevant than in
syslib. This is not a vital requirement though, I just want to know
whether someone considers the same.
> mpc82xx_devices.c need a bit of work we need to at least cover the
> same set of devices that 85xx does for the CPM:
> SPI, I2C, USB, SCC1-4, FCC1-3, MCC1-2, SMC1-2
>
OK. These stuff is not there yet because I wasn't sure what should come
first - the platform stuff or driver that will utilize it. So, the
correct way is to define PD first, than add drivers.
> Additionally, the device name can not me FS_ENET_NAME, which assumes
> that FCC is only used for enet.
>
OK
> mpc82xx_sys.c: what is the .value field? is this the IMMR and if so
> why bother shifting it?
Because I want only partnum & masknum (RM, Fig. 4.26), remaining part is
HRCW-dependent and can be written so couldn't be used as a device
identification.
> Also there are a whole bunch of variants that need to be captured
>
What exactly do you mean by this? Enumerate all the 82xx boards in
mpc82xx_sys.c identifying them by immr, or?
> Let's get clean versions of these two files before we worry about how
> to handle FCC enet specific bits.
Agreed.
>
> - kumar
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* RE: Réf. : Re: starting RAM adress for linux kernel
From: Steven Blakeslee @ 2005-06-03 15:06 UTC (permalink / raw)
To: scarayol, wd; +Cc: ctrichet, linuxppc-embedded
>=20
> we need to have the start of Ram at 0x0300 0000 because we=20
> use the command mem=3D40M (for uboot) to force Linux in the low=20
> part of memory and to reserve the high part of memory (218M=20
> exactly ) for ioremap (for our application) but we keep the=20
> same flash mapping (to avoid more problems).
> So how can we do that ? The boot seems OK but there is some=20
> problems in Kernel after uncompressing the kernel image.
> Is the only solution is to inverse the mapping with Ram from=20
> 0 to 258M and the flash above ?
RAM should always start at address 0x0 in your chip select mapping. =
When you pass mem=3D40M Linux will claim
RAM from 0x0 to 0x02800000. The rest of the RAM, 0x02800000 to the end =
will be available for ioremap. The reason your kernel does nothing =
after being uncompressed is because it has no idea where it is and =
probably is not being uncompressed to a valid RAM address.
The sensible place to map FLASH is the end of memory, or anywhere out of =
the way. I assume you are low booting and that is why you think FLASH =
needs to be at the beginning of memory. It does not, even though that =
is where you boot from you can remap the FLASH.
>=20
> Finally, will Busybox work with Ram starting at 0x03000000 ?
Busy box is part of your ramdisk, it does not know anything about the =
memory map. If your kernel does not get past uncompressing then you did =
not get anywhere near busy box running.
^ permalink raw reply
* Réf. : Re: starting RAM adress for linux kernel
From: scarayol @ 2005-06-03 14:55 UTC (permalink / raw)
To: wd; +Cc: ctrichet, linuxppc-embedded
Dear Wolfgang,
we need to have the start of Ram at 0x0300 0000 because we use the comm=
and
mem=3D40M (for uboot) to force Linux
in the low part of memory and to reserve the high part of memory (218M
exactly ) for ioremap (for our application) but we keep
the same flash mapping (to avoid more problems).
So how can we do that ? The boot seems OK but there is some problems in=
Kernel after uncompressing the kernel image.
Is the only solution is to inverse the mapping with Ram from 0 to 258M =
and
the flash above ?
Finally, will Busybox work with Ram starting at 0x03000000 ?
Thank you really for your help.
Sophie CARAYOL.
=
=
Wolfgang Denk =
=
<wd@denx.de> Pour : scarayol@assystembrime=
.com =
Envoy=E9 par : cc : linuxppc-embedded@oz=
labs.org, ctrichet@assystembrime.com =
=20
wd@denx.de Objet : Re: starting RAM =
adress for linux kernel =
=
=
=
=
03/06/05 =
=
16:14 =
=
=
=
=
=
Dear Sophie,
in message <OFED9D0639.75930571-ONC1257015.0031274C@brime.fr> you wrote=
:
>
> We have a platform similar to MPC885ADS (xith Kernel version 2.4.26)
except
> that :
> - the RAM is at 0x0300 0000 (size 0x10000000)
> - the flash is at 0x0280 0000 (size 0x00200000)
> - IMMR =3D 0x0220 0000
Ummm - just to avoid any misunderstandings: there is no technical
reason for such a memory map, and no other good reason either as such
a configuration will not be able to run Linux.
> After u-boot on MPC885ADS, we get the following platform information =
:
> - RAM at 0 size 0x0080 0000
> - FLASH at 0xFE00 0000 size 0x00200000
> - IMMR at 0xFF00 0000
>
> This information is different from the documentation of MPC885ADS :
> - FLASH at 0x0280 0000 size 0x00800000
> - IMMR at 0x0220 0000
So what is your problem? The memory map ist just something you define
as it fits your project. The values in the MPC885ADS are not really
useful for any practical purposes, so U-Boot choses to define
different, more useful values. This is perfectly fine.
> 1) in fads.h of u-boot, it is specified that RAM __must_ start at 0 :=
it
> isn't true on our board :
This applies for your board, too.
> - can linux work with RAM not beginning at 0 on this board ?
You can make it work, but there is no good reason to do this. Juts
change your memory map to use a more sensible configuration.
> - what modifications should we make in the kernel to accept RAM at
0x03000000 ?
Please forget this idea.
> 2) is brd_info the only structure given to kernel by u-boot ?
> That is to say is it the only way for the kernel to have information
about
> the boad ?
It also gets passed the kernel commandline and some other data in
registers.
> 4) are the following values important if CONFIG_HIGHMEM is not defin=
ed
You don't want to play with these data unless you know exactly what
you are doing.
> (they are automatically generated by our Metrowerks PCS tool in
autoconf.h ) ?
Then please ask Metrowerks support who provided such a tool which is
unknown to me.
> 5) is the base value of IMMR very important (real value in u-boot
different
> from documentation) ?
Yes, it is very important. Your current memory map cannot work with
Linux.
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
Fascinating is a word I use for the unexpected.
-- Spock, "The Squire of Gothos", stardate 2124.5
=
^ permalink raw reply
* Re: [PATCH] Fix PPC440 pagetable attributes
From: Kumar Gala @ 2005-06-03 14:42 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-embedded
In-Reply-To: <429F8F86.1040308@am.sony.com>
On Jun 2, 2005, at 6:00 PM, Geoff Levand wrote:
> This patch fixes a bug in the PPC440 pagetable attributes that breaks
> swap support. It also adds some notes on the PPC440 attribute fields.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
>
> --
>
> Index: linux-2.6.12-bhpm/include/asm-ppc/pgtable.h
> ===================================================================
> --- linux-2.6.12-bhpm.orig/include/asm-ppc/pgtable.h 2005-06-02
> 15:09:24.000000000 -0700
> +++ linux-2.6.12-bhpm/include/asm-ppc/pgtable.h 2005-06-02
> 15:47:53.000000000 -0700
> @@ -202,18 +202,64 @@
> *
> * Note that these bits preclude future use of a page size
> * less than 4KB.
> + *
> + *
> + * PPC 440 core has following TLB attribute fields;
> + *
> + * TLB1:
> + * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
> 31
> + * RPN................................. - - - - - -
> ERPN.......
> + *
> + * TLB2:
> + * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
> 31
> + * - - - - - - U0 U1 U2 U3 W I M G E - UX UW UR SX SW
> SR
> + *
> + * There are some constrains and options, to decide mapping software
> bits
> + * into TLB entry.
> + *
> + * - PRESENT *must* be in the bottom three bits because swap cache
> + * entries use the top 29 bits for TLB2.
> + *
> + * - FILE *must* be in the bottom three bits because swap cache
> + * entries use the top 29 bits for TLB2.
> + *
> + * - CACHE COHERENT bit (M) has no effect on PPC440 core, because it
> + * doesn't support SMP. So we can use this as software bit, like
> + * DIRTY.
> + *
> + * PPC Book-E Linux implementation uses PPC HW PTE bit field
> definition,
> + * even it doesn't have HW PTE. 0-11th LSB of PTE stand for memory
> + * protection-related function. (See PTE structure in
> include/asm-ppc/mmu.h)
> + * Definition of _PAGE_XXX in "include/asm-ppc/pagetable.h" stands for
> + * above bits. Note that those bits values are CPU dependent, not
> + * architecture.
> + *
I disagree with this comment. PPC Book-E PTE format has nothing to do
with PPC HW PTE format.
> + * Kernel PTE entry holds arch-dependent swp_entry structure under
> certain
> + * situation. In other words, in such situation, some portion of PTE
> bits
> + * are used as swp_entry. In PPC implementation, 3-24th LSB are
> shared with
> + * swp_entry, however 0-2nd three LSB still hold protection values.
> + * That means three protection bits are reserved for both PTE and SWAP
> + * entry at the most three LSBs.
> + *
> + * There are three protection bits available for SWAP entry;
> + * _PAGE_PRESENT
> + * _PAGE_FILE
> + * _PAGE_HASHPTE (if HW has)
> + *
> + * So those three bits have to be inside of 0-2nd LSB of PTE.
> + *
> */
> +
> #define _PAGE_PRESENT 0x00000001 /* S: PTE valid */
> #define _PAGE_RW 0x00000002 /* S: Write permission */
> -#define _PAGE_DIRTY 0x00000004 /* S: Page dirty */
> +#define _PAGE_FILE 0x00000004 /* S: nonlinear file mapping */
> #define _PAGE_ACCESSED 0x00000008 /* S: Page referenced */
> #define _PAGE_HWWRITE 0x00000010 /* H: Dirty & RW */
> #define _PAGE_HWEXEC 0x00000020 /* H: Execute permission */
> #define _PAGE_USER 0x00000040 /* S: User page */
> #define _PAGE_ENDIAN 0x00000080 /* H: E bit */
> #define _PAGE_GUARDED 0x00000100 /* H: G bit */
> -#define _PAGE_COHERENT 0x00000200 /* H: M bit */
> -#define _PAGE_FILE 0x00000400 /* S: nonlinear file mapping */
> +#define _PAGE_DIRTY 0x00000200 /* S: Page dirty */
> #define _PAGE_NO_CACHE 0x00000400 /* H: I bit */
> #define _PAGE_WRITETHRU 0x00000800 /* H: W bit */
- kumar
^ permalink raw reply
* Re: starting RAM adress for linux kernel
From: Wolfgang Denk @ 2005-06-03 14:14 UTC (permalink / raw)
To: scarayol; +Cc: ctrichet, linuxppc-embedded
In-Reply-To: <OFED9D0639.75930571-ONC1257015.0031274C@brime.fr>
Dear Sophie,
in message <OFED9D0639.75930571-ONC1257015.0031274C@brime.fr> you wrote:
>
> We have a platform similar to MPC885ADS (xith Kernel version 2.4.26) except
> that :
> - the RAM is at 0x0300 0000 (size 0x10000000)
> - the flash is at 0x0280 0000 (size 0x00200000)
> - IMMR = 0x0220 0000
Ummm - just to avoid any misunderstandings: there is no technical
reason for such a memory map, and no other good reason either as such
a configuration will not be able to run Linux.
> After u-boot on MPC885ADS, we get the following platform information :
> - RAM at 0 size 0x0080 0000
> - FLASH at 0xFE00 0000 size 0x00200000
> - IMMR at 0xFF00 0000
>
> This information is different from the documentation of MPC885ADS :
> - FLASH at 0x0280 0000 size 0x00800000
> - IMMR at 0x0220 0000
So what is your problem? The memory map ist just something you define
as it fits your project. The values in the MPC885ADS are not really
useful for any practical purposes, so U-Boot choses to define
different, more useful values. This is perfectly fine.
> 1) in fads.h of u-boot, it is specified that RAM __must_ start at 0 : it
> isn't true on our board :
This applies for your board, too.
> - can linux work with RAM not beginning at 0 on this board ?
You can make it work, but there is no good reason to do this. Juts
change your memory map to use a more sensible configuration.
> - what modifications should we make in the kernel to accept RAM at 0x03000000 ?
Please forget this idea.
> 2) is brd_info the only structure given to kernel by u-boot ?
> That is to say is it the only way for the kernel to have information about
> the boad ?
It also gets passed the kernel commandline and some other data in
registers.
> 4) are the following values important if CONFIG_HIGHMEM is not defined
You don't want to play with these data unless you know exactly what
you are doing.
> (they are automatically generated by our Metrowerks PCS tool in autoconf.h ) ?
Then please ask Metrowerks support who provided such a tool which is
unknown to me.
> 5) is the base value of IMMR very important (real value in u-boot different
> from documentation) ?
Yes, it is very important. Your current memory map cannot work with
Linux.
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
Fascinating is a word I use for the unexpected.
-- Spock, "The Squire of Gothos", stardate 2124.5
^ permalink raw reply
* Re: [RFC] handle access to non-present IO ports on 8xx
From: Mark Chambers @ 2005-06-03 12:08 UTC (permalink / raw)
To: linux-ppc-embedded
In-Reply-To: <1117750262.31082.73.camel@gaston>
> > >
> > > Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With
> > > "proper" PCMCIA controllers, those are swallowed properly when the
card
> > > is removed. The eating of the machine check is a bit too hackish to my
> > > taste... Better is to "not do that" by making sure the legacy crap
isn't
> > > trying to tap unexisting ports, but then, if PCMCIA is also a
> > > problem...
> >
> > Well, cardmgr calls the driver's shutdown/close routine as soon as
> > the card is removed. Some of those methods write to IO registers in
> > the process (eg net/pcmcia/pcnet_cs.c).
> >
> > I dont see any elegant change that could be done in PCMCIA.
>
> I know, the thing is, on platforms with a "classical" PCI<->PCMCIA
> bridge, the bridge will not issue machine checks when the card is
> removed. I don't know if that is possible with your HW setup, I suppose
> you are hooking PCMCIA directly to the CPU IO bus ...
>
I forget if I pointed this out already or not, but there's a good chance the
mchecks you are seeing are from a bad PCMCIA implementation, not
the 8xx itself. PCMCIA uses WAIT, which is a negative ACK really,
and that must be pulled up externally, so if you remove the card any
active WAIT goes away. I'd be glad to take a look at the schematics
if available and tell you if I think there might be a problem there.
Then again, maybe it doesn't matter where the mchecks are coming
from, you just need to handle them...
Mark Chambers
^ permalink raw reply
* Re: [PATCH] ppc32: Rework power management take #3
From: Geoff Levand @ 2005-06-02 22:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1117424155.5228.28.camel@gaston>
I had a problem when building for ppc440 (gcc -m405). I wonder if we
need some conditionals on the DSSALL statement as below, or is DSSALL
intended to be a perprocessor macro that would expand to a blank line
in this case?
-Geoff
dssall-fix.patch:
Index: linux-2.6.12-bhpm/arch/ppc/kernel/swsusp.S
===================================================================
--- linux-2.6.12-bhpm.orig/arch/ppc/kernel/swsusp.S 2005-06-02 15:09:22.000000000 -0700
+++ linux-2.6.12-bhpm/arch/ppc/kernel/swsusp.S 2005-06-02 15:29:56.000000000 -0700
@@ -134,11 +134,13 @@
/* Resume code */
_GLOBAL(swsusp_arch_resume)
+#ifdef CONFIG_ALTIVEC
/* Stop pending alitvec streams and memory accesses */
BEGIN_FTR_SECTION
DSSALL
END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
- sync
+#endif
+ sync
/* Disable MSR:DR to make sure we don't take a TLB or
* hash miss during the copy, as our hash table will
Benjamin Herrenschmidt wrote:
> Ok, the patch is now getting "good enough" for wider testing. It applies
> on current "git" tree (or 2.6.12-rc6 when/if that is ever released). It
> requires one other patch to be applied first:
>
> http://gate.crashing.org/~benh/ppc32-remove-macserial.diff
>
> The PM patch itself can be found at:
>
> http://gate.crashing.org/~benh/ppc32-rework-pm.diff
>
> This patch completely reworks both suspend-to-ram and suspend-to-disk
> support on PowerMac:
>
> - suspend-to-ram code is moved away from the via-pmu.c driver
> - both suspend-to-disk & to-ram consolidated to use the same
> infrastructure and code base in a new pmac_pm.c file
> - significants fixes & improvements to suspend-to-disk
> - for now (may change), use the "refrigerator" with suspend-to-ram as
> well as suspend-to-disk. This may help make it a bit more robust vs.
> userland activity during the sleep process
> - CONFIG_PMAC_PBOOK is gone. CONFIG_PMAC_MEDIABAY is new and controls
> wether the powerbook hostwap bay driver is included. The rest of bits
> formerly under CONFIG_PMAC_PBOOK control are now either always on
> (like /dev/pmu interface on PMU based machines) or dependent on other
> config options (like CONFIG_PM, CONFIG_PPC_PMAC, ...)
>
> The patch will not be in 2.6.12 (though will probably apply on top of
> it). I aim for a 2.6.13 release, knowing that the patch changes a bunch
> of non-ppc-specific power management bits, and thus may need some time
> to be fully merged upstream.
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* RTnet broadcast
From: peng gu @ 2005-06-03 11:01 UTC (permalink / raw)
To: linuxppc-embedded
hello
I am a postgraduate. I only want to use RT-net to generate UDP-packets
every 10 millisecond(broadcast).
I had post my question to the RTnet mailing list to find someone to help
,but no one answer me. may be it is too simple and funny to answer for
them,. but it is hard to me . If I use RTnet only for a packet generator
not for building real-time Ethernet , whether there are something different
from the socket programming to generate UDP packets on a "normal" network?
(for example ,a local network that have one switch, and only one station
broadcasting message to itself,) , If yes, Would you kind to tell me, and
to list the functions of RTnet and RTAI that I must used to do this work.
and tell me where I can find the similar application
would someone give me a hand.
best regards
P.G
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: ppc32: Rework power management take #3
From: Wolfram Quester @ 2005-06-03 9:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1117750504.31082.76.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
On Fri, Jun 03, 2005 at 08:15:03AM +1000, Benjamin Herrenschmidt wrote:
>
> > Today I applied the two mentioned patches to rc5-git6. There were quite
> > a lot of offsets and one time fuzz 2 (hunk 10 in via-pm.c). But still I
> > get a freeze on my PowerBook6,2 (12", 1Ghz from Dec. 2004) when I
> > suspend to disk from X. If I suspend from tty1 the first time, the
> > following suspends work well even from X.
> >
> > Thanks for your work,
>
> Bizarre... The kernel is normally first opens a new tty and switches to
> it before suspend. It seems that this opening of a new tty is
> conflicting in some way with X "nv" driver and causing that freeze. Are
> you also using an fbdev like rivafb or nvidiafb or are you defaulting to
> offb ? If you do, Can you try booting with video=ofonly and tell me if
> it helps ?
>
> Ben.
Normally I use rivafb, but I tried video=ofonly and did not get a
freeze. I tried it three times and I hope that this is good statistics.
With 2.6.12-rc2 and riva fb I got the freeze in about 80% of all initial
suspends, with rc{4,5-git6} and riva fb I had it everytime. But it may
still well be that there is a random component since I learned to
workaround the problem by switching to tty1 and thus don't trigger the
freeze condition that often.
Thanks,
Wolfi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* starting RAM adress for linux kernel
From: scarayol @ 2005-06-03 9:03 UTC (permalink / raw)
To: wd, linuxppc-embedded; +Cc: ctrichet
Hello,
We have a platform similar to MPC885ADS (xith Kernel version 2.4.26) except
that :
- the RAM is at 0x0300 0000 (size 0x10000000)
- the flash is at 0x0280 0000 (size 0x00200000)
- IMMR = 0x0220 0000
After u-boot on MPC885ADS, we get the following platform information :
- RAM at 0 size 0x0080 0000
- FLASH at 0xFE00 0000 size 0x00200000
- IMMR at 0xFF00 0000
This information is different from the documentation of MPC885ADS :
- FLASH at 0x0280 0000 size 0x00800000
- IMMR at 0x0220 0000
1) in fads.h of u-boot, it is specified that RAM __must_ start at 0 : it
isn't true on our board :
- can linux work with RAM not beginning at 0 on this board ?
- what modifications should we make in the kernel to accept RAM at 0x0300
0000 ?
2) is brd_info the only structure given to kernel by u-boot ?
That is to say is it the only way for the kernel to have information about
the boad ?
4) are the following values important if CONFIG_HIGHMEM is not defined
(they are automatically generated by our Metrowerks PCS tool in autoconf.h
) ?
#define CONFIG_HIGHMEM_START 0xfe000000
#define CONFIG_LOWMEM_SIZE 0x30000000
#define CONFIG_KERNEL_START 0xc0000000
#define CONFIG_TASK_SIZE 0x80000000
Should we change these values if CONFIG_HIGHMEM is not defined ?
5) is the base value of IMMR very important (real value in u-boot different
from documentation) ?
Thanks really for your help.
Sophie CARAYOL.
^ permalink raw reply
* [PATCH] Fix PPC440 pagetable attributes
From: Geoff Levand @ 2005-06-02 23:00 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
This patch fixes a bug in the PPC440 pagetable attributes that breaks
swap support. It also adds some notes on the PPC440 attribute fields.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
--
Index: linux-2.6.12-bhpm/include/asm-ppc/pgtable.h
===================================================================
--- linux-2.6.12-bhpm.orig/include/asm-ppc/pgtable.h 2005-06-02 15:09:24.000000000 -0700
+++ linux-2.6.12-bhpm/include/asm-ppc/pgtable.h 2005-06-02 15:47:53.000000000 -0700
@@ -202,18 +202,64 @@
*
* Note that these bits preclude future use of a page size
* less than 4KB.
+ *
+ *
+ * PPC 440 core has following TLB attribute fields;
+ *
+ * TLB1:
+ * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
+ * RPN................................. - - - - - - ERPN.......
+ *
+ * TLB2:
+ * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
+ * - - - - - - U0 U1 U2 U3 W I M G E - UX UW UR SX SW SR
+ *
+ * There are some constrains and options, to decide mapping software bits
+ * into TLB entry.
+ *
+ * - PRESENT *must* be in the bottom three bits because swap cache
+ * entries use the top 29 bits for TLB2.
+ *
+ * - FILE *must* be in the bottom three bits because swap cache
+ * entries use the top 29 bits for TLB2.
+ *
+ * - CACHE COHERENT bit (M) has no effect on PPC440 core, because it
+ * doesn't support SMP. So we can use this as software bit, like
+ * DIRTY.
+ *
+ * PPC Book-E Linux implementation uses PPC HW PTE bit field definition,
+ * even it doesn't have HW PTE. 0-11th LSB of PTE stand for memory
+ * protection-related function. (See PTE structure in include/asm-ppc/mmu.h)
+ * Definition of _PAGE_XXX in "include/asm-ppc/pagetable.h" stands for
+ * above bits. Note that those bits values are CPU dependent, not
+ * architecture.
+ *
+ * Kernel PTE entry holds arch-dependent swp_entry structure under certain
+ * situation. In other words, in such situation, some portion of PTE bits
+ * are used as swp_entry. In PPC implementation, 3-24th LSB are shared with
+ * swp_entry, however 0-2nd three LSB still hold protection values.
+ * That means three protection bits are reserved for both PTE and SWAP
+ * entry at the most three LSBs.
+ *
+ * There are three protection bits available for SWAP entry;
+ * _PAGE_PRESENT
+ * _PAGE_FILE
+ * _PAGE_HASHPTE (if HW has)
+ *
+ * So those three bits have to be inside of 0-2nd LSB of PTE.
+ *
*/
+
#define _PAGE_PRESENT 0x00000001 /* S: PTE valid */
#define _PAGE_RW 0x00000002 /* S: Write permission */
-#define _PAGE_DIRTY 0x00000004 /* S: Page dirty */
+#define _PAGE_FILE 0x00000004 /* S: nonlinear file mapping */
#define _PAGE_ACCESSED 0x00000008 /* S: Page referenced */
#define _PAGE_HWWRITE 0x00000010 /* H: Dirty & RW */
#define _PAGE_HWEXEC 0x00000020 /* H: Execute permission */
#define _PAGE_USER 0x00000040 /* S: User page */
#define _PAGE_ENDIAN 0x00000080 /* H: E bit */
#define _PAGE_GUARDED 0x00000100 /* H: G bit */
-#define _PAGE_COHERENT 0x00000200 /* H: M bit */
-#define _PAGE_FILE 0x00000400 /* S: nonlinear file mapping */
+#define _PAGE_DIRTY 0x00000200 /* S: Page dirty */
#define _PAGE_NO_CACHE 0x00000400 /* H: I bit */
#define _PAGE_WRITETHRU 0x00000800 /* H: W bit */
-EOF
^ permalink raw reply
* Re: Booting the linux-ppc64 kernel & flattened device tree v0.4
From: David Gibson @ 2005-06-03 8:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-embedded, u-boot-users,
linuxppc-dev list, linuxppc64-dev
In-Reply-To: <20050602070918.GI4748@localhost.localdomain>
On Thu, Jun 02, 2005 at 05:09:18PM +1000, David Gibson wrote:
> On Wed, Jun 01, 2005 at 06:26:30PM +1000, Benjamin Herrenschmidt wrote:
> > DO NOT REPLY TO ALL LISTS PLEASE ! (and CC me on replies).
> >
> > Here's the fourth version of my document along with new kernel patches
> > for the new improved flattened format, and the first release of the
> > device-tree "compiler" tool. The patches will be posted as a reply to
> > this email. The compiler, dtc, can be downloaded, the URL is in the
> > document.
>
> [snip]
>
> > IV - "dtc", the device tree compiler
> > ====================================
>
> >
> > dtc source code can be found at
> > <http://ozlabs.org/~dgibson/dtc/dtc.tar.gz>
>
> I've just updated the dtc tarball with a new version. Notable
> changes:
> - Corrected comment parsing
> - Corrected handling of #address-cells, #size-cells properties
> - Input from device tree blobs should actually work now
> - Corrected autogeneration of "name" properties in blob/asm
> output version < 0x10
> - Added a TODO list
And yet another. Notable changes:
- Basic generation of the reserve map in blob output, use -R
command line option to leave space for a number of reserve
map entries to be filled in by bootloader.
- Rewrite blob and assembler output to better share code, and
produce more readable assembler output.
--
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/people/dgibson
^ permalink raw reply
* Re: Getting ownership for various boards/platforms configs
From: Geert Uytterhoeven @ 2005-06-03 8:02 UTC (permalink / raw)
To: Pavel Fedin; +Cc: Linux/PPC Development
In-Reply-To: <42A06E8C.5020705@rambler.ru>
On Fri, 3 Jun 2005, Pavel Fedin wrote:
> Kumar Gala wrote:
> > One issue that comes up from time to time is knowing who to contact about
> > some of the various boards that are supported for PPC. I've suggested in
> > the past that we create a MAINTAINERS file in arch/ppc/platforms.
>
> I am an owner of PegasosII board. You didn't mention it here.
Pegasos II is CHRP, hence under common (and BenH will take care of it? ;-).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Getting ownership for various boards/platforms configs
From: Geert Uytterhoeven @ 2005-06-03 8:01 UTC (permalink / raw)
To: Simon Richter; +Cc: Roman Zippel, linuxppc-dev list, Linux PPC Embedded list
In-Reply-To: <429F965F.1020100@hogyros.de>
On Fri, 3 Jun 2005, Simon Richter wrote:
> Kumar Gala wrote:
>
> > apus
>
> I have such a beast and would like to get 2.6 to compile and work again
> for APUS.
Please coordinate with Roman Zippel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Getting ownership for various boards/platforms configs
From: Pavel Fedin @ 2005-06-03 14:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <bf0d9d49e4c115e67aa5df39e33017a1@freescale.com>
Kumar Gala wrote:
> One issue that comes up from time to time is knowing who to contact
> about some of the various boards that are supported for PPC. I've
> suggested in the past that we create a MAINTAINERS file in
> arch/ppc/platforms.
I am an owner of PegasosII board. You didn't mention it here.
--
Kind regards, Pavel Fedin
^ permalink raw reply
* Re: Booting the linux-ppc64 kernel & flattened device tree v0.4
From: Benjamin Herrenschmidt @ 2005-06-03 7:18 UTC (permalink / raw)
To: u-boot-users; +Cc: linuxppc-dev list, linuxppc-embedded, linuxppc64-dev
In-Reply-To: <1117614484.19020.27.camel@gaston>
On Wed, 2005-06-01 at 18:28 +1000, Benjamin Herrenschmidt wrote:
> Here is the kernel patch. It applies on top of the various prom_init.c
> bug fixes that I already posted today on the linuxppc-dev &
> linuxppc64-dev lists (those will be in the next -mm and maybe in
> 2.6.12).
>
> This patch is intended to hit upstream by 2.6.13
Ok, the patch I posted with version 0.4 implementing version 0x10 of the
format was broken, here is a fixed version against current linus "git"
as of today:
Index: linux-work/arch/ppc64/kernel/prom_init.c
===================================================================
--- linux-work.orig/arch/ppc64/kernel/prom_init.c 2005-06-03 16:52:28.000000000 +1000
+++ linux-work/arch/ppc64/kernel/prom_init.c 2005-06-03 16:58:01.000000000 +1000
@@ -1534,7 +1534,8 @@
*/
#define MAX_PROPERTY_NAME 64
-static void __init scan_dt_build_strings(phandle node, unsigned long *mem_start,
+static void __init scan_dt_build_strings(phandle node,
+ unsigned long *mem_start,
unsigned long *mem_end)
{
unsigned long offset = reloc_offset();
@@ -1547,16 +1548,21 @@
/* get and store all property names */
prev_name = RELOC("");
for (;;) {
- int rc;
-
/* 64 is max len of name including nul. */
namep = make_room(mem_start, mem_end, MAX_PROPERTY_NAME, 1);
- rc = call_prom("nextprop", 3, 1, node, prev_name, namep);
- if (rc != 1) {
+ if (call_prom("nextprop", 3, 1, node, prev_name, namep) != 1) {
/* No more nodes: unwind alloc */
*mem_start = (unsigned long)namep;
break;
}
+
+ /* skip "name" */
+ if (strcmp(namep, RELOC("name")) == 0) {
+ *mem_start = (unsigned long)namep;
+ prev_name = RELOC("name");
+ continue;
+ }
+ /* get/create string entry */
soff = dt_find_string(namep);
if (soff != 0) {
*mem_start = (unsigned long)namep;
@@ -1571,7 +1577,7 @@
/* do all our children */
child = call_prom("child", 1, 1, node);
- while (child != (phandle)0) {
+ while (child != 0) {
scan_dt_build_strings(child, mem_start, mem_end);
child = call_prom("peer", 1, 1, child);
}
@@ -1580,16 +1586,13 @@
static void __init scan_dt_build_struct(phandle node, unsigned long *mem_start,
unsigned long *mem_end)
{
- int l, align;
phandle child;
- char *namep, *prev_name, *sstart, *p, *ep;
+ char *namep, *prev_name, *sstart, *p, *ep, *lp, *path;
unsigned long soff;
unsigned char *valp;
unsigned long offset = reloc_offset();
- char pname[MAX_PROPERTY_NAME];
- char *path;
-
- path = RELOC(prom_scratch);
+ static char pname[MAX_PROPERTY_NAME];
+ int l;
dt_push_token(OF_DT_BEGIN_NODE, mem_start, mem_end);
@@ -1599,23 +1602,33 @@
namep, *mem_end - *mem_start);
if (l >= 0) {
/* Didn't fit? Get more room. */
- if (l+1 > *mem_end - *mem_start) {
+ if ((l+1) > (*mem_end - *mem_start)) {
namep = make_room(mem_start, mem_end, l+1, 1);
call_prom("package-to-path", 3, 1, node, namep, l);
}
namep[l] = '\0';
+
/* Fixup an Apple bug where they have bogus \0 chars in the
* middle of the path in some properties
*/
for (p = namep, ep = namep + l; p < ep; p++)
if (*p == '\0') {
memmove(p, p+1, ep - p);
- ep--; l--;
+ ep--; l--; p--;
}
- *mem_start = _ALIGN(((unsigned long) namep) + strlen(namep) + 1, 4);
+
+ /* now try to extract the unit name in that mess */
+ for (p = namep, lp = NULL; *p; p++)
+ if (*p == '/')
+ lp = p + 1;
+ if (lp != NULL)
+ memmove(namep, lp, strlen(lp) + 1);
+ *mem_start = _ALIGN(((unsigned long) namep) +
+ strlen(namep) + 1, 4);
}
/* get it again for debugging */
+ path = RELOC(prom_scratch);
memset(path, 0, PROM_SCRATCH_SIZE);
call_prom("package-to-path", 3, 1, node, path, PROM_SCRATCH_SIZE-1);
@@ -1623,23 +1636,27 @@
prev_name = RELOC("");
sstart = (char *)RELOC(dt_string_start);
for (;;) {
- int rc;
-
- rc = call_prom("nextprop", 3, 1, node, prev_name, pname);
- if (rc != 1)
+ if (call_prom("nextprop", 3, 1, node, prev_name,
+ RELOC(pname)) != 1)
break;
+ /* skip "name" */
+ if (strcmp(RELOC(pname), RELOC("name")) == 0) {
+ prev_name = RELOC("name");
+ continue;
+ }
+
/* find string offset */
- soff = dt_find_string(pname);
+ soff = dt_find_string(RELOC(pname));
if (soff == 0) {
- prom_printf("WARNING: Can't find string index for <%s>, node %s\n",
- pname, path);
+ prom_printf("WARNING: Can't find string index for"
+ " <%s>, node %s\n", RELOC(pname), path);
break;
}
prev_name = sstart + soff;
/* get length */
- l = call_prom("getproplen", 2, 1, node, pname);
+ l = call_prom("getproplen", 2, 1, node, RELOC(pname));
/* sanity checks */
if (l == PROM_ERROR)
@@ -1648,7 +1665,7 @@
prom_printf("WARNING: ignoring large property ");
/* It seems OF doesn't null-terminate the path :-( */
prom_printf("[%s] ", path);
- prom_printf("%s length 0x%x\n", pname, l);
+ prom_printf("%s length 0x%x\n", RELOC(pname), l);
continue;
}
@@ -1658,17 +1675,16 @@
dt_push_token(soff, mem_start, mem_end);
/* push property content */
- align = (l >= 8) ? 8 : 4;
- valp = make_room(mem_start, mem_end, l, align);
- call_prom("getprop", 4, 1, node, pname, valp, l);
+ valp = make_room(mem_start, mem_end, l, 4);
+ call_prom("getprop", 4, 1, node, RELOC(pname), valp, l);
*mem_start = _ALIGN(*mem_start, 4);
}
/* Add a "linux,phandle" property. */
soff = dt_find_string(RELOC("linux,phandle"));
if (soff == 0)
- prom_printf("WARNING: Can't find string index for <linux-phandle>"
- " node %s\n", path);
+ prom_printf("WARNING: Can't find string index for"
+ " <linux-phandle> node %s\n", path);
else {
dt_push_token(OF_DT_PROP, mem_start, mem_end);
dt_push_token(4, mem_start, mem_end);
@@ -1679,7 +1695,7 @@
/* do all our children */
child = call_prom("child", 1, 1, node);
- while (child != (phandle)0) {
+ while (child != 0) {
scan_dt_build_struct(child, mem_start, mem_end);
child = call_prom("peer", 1, 1, child);
}
@@ -1718,7 +1734,8 @@
/* Build header and make room for mem rsv map */
mem_start = _ALIGN(mem_start, 4);
- hdr = make_room(&mem_start, &mem_end, sizeof(struct boot_param_header), 4);
+ hdr = make_room(&mem_start, &mem_end,
+ sizeof(struct boot_param_header), 4);
RELOC(dt_header_start) = (unsigned long)hdr;
rsvmap = make_room(&mem_start, &mem_end, sizeof(mem_reserve_map), 8);
@@ -1731,11 +1748,11 @@
namep = make_room(&mem_start, &mem_end, 16, 1);
strcpy(namep, RELOC("linux,phandle"));
mem_start = (unsigned long)namep + strlen(namep) + 1;
- RELOC(dt_string_end) = mem_start;
/* Build string array */
prom_printf("Building dt strings...\n");
scan_dt_build_strings(root, &mem_start, &mem_end);
+ RELOC(dt_string_end) = mem_start;
/* Build structure */
mem_start = PAGE_ALIGN(mem_start);
@@ -1750,9 +1767,11 @@
hdr->totalsize = RELOC(dt_struct_end) - RELOC(dt_header_start);
hdr->off_dt_struct = RELOC(dt_struct_start) - RELOC(dt_header_start);
hdr->off_dt_strings = RELOC(dt_string_start) - RELOC(dt_header_start);
+ hdr->dt_strings_size = RELOC(dt_string_end) - RELOC(dt_string_start);
hdr->off_mem_rsvmap = ((unsigned long)rsvmap) - RELOC(dt_header_start);
hdr->version = OF_DT_VERSION;
- hdr->last_comp_version = 1;
+ /* Version 16 is not backward compatible */
+ hdr->last_comp_version = 0x10;
/* Reserve the whole thing and copy the reserve map in, we
* also bump mem_reserve_cnt to cause further reservations to
@@ -1808,6 +1827,9 @@
/* does it need fixup ? */
if (prom_getproplen(i2c, "interrupts") > 0)
return;
+
+ prom_printf("fixing up bogus interrupts for u3 i2c...\n");
+
/* interrupt on this revision of u3 is number 0 and level */
interrupts[0] = 0;
interrupts[1] = 1;
Index: linux-work/arch/ppc64/kernel/prom.c
===================================================================
--- linux-work.orig/arch/ppc64/kernel/prom.c 2005-05-09 14:44:32.000000000 +1000
+++ linux-work/arch/ppc64/kernel/prom.c 2005-06-03 16:58:01.000000000 +1000
@@ -625,8 +625,8 @@
static inline char *find_flat_dt_string(u32 offset)
{
- return ((char *)initial_boot_params) + initial_boot_params->off_dt_strings
- + offset;
+ return ((char *)initial_boot_params) +
+ initial_boot_params->off_dt_strings + offset;
}
/**
@@ -635,26 +635,33 @@
* unflatten the tree
*/
static int __init scan_flat_dt(int (*it)(unsigned long node,
- const char *full_path, void *data),
+ const char *uname, int depth,
+ void *data),
void *data)
{
unsigned long p = ((unsigned long)initial_boot_params) +
initial_boot_params->off_dt_struct;
int rc = 0;
+ int depth = -1;
do {
u32 tag = *((u32 *)p);
char *pathp;
p += 4;
- if (tag == OF_DT_END_NODE)
+ if (tag == OF_DT_END_NODE) {
+ depth --;
+ continue;
+ }
+ if (tag == OF_DT_NOP)
continue;
if (tag == OF_DT_END)
break;
if (tag == OF_DT_PROP) {
u32 sz = *((u32 *)p);
p += 8;
- p = _ALIGN(p, sz >= 8 ? 8 : 4);
+ if (initial_boot_params->version < 0x10)
+ p = _ALIGN(p, sz >= 8 ? 8 : 4);
p += sz;
p = _ALIGN(p, 4);
continue;
@@ -664,9 +671,18 @@
" device tree !\n", tag);
return -EINVAL;
}
+ depth++;
pathp = (char *)p;
p = _ALIGN(p + strlen(pathp) + 1, 4);
- rc = it(p, pathp, data);
+ if ((*pathp) == '/') {
+ char *lp, *np;
+ for (lp = NULL, np = pathp; *np; np++)
+ if ((*np) == '/')
+ lp = np+1;
+ if (lp != NULL)
+ pathp = lp;
+ }
+ rc = it(p, pathp, depth, data);
if (rc != 0)
break;
} while(1);
@@ -689,17 +705,21 @@
const char *nstr;
p += 4;
+ if (tag == OF_DT_NOP)
+ continue;
if (tag != OF_DT_PROP)
return NULL;
sz = *((u32 *)p);
noff = *((u32 *)(p + 4));
p += 8;
- p = _ALIGN(p, sz >= 8 ? 8 : 4);
+ if (initial_boot_params->version < 0x10)
+ p = _ALIGN(p, sz >= 8 ? 8 : 4);
nstr = find_flat_dt_string(noff);
if (nstr == NULL) {
- printk(KERN_WARNING "Can't find property index name !\n");
+ printk(KERN_WARNING "Can't find property index"
+ " name !\n");
return NULL;
}
if (strcmp(name, nstr) == 0) {
@@ -713,7 +733,7 @@
}
static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
- unsigned long align)
+ unsigned long align)
{
void *res;
@@ -727,13 +747,16 @@
static unsigned long __init unflatten_dt_node(unsigned long mem,
unsigned long *p,
struct device_node *dad,
- struct device_node ***allnextpp)
+ struct device_node ***allnextpp,
+ unsigned long fpsize)
{
struct device_node *np;
struct property *pp, **prev_pp = NULL;
char *pathp;
u32 tag;
- unsigned int l;
+ unsigned int l, allocl;
+ int has_name = 0;
+ int new_format = 0;
tag = *((u32 *)(*p));
if (tag != OF_DT_BEGIN_NODE) {
@@ -742,21 +765,62 @@
}
*p += 4;
pathp = (char *)*p;
- l = strlen(pathp) + 1;
+ l = allocl = strlen(pathp) + 1;
*p = _ALIGN(*p + l, 4);
- np = unflatten_dt_alloc(&mem, sizeof(struct device_node) + l,
+ /* version 0x10 has a more compact unit name here instead of the full
+ * path. we accumulate the full path size using "fpsize", we'll rebuild
+ * it later. We detect this because the first character of the name is
+ * not '/'.
+ */
+ if ((*pathp) != '/') {
+ new_format = 1;
+ if (fpsize == 0) {
+ /* root node: special case. fpsize accounts for path
+ * plus terminating zero. root node only has '/', so
+ * fpsize should be 2, but we want to avoid the first
+ * level nodes to have two '/' so we use fpsize 1 here
+ */
+ fpsize = 1;
+ allocl = 2;
+ } else {
+ /* account for '/' and path size minus terminal 0
+ * already in 'l'
+ */
+ fpsize += l;
+ allocl = fpsize;
+ }
+ }
+
+
+ np = unflatten_dt_alloc(&mem, sizeof(struct device_node) + allocl,
__alignof__(struct device_node));
if (allnextpp) {
memset(np, 0, sizeof(*np));
np->full_name = ((char*)np) + sizeof(struct device_node);
- memcpy(np->full_name, pathp, l);
+ if (new_format) {
+ char *p = np->full_name;
+ /* rebuild full path for new format */
+ if (dad && dad->parent) {
+ strcpy(p, dad->full_name);
+#ifdef DEBUG
+ if ((strlen(p) + l + 1) != allocl) {
+ DBG("%s: p: %d, l: %d, a: %d\n",
+ pathp, strlen(p), l, allocl);
+ }
+#endif
+ p += strlen(p);
+ }
+ *(p++) = '/';
+ memcpy(p, pathp, l);
+ } else
+ memcpy(np->full_name, pathp, l);
prev_pp = &np->properties;
**allnextpp = np;
*allnextpp = &np->allnext;
if (dad != NULL) {
np->parent = dad;
- /* we temporarily use the `next' field as `last_child'. */
+ /* we temporarily use the next field as `last_child'*/
if (dad->next == 0)
dad->child = np;
else
@@ -770,18 +834,26 @@
char *pname;
tag = *((u32 *)(*p));
+ if (tag == OF_DT_NOP) {
+ *p += 4;
+ continue;
+ }
if (tag != OF_DT_PROP)
break;
*p += 4;
sz = *((u32 *)(*p));
noff = *((u32 *)((*p) + 4));
- *p = _ALIGN((*p) + 8, sz >= 8 ? 8 : 4);
+ *p += 8;
+ if (initial_boot_params->version < 0x10)
+ *p = _ALIGN(*p, sz >= 8 ? 8 : 4);
pname = find_flat_dt_string(noff);
if (pname == NULL) {
printk("Can't find property name in list !\n");
break;
}
+ if (strcmp(pname, "name") == 0)
+ has_name = 1;
l = strlen(pname) + 1;
pp = unflatten_dt_alloc(&mem, sizeof(struct property),
__alignof__(struct property));
@@ -801,6 +873,36 @@
}
*p = _ALIGN((*p) + sz, 4);
}
+ /* with version 0x10 we may not have the name property, recreate
+ * it here from the unit name if absent
+ */
+ if (!has_name) {
+ char *p = pathp, *ps = pathp, *pa = NULL;
+ int sz;
+
+ while (*p) {
+ if ((*p) == '@')
+ pa = p;
+ if ((*p) == '/')
+ ps = p + 1;
+ p++;
+ }
+ if (pa < ps)
+ pa = p;
+ sz = (pa - ps) + 1;
+ pp = unflatten_dt_alloc(&mem, sizeof(struct property) + sz,
+ __alignof__(struct property));
+ if (allnextpp) {
+ pp->name = "name";
+ pp->length = sz;
+ pp->value = (unsigned char *)(pp + 1);
+ *prev_pp = pp;
+ prev_pp = &pp->next;
+ memcpy(pp->value, ps, sz - 1);
+ ((char *)pp->value)[sz - 1] = 0;
+ DBG("fixed up name for %s -> %s\n", pathp, pp->value);
+ }
+ }
if (allnextpp) {
*prev_pp = NULL;
np->name = get_property(np, "name", NULL);
@@ -812,7 +914,7 @@
np->type = "<NULL>";
}
while (tag == OF_DT_BEGIN_NODE) {
- mem = unflatten_dt_node(mem, p, np, allnextpp);
+ mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
tag = *((u32 *)(*p));
}
if (tag != OF_DT_END_NODE) {
@@ -842,21 +944,27 @@
/* First pass, scan for size */
start = ((unsigned long)initial_boot_params) +
initial_boot_params->off_dt_struct;
- size = unflatten_dt_node(0, &start, NULL, NULL);
+ size = unflatten_dt_node(0, &start, NULL, NULL, 0);
+ size = (size | 3) + 1;
DBG(" size is %lx, allocating...\n", size);
/* Allocate memory for the expanded device tree */
- mem = (unsigned long)abs_to_virt(lmb_alloc(size,
+ mem = (unsigned long)abs_to_virt(lmb_alloc(size + 4,
__alignof__(struct device_node)));
+ ((u32 *)mem)[size / 4] = 0xdeadbeef;
+
DBG(" unflattening...\n", mem);
/* Second pass, do actual unflattening */
start = ((unsigned long)initial_boot_params) +
initial_boot_params->off_dt_struct;
- unflatten_dt_node(mem, &start, NULL, &allnextp);
+ unflatten_dt_node(mem, &start, NULL, &allnextp, 0);
if (*((u32 *)start) != OF_DT_END)
- printk(KERN_WARNING "Weird tag at end of tree: %x\n", *((u32 *)start));
+ printk(KERN_WARNING "Weird tag at end of tree: %08x\n", *((u32 *)start));
+ if (((u32 *)mem)[size / 4] != 0xdeadbeef)
+ printk(KERN_WARNING "End of tree marker overwritten: %08x\n",
+ ((u32 *)mem)[size / 4] );
*allnextp = NULL;
/* Get pointer to OF "/chosen" node for use everywhere */
@@ -880,7 +988,7 @@
static int __init early_init_dt_scan_cpus(unsigned long node,
- const char *full_path, void *data)
+ const char *uname, int depth, void *data)
{
char *type = get_flat_dt_prop(node, "device_type", NULL);
u32 *prop;
@@ -933,13 +1041,15 @@
}
static int __init early_init_dt_scan_chosen(unsigned long node,
- const char *full_path, void *data)
+ const char *uname, int depth, void *data)
{
u32 *prop;
u64 *prop64;
extern unsigned long memory_limit, tce_alloc_start, tce_alloc_end;
- if (strcmp(full_path, "/chosen") != 0)
+ DBG("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
+
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
return 0;
/* get platform type */
@@ -989,18 +1099,20 @@
}
static int __init early_init_dt_scan_root(unsigned long node,
- const char *full_path, void *data)
+ const char *uname, int depth, void *data)
{
u32 *prop;
- if (strcmp(full_path, "/") != 0)
+ if (depth != 0)
return 0;
prop = (u32 *)get_flat_dt_prop(node, "#size-cells", NULL);
dt_root_size_cells = (prop == NULL) ? 1 : *prop;
-
+ DBG("dt_root_size_cells = %x\n", dt_root_size_cells);
+
prop = (u32 *)get_flat_dt_prop(node, "#address-cells", NULL);
dt_root_addr_cells = (prop == NULL) ? 2 : *prop;
+ DBG("dt_root_addr_cells = %x\n", dt_root_addr_cells);
/* break now */
return 1;
@@ -1028,7 +1140,7 @@
static int __init early_init_dt_scan_memory(unsigned long node,
- const char *full_path, void *data)
+ const char *uname, int depth, void *data)
{
char *type = get_flat_dt_prop(node, "device_type", NULL);
cell_t *reg, *endp;
@@ -1044,7 +1156,9 @@
endp = reg + (l / sizeof(cell_t));
- DBG("memory scan node %s ...\n", full_path);
+ DBG("memory scan node %s ..., reg size %ld, data: %x %x %x %x, ...\n",
+ uname, l, reg[0], reg[1], reg[2], reg[3]);
+
while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
unsigned long base, size;
@@ -1455,10 +1569,11 @@
struct device_node *np = allnodes;
read_lock(&devtree_lock);
- for (; np != 0; np = np->allnext)
+ for (; np != 0; np = np->allnext) {
if (np->full_name != 0 && strcasecmp(np->full_name, path) == 0
&& of_node_get(np))
break;
+ }
read_unlock(&devtree_lock);
return np;
}
Index: linux-work/include/asm-ppc64/prom.h
===================================================================
--- linux-work.orig/include/asm-ppc64/prom.h 2005-06-02 08:05:58.000000000 +1000
+++ linux-work/include/asm-ppc64/prom.h 2005-06-03 16:58:01.000000000 +1000
@@ -22,13 +22,15 @@
#define RELOC(x) (*PTRRELOC(&(x)))
/* Definitions used by the flattened device tree */
-#define OF_DT_HEADER 0xd00dfeed /* 4: version, 4: total size */
-#define OF_DT_BEGIN_NODE 0x1 /* Start node: full name */
+#define OF_DT_HEADER 0xd00dfeed /* marker */
+#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
#define OF_DT_END_NODE 0x2 /* End node */
-#define OF_DT_PROP 0x3 /* Property: name off, size, content */
+#define OF_DT_PROP 0x3 /* Property: name off, size,
+ * content */
+#define OF_DT_NOP 0x4 /* nop */
#define OF_DT_END 0x9
-#define OF_DT_VERSION 1
+#define OF_DT_VERSION 0x10
/*
* This is what gets passed to the kernel by prom_init or kexec
@@ -54,7 +56,9 @@
u32 version; /* format version */
u32 last_comp_version; /* last compatible version */
/* version 2 fields below */
- u32 boot_cpuid_phys; /* Which physical CPU id we're booting on */
+ u32 boot_cpuid_phys; /* Physical CPU id we're booting on */
+ /* version 3 fields below */
+ u32 dt_strings_size; /* size of the DT strings block */
};
Index: linux-work/arch/ppc64/kernel/smp.c
===================================================================
--- linux-work.orig/arch/ppc64/kernel/smp.c 2005-06-03 16:52:28.000000000 +1000
+++ linux-work/arch/ppc64/kernel/smp.c 2005-06-03 16:58:01.000000000 +1000
@@ -15,7 +15,7 @@
* 2 of the License, or (at your option) any later version.
*/
-#undef DEBUG
+#define DEBUG
#include <linux/config.h>
#include <linux/kernel.h>
^ permalink raw reply
* Re: [PATCH][1/5] RapidIO support: core
From: Greg KH @ 2005-06-03 7:20 UTC (permalink / raw)
To: Matt Porter; +Cc: akpm, torvalds, linux-kernel, linuxppc-embedded
In-Reply-To: <20050602140359.B24818@cox.net>
On Thu, Jun 02, 2005 at 02:03:59PM -0700, Matt Porter wrote:
> +static struct device rio_bus = {
> + .bus_id = "rapidio",
> +};
Why do you need this device? You shouldn't have a static struct device
to start with. Or you just don't like having your root rio device
showing up in /sys/devices/ ?
If so, just create a kobject and put it there, and then base your
devices off of it, no need for a real device.
Oh wait, that's what the platform and system code does. bah,
nevermind...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH][1/5] RapidIO support: core
From: Greg KH @ 2005-06-03 7:11 UTC (permalink / raw)
To: Matt Porter; +Cc: akpm, torvalds, linux-kernel, linuxppc-embedded
In-Reply-To: <20050602140359.B24818@cox.net>
On Thu, Jun 02, 2005 at 02:03:59PM -0700, Matt Porter wrote:
> +RIO_LOP_READ(8, u8, 1)
> + RIO_LOP_READ(16, u16, 2)
> + RIO_LOP_READ(32, u32, 4)
> + RIO_LOP_WRITE(8, u8, 1)
> + RIO_LOP_WRITE(16, u16, 2)
> + RIO_LOP_WRITE(32, u32, 4)
> +
> + EXPORT_SYMBOL(__rio_local_read_config_8);
> +EXPORT_SYMBOL(__rio_local_read_config_16);
> +EXPORT_SYMBOL(__rio_local_read_config_32);
> +EXPORT_SYMBOL(__rio_local_write_config_8);
> +EXPORT_SYMBOL(__rio_local_write_config_16);
> +EXPORT_SYMBOL(__rio_local_write_config_32);
Odd indenting here.
And why the __rio* stuff for public functions? You should drop the "__"
part.
> +RIO_OP_READ(8, u8, 1)
> + RIO_OP_READ(16, u16, 2)
> + RIO_OP_READ(32, u32, 4)
> + RIO_OP_WRITE(8, u8, 1)
> + RIO_OP_WRITE(16, u16, 2)
> + RIO_OP_WRITE(32, u32, 4)
> +
> + EXPORT_SYMBOL(rio_mport_read_config_8);
> +EXPORT_SYMBOL(rio_mport_read_config_16);
> +EXPORT_SYMBOL(rio_mport_read_config_32);
> +EXPORT_SYMBOL(rio_mport_write_config_8);
> +EXPORT_SYMBOL(rio_mport_write_config_16);
> +EXPORT_SYMBOL(rio_mport_write_config_32);
Again the odd indenting.
> +EXPORT_SYMBOL(rio_mport_send_doorbell);
Just a question, should these be EXPORT_SYMBOL_GPL() as this is GPL
code? Just to be explicit that is.
> +static ssize_t
> +rio_read_config(struct kobject *kobj, char *buf, loff_t off, size_t count)
<snip>
You might want to compare this to the recent changes in the 2.6.12-rc
kernels in the pci sysfs config code. There were some 64 and endian
issues fixed up there that you might want to make sure are also done
properly here.
> +static struct bin_attribute rio_config_attr = {
> + .attr = {
> + .name = "config",
> + .mode = S_IRUGO | S_IWUSR,
> + .owner = THIS_MODULE,
> + },
> + .size = 0x200000,
> + .read = rio_read_config,
> + .write = rio_write_config,
> +};
Wow, that's a huge config space (just a comment, not an issue...)
thanks,
greg k-h
^ permalink raw reply
* Re: Getting ownership for various boards/platforms configs
From: Wojciech Kromer @ 2005-06-03 6:40 UTC (permalink / raw)
In-Reply-To: <bf0d9d49e4c115e67aa5df39e33017a1@freescale.com>
Dnia 2005-06-03 01:19, Użytkownik Kumar Gala napisał:
> One issue that comes up from time to time is knowing who to contact
> about some of the various boards that are supported for PPC. I've
> suggested in the past that we create a MAINTAINERS file in
> arch/ppc/platforms. I've started with a list of all the _defconfigs
> that we have and would like to see if we can get contacts for the
> boards. All this list is meant to be is a contact point.
>
>
There is another issue..
May I suggest to add one full-custom board?
There are a lot of changes to do inside uart,fec,fcc drivers with a lot
of #ifdefs,
just because different use of mpc resources on different boards.
Why it's not configured via menuconfig?
Another nice example is inside status_led.h...
^ permalink raw reply
* Re: [RFC] PlatformDevice definitions for 82xx
From: Kumar Gala @ 2005-06-03 6:13 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <429F30D7.2040806@ru.mvista.com>
On Jun 2, 2005, at 11:16 AM, Vitaly Bordug wrote:
> Hi!
> This adds platform definition files for 82xx, while the platform_info
> is
> filled in board-specific .C file residing in platforms/82xx. Another
> disputable thing I did - I moved m8260_setup.c from the syslib/ up to
> platforms/82xx/. The file was slightly changed - added 2 prototypes
> from the cpm2_pic.h and removed the respective include.
Why the move of m8260_setup.c? Also, if this is required can we do
this as two different patches so we can see clearly any changes also
maded to m8260_setup.c
mpc82xx_devices.c need a bit of work we need to at least cover the same
set of devices that 85xx does for the CPM:
SPI, I2C, USB, SCC1-4, FCC1-3, MCC1-2, SMC1-2
Additionally, the device name can not me FS_ENET_NAME, which assumes
that FCC is only used for enet.
mpc82xx_sys.c: what is the .value field? is this the IMMR and if so
why bother shifting it? Also there are a whole bunch of variants that
need to be captured
Let's get clean versions of these two files before we worry about how
to handle FCC enet specific bits.
- kumar
^ permalink raw reply
* Re: Getting ownership for various boards/platforms configs
From: Kumar Gala @ 2005-06-03 5:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Linux PPC Embedded list
In-Reply-To: <1117758135.31082.104.camel@gaston>
Ben,
Can I put you do for maintainer of pmac and common? any others?
- kumar
On Jun 2, 2005, at 7:22 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2005-06-02 at 19:09 -0500, Kumar Gala wrote:
>> On Jun 2, 2005, at 7:00 PM, Mark A. Greer wrote:
>>
>>> Two things:
>>>
>>> 1) What is "common" in your list?
>>
>> Good question, hopefully Paul knows. I just did an ls in
>> arch/ppc/configs/ to create the list.
>
> it's pmac+chrp+prep in a single image
>
> 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