* Re: local_irq_save not masking interrupts
From: Esben Nielsen @ 2006-09-27 16:52 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <4518FA21.8050801@cambridgebroadband.com>
On Tue, 26 Sep 2006, Alex Zeffertt wrote:
> Hi list,
>
> I'm having a strange problem with interrupts. My platform is the
> MPC832xEMDS and the BSP I'm using (from Freescale) uses Linux-2.6.11.
>
> In the code below I enter a critical section with local_irq_save(),
> call request_irq() (from mpc832xemds_phy_interrupt_enable) 4 times,
> then exit the critical section using local_irq_restore.
>
> /* Enable interrupts from PHYs */
> local_irq_save(flags);
> for (i = 0; i < driver_data->num_phys; i++) {
> struct atm_dev *dev = driver_data->dev_data[i]->dev;
> printk("%s/%d\n",__FUNCTION__,__LINE__);
> RETURN_ON_ERROR(mpc832xemds_phy_interrupt_enable(dev));
> }
> local_irq_restore(flags);
>
This is a pure side-comment:
Please, don't use local_irq_save() for a critical region. Use
spin_lock_irqsave(), for 3 reasons:
1) SMP.
2) Preempt-realtime is like SMP not happy about using local_irq_save().
3) Read-ability: It is more clear what data is protected when there is a
named lock object in the code.
You might not care about 1) and 2) but 3) should matter for you. And
remember: When CONFIG_SMP is not set spin_lock_irqsave() will just
become a local_irq_save().
Esben
^ permalink raw reply
* iommu hypervisor hypothetical
From: John Rose @ 2006-09-27 16:47 UTC (permalink / raw)
To: Santiago Leon, benh, External List
Suppose the hypervisor added new failure codes for the hcall that does
tce_build(). Suppose that the device driver needed to expect such
failures when alloc_[coherent,consistent] is not successful, and handle
that case accordingly.
Is this something we can accommodate without rewriting the iommu stuff
for various platforms? All these functions in machdep.h are defined to
return NULL. Is this because we haven't had a reasonable expectation of
failure, or because device drivers _have_ to assume success for such
operations?
Thanks-
John
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Olof Johansson @ 2006-09-27 16:22 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Paul, Mackerras
In-Reply-To: <CE624A83-809E-4180-800E-660A578FFCFC@embeddedalley.com>
On Wed, 27 Sep 2006 10:42:17 -0400 Dan Malek <dan@embeddedalley.com> wrote:
> Since BCSRs are board specific, does anyone remember
> the day when a simple #define, ioremap, and a few lines
> of code in the board setup file was all that was needed? :-)
Yes, also called "board port hell". One of the major points with the
device tree is that the needed information for the system is in there,
not compiled into the kernel. So you can boot the same kernel binary on
several boards, as long as the drivers are built in and the correct
device tree is used. Has everyone missed/forgotten that objective
completely?
> What wrong with still doing that? It seems everyone is
> obsessed with device tree syntax and forget that a
> few lines of code may still be a reasonable solution.
The device tree describes the system, not how to program it. I think
that's where the confusion might be.
I.e. create a generic "board-controller" device node, and put a
suitable "compatible" property in there, so the right board controller
driver can be chosen based on it. Having the address of the controller
in there helps too, especially if there are two boards out there with
the same controller but at different memory location.
-Olof
^ permalink raw reply
* RE: Asterisk on Embedded Linux
From: Stelios Koroneos @ 2006-09-27 16:01 UTC (permalink / raw)
To: Iwan Koenig, Linuxppc-embedded
In-Reply-To: <20060926064451.71706.qmail@web26012.mail.ukl.yahoo.com>
> -----Original Message-----
> Does anyone known how to compile Asterisk for a
> powerpc-processor?
Asterisk + bristuff (for isdn support) for uclibc does crosscompile (and
run) but needs patching in several places (make files and asterisk itself).
We got the zaptel drivers to cross-compile also but it seems there are
endianess issues with the drivers we now try to iron out.
The main "difference" is that we have used OpenEmbedded as our build system
in order to get going.
^ permalink raw reply
* Re: [PATCH 1/2] Add powerpc get/set_rtc_time interface to new generic rtc class
From: Tom Rini @ 2006-09-27 15:59 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060926174637.1f70938d.kim.phillips@freescale.com>
On Tue, Sep 26, 2006 at 05:46:37PM -0500, Kim Phillips wrote:
[snip]
> --- a/include/asm-powerpc/time.h
> +++ b/include/asm-powerpc/time.h
> @@ -39,6 +39,10 @@ extern void generic_calibrate_decr(void)
> extern void wakeup_decrementer(void);
> extern void snapshot_timebase(void);
>
> +#ifdef CONFIG_RTC_CLASS
> +extern int __init rtc_class_hookup(void);
> +#endif
Conditional code doesn't usually get externs ifdef'd, unless I'm
mistaken.
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
From: Tom Rini @ 2006-09-27 15:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B35FD5A1-2C71-41E2-A014-A2C8D37F10C2@kernel.crashing.org>
On Tue, Sep 26, 2006 at 11:34:43PM -0500, Kumar Gala wrote:
> On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
[snip]
> > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> > powerpc/platforms/83xx/mpc834x_itx.c
> > index 969fbb6..8c676d7 100644
> > --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> > return 1;
> > }
> >
> > +#ifdef CONFIG_RTC_CLASS
> > +late_initcall(rtc_class_hookup);
> > +#endif
>
> Any reason we can't just do this in setup_arch?
I think because of rtc-over-i2c and similar where we need the whole rest
of the system 'up' before we can try and use the RTC (which might not be
the case for this specific board, but for consistency it looks like a
good thing to always do it like this).
--
Tom Rini
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Fredrik Roubert @ 2006-09-27 15:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060913132817.GD18263@igloo.df.lth.se>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
On Wed 13 Sep 15:28 CEST 2006, Fredrik Roubert wrote:
> > Matt's u-boot patches address the issue well for 85xx, they are
> > straightforward to adapt to 83xx:
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_id=15518792&forum_id=12898
>
> OK, I've adapted and applied those patches now.
In case someone else also is interested in using Matt's flat device tree
patches with U-Boot 1.1.4, I've posted my backport of the relevant parts
of the patch to the u-boot-users mailing list now.
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Sergei Shtylyov @ 2006-09-27 14:57 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
Hello.
Vitaly Bordug wrote:
>>>>>+#define BCSR_PHYS_ADDR ((uint)0xf8000000)
>>>>>+#define BCSR_SIZE ((uint)(32 * 1024))
>>>>This sort of thing should really be in the device tree.
>>>Just a suggestion, but for the similar aim in pq2 I have those stuff
>>in memory node :
>>>+memory {
>>>+ device_type = "memory";
>>>+ linux,phandle = <300>;
>>>+ reg = <00000000 4000000 f4500000 00000020>;
>>>+ };
>>>the second pair is about bcsr and its size.
>>>Just in case this may help (and wondering if I'm not violating
>>something :) )
>>Well, this can make it work. But I would prefer to use a new node
>>because the BCSR is by no means a memory type of device. I have made my
>>change to use node like this:
>> bcsr@f8000000 {
>> device_type = "board-control";
>> reg = <f8000000 8000>;
>> };
> I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff.
You might have utilized "memory" even for the Ethernet controllers guided
by such logic. Of course, that was a wrong criterion -- "memory" is for RAM,
otherwise you'd be fooling the kernel device tree scanner which looks for the
"memory" nodes.
> I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).
And this is hardly a memory, neverthless.
WBR, Sergei
^ permalink raw reply
* Re: Need help to write I2C EEPROM device driver
From: Matthias Fuchs @ 2006-09-27 14:51 UTC (permalink / raw)
To: Sachin Rane; +Cc: linuxppc-embedded
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B34F6593@sbsserver.AlphionCorp.local>
On Wednesday 27 September 2006 16:11, Sachin Rane wrote:
> To access EEPROM using /dev/i2c-<x>, which drivers I need to load?
>
> Please confirm that I need to load following drivers:
> 1. i2c-core.ko (Core Driver)
> 2. i2c-ibm-iic.ko (Bus Driver)
> 3. i2c-dev.ko (Dev Interface driver)
That looks good.
> Do I need to load 'eeprom.ko'?
No.
> Because in one of the mail from the mailing list, it was mentioned that I
should not load ''eeprom.ko" to access the chip using 'dev' interface.
Either use access via /dev/i2c-x or via eeprom driver. I haven't used the
later one so far. Using both at the same time is probably not possible.
Matthias
>
> Thanks and Regards,
> Sachin Rane
>
> ________________________________
>
> From: Matthias Fuchs [mailto:matthias.fuchs@esd-electronics.com]
> Sent: Wed 9/27/2006 6:21 AM
> To: linuxppc-embedded@ozlabs.org
> Cc: Sachin Rane
> Subject: Re: Need help to write I2C EEPROM device driver
>
>
>
> Hi Sachin,
>
> there is already a driver for this part in the kernel
> (drivers/i2c/chips/eeprom.c).
>
> BTW: to do some simple reads and writes to an I2C EEPROM it is very simple
to
> access the EEPROM via read/write/ioctl through /dev/i2c-<x>. No driver -
only
> userland code.
>
> Matthias
>
>
> On Tuesday 26 September 2006 16:34, Sachin Rane wrote:
> > Hi,
> >
> > I am looking for an information to write a device driver to access EEPROM
IC
> M24C02-WBN6.
> > The EEPROM IC M24C02-WBN is present on the 'ppc440' evaluation board for
> boot strap purpose.
>
>
>
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Fredrik Roubert @ 2006-09-27 14:49 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-embedded
In-Reply-To: <1159210763.5485.10.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
On Mon 25 Sep 20:59 CEST 2006, Matthew McClintock wrote:
> Can you verify the flat device tree passed to the kernel is correct?
> Specifically these properties:
>
> timebase-frequency = <0>; // from bootloader
> bus-frequency = <0>; // from bootloader
> clock-frequency = <0>; // from bootloader
Right on target! These values were not set up correctly, and after
fixing that I can now boot an unmodified powerpc 2.6.18 kernel.
Thank you so very much!
Are your flat device tree patches going to be included in the mainline
U-Boot in the future, or is it likely that some other method will be
used?
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Dan Malek @ 2006-09-27 14:42 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
On Sep 27, 2006, at 8:55 AM, Vitaly Bordug wrote:
> hence let's open a discussion what others think about that. The
> problem seems common (and for some boards
> is called somewhat else apparently), but at this point we should
> come to some conclusion, document it, and use it.
Well, I haven't voiced my opinion lately.......... :-)
I think this is totally out of control. I don't even know what
we are trying to create here any more. We took a reasonable
idea to express some configuration flexibility and are running
off into into some world that we think we need to create
something infinitely flexible that anyone can use for anything
they wish. I could expect this from a university research
project, but not from seasoned developers that are trying
to create products where only a few real configuration
combinations make sense.
Since BCSRs are board specific, does anyone remember
the day when a simple #define, ioremap, and a few lines
of code in the board setup file was all that was needed? :-)
What wrong with still doing that? It seems everyone is
obsessed with device tree syntax and forget that a
few lines of code may still be a reasonable solution.
I still think an embedded_feature_call() support in a
board port would be the best solution to many of these
complex things we are trying to define in this device
tree information. In the places where we need some
kind of board specific support, like hardware set up for
some peripheral, just do the feature_call, passing enough
information to indicate what is needed, and let the
board support do what is necessary. This could be
setting bits in a BCSR, setting up the processor IO
ports, enabling power to external logic, etc. This has
been proven to work well on the PMAC, just extend it
to be used on embedded boards.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Jon Loeliger @ 2006-09-27 14:14 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19D866@zch01exm20.fsl.freescale.net>
So, like, the other day "Li Yang-r58472" mumbled:
> Agreed. As we are adding more devices to the device tree, we should
> also have a guideline clearly stated for adding new nodes.
>
> I'm adding MURAM as a new node under QE bus. Please comment.
> muram@10000 {
> device_type = "memory";
> ranges = <0 00010000 0000c000>;
>
> data-only@0{
> reg = <0 c000>;
> };
> };
>
> - Leo
So, does it make sense for this node to participate in the early scan
of memory available during the early_init_dt_scan_memory() pass?
Out of curiosity, is "data-only" a standard thing, or did you make
that up too? What's it mean?
And your patch for this new node introduction will contain
proposed additions to the QE section of the booting-without-of
documentation, right?
Thanks,
jdl
^ permalink raw reply
* RE: Need help to write I2C EEPROM device driver
From: Sachin Rane @ 2006-09-27 14:11 UTC (permalink / raw)
To: Matthias Fuchs, linuxppc-embedded
In-Reply-To: <200609271221.54878.matthias.fuchs@esd-electronics.com>
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
Hi Matthias,
Thanks for reply.
To access EEPROM using /dev/i2c-<x>, which drivers I need to load?
Please confirm that I need to load following drivers:
1. i2c-core.ko (Core Driver)
2. i2c-ibm-iic.ko (Bus Driver)
3. i2c-dev.ko (Dev Interface driver)
Do I need to load 'eeprom.ko'?
Because in one of the mail from the mailing list, it was mentioned that I should not load ''eeprom.ko" to access the chip using 'dev' interface.
Thanks and Regards,
Sachin Rane
________________________________
From: Matthias Fuchs [mailto:matthias.fuchs@esd-electronics.com]
Sent: Wed 9/27/2006 6:21 AM
To: linuxppc-embedded@ozlabs.org
Cc: Sachin Rane
Subject: Re: Need help to write I2C EEPROM device driver
Hi Sachin,
there is already a driver for this part in the kernel
(drivers/i2c/chips/eeprom.c).
BTW: to do some simple reads and writes to an I2C EEPROM it is very simple to
access the EEPROM via read/write/ioctl through /dev/i2c-<x>. No driver - only
userland code.
Matthias
On Tuesday 26 September 2006 16:34, Sachin Rane wrote:
> Hi,
>
> I am looking for an information to write a device driver to access EEPROM IC
M24C02-WBN6.
> The EEPROM IC M24C02-WBN is present on the 'ppc440' evaluation board for
boot strap purpose.
[-- Attachment #2: Type: text/html, Size: 2589 bytes --]
^ permalink raw reply
* RE: [PATCH 10/11] Add MPC8360EMDS board support
From: Joakim Tjernlund @ 2006-09-27 13:54 UTC (permalink / raw)
To: Li Yang-r58472, Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
>=20
> I'm adding MURAM as a new node under QE bus. Please comment.
> muram@10000 {
> device_type =3D "memory";
> ranges =3D <0 00010000 0000c000>;
>=20
> data-only@0{
> reg =3D <0 c000>;
> };
> };
while you are at it, I think you should add support for the ASSIGN PAGE
command that can relocate
the parameter RAM used by UCC, SPI etc. As it is now the third(8400) and
fourth(100) value
in reg below is ignored.
ucc@2000 {
device_type =3D "network";
compatible =3D "ucc_geth";
model =3D "UCC";
device-id =3D <1>;
reg =3D <2000 200 8400 100>;
MPC832x only has 16KB of parameter RAM and needs to move this to lower
addresses.=20
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Kumar Gala @ 2006-09-27 13:33 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19D866@zch01exm20.fsl.freescale.net>
>>>> +memory {
>>>> + device_type = "memory";
>>>> + linux,phandle = <300>;
>>>> + reg = <00000000 4000000 f4500000 00000020>;
>>>> + };
>>>> the second pair is about bcsr and its size.
>>>>
>>>> Just in case this may help (and wondering if I'm not violating
>>> something :) )
>>>
>>> Well, this can make it work. But I would prefer to use a new node
>>> because the BCSR is by no means a memory type of device. I have
> made my
>>> change to use node like this:
>>>
>>> bcsr@f8000000 {
>>> device_type = "board-control";
>>> reg = <f8000000 8000>;
>>> };
>>>
>>
>> I though about that approach, but saw somewhere a reference that we
> should not summon
>> new node types without utter necessity, and utilized memory because
> bcsr is
>> memory-mapped stuff. I can hardly imagine bcsr as a device (which
> would require
>> respective spec inclusion btw).
>
> Well I didn't see such a guideline. However BCSR is truly a device
> like
> any other peripherals on board. Usually it is an FPGA on local bus to
> control the board.
Agree that a new node is better, calling it memory isn't right.
However, I'm not sure this really needs a node in the device tree.
The BCSR isn't really the same from board to board last time I
checked. I'd be interested in Paul's thinking about why it should be
in the tree.
>> hence let's open a discussion what others think about that. The
> problem seems common
>> (and for some boards
>> is called somewhat else apparently), but at this point we should come
> to some
>> conclusion, document it, and use it.
>
> Agreed. As we are adding more devices to the device tree, we should
> also have a guideline clearly stated for adding new nodes.
>
> I'm adding MURAM as a new node under QE bus. Please comment.
> muram@10000 {
> device_type = "memory";
> ranges = <0 00010000 0000c000>;
>
> data-only@0{
> reg = <0 c000>;
> };
> };
What was the need for this?
- kumar
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Ben Warren @ 2006-09-27 13:09 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
On Wed, 2006-09-27 at 16:55 +0400, Vitaly Bordug wrote:
>
> I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff. I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).
>
> hence let's open a discussion what others think about that. The problem seems common (and for some boards
> is called somewhat else apparently), but at this point we should come to some conclusion, document it, and use it.
>
Since "memory" is not quite specific enough, but "board-control" is a
little bit Freescale and application-centric, how about
"memmapped-device", or something like that. This could encompass FPGAs,
ASICs, CPLDs or anything else that is memory mapped. Many custom
embedded boards have lots of such devices and could benefit from this
approach.
regards,
Ben
^ permalink raw reply
* flash operations in linux on ML403
From: Ming Liu @ 2006-09-27 13:24 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
Can anyone tell me, how to include the driver for flash chips on ML403
board and make the flash chip a visible device which could be written or
read in Linux 2.6? I notice that there is a item called "MTD" in the
"device driver" in the kernel menuconfig. Is that the driver for the flash
chip? And also how to make it visiable in /dev/ ? Thanks in advance for
your telling.
Regards
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* RE: [PATCH 10/11] Add MPC8360EMDS board support
From: Li Yang-r58472 @ 2006-09-27 13:20 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Wednesday, September 27, 2006 8:56 PM
> To: Li Yang-r58472
> Cc: Paul Mackerras; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> On Wed, 27 Sep 2006 20:02:56 +0800
> "Li Yang-r58472" <LeoLi@freescale.com> wrote:
>=20
> > > -----Original Message-----
> > > From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> > > Sent: Wednesday, September 27, 2006 7:56 PM
> > > To: Paul Mackerras
> > > Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> > > Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
> > >
> > > On Wed, 27 Sep 2006 16:39:11 +1000
> > > Paul Mackerras <paulus@samba.org> wrote:
> > >
> > > > Li Yang writes:
> > > >
> > > > > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > > > > +#define BCSR_SIZE ((uint)(32 * 1024))
> > > >
> > > > This sort of thing should really be in the device tree.
> > > >
> > > Just a suggestion, but for the similar aim in pq2 I have those
stuff
> > in memory node :
> > >
> > > +memory {
> > > + device_type =3D "memory";
> > > + linux,phandle =3D <300>;
> > > + reg =3D <00000000 4000000 f4500000 00000020>;
> > > + };
> > > the second pair is about bcsr and its size.
> > >
> > > Just in case this may help (and wondering if I'm not violating
> > something :) )
> >
> > Well, this can make it work. But I would prefer to use a new node
> > because the BCSR is by no means a memory type of device. I have
made my
> > change to use node like this:
> >
> > bcsr@f8000000 {
> > device_type =3D "board-control";
> > reg =3D <f8000000 8000>;
> > };
> >
>=20
> I though about that approach, but saw somewhere a reference that we
should not summon
> new node types without utter necessity, and utilized memory because
bcsr is
> memory-mapped stuff. I can hardly imagine bcsr as a device (which
would require
> respective spec inclusion btw).
Well I didn't see such a guideline. However BCSR is truly a device like
any other peripherals on board. Usually it is an FPGA on local bus to
control the board.
>=20
> hence let's open a discussion what others think about that. The
problem seems common
> (and for some boards
> is called somewhat else apparently), but at this point we should come
to some
> conclusion, document it, and use it.
Agreed. As we are adding more devices to the device tree, we should
also have a guideline clearly stated for adding new nodes. =20
I'm adding MURAM as a new node under QE bus. Please comment.
muram@10000 {
device_type =3D "memory";
ranges =3D <0 00010000 0000c000>;
data-only@0{
reg =3D <0 c000>;
};
};
- Leo
^ permalink raw reply
* Re: [PATCH] Use check_legacy_ioport() for ISAPnP
From: Olaf Hering @ 2006-09-27 13:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1159361385.3309.118.camel@pmac.infradead.org>
On Wed, Sep 27, David Woodhouse wrote:
> And did you fix the case of PCI parallel ports? We only want to do the
> check_legacy_ioport() thing for the 'default' built-in ports, not for
> all ports.
I have to check if my multiport IO card still works, but I'm sure it
will.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Vitaly Bordug @ 2006-09-27 12:55 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19D865@zch01exm20.fsl.freescale.net>
On Wed, 27 Sep 2006 20:02:56 +0800
"Li Yang-r58472" <LeoLi@freescale.com> wrote:
> > -----Original Message-----
> > From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> > Sent: Wednesday, September 27, 2006 7:56 PM
> > To: Paul Mackerras
> > Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
> >
> > On Wed, 27 Sep 2006 16:39:11 +1000
> > Paul Mackerras <paulus@samba.org> wrote:
> >
> > > Li Yang writes:
> > >
> > > > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > > > +#define BCSR_SIZE ((uint)(32 * 1024))
> > >
> > > This sort of thing should really be in the device tree.
> > >
> > Just a suggestion, but for the similar aim in pq2 I have those stuff
> in memory node :
> >
> > +memory {
> > + device_type = "memory";
> > + linux,phandle = <300>;
> > + reg = <00000000 4000000 f4500000 00000020>;
> > + };
> > the second pair is about bcsr and its size.
> >
> > Just in case this may help (and wondering if I'm not violating
> something :) )
>
> Well, this can make it work. But I would prefer to use a new node
> because the BCSR is by no means a memory type of device. I have made my
> change to use node like this:
>
> bcsr@f8000000 {
> device_type = "board-control";
> reg = <f8000000 8000>;
> };
>
I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff. I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).
hence let's open a discussion what others think about that. The problem seems common (and for some boards
is called somewhat else apparently), but at this point we should come to some conclusion, document it, and use it.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] Use check_legacy_ioport() for ISAPnP
From: David Woodhouse @ 2006-09-27 12:49 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060927081838.GA5984@aepfle.de>
On Wed, 2006-09-27 at 10:18 +0200, Olaf Hering wrote:
> Isnt that fixed by my other patch which was merged into -mm today?
Hm, wasn't aware of that.
/me looks...
No, your patch seems to change pnpbios, not isapnp. Which is odd, since
pnpbios is x86-only anyway.
And did you fix the case of PCI parallel ports? We only want to do the
check_legacy_ioport() thing for the 'default' built-in ports, not for
all ports.
--
dwmw2
^ permalink raw reply
* [PATCH V2] Create a "wrapper" script and use it in arch/powerpc/boot
From: Paul Mackerras @ 2006-09-27 12:47 UTC (permalink / raw)
To: linuxppc-dev
This puts the knowledge of how to create various sorts of zImage
wrappers into a script called "wrapper" that could be used outside of
the kernel tree. This changes arch/powerpc/boot so it first builds
the files that the wrapper script needs, then runs it to create
whatever flavours of zImage are required.
This version does uImages as well. The zImage names are changed
slightly; zImage.pseries is the one with the PT_NOTE program header
entry added, and zImage.pmac is the one without. If the
zImage.pseries gets made, it will also get hardlinked to zImage;
otherwise, if zImage.pmac is made, it gets hardlinked to zImage.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..a00fe72 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -20,6 +20,7 @@ CROSS32_COMPILE ?=
CROSS32CC := $(CROSS32_COMPILE)gcc
CROSS32AS := $(CROSS32_COMPILE)as
CROSS32LD := $(CROSS32_COMPILE)ld
+CROSS32AR := $(CROSS32_COMPILE)ar
CROSS32OBJCOPY := $(CROSS32_COMPILE)objcopy
ifeq ($(HAS_BIARCH),y)
@@ -28,10 +29,11 @@ CROSS32CC := $(CC) -m32
CROSS32AS := $(AS) -a32
CROSS32LD := $(LD) -m elf32ppc
CROSS32OBJCOPY := $(OBJCOPY)
+CROSS32AR := $(AR)
endif
endif
-export CROSS32CC CROSS32AS CROSS32LD CROSS32OBJCOPY
+export CROSS32CC CROSS32AS CROSS32LD CROSS32AR CROSS32OBJCOPY
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
@@ -146,7 +148,7 @@ all: $(KBUILD_IMAGE)
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm uImage vmlinux.bin
+BOOT_TARGETS = zImage zImage.initrd uImage
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e737741..962fa4e 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -20,33 +20,34 @@ # To make it easier to setup a cross com
# CROSS32_COMPILE is setup as a prefix just like CROSS_COMPILE
# in the toplevel makefile.
+all: $(obj)/zImage
HOSTCC := gcc
BOOTCFLAGS := $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
$(shell $(CROSS32CC) -print-file-name=include) -fPIC
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
-OBJCOPYFLAGS := contents,alloc,load,readonly,data
-OBJCOPY_COFF_ARGS := -O aixcoff-rs6000 --set-start 0x500000
-OBJCOPY_MIB_ARGS := -O aixcoff-rs6000 -R .stab -R .stabstr -R .comment
+
+ifeq ($(call cc-option-yn, -fstack-protector),y)
+BOOTCFLAGS += -fno-stack-protector
+endif
+
+BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
zlib := inffast.c inflate.c inftrees.c
zlibheader := inffast.h inffixed.h inflate.h inftrees.h infutil.h
zliblinuxheader := zlib.h zconf.h zutil.h
-$(addprefix $(obj)/,$(zlib) main.o): $(addprefix $(obj)/,$(zliblinuxheader)) $(addprefix $(obj)/,$(zlibheader))
-#$(addprefix $(obj)/,main.o): $(addprefix $(obj)/,zlib.h)
+$(addprefix $(obj)/,$(zlib) main.o): $(addprefix $(obj)/,$(zliblinuxheader)) \
+ $(addprefix $(obj)/,$(zlibheader))
+
+src-wlib := string.S stdio.c main.c div64.S $(zlib)
+src-plat := of.c
+src-boot := crt0.S $(src-wlib) $(src-plat) empty.c
-src-boot-$(CONFIG_PPC_MULTIPLATFORM) := of.c
-src-boot := crt0.S string.S stdio.c main.c div64.S $(src-boot-y)
-src-boot += $(zlib)
src-boot := $(addprefix $(obj)/, $(src-boot))
obj-boot := $(addsuffix .o, $(basename $(src-boot)))
-
-ifeq ($(call cc-option-yn, -fstack-protector),y)
-BOOTCFLAGS += -fno-stack-protector
-endif
-
-BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
+obj-wlib := $(addsuffix .o, $(basename $(addprefix $(obj)/, $(src-wlib))))
+obj-plat := $(addsuffix .o, $(basename $(addprefix $(obj)/, $(src-plat))))
quiet_cmd_copy_zlib = COPY $@
cmd_copy_zlib = sed "s@__attribute_used__@@;s@<linux/\([^>]\+\).*@\"\1\"@" $< > $@
@@ -66,8 +67,14 @@ quiet_cmd_copy_zliblinuxheader = COPY
$(addprefix $(obj)/,$(zliblinuxheader)): $(obj)/%: $(srctree)/include/linux/%
$(call cmd,copy_zliblinuxheader)
-clean-files := $(zlib) $(zlibheader) $(zliblinuxheader)
+$(obj)/empty.c:
+ @touch $@
+
+$(obj)/zImage.lds $(obj)/zImage.coff.lds: $(obj)/%: $(srctree)/$(src)/%.S
+ @cp $< $@
+clean-files := $(zlib) $(zlibheader) $(zliblinuxheader) \
+ $(obj)/empty.c
quiet_cmd_bootcc = BOOTCC $@
cmd_bootcc = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
@@ -75,146 +82,97 @@ quiet_cmd_bootcc = BOOTCC $@
quiet_cmd_bootas = BOOTAS $@
cmd_bootas = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<
-quiet_cmd_bootld = BOOTLD $@
- cmd_bootld = $(CROSS32LD) -T $(srctree)/$(src)/$(3) -o $@ $(2)
+quiet_cmd_bootar = BOOTAR $@
+ cmd_bootar = $(CROSS32AR) -cr $@.$$$$ $^; mv $@.$$$$ $@
$(patsubst %.c,%.o, $(filter %.c, $(src-boot))): %.o: %.c
$(call if_changed_dep,bootcc)
$(patsubst %.S,%.o, $(filter %.S, $(src-boot))): %.o: %.S
$(call if_changed_dep,bootas)
-#-----------------------------------------------------------
-# ELF sections within the zImage bootloader/wrapper
-#-----------------------------------------------------------
-required := vmlinux.strip
-initrd := initrd
+$(obj)/wrapper.a: $(obj-wlib)
+ $(call cmd,bootar)
-obj-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.o, $(section)))
-src-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.c, $(section)))
-gz-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.gz, $(section)))
+hostprogs-y := addnote addRamDisk hack-coff
-hostprogs-y := addnote addRamDisk hack-coff
+extra-y := $(obj)/crt0.o $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
+ $(obj)/zImage.lds $(obj)/zImage.coff.lds
-targets += zImage.vmode zImage.initrd.vmode zImage zImage.initrd \
- zImage.coff zImage.initrd.coff miboot.image miboot.initrd.image \
- $(patsubst $(obj)/%,%, $(call obj-sec, $(required) $(initrd))) \
- $(patsubst $(obj)/%,%, $(call src-sec, $(required) $(initrd))) \
- $(patsubst $(obj)/%,%, $(call gz-sec, $(required) $(initrd))) \
- vmlinux.initrd dummy.o
-extra-y := initrd.o
+wrapper :=$(srctree)/$(src)/wrapper
+wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff)
-quiet_cmd_ramdisk = RAMDISK $@
- cmd_ramdisk = $(obj)/addRamDisk $(obj)/ramdisk.image.gz $< $@
+#############
+# Bits for building various flavours of zImage
-quiet_cmd_stripvm = STRIP $@
- cmd_stripvm = $(STRIP) -s -R .comment $< -o $@
+ifneq ($(CROSS32_COMPILE),)
+CROSSWRAP := -C $(CROSS32_COMPILE)
+else
+ifneq ($(CROSS_COMPILE),)
+CROSSWRAP := -C $(CROSS_COMPILE)
+endif
+endif
-vmlinux.strip: vmlinux
- $(call if_changed,stripvm)
-$(obj)/vmlinux.initrd: vmlinux.strip $(obj)/addRamDisk $(obj)/ramdisk.image.gz
- $(call if_changed,ramdisk)
+quiet_cmd_wrap = WRAP $@
+ cmd_wrap =$(wrapper) -c -o $@ -p $2 $(CROSSWRAP) vmlinux
+quiet_cmd_wrap_initrd = WRAP $@
+ cmd_wrap_initrd =$(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
+ -i $(obj)/ramdisk.image.gz vmlinux
-quiet_cmd_addsection = ADDSEC $@
- cmd_addsection = $(CROSS32OBJCOPY) $@ \
- --add-section=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $@))=$(patsubst %.o,%.gz, $@) \
- --set-section-flags=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $@))=$(OBJCOPYFLAGS)
+$(obj)/zImage.chrp: vmlinux $(wrapperbits)
+ $(call cmd,wrap,chrp)
-quiet_cmd_addnote = ADDNOTE $@
- cmd_addnote = $(obj)/addnote $@
+$(obj)/zImage.initrd.chrp: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,chrp)
-quiet_cmd_gen-miboot = GEN $@
- cmd_gen-miboot = $(OBJCOPY) $(OBJCOPY_MIB_ARGS) \
- --add-section=$1=$(word 2, $^) $< $@
+$(obj)/zImage.pseries: vmlinux $(wrapperbits)
+ $(call cmd,wrap,pseries)
-quiet_cmd_gencoff = COFF $@
- cmd_gencoff = $(OBJCOPY) $(OBJCOPY_COFF_ARGS) $@ && \
- $(obj)/hack-coff $@
+$(obj)/zImage.initrd.pseries: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,pseries)
-$(call gz-sec, $(required)): $(obj)/kernel-%.gz: %
- $(call if_changed,gzip)
+$(obj)/zImage.pmac: vmlinux $(wrapperbits)
+ $(call cmd,wrap,pmac)
-$(obj)/kernel-initrd.gz: $(obj)/ramdisk.image.gz
- cp -f $(obj)/ramdisk.image.gz $@
+$(obj)/zImage.initrd.pmac: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,pmac)
-$(call src-sec, $(required) $(initrd)): $(obj)/kernel-%.c: $(obj)/kernel-%.gz
- @touch $@
+$(obj)/zImage.coff: vmlinux $(wrapperbits)
+ $(call cmd,wrap,pmaccoff)
-$(call obj-sec, $(required) $(initrd)): $(obj)/kernel-%.o: $(obj)/kernel-%.c
- $(call if_changed_dep,bootcc)
- $(call cmd,addsection)
+$(obj)/zImage.initrd.coff: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,pmaccoff)
+
+$(obj)/zImage.miboot: vmlinux $(wrapperbits)
+ $(call cmd,wrap,miboot)
-$(obj)/zImage.vmode $(obj)/zImage.coff: obj-boot += $(call obj-sec, $(required))
-$(obj)/zImage.vmode: $(call obj-sec, $(required)) $(obj-boot) $(srctree)/$(src)/zImage.lds
- $(call cmd,bootld,$(obj-boot),zImage.lds)
+$(obj)/zImage.initrd.miboot: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,miboot)
-$(obj)/zImage.initrd.vmode $(obj)/zImage.initrd.coff: obj-boot += $(call obj-sec, $(required) $(initrd))
-$(obj)/zImage.initrd.vmode: $(call obj-sec, $(required) $(initrd)) $(obj-boot) $(srctree)/$(src)/zImage.lds
- $(call cmd,bootld,$(obj-boot),zImage.lds)
+$(obj)/uImage: vmlinux $(wrapperbits)
+ $(call cmd,wrap,uboot)
+
+image-$(CONFIG_PPC_PSERIES) += zImage.pseries
+image-$(CONFIG_PPC_MAPLE) += zImage.pseries
+image-$(CONFIG_PPC_CELL) += zImage.pseries
+image-$(CONFIG_PPC_CHRP) += zImage.chrp
+image-$(CONFIG_PPC_PMAC) += zImage.pmac
+image-$(CONFIG_DEFAULT_UIMAGE) += uImage
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
-coffimage-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/zImage.coff
-coffrdimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/zImage.initrd.coff
-mibootimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/miboot.image
-mibrdimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/miboot.initrd.image
-
-$(obj)/zImage: $(obj)/zImage.vmode $(obj)/addnote $(coffimage-y-y) \
- $(mibootimg-y-y)
- @cp -f $< $@
- $(call if_changed,addnote)
-
-$(obj)/zImage.initrd: $(obj)/zImage.initrd.vmode $(obj)/addnote \
- $(coffrdimg-y-y) $(mibrdimg-y-y)
- @cp -f $< $@
- $(call if_changed,addnote)
-
-$(obj)/zImage.coff: $(call obj-sec, $(required)) $(obj-boot) \
- $(srctree)/$(src)/zImage.coff.lds $(obj)/hack-coff
- $(call cmd,bootld,$(obj-boot),zImage.coff.lds)
- $(call cmd,gencoff)
-
-$(obj)/zImage.initrd.coff: $(call obj-sec, $(required) $(initrd)) $(obj-boot) \
- $(srctree)/$(src)/zImage.coff.lds $(obj)/hack-coff
- $(call cmd,bootld,$(obj-boot),zImage.coff.lds)
- $(call cmd,gencoff)
-
-$(obj)/miboot.image: $(obj)/dummy.o $(obj)/vmlinux.gz
- $(call cmd,gen-miboot,image)
-
-$(obj)/miboot.initrd.image: $(obj)/miboot.image $(images)/ramdisk.image.gz
- $(call cmd,gen-miboot,initrd)
-
-#-----------------------------------------------------------
-# build u-boot images
-#-----------------------------------------------------------
-quiet_cmd_mygzip = GZIP $@
-cmd_mygzip = gzip -f -9 < $< > $@.$$$$ && mv $@.$$$$ $@
-
-quiet_cmd_objbin = OBJCOPY $@
- cmd_objbin = $(OBJCOPY) -O binary $< $@
-
-quiet_cmd_uimage = UIMAGE $@
- cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T kernel \
- -C gzip -a 00000000 -e 00000000 -n 'Linux-$(KERNELRELEASE)' \
- -d $< $@
-
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
-targets += uImage
-extra-y += vmlinux.bin vmlinux.gz
-
-$(obj)/vmlinux.bin: vmlinux FORCE
- $(call if_changed,objbin)
-
-$(obj)/vmlinux.gz: $(obj)/vmlinux.bin FORCE
- $(call if_changed,mygzip)
-
-$(obj)/uImage: $(obj)/vmlinux.gz
- $(Q)rm -f $@
- $(call cmd,uimage)
- @echo -n ' Image: $@ '
- @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
-
-install: $(CONFIGURE) $(BOOTIMAGE)
- sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
-
-clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+ifeq ($(CONFIG_PPC32),y)
+image-$(CONFIG_PPC_PMAC) += zImage.coff zImage.miboot
+endif
+
+initrd-y := $(patsubst zImage%, zImage.initrd%, $(image-y))
+
+$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
+ @rm -f $@; ln $< $@
+$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
+ @rm -f $@; ln $< $@
+
+install: $(CONFIGURE) $(image-y)
+ sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" $<
+
+clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip.gz)
+clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.bin.gz)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
new file mode 100755
index 0000000..eab7318
--- /dev/null
+++ b/arch/powerpc/boot/wrapper
@@ -0,0 +1,204 @@
+#!/bin/sh
+
+# Copyright (C) 2006 Paul Mackerras, IBM Corporation <paulus@samba.org>
+# This program may be used under the terms of version 2 of the GNU
+# General Public License.
+
+# This script takes a kernel binary and optionally an initrd image
+# and/or a device-tree blob, and creates a bootable zImage for a
+# given platform.
+
+# Options:
+# -o zImage specify output file
+# -p platform specify platform (links in $platform.o)
+# -i initrd specify initrd file
+# -d devtree specify device-tree blob
+# -s tree.dts specify device-tree source file (needs dtc installed)
+# -c cache $kernel.strip.gz (use if present & newer, else make)
+# -C prefix specify command prefix for cross-building tools
+# (strip, objcopy, ld)
+# -D dir specify directory containing data files used by script
+# (default ./arch/powerpc/boot)
+# -W dir specify working directory for temporary files (default .)
+
+# defaults
+kernel=
+ofile=zImage
+platform=of
+initrd=
+dtb=
+dts=
+cacheit=
+
+# cross-compilation prefix
+CROSS=
+
+# directory for object and other files used by this script
+object=arch/powerpc/boot
+
+# directory for working files
+tmpdir=.
+
+usage() {
+ echo 'Usage: wrapper [-o output] [-p platform] [-i initrd]' >&2
+ echo ' [-d devtree] [-s tree.dts] [-c] [-C cross-prefix]' >&2
+ echo ' [-D datadir] [-W workingdir] [vmlinux]' >&2
+ exit 1
+}
+
+while [ "$#" -gt 0 ]; do
+ case "$1" in
+ -o)
+ shift
+ [ "$#" -gt 0 ] || usage
+ ofile="$1"
+ ;;
+ -p)
+ shift
+ [ "$#" -gt 0 ] || usage
+ platform="$1"
+ ;;
+ -i)
+ shift
+ [ "$#" -gt 0 ] || usage
+ initrd="$1"
+ ;;
+ -d)
+ shift
+ [ "$#" -gt 0 ] || usage
+ dtb="$1"
+ ;;
+ -s)
+ shift
+ [ "$#" -gt 0 ] || usage
+ dts="$1"
+ ;;
+ -c)
+ cacheit=y
+ ;;
+ -C)
+ shift
+ [ "$#" -gt 0 ] || usage
+ CROSS="$1"
+ ;;
+ -D)
+ shift
+ [ "$#" -gt 0 ] || usage
+ object="$1"
+ ;;
+ -W)
+ shift
+ [ "$#" -gt 0 ] || usage
+ tmpdir="$1"
+ ;;
+ -?)
+ usage
+ ;;
+ *)
+ [ -z "$kernel" ] || usage
+ kernel="$1"
+ ;;
+ esac
+ shift
+done
+
+if [ -n "$dts" ]; then
+ if [ -z "$dtb" ]; then
+ dtb="$platform.dtb"
+ fi
+ dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
+fi
+
+if [ -z "$kernel" ]; then
+ kernel=vmlinux
+fi
+
+platformo=$object/"$platform".o
+lds=$object/zImage.lds
+ext=strip
+objflags=-S
+tmp=$tmpdir/zImage.$$.o
+ksection=.kernel:vmlinux.strip
+isection=.kernel:initrd
+
+case "$platform" in
+pmac|pseries|chrp)
+ platformo=$object/of.o
+ ;;
+pmaccoff)
+ platformo=$object/of.o
+ lds=$object/zImage.coff.lds
+ ;;
+miboot|uboot)
+ # miboot and U-boot want just the bare bits, not an ELF binary
+ ext=bin
+ objflags="-O binary"
+ tmp="$ofile"
+ ksection=image
+ isection=initrd
+ ;;
+esac
+
+vmz="$tmpdir/`basename \"$kernel\"`.$ext"
+if [ -z "$cacheit" -o ! -f "$vmz.gz" -o "$vmz.gz" -ot "$kernel" ]; then
+ ${CROSS}objcopy $objflags "$kernel" "$vmz.$$"
+ gzip -f -9 "$vmz.$$"
+ if [ -n "$cacheit" ]; then
+ mv -f "$vmz.$$.gz" "$vmz.gz"
+ else
+ vmz="$vmz.$$"
+ fi
+fi
+
+case "$platform" in
+uboot)
+ rm -f "$ofile"
+ version=`${CROSS}strings "$kernel" | grep '^Linux version [-0-9.]' | \
+ cut -d' ' -f3`
+ if [ -n "$version" ]; then
+ version="-n Linux-$version"
+ fi
+ mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
+ $version -d "$vmz.gz" "$ofile"
+ if [ -z "$cacheit" ]; then
+ rm -f $vmz.gz
+ fi
+ exit 0
+ ;;
+esac
+
+addsec() {
+ ${CROSS}objcopy $4 $1 \
+ --add-section=$3="$2" \
+ --set-section-flags=$3=contents,alloc,load,readonly,data
+}
+
+addsec $tmp "$vmz.gz" $ksection $object/empty.o
+if [ -z "$cacheit" ]; then
+ rm -f "$vmz.gz"
+fi
+
+if [ -n "$initrd" ]; then
+ addsec $tmp "$initrd" initrd
+fi
+
+if [ -n "$dtb" ]; then
+ addsec $tmp "$dtb" dtb
+fi
+
+if [ "$platform" != "miboot" ]; then
+ ${CROSS}ld -m elf32ppc -T $lds -o "$ofile" \
+ $object/crt0.o $platformo $tmp $object/wrapper.a
+ rm $tmp
+fi
+
+# post-processing needed for some platforms
+case "$platform" in
+pseries|chrp)
+ $object/addnote "$ofile"
+ ;;
+pmaccoff)
+ ${CROSS}objcopy -O aixcoff-rs6000 --set-start 0x500000 "$ofile"
+ $object/hack-coff "$ofile"
+ ;;
+esac
diff --git a/arch/powerpc/boot/zImage.coff.lds b/arch/powerpc/boot/zImage.coff.lds
deleted file mode 100644
index 6016251..0000000
--- a/arch/powerpc/boot/zImage.coff.lds
+++ /dev/null
@@ -1,46 +0,0 @@
-OUTPUT_ARCH(powerpc:common)
-ENTRY(_start)
-SECTIONS
-{
- . = (5*1024*1024);
- _start = .;
- .text :
- {
- *(.text)
- *(.fixup)
- }
- _etext = .;
- . = ALIGN(4096);
- .data :
- {
- *(.rodata*)
- *(.data*)
- *(.sdata*)
- __got2_start = .;
- *(.got2)
- __got2_end = .;
-
- _vmlinux_start = .;
- *(.kernel:vmlinux.strip)
- _vmlinux_end = .;
-
- _initrd_start = .;
- *(.kernel:initrd)
- _initrd_end = .;
- }
-
- . = ALIGN(4096);
- _edata = .;
- __bss_start = .;
- .bss :
- {
- *(.sbss)
- *(.bss)
- }
- _end = . ;
-
- /DISCARD/ :
- {
- *(.comment)
- }
-}
diff --git a/arch/powerpc/boot/zImage.coff.lds.S b/arch/powerpc/boot/zImage.coff.lds.S
new file mode 100644
index 0000000..6016251
--- /dev/null
+++ b/arch/powerpc/boot/zImage.coff.lds.S
@@ -0,0 +1,46 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(_start)
+SECTIONS
+{
+ . = (5*1024*1024);
+ _start = .;
+ .text :
+ {
+ *(.text)
+ *(.fixup)
+ }
+ _etext = .;
+ . = ALIGN(4096);
+ .data :
+ {
+ *(.rodata*)
+ *(.data*)
+ *(.sdata*)
+ __got2_start = .;
+ *(.got2)
+ __got2_end = .;
+
+ _vmlinux_start = .;
+ *(.kernel:vmlinux.strip)
+ _vmlinux_end = .;
+
+ _initrd_start = .;
+ *(.kernel:initrd)
+ _initrd_end = .;
+ }
+
+ . = ALIGN(4096);
+ _edata = .;
+ __bss_start = .;
+ .bss :
+ {
+ *(.sbss)
+ *(.bss)
+ }
+ _end = . ;
+
+ /DISCARD/ :
+ {
+ *(.comment)
+ }
+}
diff --git a/arch/powerpc/boot/zImage.lds b/arch/powerpc/boot/zImage.lds
deleted file mode 100644
index 4b6bb3f..0000000
--- a/arch/powerpc/boot/zImage.lds
+++ /dev/null
@@ -1,46 +0,0 @@
-OUTPUT_ARCH(powerpc:common)
-ENTRY(_zimage_start)
-SECTIONS
-{
- . = (4*1024*1024);
- _start = .;
- .text :
- {
- *(.text)
- *(.fixup)
- }
- _etext = .;
- . = ALIGN(4096);
- .data :
- {
- *(.rodata*)
- *(.data*)
- *(.sdata*)
- __got2_start = .;
- *(.got2)
- __got2_end = .;
- }
-
- . = ALIGN(4096);
- _vmlinux_start = .;
- .kernel:vmlinux.strip : { *(.kernel:vmlinux.strip) }
- _vmlinux_end = .;
-
- . = ALIGN(4096);
- _initrd_start = .;
- .kernel:initrd : { *(.kernel:initrd) }
- _initrd_end = .;
-
- . = ALIGN(4096);
- _edata = .;
-
- . = ALIGN(4096);
- __bss_start = .;
- .bss :
- {
- *(.sbss)
- *(.bss)
- }
- . = ALIGN(4096);
- _end = . ;
-}
diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
new file mode 100644
index 0000000..4b6bb3f
--- /dev/null
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -0,0 +1,46 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(_zimage_start)
+SECTIONS
+{
+ . = (4*1024*1024);
+ _start = .;
+ .text :
+ {
+ *(.text)
+ *(.fixup)
+ }
+ _etext = .;
+ . = ALIGN(4096);
+ .data :
+ {
+ *(.rodata*)
+ *(.data*)
+ *(.sdata*)
+ __got2_start = .;
+ *(.got2)
+ __got2_end = .;
+ }
+
+ . = ALIGN(4096);
+ _vmlinux_start = .;
+ .kernel:vmlinux.strip : { *(.kernel:vmlinux.strip) }
+ _vmlinux_end = .;
+
+ . = ALIGN(4096);
+ _initrd_start = .;
+ .kernel:initrd : { *(.kernel:initrd) }
+ _initrd_end = .;
+
+ . = ALIGN(4096);
+ _edata = .;
+
+ . = ALIGN(4096);
+ __bss_start = .;
+ .bss :
+ {
+ *(.sbss)
+ *(.bss)
+ }
+ . = ALIGN(4096);
+ _end = . ;
+}
^ permalink raw reply related
* RE: [PATCH 10/11] Add MPC8360EMDS board support
From: Li Yang-r58472 @ 2006-09-27 12:02 UTC (permalink / raw)
To: Vitaly Bordug, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060927155626.4d5ca19c@vitb.ru.mvista.com>
> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Wednesday, September 27, 2006 7:56 PM
> To: Paul Mackerras
> Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> On Wed, 27 Sep 2006 16:39:11 +1000
> Paul Mackerras <paulus@samba.org> wrote:
>=20
> > Li Yang writes:
> >
> > > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > > +#define BCSR_SIZE ((uint)(32 * 1024))
> >
> > This sort of thing should really be in the device tree.
> >
> Just a suggestion, but for the similar aim in pq2 I have those stuff
in memory node :
>=20
> +memory {
> + device_type =3D "memory";
> + linux,phandle =3D <300>;
> + reg =3D <00000000 4000000 f4500000 00000020>;
> + };
> the second pair is about bcsr and its size.
>=20
> Just in case this may help (and wondering if I'm not violating
something :) )
Well, this can make it work. But I would prefer to use a new node
because the BCSR is by no means a memory type of device. I have made my
change to use node like this:
bcsr@f8000000 {
device_type =3D "board-control";
reg =3D <f8000000 8000>;
};
- Leo
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Vitaly Bordug @ 2006-09-27 11:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Li Yang
In-Reply-To: <17690.7311.157219.154172@cargo.ozlabs.ibm.com>
On Wed, 27 Sep 2006 16:39:11 +1000
Paul Mackerras <paulus@samba.org> wrote:
> Li Yang writes:
>
> > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > +#define BCSR_SIZE ((uint)(32 * 1024))
>
> This sort of thing should really be in the device tree.
>
Just a suggestion, but for the similar aim in pq2 I have those stuff in memory node :
+memory {
+ device_type = "memory";
+ linux,phandle = <300>;
+ reg = <00000000 4000000 f4500000 00000020>;
+ };
the second pair is about bcsr and its size.
Just in case this may help (and wondering if I'm not violating something :) )
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Need help to write I2C EEPROM device driver
From: Matthias Fuchs @ 2006-09-27 10:21 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Sachin Rane
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B34F658F@sbsserver.AlphionCorp.local>
Hi Sachin,
there is already a driver for this part in the kernel
(drivers/i2c/chips/eeprom.c).
BTW: to do some simple reads and writes to an I2C EEPROM it is very simple to
access the EEPROM via read/write/ioctl through /dev/i2c-<x>. No driver - only
userland code.
Matthias
On Tuesday 26 September 2006 16:34, Sachin Rane wrote:
> Hi,
>
> I am looking for an information to write a device driver to access EEPROM IC
M24C02-WBN6.
> The EEPROM IC M24C02-WBN is present on the 'ppc440' evaluation board for
boot strap purpose.
^ 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