* Re: [PATCH, RFC] linkstation: implement standby
From: Johannes Berg @ 2007-08-29 10:32 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Stephen Rothwell, linuxppc-dev, Pavel Machek, linux-pm
In-Reply-To: <Pine.LNX.4.60.0708290015580.3552@poirot.grange>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
On Wed, 2007-08-29 at 00:30 +0200, Guennadi Liakhovetski wrote:
> > > +#ifdef CONFIG_PM
> >
> > some of those probably want to be CONFIG_PM_SLEEP now.
>
> Well, I wasn't sure when PM can be used not meaning PM_SLEEP, so, I left
> PM for now. Can certainly change, if it really matters.
You end up compiling more code than necessary if PM_SLEEP is disabled
but PM is enabled (i.e. runtime powermanagement enabled but no sleep
states)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: Newbie and linux on virtex-II ppc
From: schardt @ 2007-08-29 9:29 UTC (permalink / raw)
To: Linux PPC Linux PPC
In-Reply-To: <fa686aa40708280744g29cb8e17r6153271cd67117ed@mail.gmail.com>
Step by step i becomes running :)
kernel is booting, root-fs is mounting on systemace, busybox compiled
and rootfs installed (i used klingauf's mkrootfs)
but now it says:
[ 2.964978] Freeing unused kernel memory: 92k init
[ 3.081332] Warning: unable to open an initial console.
[ 3.306406] request_module: runaway loop modprobe binfmt-4c46
[ 3.375612] request_module: runaway loop modprobe binfmt-4c46
[ 3.446800] request_module: runaway loop modprobe binfmt-4c46
and i don't know what this is :(
Can give me a hint, where to look ?
thx
Georg
Grant Likely wrote:
> On 8/28/07, Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> On 8/28/07, schardt <g.schardt@fz-juelich.de> wrote:
>>
>>> Okay, im really blind i think, so i started again :
>>>
>>> - 2.6.22 kernel from kernel.org
>>> - cp /arch/ppc/configs/ml300_defconfig .config
>>>
>
> BTW, "make ml300_defconfig" does this for you.
>
> g.
>
>
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* RE: ppc_8xx-gcc from eldk strange behaviour
From: DI BACCO ANTONIO - technolabs @ 2007-08-29 9:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20070828190158.GA21155@ld0162-tx32.am.freescale.net>
> C does not specify the signedness of char. If you care, you need to
> explicitly specify.
Sorry, I didn't know this. Anyway I would expect the same behaviour from
both host gcc and ppc_8xx-gcc. In this case host gcc is wrong.=20
Bye,
Antonio.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 1/5] spu_manage: use newer physical-id
From: Ishizaki Kou @ 2007-08-29 8:56 UTC (permalink / raw)
To: krafft; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel, arnd, jk
In-Reply-To: <20070828162011.5356afaa@localhost>
Christian Krafft wrote:
> On Thu, 23 Aug 2007 18:12:19 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Thursday 23 August 2007, kou.ishizaki@toshiba.co.jp wrote:
> > > Please check "unit-id" if "physical-id" doesn't exist. Because
Celleb
> > > uses "unit-id" to provide spe_id.
>
> Sorry for the late answer, wasn't on cc
> and had to receive all mails of the last 6 month once again :-(
>
> Can you check if the patch below is working with celleb device tree ?
>
> ------
> Subject: spu_manage: fix spu_unit_number for celleb device tree
>
> From: Christian Krafft <krafft@de.ibm.com>
>
> New device trees provide "physical-id".
> Celleb device tree provide the "unit-id".
> Legacy device tree used the reg property for the physical id of an
spe.
> This patch fixes find_spu_unit_number to look for the spu id in that
order.
> The length is checked to avoid misinterpretation in case the
attributes
> unit-id or reg do not contain the id.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Acked-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
It works good on Celleb, thanks. Please apply it to 2.6.23.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: Domen Puncer @ 2007-08-29 8:43 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
In-Reply-To: <20070829061300.GF3206@localhost.localdomain>
On 29/08/07 16:13 +1000, David Gibson wrote:
<snip>
> static int __devinit of_physmap_probe(struct of_device *dev, const struct of_device_id *match)
> {
> struct device_node *dp = dev->node;
> struct resource res;
> struct physmap_flash_info *info;
> - const char **probe_type;
> - const char *of_probe;
> + const char *probe_type = (const char *)match->data;
> const u32 *width;
> int err;
>
> + dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
> + "flash binding\n");
This is printed for new binding too :-)
Other than this, it works fine for me.
Domen
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-29 8:43 UTC (permalink / raw)
To: James Chapman
Cc: tklein, themann, stefan.roscher, netdev, linux-kernel, raisch,
linuxppc-dev, akepner, meder, shemminger, David Miller
In-Reply-To: <46D52B14.8010508@katalix.com>
On Wednesday 29 August 2007 10:15, James Chapman wrote:
> Jan-Bernd Themann wrote:
> > What I'm trying to improve with this approach is interrupt
> > mitigation for NICs where the hardware support for interrupt
> > mitigation is limited. I'm not trying to improve this for NICs
> > that work well with the means their HW provides. I'm aware of
> > the fact that this scheme has it's tradeoffs and certainly
> > can not be as good as a HW approach.
> > So I'm grateful for any ideas that do have less tradeoffs and
> > provide a mechanism to reduce interrupts without depending on
> > HW support of the NIC.
> >
> > In the end I want to reduce the CPU utilization. And one way
> > to do that is LRO which also works only well if there are more
> > then just a very few packets to aggregate. So at least our
> > driver (eHEA) would benefit from a mix of timer based polling
> > and plain NAPI (depending on load situations).
>
> Wouldn't you achieve the same result by enabling hardware interrupt
> mitigation in eHEA in combination with NAPI? Presumably a 10G interface
> has hardware mitigation features?
Quote from above: "What I'm trying to improve with this approach
is interrupt mitigation for NICs where the hardware support for
interrupt mitigation is limited"
So guess why I'm doing that ;-)
>
> > If there is no need for a generic mechanism for this kind of
> > network adapters, then we can just leave this to each device
> > driver.
>
> I've been looking at this from a different angle. My goal is to optimize
> NAPI packet forwarding rates while minimizing packet latency. Using
> hardware interrupt mitigation hurts latency so I'm investigating ways to
> turn it off without risking NAPI poll on/off thrashing at certain packet
> rates.
>
> Jan-Bernd, I think I've found a solution to the issue that you
> highlighted with my scheme yesterday and it doesn't involve generating
> other interrupts using hrtimers etc. :) Initial results are very
> encouraging in my setups. Would you be willing to test it with eHEA? I
> don't have a 10G setup. If results are encouraging, I'll post an RFC to
> ask for review / feedback from the NAPI experts here. What do you think?
>
I'm not sure which solution you mean. If you post your RFC, please create
a new thread (other title)
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-29 8:41 UTC (permalink / raw)
To: Grant Likely; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <fa686aa40708280828h408ce7damf04b31a2048d40c4@mail.gmail.com>
Hi Grant,
My zImage.elf has 1.1 MB and uImage 968 KB.
Could you tell me please how to hook up GDB to debug u-boot?
I have examined the file in u-boot which does the bootelf:
cat common/cmd_elf.c:
int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
:
:
:
:
addr = load_elf_image (addr);
printf ("## Starting application at 0x%08lx ...\n", addr);
/*
* QNX images require the data cache is disabled.
* Data cache is already flushed, so just turn it off.
*/
if (dcache_status ())
dcache_disable ();
/*
* pass address parameter as argv[0] (aka command name),
* and all remaining args
*/
rc = ((ulong (*)(int, char *[])) addr) (--argc, &argv[1]);
:
:
}
and I have determined that the system hangs just after the command:
rc = ((ulong (*)(int, char *[])) addr) (--argc, &argv[1]);
This command starts executing the linux image from the location:
0x00400000
On the console it is printed the following stuff:
loaded at: 00400000 004F3138
board data at: 004F1120 004F1138
relocated to: 004040B4 004040CC
zimage at: 00404E59 004F003D
avail ram: 004F4000 01FFFFFF
Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...
It seems to be that it is the Linux kernel which does the uncompression
and it hangs. The question remain why?
Maybe it is not enough space in RAM or the address in RAM where the
uncompression is done is wrong.
When I load the u-boot to ram via jtag it is placed under the address:
0x800000 as follows:
section, .text: 0x00800000-0x0081513c
section, .resetvec: 0x0081513c-0x00815140
section, .rodata: 0x00815140-0x00817ce0
section, .reloc: 0x00817d00-0x00818674
section, .data: 0x00818674-0x00818b08
section, .data.rel: 0x00818b08-0x00818b34
section, .data.rel.local: 0x00818b34-0x00818f6c
section, .u_boot_cmd: 0x00818f6c-0x008191dc
section, .bss: 0x00819200-0x0081dd04
Than I load the zImage.elf via tftp to the memory location
0xf00000.
When I issue the command bootelf 0xf00000 the zImage.elf is placed in the
memory:
0x400000 as follows:
section, .text: 0x00400000-0x004036cc
section, .data: 0x00404000-0x004f7000
section, .bss: 0x004f7000-0x004f9138
After that uncompression of zImage.elf starts. I am just wandering which
memory location is involved for that?
My evaluation board has 32 MB of SDRAM address range:
(0x00000000-0x01ffffff) DDR_SDRAM_1 plb
Any Idea?
Best Regards
Mirek
On Tue, 28 Aug 2007, Grant Likely wrote:
> On 8/28/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> > This buffer refers to the kernel which I boot straight from jtag but not
> > u-boot.
>
> /me remembers something....
>
> How big is your kernel image? Seems to me I've had problems with
> kernel images that were too large not being uncompressed properly.
> Can you hook up GDB and debug u-boot? Find out where it is hanging?
>
> g.
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-29 8:31 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070829.012916.02298847.davem@davemloft.net>
On Wednesday 29 August 2007 10:29, David Miller wrote:
> From: Jan-Bernd Themann <ossthema@de.ibm.com>
> Date: Wed, 29 Aug 2007 09:10:15 +0200
>
> > In the end I want to reduce the CPU utilization. And one way
> > to do that is LRO which also works only well if there are more
> > then just a very few packets to aggregate. So at least our
> > driver (eHEA) would benefit from a mix of timer based polling
> > and plain NAPI (depending on load situations).
> >
> > If there is no need for a generic mechanism for this kind of
> > network adapters, then we can just leave this to each device
> > driver.
>
> No objections from me either way, if something works then
> fine.
>
> Let's come back to this once you have a tested sample implementation
> that does what you want, ok?
Sounds good
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: David Miller @ 2007-08-29 8:29 UTC (permalink / raw)
To: ossthema
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <46D51BD7.6040904@de.ibm.com>
From: Jan-Bernd Themann <ossthema@de.ibm.com>
Date: Wed, 29 Aug 2007 09:10:15 +0200
> In the end I want to reduce the CPU utilization. And one way
> to do that is LRO which also works only well if there are more
> then just a very few packets to aggregate. So at least our
> driver (eHEA) would benefit from a mix of timer based polling
> and plain NAPI (depending on load situations).
>
> If there is no need for a generic mechanism for this kind of
> network adapters, then we can just leave this to each device
> driver.
No objections from me either way, if something works then
fine.
Let's come back to this once you have a tested sample implementation
that does what you want, ok?
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: James Chapman @ 2007-08-29 8:15 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: tklein, themann, stefan.roscher, netdev, linux-kernel, raisch,
linuxppc-dev, akepner, meder, shemminger, David Miller
In-Reply-To: <46D51BD7.6040904@de.ibm.com>
Jan-Bernd Themann wrote:
> Hi David
>
> David Miller schrieb:
>> Interrupt mitigation only works if it helps you avoid interrupts.
>> This scheme potentially makes more of them happen.
>>
>> The hrtimer is just another interrupt, a cpu locally triggered one,
>> but it has much of the same costs nonetheless.
>>
>> So if you set this timer, it triggers, and no packets arrive, you are
>> taking more interrupts and doing more work than if you had disabled
>> NAPI.
>>
>> In fact, for certain packet rates, your scheme would result in
>> twice as many interrupts than the current scheme
>>
> That depends how smart the driver switches between timer
> polling and plain NAPI (depending on load situation).
>> This is one of several reasons why hardware is the only truly proper
>> place for this kind of logic. Only the hardware can see the packet
>> arrive, and do the interrupt deferral without any cpu intervention
>> whatsoever.
>>
> What I'm trying to improve with this approach is interrupt
> mitigation for NICs where the hardware support for interrupt
> mitigation is limited. I'm not trying to improve this for NICs
> that work well with the means their HW provides. I'm aware of
> the fact that this scheme has it's tradeoffs and certainly
> can not be as good as a HW approach.
> So I'm grateful for any ideas that do have less tradeoffs and
> provide a mechanism to reduce interrupts without depending on
> HW support of the NIC.
>
> In the end I want to reduce the CPU utilization. And one way
> to do that is LRO which also works only well if there are more
> then just a very few packets to aggregate. So at least our
> driver (eHEA) would benefit from a mix of timer based polling
> and plain NAPI (depending on load situations).
Wouldn't you achieve the same result by enabling hardware interrupt
mitigation in eHEA in combination with NAPI? Presumably a 10G interface
has hardware mitigation features?
> If there is no need for a generic mechanism for this kind of
> network adapters, then we can just leave this to each device
> driver.
I've been looking at this from a different angle. My goal is to optimize
NAPI packet forwarding rates while minimizing packet latency. Using
hardware interrupt mitigation hurts latency so I'm investigating ways to
turn it off without risking NAPI poll on/off thrashing at certain packet
rates.
Jan-Bernd, I think I've found a solution to the issue that you
highlighted with my scheme yesterday and it doesn't involve generating
other interrupts using hrtimers etc. :) Initial results are very
encouraging in my setups. Would you be willing to test it with eHEA? I
don't have a 10G setup. If results are encouraging, I'll post an RFC to
ask for review / feedback from the NAPI experts here. What do you think?
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Wolfgang Denk @ 2007-08-29 7:49 UTC (permalink / raw)
To: Oliver Rutsch, Mustafa Cayir; +Cc: linuxppc-embedded
In-Reply-To: <46D50C0B.80402@sympatec.com>
In message <46D50C0B.80402@sympatec.com> you wrote:
>
> > i build Linux-2.6.22-gbcfc8d37 kernel lastest kernel from denx git for
> > the board (STK5200 with TQM5200-AB).
> > ELDK 4.1 version is used.
> >
> > make mrproper
> > export ARCH=powerpc
> > make tqm5200_defconfig
> > make uImage
> >
> > It hangs on after following line
> > Uncompressing Kernel Image ... OK
Probably it does not hang, but you just don't see any console output.
Eventually you just forgot to set the correct console device
(/dev/ttyPSC0) or console speed.
Also, you need a recent version of U-Boot (for example 99c2fdab or
later).
Try something like this:
=> tftp 200000 /tftpboot/tqm5200/uImage
=> tftp 400000 /tftpboot/tqm5200/tqm5200.dtb
=> setenv bootargs root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk/ppc_6xx ip=192.168.160.4:192.168.1.1:::tqm5200:eth0:off console=ttyPSC0,115200
=> bootm 200000 - 400000
## Booting image at 00200000 ...
Image Name: Linux-2.6.22-gab27a987
Created: 2007-08-05 8:24:43 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1454249 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x400000
Using tqm5200 machine description
Linux version 2.6.22-gab27a987 (wd@pollux.denx.de) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Sun Aug 5 10:24:37 MEST 2007
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Built 1 zonelists. Total pages: 16256
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk/ppc_6xx ip=192.168.160.4:192.168.1.1:::tqm5200:eth0:off panic=1 console=ttyPSC0,115200
MPC52xx PIC is up and running!
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 61704k/65536k available (2872k kernel code, 3772k reserved, 132k data, 142k bss, 156k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
MPC52xx BestComm inited
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
...
etc.
> I encountered exactly the same problem. Using U-Boot 1.2 with Kernel
> Linux-2.6.22-gef92f1d7 and a TQM5200S-BD module on the STK52000. I tried
> to modify some kernel settings but it always stopped booting at the
> "Uncompressing Kernel Image ... OK" line.
Please note that the device tree we have at the moment is for the
TQM5200 only and does not include support for the TQM5200S.
But probably you just had the same problem - missing or bad console
device specification.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
That's their goal, remember, a goal that's really contrary to that of
the programmer or administrator. We just want to get our jobs done.
$Bill just wants to become $$Bill. These aren't even marginallly
congruent.
-- Tom Christiansen in <6jhtqk$qls$1@csnews.cs.colorado.edu>
^ permalink raw reply
* Re: RFC: issues concerning the next NAPI interface
From: Jan-Bernd Themann @ 2007-08-29 7:10 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, stefan.roscher, netdev, jchapman, raisch,
linux-kernel, linuxppc-dev, akepner, meder, shemminger
In-Reply-To: <20070828.132152.38706038.davem@davemloft.net>
Hi David
David Miller schrieb:
> Interrupt mitigation only works if it helps you avoid interrupts.
> This scheme potentially makes more of them happen.
>
> The hrtimer is just another interrupt, a cpu locally triggered one,
> but it has much of the same costs nonetheless.
>
> So if you set this timer, it triggers, and no packets arrive, you are
> taking more interrupts and doing more work than if you had disabled
> NAPI.
>
> In fact, for certain packet rates, your scheme would result in
> twice as many interrupts than the current scheme
>
That depends how smart the driver switches between timer
polling and plain NAPI (depending on load situation).
> This is one of several reasons why hardware is the only truly proper
> place for this kind of logic. Only the hardware can see the packet
> arrive, and do the interrupt deferral without any cpu intervention
> whatsoever.
>
What I'm trying to improve with this approach is interrupt
mitigation for NICs where the hardware support for interrupt
mitigation is limited. I'm not trying to improve this for NICs
that work well with the means their HW provides. I'm aware of
the fact that this scheme has it's tradeoffs and certainly
can not be as good as a HW approach.
So I'm grateful for any ideas that do have less tradeoffs and
provide a mechanism to reduce interrupts without depending on
HW support of the NIC.
In the end I want to reduce the CPU utilization. And one way
to do that is LRO which also works only well if there are more
then just a very few packets to aggregate. So at least our
driver (eHEA) would benefit from a mix of timer based polling
and plain NAPI (depending on load situations).
If there is no need for a generic mechanism for this kind of
network adapters, then we can just leave this to each device
driver.
^ permalink raw reply
* Sorry - please ignore Re: Bill F wants to chat
From: Bill F @ 2007-08-29 6:57 UTC (permalink / raw)
To: linuxppc-embedded
On 8/29/07, Bill F <list.mail.for.bill@gmail.com> wrote:
> -----------------------------------------------------------------------
>
> Bill F wants to stay in better touch using some of Google's coolest new
> products.
Sorry about that.
Please ignore my previous message. I'm switching over to use gmail so
that I can bypass our company's Exhange Server.
Bill
^ permalink raw reply
* Bill F wants to chat
From: Bill F @ 2007-08-29 6:52 UTC (permalink / raw)
To: linuxppc-embedded
-----------------------------------------------------------------------
Bill F wants to stay in better touch using some of Google's coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-786dedfe41-9ba528e872-9319a317c93199c9
You'll need to click this link to be able to chat with Bill F.
To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Bill F, visit:
http://mail.google.com/mail/a-786dedfe41-9ba528e872-8d8d2d59f9
Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
that are relevant to the content of your messages
All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:
http://www.google.com/talk/
Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
client
Gmail and Google Talk are still in beta. We're working hard to add new features
and make improvements, so we might also ask for your comments and suggestions
periodically. We appreciate your help in making our products even better!
Thanks,
The Google Team
To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html
(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).
^ permalink raw reply
* Re: [PATCH 1/4] PowerPC 440EPx: Sequoia bootwrapper
From: David Gibson @ 2007-08-29 6:33 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070828165610.GA1552@ru.mvista.com>
On Tue, Aug 28, 2007 at 08:56:10PM +0400, Valentine Barshak wrote:
> Bootwrapper code for AMCC PPC440EPx Sequoia.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
[snip]
> +static void sequoia_fixups(void)
> +{
> + unsigned long sysclk = 33333333;
> +
> + ibm440ep_fixup_clocks(sysclk, 11059200);
> + ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> + ibm4xx_denali_fixup_memsize();
> + dt_fixup_mac_addresses(sequoia_mac0, sequoia_mac1);
> +}
> +
> +static void sequoia_init(void *mac0, void *mac1)
No need to separate this function out, just drop it into
platform_init(). Also no need for the seqouia_mac* variables - they
were in ebony to handle the cuboot vs. openbios variants. For
sequoia, you can just pull the values straight from the bd_t in
sequoia_fixups()
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: David Gibson @ 2007-08-29 6:13 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
for powerpc (v3)
Reply-To:
This patch replaces the binding for flash chips in
booting-without-of.txt with an clarified and improved version. It
also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
Finally it revises the Ebony device tree source to use the new binding
as an example.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Third try at this...
Index: working-2.6/Documentation/powerpc/booting-without-of.txt
===================================================================
--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-08-29 15:56:19.000000000 +1000
+++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-08-29 16:10:32.000000000 +1000
@@ -50,7 +50,7 @@
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
- j) Flash chip nodes
+ j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
VII - Specifying interrupt information for devices
@@ -1757,45 +1757,61 @@
};
};
- j) Flash chip nodes
+ j) CFI or JEDEC memory-mapped NOR flash
Flash chips (Memory Technology Devices) are often used for solid state
file systems on embedded devices.
- Required properties:
-
- - device_type : has to be "rom"
- - compatible : Should specify what this flash device is compatible with.
- Currently, this is most likely to be "direct-mapped" (which
- corresponds to the MTD physmap mapping driver).
- - reg : Offset and length of the register set (or memory mapping) for
- the device.
- - bank-width : Width of the flash data bus in bytes. Required
- for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
-
- Recommended properties :
-
- - partitions : Several pairs of 32-bit values where the first value is
- partition's offset from the start of the device and the second one is
- partition size in bytes with LSB used to signify a read only
- partition (so, the partition size should always be an even number).
- - partition-names : The list of concatenated zero terminated strings
- representing the partition names.
- - probe-type : The type of probe which should be done for the chip
- (JEDEC vs CFI actually). Valid ONLY for NOR flashes.
+ - compatible : should contain the specific model of flash chip(s)
+ used, if known, followed by either "cfi-flash" or "jedec-flash"
+ - reg : Address range of the flash chip
+ - bank-width : Width (in bytes) of the flash bank. Equal to the
+ device width times the number of interleaved chips.
+ - device-width : (optional) Width of a single flash chip. If
+ omitted, assumed to be equal to 'bank-width'.
+ - #address-cells, #size-cells : Must be present if the flash has
+ sub-nodes representing partitions (see below). In this case
+ both #address-cells and #size-cells must be equal to 1.
+
+ For JEDEC compatible devices, the following additional properties
+ are defined:
+
+ - vendor-id : Contains the flash chip's vendor id (1 byte).
+ - device-id : Contains the flash chip's device id (1 byte).
+
+ In addition to the information on the flash bank itself, the
+ device tree may optionally contain additional information
+ describing partitions of the flash address space. This can be
+ used on platforms which have strong conventions about which
+ portions of the flash are used for what purposes, but which don't
+ use an on-flash partition table such as RedBoot.
+
+ Each partition is represented as a sub-node of the flash device.
+ Each node's name represents the name of the corresponding
+ partition of the flash device.
+
+ Flash partitions
+ - reg : The partition's offset and size within the flash bank.
+ - read-only : (optional) This parameter, if present, is a hint to
+ Linux that this flash partition should only be mounted
+ read-only. This is usually used for flash partitions
+ containing early-boot firmware images or data which should not
+ be clobbered.
- Example:
+ Example:
- flash@ff000000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "CFI";
- reg = <ff000000 01000000>;
- bank-width = <4>;
- partitions = <00000000 00f80000
- 00f80000 00080001>;
- partition-names = "fs\0firmware";
- };
+ flash@ff000000 {
+ compatible = "amd,am29lv128ml", "cfi-flash";
+ reg = <ff000000 01000000>;
+ bank-width = <4>;
+ fs@0 {
+ reg = <0 f80000>;
+ };
+ firmware@f80000 {
+ reg = <f80000 80000>;
+ read-only;
+ };
+ };
k) Global Utilities Block
Index: working-2.6/drivers/mtd/maps/physmap_of.c
===================================================================
--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-08-29 15:56:18.000000000 +1000
+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-08-29 15:56:19.000000000 +1000
@@ -4,6 +4,9 @@
* Copyright (C) 2006 MontaVista Software Inc.
* Author: Vitaly Wool <vwool@ru.mvista.com>
*
+ * Revised to handle newer style flash binding by:
+ * Copyright (C) 2007 David Gibson, IBM Corporation.
+ *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -30,56 +33,132 @@
struct map_info map;
struct resource *res;
#ifdef CONFIG_MTD_PARTITIONS
- int nr_parts;
struct mtd_partition *parts;
#endif
};
-static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };
-#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
-#endif
-
#ifdef CONFIG_MTD_PARTITIONS
-static int parse_flash_partitions(struct device_node *node,
- struct mtd_partition **parts)
+static int parse_obsolete_partitions(struct of_device *dev,
+ struct physmap_flash_info *info,
+ struct device_node *dp)
{
- int i, plen, retval = -ENOMEM;
- const u32 *part;
- const char *name;
-
- part = of_get_property(node, "partitions", &plen);
- if (part == NULL)
- goto err;
-
- retval = plen / (2 * sizeof(u32));
- *parts = kzalloc(retval * sizeof(struct mtd_partition), GFP_KERNEL);
- if (*parts == NULL) {
+ int i, plen, nr_parts;
+ const struct {
+ u32 offset, len;
+ } *part;
+ const char *names;
+
+ part = of_get_property(dp, "partitions", &plen);
+ if (!part)
+ return -ENOENT;
+
+ dev_warn(&dev->dev, "Device tree uses obsolete partition map binding\n");
+
+ nr_parts = plen / sizeof(part[0]);
+
+ info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition), GFP_KERNEL);
+ if (!info->parts) {
printk(KERN_ERR "Can't allocate the flash partition data!\n");
- goto err;
+ return -ENOMEM;
}
- name = of_get_property(node, "partition-names", &plen);
+ names = of_get_property(dp, "partition-names", &plen);
- for (i = 0; i < retval; i++) {
- (*parts)[i].offset = *part++;
- (*parts)[i].size = *part & ~1;
- if (*part++ & 1) /* bit 0 set signifies read only partition */
- (*parts)[i].mask_flags = MTD_WRITEABLE;
+ for (i = 0; i < nr_parts; i++) {
+ info->parts[i].offset = part->offset;
+ info->parts[i].size = part->len & ~1;
+ if (part->len & 1) /* bit 0 set signifies read only partition */
+ info->parts[i].mask_flags = MTD_WRITEABLE;
- if (name != NULL && plen > 0) {
- int len = strlen(name) + 1;
+ if (names && (plen > 0)) {
+ int len = strlen(names) + 1;
- (*parts)[i].name = (char *)name;
+ info->parts[i].name = (char *)names;
plen -= len;
- name += len;
- } else
- (*parts)[i].name = "unnamed";
+ names += len;
+ } else {
+ info->parts[i].name = "unnamed";
+ }
+
+ part++;
}
-err:
- return retval;
+
+ return nr_parts;
}
-#endif
+
+static int __devinit process_partitions(struct physmap_flash_info *info,
+ struct of_device *dev)
+{
+ static const char *part_probe_types[]
+ = { "cmdlinepart", "RedBoot", NULL };
+ struct device_node *dp = dev->node, *pp;
+ int nr_parts, i, err;
+
+ /* First look for RedBoot table or partitions on the command
+ * line, these take precedence over device tree information */
+ nr_parts = parse_mtd_partitions(info->mtd, part_probe_types,
+ &info->parts, 0);
+ if (nr_parts > 0) {
+ add_mtd_partitions(info->mtd, info->parts, err);
+ return 0;
+ }
+
+ /* First count the subnodes */
+ nr_parts = 0;
+ for (pp = dp->child; pp; pp = pp->sibling)
+ nr_parts++;
+
+ if (nr_parts) {
+ info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition),
+ GFP_KERNEL);
+ if (!info->parts) {
+ printk(KERN_ERR "Can't allocate the flash partition data!\n");
+ return -ENOMEM;
+ }
+
+ for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
+ const u32 *reg;
+ int len;
+
+ reg = of_get_property(pp, "reg", &len);
+ if (!reg || (len != 2*sizeof(u32))) {
+ dev_err(&dev->dev, "Invalid 'reg' on %s\n",
+ dp->full_name);
+ kfree(info->parts);
+ info->parts = NULL;
+ return -EINVAL;
+ }
+ info->parts[i].offset = reg[0];
+ info->parts[i].size = reg[1];
+
+ info->parts[i].name =
+ (char *)of_get_property(pp, "name", &len);
+
+ if (of_get_property(pp, "read-only", &len))
+ info->parts[i].mask_flags = MTD_WRITEABLE;
+ }
+ } else {
+ nr_parts = parse_obsolete_partitions(dev, info, dp);
+ }
+
+ if (nr_parts < 0)
+ return nr_parts;
+
+ if (nr_parts > 0)
+ add_mtd_partitions(info->mtd, info->parts, nr_parts);
+ else
+ add_mtd_device(info->mtd);
+
+ return 0;
+}
+#else /* MTD_PARTITIONS */
+static int __devinit process_partitions(struct physmap_flash_info *info,
+ struct device_node *dev)
+{
+ add_mtd_device(info->mtd);
+ return 0;
+}
+#endif /* MTD_PARTITIONS */
static int of_physmap_remove(struct of_device *dev)
{
@@ -92,7 +171,7 @@
if (info->mtd != NULL) {
#ifdef CONFIG_MTD_PARTITIONS
- if (info->nr_parts) {
+ if (info->parts) {
del_mtd_partitions(info->mtd);
kfree(info->parts);
} else {
@@ -115,16 +194,50 @@
return 0;
}
+/* Helper function to handle probing of the obsolete "direct-mapped"
+ * compatible binding, which has an extra "probe-type" property
+ * describing the type of flash probe necessary. */
+static struct mtd_info * __devinit obsolete_probe(struct of_device *dev,
+ struct map_info *map)
+{
+ struct device_node *dp = dev->node;
+ const char *of_probe;
+ struct mtd_info *mtd;
+ static const char *rom_probe_types[]
+ = { "cfi_probe", "jedec_probe", "map_rom"};
+ int i;
+
+ of_probe = of_get_property(dp, "probe-type", NULL);
+ if (!of_probe) {
+ for (i = 0; i < ARRAY_SIZE(rom_probe_types); i++) {
+ mtd = do_map_probe(rom_probe_types[i], map);
+ if (mtd)
+ return mtd;
+ }
+ return NULL;
+ } else if (strcmp(of_probe, "CFI") == 0) {
+ return do_map_probe("cfi_probe", map);
+ } else if (strcmp(of_probe, "JEDEC") == 0) {
+ return do_map_probe("jedec_probe", map);
+ } else {
+ if (strcmp(of_probe, "ROM") != 0)
+ dev_dbg(&dev->dev, "obsolete_probe: don't know probe type "
+ "'%s', mapping as rom\n", of_probe);
+ return do_map_probe("mtd_rom", map);
+ }
+}
+
static int __devinit of_physmap_probe(struct of_device *dev, const struct of_device_id *match)
{
struct device_node *dp = dev->node;
struct resource res;
struct physmap_flash_info *info;
- const char **probe_type;
- const char *of_probe;
+ const char *probe_type = (const char *)match->data;
const u32 *width;
int err;
+ dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
+ "flash binding\n");
if (of_address_to_resource(dp, 0, &res)) {
dev_err(&dev->dev, "Can't get the flash mapping!\n");
@@ -174,21 +287,11 @@
simple_map_init(&info->map);
- of_probe = of_get_property(dp, "probe-type", NULL);
- if (of_probe == NULL) {
- probe_type = rom_probe_types;
- for (; info->mtd == NULL && *probe_type != NULL; probe_type++)
- info->mtd = do_map_probe(*probe_type, &info->map);
- } else if (!strcmp(of_probe, "CFI"))
- info->mtd = do_map_probe("cfi_probe", &info->map);
- else if (!strcmp(of_probe, "JEDEC"))
- info->mtd = do_map_probe("jedec_probe", &info->map);
- else {
- if (strcmp(of_probe, "ROM"))
- dev_dbg(&dev->dev, "map_probe: don't know probe type "
- "'%s', mapping as rom\n", of_probe);
- info->mtd = do_map_probe("mtd_rom", &info->map);
- }
+ if (probe_type)
+ info->mtd = do_map_probe(probe_type, &info->map);
+ else
+ info->mtd = obsolete_probe(dev, &info->map);
+
if (info->mtd == NULL) {
dev_err(&dev->dev, "map_probe failed\n");
err = -ENXIO;
@@ -196,19 +299,7 @@
}
info->mtd->owner = THIS_MODULE;
-#ifdef CONFIG_MTD_PARTITIONS
- err = parse_mtd_partitions(info->mtd, part_probe_types, &info->parts, 0);
- if (err > 0) {
- add_mtd_partitions(info->mtd, info->parts, err);
- } else if ((err = parse_flash_partitions(dp, &info->parts)) > 0) {
- dev_info(&dev->dev, "Using OF partition information\n");
- add_mtd_partitions(info->mtd, info->parts, err);
- info->nr_parts = err;
- } else
-#endif
-
- add_mtd_device(info->mtd);
- return 0;
+ return process_partitions(info, dev);
err_out:
of_physmap_remove(dev);
@@ -221,6 +312,14 @@
static struct of_device_id of_physmap_match[] = {
{
+ .compatible = "cfi-flash",
+ .data = (void *)"cfi_probe",
+ },
+ {
+ .compatible = "jedec-flash",
+ .data = (void *)"jedec_probe",
+ },
+ {
.type = "rom",
.compatible = "direct-mapped"
},
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-08-29 15:56:18.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-08-29 15:56:19.000000000 +1000
@@ -142,13 +142,15 @@
interrupt-parent = <&UIC1>;
small-flash@0,80000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 80000>;
- partition-names = "OpenBIOS";
reg = <0 80000 80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ OpenBIOS@0 {
+ reg = <0 80000>;
+ read-only;
+ };
};
ds1743@1,0 {
@@ -158,14 +160,17 @@
};
large-flash@2,0 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 380000
- 380000 80000>;
- partition-names = "fs", "firmware";
reg = <2 0 400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fs@0 {
+ reg = <0 380000>;
+ };
+ firmware@380000 {
+ reg = <380000 80000>;
+ };
};
ir@3,0 {
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-08-29 6:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7B9A8FF57DBB524190E98CABF6E56F070B9283@itri.bte.mam.gov.tr>
Hi Mustafa,
> Hi,
>
> i build Linux-2.6.22-gbcfc8d37 kernel lastest kernel from denx git for
> the board (STK5200 with TQM5200-AB).
> ELDK 4.1 version is used.
>
> make mrproper
> export ARCH=powerpc
> make tqm5200_defconfig
> make uImage
>
> It hangs on after following line
> Uncompressing Kernel Image ... OK
>
I encountered exactly the same problem. Using U-Boot 1.2 with Kernel
Linux-2.6.22-gef92f1d7 and a TQM5200S-BD module on the STK52000. I tried
to modify some kernel settings but it always stopped booting at the
"Uncompressing Kernel Image ... OK" line.
Bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: [PATCH 6/9] mpc82xx: Rename mpc82xx_ads to mpc8272_ads.
From: David Gibson @ 2007-08-29 5:55 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070828201926.GF24329@ld0162-tx32.am.freescale.net>
On Tue, Aug 28, 2007 at 03:19:26PM -0500, Scott Wood wrote:
> This is just a rename patch; internal references to mpc82xx_ads will be
> changed in the next one.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/platforms/82xx/Kconfig | 8 ++++----
> arch/powerpc/platforms/82xx/Makefile | 2 +-
> .../82xx/{mpc82xx_ads.c => mpc8272_ads.c} | 0
> 3 files changed, 5 insertions(+), 5 deletions(-)
> rename arch/powerpc/platforms/82xx/{mpc82xx_ads.c => mpc8272_ads.c} (100%)
>
> diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
> index 89fde43..f260c01 100644
> --- a/arch/powerpc/platforms/82xx/Kconfig
> +++ b/arch/powerpc/platforms/82xx/Kconfig
> @@ -1,17 +1,17 @@
> choice
> prompt "82xx Board Type"
> depends on PPC_82xx
> - default MPC82xx_ADS
> + default MPC8272_ADS
Not actually relevant to this patch, but we should be getting rid of
all these 'choice' things for board selection and instead allowing
each board to be separately enabled or disabled.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/3] Add early debug console for CPM serial ports.
From: David Gibson @ 2007-08-29 5:45 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070828201621.GC24210@ld0162-tx32.am.freescale.net>
On Tue, Aug 28, 2007 at 03:16:21PM -0500, Scott Wood wrote:
> This code assumes that the ports have been previously set up, with
> buffers in DPRAM, and the descriptor address defined by platform code.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/Kconfig.debug | 9 +++++++
> arch/powerpc/kernel/head_32.S | 16 +++++++++++++
> arch/powerpc/kernel/udbg.c | 2 +
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/cpm_common.c | 44 ++++++++++++++++++++++++++++++++++++++
> arch/powerpc/sysdev/cpm_common.h | 16 +++++++++++++
> include/asm-powerpc/udbg.h | 1 +
> 7 files changed, 89 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/sysdev/cpm_common.c
> create mode 100644 arch/powerpc/sysdev/cpm_common.h
>
> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> index 22acece..d471154 100644
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -211,6 +211,15 @@ config PPC_EARLY_DEBUG_44x
> Select this to enable early debugging for IBM 44x chips via the
> inbuilt serial port.
>
> +config PPC_EARLY_DEBUG_CPM
> + bool "Early serial debugging for Freescale CPM-based serial ports"
> + depends on SERIAL_CPM
> + select PIN_TLB if PPC_8xx
I see this Kconfig line, but I don't see any code below that would set
up a suitable TLB on 8xx for the CPM...?
[snip]
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 08ce31e..5063e74 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -34,6 +34,7 @@ endif
>
> # Temporary hack until we have migrated to asm-powerpc
> ifeq ($(ARCH),powerpc)
> +obj-$(CONFIG_CPM1)$(CONFIG_CPM2) += cpm_common.o
Uh.. I don't think this will work properly. If CONFIG_CPM1 and
CONFIG_CPM2 are both enabled, it will set obj-yy rather than obj-y.
> obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
> obj-$(CONFIG_8xx) += mpc8xx_pic.o commproc.o
> obj-$(CONFIG_UCODE_PATCH) += micropatch.o
> diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
> new file mode 100644
> index 0000000..1972a8f
> --- /dev/null
> +++ b/arch/powerpc/sysdev/cpm_common.c
> @@ -0,0 +1,44 @@
> +/*
> + * Common CPM code
> + *
> + * Author: Scott Wood <scottwood@freescale.com>
> + *
> + * Copyright 2007 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <asm/udbg.h>
> +#include <asm/io.h>
> +#include <asm/system.h>
> +#include <mm/mmu_decl.h>
> +#include "cpm_common.h"
> +
> +#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
> +static void udbg_putc_cpm(char c)
> +{
> + u8 __iomem *txbuf = (u8 __iomem __force *)in_be32(&cpm_udbg_txdesc[1]);
> +
> + if (c == '\n')
> + udbg_putc('\r');
> +
> + while (in_be32(&cpm_udbg_txdesc[0]) & 0x80000000)
> + ;
> +
> + out_8(txbuf, c);
> + out_be32(&cpm_udbg_txdesc[0], 0xa0000001);
> +}
> +
> +void __init udbg_init_cpm(void)
> +{
> + if (cpm_udbg_txdesc) {
> +#ifdef CONFIG_CPM2
> + setbat(1, 0xf0000000, 0xf0000000, 1024*1024, _PAGE_IO);
> +#endif
> + udbg_putc = udbg_putc_cpm;
> + }
> +}
> +#endif
Since this is all udbg related, it could go (within an ifdef) into
udbg.c rather than creating a new file for it.
> diff --git a/arch/powerpc/sysdev/cpm_common.h b/arch/powerpc/sysdev/cpm_common.h
> new file mode 100644
> index 0000000..f42343f
> --- /dev/null
> +++ b/arch/powerpc/sysdev/cpm_common.h
> @@ -0,0 +1,16 @@
> +#ifndef _POWERPC_SYSDEV_CPM_COMMON_H
> +#define _POWERPC_SYSDEV_CPM_COMMON_H
> +
> +#include <linux/types.h>
> +
> +/*
> + * Board code must define this address if the early console is used.
> + *
> + * Note that this is not multi-platform safe, and thus the CPM
> + * UDBG console must only be enabled when only a single platform
> + * is selected. It is done this way because udbg init runs before
> + * platform probing.
> + */
> +extern u32 __iomem *cpm_udbg_txdesc;
Urg... this is ugly, because it looks like it can be muti-platform,
but actually isn't. I think a better approach is to set the magic
address as a Kconfig variable, as we do on 44x. This approach can
also be useful for hacking up early debug for new chips during the
process of creating platform code for them.
> +
> +#endif
> diff --git a/include/asm-powerpc/udbg.h b/include/asm-powerpc/udbg.h
> index ce9d82f..a9e0b0e 100644
> --- a/include/asm-powerpc/udbg.h
> +++ b/include/asm-powerpc/udbg.h
> @@ -48,6 +48,7 @@ extern void __init udbg_init_rtas_console(void);
> extern void __init udbg_init_debug_beat(void);
> extern void __init udbg_init_btext(void);
> extern void __init udbg_init_44x_as1(void);
> +extern void __init udbg_init_cpm(void);
>
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_UDBG_H */
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/3] Introduce new CPM device bindings.
From: David Gibson @ 2007-08-29 5:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070828201619.GB24210@ld0162-tx32.am.freescale.net>
On Tue, Aug 28, 2007 at 03:16:19PM -0500, Scott Wood wrote:
> This introduces a new device binding for the CPM and other devices on
> these boards. Some of the changes include:
>
> 1. Proper namespace scoping for Freescale compatibles and properties.
>
> 2. Use compatible rather than things like device_type and model
> to determine which particular variant of a device is present.
>
> 3. Give the drivers the relevant CPM command word directly, rather than
> requiring it to have a lookup table based on device-id, SCC v. SMC, and
> CPM version.
>
> 4. Specify the CPCR and the usable DPRAM region in the CPM's reg property.
>
> Boards that do not require the legacy bindings should select
> CONFIG_PPC_CPM_NEW_BINDING to enable the of_platform CPM devices. Once
> all existing boards are converted and tested, the config option can
> become default y to prevent new boards from using the old model. Once
> arch/ppc is gone, the config option can be removed altogether.
I think it would be better to change the name and reverse the sense of
this config option, since what it actually does is disable the old
binding, not enable the new one.
[snip]
> @@ -1824,6 +1827,170 @@ platforms are moved over to use the flattened-device-tree model.
> fsl,has-rstcr;
> };
>
> + l) Freescale Communications Processor Module
> +
> + NOTE: This is an interim binding, and will likely change slightly,
> + as more devices are supported. The QE bindings especially are
> + incomplete.
> +
> + i) Root CPM node
> +
> + Properties:
> + - compatible : "fsl,cpm1", "fsl,cpm2", or "fsl,qe".
> + - reg : The first resource is a 48-byte region beginning with
> + CPCR. The second is the available general-purpose
> + DPRAM.
> + - fsl,brg-frequency : the internal clock source frequency for baud-rate
> + generators in Hz.
> +
> + Example:
> + cpm@119c0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
> + reg = <119c0 30 0 2000>;
> + bus-frequency = <d#25000000>;
> + }
Your example has bus-frequency, but lacks fsl,brg-frequency, in
contrast to the description above.
Since you have a separate brg node defined below, maybe
fsl,brg-frequency should just be replaced with a 'clock-frequency'
property in that subnode.
> + ii) Properties common to mulitple CPM/QE devices
> +
> + - fsl,cpm-command : This value is ORed with the opcode and command flag
> + to specify the device on which a CPM command operates.
> +
> + - fsl,cpm-brg : Indicates which baud rate generator the device
> + is associated with. If absent, an unused BRG
> + should be dynamically allocated.
Maybe a property with the brg node's phandle could be included as
well, to avoid having to hop up to the CPM node, then back down to the
brg-compatible node to find it?
Or maybe even have a separate subnode for each brg, and just have a
phandle to reference it from the other devices, rather than using this
index.
> +
> + - reg : Unless otherwise specified, the first resource represents the
> + scc/fcc/ucc registers, and the second represents the device's
> + parameter RAM region (if it has one).
> +
> + iii) Serial
> +
> + Currently defined compatibles:
> + - fsl,cpm1-smc-uart
> + - fsl,cpm2-smc-uart
> + - fsl,cpm1-scc-uart
> + - fsl,cpm2-scc-uart
> + - fsl,qe-uart
> +
> + Example:
> +
> + serial@11a00 {
> + device_type = "serial";
> + compatible = "fsl,mpc8272-scc-uart",
> + "fsl,cpm2-scc-uart";
> + reg = <11a00 20 8000 100>;
> + interrupts = <28 8>;
> + interrupt-parent = <&PIC>;
> + fsl,cpm-brg = <1>;
> + fsl,cpm-command = <00800000>;
> + };
> +
> + iii) Network
> +
> + Currently defined compatibles:
> + - fsl,cpm1-scc-enet
> + - fsl,cpm2-scc-enet
> + - fsl,cpm1-fec-enet
> + - fsl,cpm2-fcc-enet (third resource is GFEMR)
> + - fsl,qe-enet
> +
> + Example:
> +
> + ethernet@11300 {
> + device_type = "network";
> + compatible = "fsl,mpc8272-fcc-enet",
> + "fsl,cpm2-fcc-enet";
> + reg = <11300 20 8400 100 11390 1>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <20 8>;
> + interrupt-parent = <&PIC>;
> + phy-handle = <&PHY0>;
> + linux,network-index = <0>;
> + fsl,cpm-command = <12000300>;
> + };
Should this also have a phandle pointer to the mdio node?
> + iv) MDIO
> +
> + Currently defined compatibles:
> + fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
> + fsl,cpm2-mdio-bitbang (reg is port C registers)
> +
> + Properties for fsl,cpm2-mdio-bitbang:
> + fsl,mdio-pin : pin of port C controlling mdio data
> + fsl,mdc-pin : pin of port C controlling mdio clock
> +
> + Example:
> +
> + mdio@10d40 {
> + device_type = "mdio";
> + compatible = "fsl,mpc8272ads-mdio-bitbang",
> + "fsl,mpc8272-mdio-bitbang",
> + "fsl,cpm2-mdio-bitbang";
> + reg = <10d40 14>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + fsl,mdio-pin = <12>;
> + fsl,mdc-pin = <13>;
> + };
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/3] fsl_soc.c cleanup
From: David Gibson @ 2007-08-29 5:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070828201618.GA24210@ld0162-tx32.am.freescale.net>
Hrm.. in future could you add a separate 0/N for each of your series,
and make sure the In-Reply-To fields are right... as it is, my mailer
has threaded together these 4 or so patch series you posted into one
great wodge.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Document and implement an improved flash device binding for powerpc
From: David Gibson @ 2007-08-29 5:22 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070828133926.230b4132@weaponx.rchland.ibm.com>
On Tue, Aug 28, 2007 at 01:39:26PM -0500, Josh Boyer wrote:
> On Tue, 28 Aug 2007 13:47:51 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > This patch replaces the binding for flash chips in
> > booting-without-of.txt with an clarified and improved version. It
> > also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
> > Finally it revises the Ebony device tree source to use the new binding
> > as an example.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > I don't know that this is ready yet, but I thought I'd try to kick
> > along the rather stalled process of getting this new flash binding in
> > place by sending out my current draft.
> >
> > Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> > ===================================================================
> > --- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-08-28 13:25:42.000000000 +1000
> > +++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-08-28 13:38:10.000000000 +1000
> > @@ -1757,45 +1757,46 @@ platforms are moved over to use the flat
> > };
> > };
> >
> > - j) Flash chip nodes
> > + j) CFI or JEDEC memory-mapped NOR flash
>
> > - Example:
> > -
> > - flash@ff000000 {
> > - device_type = "rom";
> > - compatible = "direct-mapped";
> > - probe-type = "CFI";
> > - reg = <ff000000 01000000>;
> > - bank-width = <4>;
> > - partitions = <00000000 00f80000
> > - 00f80000 00080001>;
> > - partition-names = "fs\0firmware";
> > - };
>
> Instead of removing it completely, could you fix the example to match
> the new binding?
Oops, meant to do that. Done now.
> > + - compatible : should contain the specific model of flash chip(s)
> > + used, if known, followed by either "cfi-flash" or "jedec-flash"
> > + - reg : Address range of the flash chip
> > + - bank-width : Width (in bytes) of the flash bank. Equal to the
> > + device width times the number of interleaved chips.
> > + - device-width : (optional) Width of a single flash chip. If
> > + omitted, assumed to be equal to 'bank-width'.
>
> > + - #address-cells, #size-cells : Must be present if the flash has
> > + sub-nodes representing partitions (see below). In this case
> > + both #address-cells and #size-cells must be equal to 1.
>
> Why is that? Are we explicitly not caring about chips that are > 4
> GiB? I think MTD has a limitation here anyway, but it seems a bit
> short-sighted to explicitly limit what #address-cells can be.
>4GiB of NOR flash would be rather unusual (and pricey). I think it's
simplest to leave this in the binding for now - it's a restriction
which can easily be removed later without breaking backwards
compatibility.
> > +
> > + For JEDEC compatible devices, the following additional properties
> > + are defined:
> > +
> > + - vendor-id : Contains the flash chip's vendor id (1 byte).
> > + - device-id : Contains the flash chip's device id (1 byte).
> > +
> > + In addition to the information on the flash bank itself, the
> > + device tree may optionally contain additional information
> > + describing partitions of the flash address space. This can be
> > + used on platforms which have strong conventions about which
> > + portions of the flash are used for what purposes, but which don't
> > + use an on-flash partition table such as RedBoot.
> > +
> > + Each partitions is represented as a sub-node of the flash device.
>
> <nit> "Each partition.." </nit>
Oops, fixed.
> > Index: working-2.6/drivers/mtd/maps/physmap_of.c
> > ===================================================================
> > --- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-08-28 13:25:42.000000000 +1000
> > +++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-08-28 13:26:43.000000000 +1000
> > @@ -4,6 +4,9 @@
> > * Copyright (C) 2006 MontaVista Software Inc.
> > * Author: Vitaly Wool <vwool@ru.mvista.com>
> > *
> > + * Revised to handle newer style flash binding by:
> > + * Copyright (C) 2007 David Gibson, IBM Corporation.
> > + *
> > * This program is free software; you can redistribute it and/or modify it
> > * under the terms of the GNU General Public License as published by the
> > * Free Software Foundation; either version 2 of the License, or (at your
> > @@ -30,56 +33,129 @@ struct physmap_flash_info {
> > struct map_info map;
> > struct resource *res;
> > #ifdef CONFIG_MTD_PARTITIONS
> > - int nr_parts;
> > struct mtd_partition *parts;
> > #endif
> > };
> >
> > -static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };
> > -#ifdef CONFIG_MTD_PARTITIONS
> > -static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
> > -#endif
> > -
> > #ifdef CONFIG_MTD_PARTITIONS
> > -static int parse_flash_partitions(struct device_node *node,
> > - struct mtd_partition **parts)
> > +static int parse_obsolete_partitions(struct physmap_flash_info *info,
> > + struct device_node *dp)
> > {
>
> If this is going to be obsoleted, can we put a printk in here whining
> about the fact that the device tree still uses it if parititions are
> found?
Good idea.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: ppc_8xx-gcc from eldk strange behaviour
From: Ricardo Scop @ 2007-08-29 4:50 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: DI BACCO ANTONIO - technolabs
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8E2649AF@aquib01a>
Hi, Antonio
On Tuesday 28 August 2007 15:56, DI BACCO ANTONIO - technolabs wrote:
> Consider the following C code snippet:
[snip]
> char x = -4;
[snip]
>
> If I compile it with host gcc, there is no warning and the message "x is
> negative" is printed. If I compile it with ppc_8xx-gcc there is a warning
> "main.c:11: warning: comparison is always false due to limited range of
> data type" and the program prints message "x is positive". To correct the
> problem I have to put signed before char.
>
You can also use the -fsigned-char compilation flag, in this case.
--
Ricardo Scop.
^ permalink raw reply
* Where to put tip to fix very jerky mouse on iBook G3?
From: Jarrod O'Flaherty @ 2007-08-29 4:19 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
SHORT VERSION:
--------------
1. I had a problem with my USB mouse on an iBook G3.
2. It took a lot of hard work to solve the problem.
3. I'd like to know where to put my solution for others to find (and find easily!
;).
For more details read on...
LONG VERSION:
-------------
I am wondering where I should put this tip/solution I worked out for fixing a very
jerky mouse pointer under X on my iBook G3.
The problem goes something like this:
- While running X (happens in both Gnome and KDE)
- and using the mouse
- the pointer will freeze
- at irregular intervals
- for about 0.5 sec or so
- then jump, to where it (probably?) "should be"
- by which point I have "over moved" the mouse
- and missed the button I was trying to hit
- all of which
- results in a system which is very hard to use.
I noted that the problem was *less* pronounced when the system was under heavy load
(eg. by running system monitor - which takes a lot of CPU!). This made sense once I
discovered the cause of the jerkiness.
The specs of the machine/setup are:
- Apple iBook G3 600MHz
- 384 MB RAM
- USB Mouse Connected
- Debian Etch (4.0)
And uname -a gives:
>> Linux ibook3 2.6.18-5-powerpc #1 Sun Aug 12 21:01:27 UTC 2007 ppc GNU/Linux
So, as for the solution...
It turns out the cause is apparently the CPU frequency switching done by (power
saving part of) the linux kernel.
I don't believe the issue is necessarily with the kernel itself, though I could be
wrong. It seems more likely it is some hardware problem, where a CPU frequency
change causes a pause in processing. And perhaps only with this generation and model
of iBook?
For anyone else who has this problem, my tip is to:
- Try disabling the cpu frequency switching of the linux kernel.
To do so, my current method is to execute:
>> echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
This confines the governor to using a range between 600 and 600MHz, instead of
between 400 and 600MHz as it is at bootup, which effectively disables frequency
switching.
It took me about 2 days to work out the cause and above solution. I actually found
one very fleeting hint indicating a link between such system hiccups and CPU
frequency changes on a website while Googling early one, but it was another 1.5 days
before, after trying a bunch of other methods, I decided I really should work out if
completely disabling it would do the trick. Playing with governors, which I did at
various points, did seem to help some, but didn't make the problem disappear
altogether.
Unfortunately, no amount of Googling since then has brought up that "life saving"
site, or any other that mentions anything similar. So I guess I was very lucky I
found it!
I also guess not too many other people have suffered this problem, since, as I said,
I can't get much on Google about the issue. But just in case someone does try
installing Debian + Linux 2.6 on an iBook G3 and does just happen to have the same
problem crop up, I thought I should park my tip somewhere they would be able to find
it.
My question therefore is:
> Where should we be putting such tips on issues with Linux on iBook hardware?
Any and all advice is appreciated (including how to disable frequency switching
permanently!).
Cheers,
Jarrod.
^ permalink raw reply
* libfdt: Fix handling of trailing / in fdt_path_offset()
From: David Gibson @ 2007-08-29 2:22 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently, fdt_path_offset() returns FDL_ERR_BADOFFSET if given a path
with a trailing '/'. In particular this means that
fdt_path_offset("/") returns FDT_ERR_BADOFFSET rather than 0 as one
would expect.
This patch fixes the function to accept and ignore trailing '/'
characters. As well as allowing fdt_path_offset("/") this means that
fdt_path_offset("/foo/") will return the same as
fdt_path_offset("/foo") which seems in keeping with the principle of
least surprise.
This also adds a testcase to ensure that fdt_path_offset("/") returns
0 as it should.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/path_offset.c
===================================================================
--- dtc.orig/tests/path_offset.c 2007-08-29 12:04:54.000000000 +1000
+++ dtc/tests/path_offset.c 2007-08-29 12:04:57.000000000 +1000
@@ -58,6 +58,7 @@
int main(int argc, char *argv[])
{
void *fdt;
+ int root_offset;
int subnode1_offset, subnode2_offset;
int subnode1_offset_p, subnode2_offset_p;
int subsubnode1_offset, subsubnode2_offset;
@@ -66,6 +67,13 @@
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
+ root_offset = fdt_path_offset(fdt, "/");
+ if (root_offset < 0)
+ FAIL("fdt_path_offset(\"/\") failed: %s",
+ fdt_strerror(root_offset));
+ else if (root_offset != 0)
+ FAIL("fdt_path_offset(\"/\") returns incorrect offset %d",
+ root_offset);
subnode1_offset = check_subnode(fdt, 0, "subnode1");
subnode2_offset = check_subnode(fdt, 0, "subnode2");
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-08-29 12:08:48.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-08-29 12:08:55.000000000 +1000
@@ -154,7 +154,7 @@
while (*p == '/')
p++;
if (! *p)
- return -FDT_ERR_BADPATH;
+ return offset;
q = strchr(p, '/');
if (! q)
q = end;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
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