* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-09 22:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1204849197.21545.272.camel@pasglop>
Hi Ben,
I now have a working linux on my mpc8540 based board, with support for
the compactflash disk and the i2c rtc.
The network tough, does not work yet. altough the the integrated ethernet
controller (FEC) seems to be recognized. Could it be a problem with the phy ?
I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
Do I need to give the phy type in the dts file, and how ?
I would also like to know if it is possible to still get in linux the mac
address known by uboot when using a dts file, and how ?
Thanks for listening.
Philippe
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-09 22:36 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080309223109.GA3989@netgate.macqel>
On Sun, 2008-03-09 at 23:31 +0100, Philippe De Muyter wrote:
> Hi Ben,
>
> I now have a working linux on my mpc8540 based board, with support for
> the compactflash disk and the i2c rtc.
>
> The network tough, does not work yet. altough the the integrated ethernet
> controller (FEC) seems to be recognized. Could it be a problem with the phy ?
> I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
> on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
> Do I need to give the phy type in the dts file, and how ?
>
> I would also like to know if it is possible to still get in linux the mac
> address known by uboot when using a dts file, and how ?
I'll let the freescale people answer here as I don't know the gianfar
driver at all.
Ben.
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Luis Machado @ 2008-03-10 0:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Paul Mackerras, Roland McGrath, Jan Kratochvil
In-Reply-To: <200711290113.29024.arnd@arndb.de>
> Yes, I know. I tried it on the PS3 first and couldn't reproduce
> the bug he saw on the blade.
Arnd,
Do we have any news on this topic?
I've seen this happening quite often within GDB when using hardware
watchpoints on a shared variable in a threaded (7+ threads) binary.
Sometimes the watchpoint won't trigger, even though the monitored
variable's value was modified.
Appreciate your feedback.
Best regards,
--
Luis Machado
LoP Toolchain
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Stephen Rothwell @ 2008-03-10 3:32 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <47D3B44D.8070909@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
Hi Heiko,
Just a few small comments.
On Sun, 09 Mar 2008 10:56:29 +0100 Heiko Schocher <hs@denx.de> wrote:
>
> +++ b/arch/powerpc/platforms/8xx/mgsuvd.c
>
> +#include <asm/of_platform.h>
You should include linux/of_platform.h (not asm/)
> +static struct cpm_pin mgsuvd_pins[] = {
Make this __initdata, please.
> + ROOT_DEV = Root_NFS;
I am not sue we do this explicitly any more ... hopefully someone else
will comment.
> +static struct of_device_id __initdata of_bus_ids[] = {
Make this __initdata, please.
> +static int __init declare_of_platform_devices(void)
> +{
> + if (!machine_is(mgsuvd))
> + return 0;
> +
> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(declare_of_platform_devices);
This should be "machine_device_initcall(mgsuvd,
declare_of_platform_devices);" then you don't need the machine_is() check
above.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Heiko Schocher @ 2008-03-10 6:33 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20080309195914.69d51e68@kernel.crashing.org>
Hello Vitaly,
Vitaly Bordug wrote:
> Heiko Schocher wrote:
>> the following patch adds support for the MPC852 based mgsuvd board
>> from keymile.
> Looks good overall. Please add supported/working/not working etc SoC devices state along with the patch
> description. Also a few really small comments below...
OK.
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> ---
[...]
>> +
>> + PowerPC,866@0 {
> But it's mpc852, isn't it?
Yes your are right.
>> + device_type = "cpu";
>> + reg = <0>;
>> + d-cache-line-size = <d#16>;
>> + i-cache-line-size = <d#16>;
>> + d-cache-size = <d#8192>;
>> + i-cache-size = <d#8192>;
>> + timebase-frequency = <0>; /* Filled in by
>> u-boot */
>> + bus-frequency = <0>; /* Filled in by u-boot
>> */
>> + clock-frequency = <0>; /* Filled in by
>> u-boot */
>> + interrupts = <f 2>; // decrementer
>> interrupt
> I would like all the comments to be consistent C style (because that's it for the most other dts'es).
Okay, I fix this, and send a new patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Heiko Schocher @ 2008-03-10 6:34 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080310143217.11e2b10f.sfr@canb.auug.org.au>
Hello Stephen,
Stephen Rothwell wrote:
> On Sun, 09 Mar 2008 10:56:29 +0100 Heiko Schocher <hs@denx.de> wrote:
>> +++ b/arch/powerpc/platforms/8xx/mgsuvd.c
>>
>> +#include <asm/of_platform.h>
>
> You should include linux/of_platform.h (not asm/)
Ok.
>> +static struct cpm_pin mgsuvd_pins[] = {
>
> Make this __initdata, please.
Argh... forgot this.
[...]
>> +static struct of_device_id __initdata of_bus_ids[] = {
>
> Make this __initdata, please.
Hmm.. it is __initdata, or? But I fix it to:
static __initdata struct of_device_id of_bus_ids[]
>> +static int __init declare_of_platform_devices(void)
>> +{
>> + if (!machine_is(mgsuvd))
>> + return 0;
>> +
>> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
>> +
>> + return 0;
>> +}
>> +device_initcall(declare_of_platform_devices);
>
> This should be "machine_device_initcall(mgsuvd,
> declare_of_platform_devices);" then you don't need the machine_is() check
> above.
Ok
I will send a overworked patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [Patch] 8xx: MGSUVD support
From: Stephen Rothwell @ 2008-03-10 6:35 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <47D4D686.8010101@denx.de>
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
Hi,
On Mon, 10 Mar 2008 07:34:46 +0100 Heiko Schocher <hs@denx.de> wrote:
>
> >> +static struct of_device_id __initdata of_bus_ids[] = {
> >
> > Make this __initdata, please.
>
> Hmm.. it is __initdata, or? But I fix it to:
OOPS, brain not working again after break :-)
sorry.
> static __initdata struct of_device_id of_bus_ids[]
It is right either way. But linux/init.h says it should go just before
the '=' sign.
> I will send a overworked patch.
Nice :-) ("overworked" means "having too much work to do" - I think you
meant "reworked")
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Sergej Stepanov @ 2008-03-10 7:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <20080307163747.GF10545@ld0162-tx32.am.freescale.net>
> Acked-by: Scott Wood <scottwood@freescale.com>, if I haven't already.
>=20
> -Scott
I thought, you did it.
Thank you.
--=20
Dipl.-Ing. Sergej Stepanov=20
Software-Entwicklung
IDS GmbH=20
E-PA (Entwicklung - Prozess Automatisierung)
Nobelstr. 18,=20
D-76275 Ettlingen=20
T. (0) 72 43/2 18-615=20
F. (0) 72 43/2 18-100=20
E. Sergej.Stepanov@ids.de
<http://www.ids.de>
Gesch=C3=A4ftsf=C3=BChrer: Norbert Wagner, Friedrich Abri=C3=9F=20
Sitz der Gesellschaft: Ettlingen=20
Amtsgericht Mannheim HRB 362503=20
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Roel Kluin @ 2008-03-10 8:22 UTC (permalink / raw)
To: benh; +Cc: Colin Leroy, linuxppc-dev, lkml
In-Reply-To: <1205136413.8621.3.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2008-03-10 at 08:46 +0100, Colin Leroy wrote:
>> On Mon, 10 Mar 2008 01:04:33 +0100, Roel Kluin wrote:
>>
>>> logical-bitwise & confusion
>> Looks good to me, but I'm not really maintaining that anymore :-)
>> I'm not sure who does, Cc:ing Benjamin as he'll probably know.
>
> Nobody is U suspect...
>
> Send it to the list linuxppc-dev@ozlabs.org, it should be picked up
> anyway.
(linuxppc-dev CC'd)
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..8ea7da2 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
int temp = simple_strtol(buf, NULL, 10);
- temp = temp && 0xFF;
+ temp &= 0xFF;
mutex_lock(&data->lock);
data->max_duty_at_overheat = temp;
^ permalink raw reply related
* RE: TQM5200 2.6-denx SM501 voyager enabling problem.
From: Pedro Luis D. L. @ 2008-03-10 8:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080308012738.0C3D9247AF@gemini.denx.de>
Wolfgang wrote:
>>=20
>> I thought about this possible solution (adding resource description to=20
>> device tree), but as far as I understood, the device tree was intended t=
o=20
>> describe the microcontroller peripherals and tqm5200, based on the mpc52=
00=20
>> is sold out also without sm501, so that's why I discarded this option.
>
>=20
> The device tree describes the hardware, and the TQM5200 (with SM501)
> and the TQM5200S (without the SM501) are two different boards and
> need different device trees.
>=20
So I got it wrong... Good to know. Once I had something working I can give =
it=20
a try and make a different device tree for TQM5200 and TQM5200S and try
to initialize the SM501 using of_platform api.
>=20
> And, Pedro - could you please restrict your line length to some 70+
> characters or so? Thanks.
Ups, sorry. I'll do it since now.
> Best regards,
>=20
> Wolfgang Denk
>
Best regards,
Pedro L. Dominguez.
=20
> --=20
> 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
> "The greatest warriors are the ones who fight for peace."
> - Holly Near
_________________________________________________________________
Tecnolog=EDa, moda, motor, viajes,=85suscr=EDbete a nuestros boletines para=
estar siempre a la =FAltima
Guapos y guapas, clips musicales y estrenos de cine. =
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Segher Boessenkool @ 2008-03-10 9:13 UTC (permalink / raw)
To: Roel Kluin; +Cc: Colin Leroy, lkml, linuxppc-dev
In-Reply-To: <47D4EFC1.1050403@tiscali.nl>
> diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
> index 9587869..8ea7da2 100644
> --- a/drivers/hwmon/adt7473.c
> +++ b/drivers/hwmon/adt7473.c
> @@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device
> *dev,
> struct i2c_client *client = to_i2c_client(dev);
> struct adt7473_data *data = i2c_get_clientdata(client);
> int temp = simple_strtol(buf, NULL, 10);
> - temp = temp && 0xFF;
> + temp &= 0xFF;
>
> mutex_lock(&data->lock);
> data->max_duty_at_overheat = temp;
The & 0xff here is bogus anyway; temp is only ever used as an u8,
so just declare it as that, or do proper overflow/underflow checking
on it. The patch will need testing on hardware too, since it changes
behaviour (it should be a bugfix, but who knows).
Segher
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Roel Kluin @ 2008-03-10 9:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Colin Leroy, Darrick J. Wong, lkml, linuxppc-dev
In-Reply-To: <64d5b5e6dfd0d1820d21db323ef88e25@kernel.crashing.org>
Segher Boessenkool wrote:
>> diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
>> index 9587869..8ea7da2 100644
>> --- a/drivers/hwmon/adt7473.c
>> +++ b/drivers/hwmon/adt7473.c
>> @@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device
>> *dev,
>> struct i2c_client *client = to_i2c_client(dev);
>> struct adt7473_data *data = i2c_get_clientdata(client);
>> int temp = simple_strtol(buf, NULL, 10);
>> - temp = temp && 0xFF;
>> + temp &= 0xFF;
>>
>> mutex_lock(&data->lock);
>> data->max_duty_at_overheat = temp;
>
> The & 0xff here is bogus anyway; temp is only ever used as an u8,
> so just declare it as that, or do proper overflow/underflow checking
> on it. The patch will need testing on hardware too, since it changes
> behaviour (it should be a bugfix, but who knows).
Maybe someone can test this?
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..2a2de73 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp && 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10) & 0xFF;
mutex_lock(&data->lock);
data->max_duty_at_overheat = temp;
^ permalink raw reply related
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Laurent Pinchart @ 2008-03-10 11:05 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: Scott Wood, linuxppc-dev, jgarzik, netdev
In-Reply-To: <1205135421.3837.1.camel@p60365-ste>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Monday 10 March 2008 08:50, Sergej Stepanov wrote:
> > Acked-by: Scott Wood <scottwood@freescale.com>, if I haven't already.
> >
> > -Scott
>
> I thought, you did it.
> Thank you.
Your documentation patch states that
"The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC."
If I'm not mistaken the code uses the first reg resource for MDC and the
second reg resource for MDIO. Which one should be fixed, the doc or the
code ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Laurent Pinchart @ 2008-03-10 12:17 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080307162135.GC10545@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
On Friday 07 March 2008 17:21, Scott Wood wrote:
> On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
> > The CPM dual port ram was defined in the device tree as follows (copied
> > from the MPC8272ADS board device tree).
> >
> > muram@0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges = <0 0 10000>;
> >
> > data@0 {
> > compatible = "fsl,cpm-muram-data";
> > reg = <0 2000 9800 800>;
> > };
> > };
> >
> > Changing the reg property to
> >
> > reg = <80 1f80 9800 800>;
> >
> > fixed my problem.
>
> Perhaps there's an SMC1 running with its parameter RAM at offset zero?
Good guess. U-Boot configured SMC1 with its parameter RAM at offset 0.
> > Does anyone have any clue regarding what could write to the dpram ? I
> > thought about some CPM peripheral set up by the boot loader, but my board
> > initialization code calls cpm2_reset() long before initializing SCC1.
>
> cpm2_reset() doesn't currently actually reset the CPM, for some reason
> (unlike cpm1). This should probably be fixed, though then we'd have to
> deal with assigning SMC parameter RAM addresses ourselves.
I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there any
reason not to rset the CPM in cpm2_reset() ?
How should SMC parameter RAM assignment be handled ? I'm not very familiar
with the CPM1, but for CPM2 the cpm_uart driver could easily cpm_dpalloc()
parameter RAM.
> For now, the above fix should be done on any board with an active SMC
> device (assuming SMC parameter RAM at zero, as u-boot sets it; other
> bootloaders may need to exempt a different region).
Thanks for your help.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: DTC 1.1.0 Release!
From: Geert Uytterhoeven @ 2008-03-10 12:32 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JI5CO-0002Y1-A1@jdl.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1001 bytes --]
Hi John,
On Thu, 24 Jan 2008, Jon Loeliger wrote:
> You may find it using git here:
>
> git://www.jdl.com/software/dtc
>
> A tarball snap-shot is also available here:
>
> http://www.jdl.com/software/dtc-1.1.0.tgz
>
> Please let me know if there are problems with it!
It looks like www.jdl.com got wiped out? I cannot get dtc anymore from your
site, both git and http (default apache page) fail?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Sergej Stepanov @ 2008-03-10 13:17 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev, jgarzik, netdev
In-Reply-To: <200803101205.16158.laurentp@cse-semaphore.com>
Am Montag, den 10.03.2008, 12:05 +0100 schrieb Laurent Pinchart:
> Your documentation patch states that
>
> "The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC."
>
> If I'm not mistaken the code uses the first reg resource for MDC and the
> second reg resource for MDIO. Which one should be fixed, the doc or the
> code ?
>
> Best regards,
>
Ooops... Sorry...
You are right: the first is MDC, second MDIO.
I have to fix the docu, it would be simpler.
Thank you and best regards
Sergej.
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Jens Osterkamp @ 2008-03-10 14:01 UTC (permalink / raw)
To: linuxppc-dev, luisgpm
Cc: Jan Kratochvil, Paul Mackerras, Roland McGrath, Arnd Bergmann
In-Reply-To: <1205110432.10078.5.camel@gargoyle>
On Monday 10 March 2008, Luis Machado wrote:
> > Yes, I know. I tried it on the PS3 first and couldn't reproduce
> > the bug he saw on the blade.
>
> Arnd,
>
> Do we have any news on this topic?
>
> I've seen this happening quite often within GDB when using hardware
> watchpoints on a shared variable in a threaded (7+ threads) binary.
> Sometimes the watchpoint won't trigger, even though the monitored
> variable's value was modified.
On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
already did this. Uli Weigand found this back in November. I submitted
a patch for this which went into 2.6.25-rc4.
Can you please try again with rc4 ?
Gruß,
Jens
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Query about Kernel Load address
From: Akhilesh Soni @ 2008-03-10 13:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi,
I''ve ported u-boot-1.1.1 sucessfully on my IBM STBx25xx rewood6 platform (ppc405 core). Earlier in the ppcboot I used to load the zImage.treeboot directly via the bootloader and it used to relocate and run.
But with u-boot which image I should use and which address I should load the image. My board has 64 MB of RAM and out of which 32 MB is mapped at 0x0000000 and another 32MB is mapped at 0xA0000000. The U-boot code is located at 0x1fe2000 in RAM.
Also is there any 2.6 kernel source supporting redwood6 IBM STBx25xx platform.
Thanx in advance.
Regards,
Akhilesh
[-- Attachment #2: Type: text/html, Size: 1425 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Kumar Gala @ 2008-03-10 14:39 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200802021047.32055.yur@emcraft.com>
On Feb 2, 2008, at 1:47 AM, Yuri Tikhonov wrote:
>
> Hello,
>
> Here is the patch which makes Linux-2.6 swap routines operate
> correctly on
> the ppc-8xx-based machines.
>
> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
applied.
- k
^ permalink raw reply
* Re: [PATCH v2] Make 83xx perfmon support selectable
From: Kumar Gala @ 2008-03-10 14:39 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, paulus
In-Reply-To: <1204934343-5235-1-git-send-email-afleming@freescale.com>
On Mar 7, 2008, at 5:59 PM, Andy Fleming wrote:
> Not all e300 cores support the performance monitors, and the ones
> that don't will be confused by the mf/mtpmr instructions. This
> allows the support to be optional, so the 8349 can turn it off
> while the 8379 can turn it on. Sadly, those aren't config options,
> so it will be left to the defconfigs and the users to make that
> determination.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
>
> Ugh. The previous version was a little hasty. Needed to base off
> PPC_83xx rather than 83xx
>
> arch/powerpc/platforms/Kconfig | 1 -
> arch/powerpc/platforms/Kconfig.cputype | 7 ++++++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
applied.
- k
^ permalink raw reply
* [PATCH v3] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2008-03-10 15:02 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev, jgarzik, netdev
In-Reply-To: <200803101205.16158.laurentp@cse-semaphore.com>
The patch updates the booting-without-of.txt-file.
There is a description for the case
if mdio data and clock pins are on different processor ports.
It extends the "[PATCH v3] using mii-bitbang on different processor ports".
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 7b4e8a7..3285f58 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2003,10 +2003,14 @@ platforms are moved over to use the flattened-device-tree model.
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)
+ fsl,cpm2-mdio-bitbang
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
+ The first reg resource is the I/O port register block on which MDC
+ resides. The second reg resource is the I/O port register block on
+ which MDIO resides. If there is only one reg resource, it is used for
+ both MDIO and MDC.
+ fsl,mdio-pin : pin of chosen port for controlling mdio data
+ fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
^ permalink raw reply related
* OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-10 15:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ben, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]
Hi everybody,
as part of a ARCH=ppc to ARCH=powerpc migration process, I'm looking for an
OpenFirmware compatible way to handle a RAM-based MTD device.
On the platform_device based ppc architecture, the drivers/mtd/maps/plat-ram.c
driver handled "mtd-ram" platform devices. There is no such driver for the
OF-based powerpc architecture.
As a temporary workaround I hacked the physmap_of driver to
handle "direct-mapped" OF devices oh type "ram" by adding a corresponding
entry in the of_flash_match[] array. This seems to work fine.
What would be the preferred way to handle OF-compatible RAM-based MTD
devices ? The 3 ways I can think of are
1. porting the plat-ram driver to OF (the driver isn't used in the kernel tree
but I suspect it is used by out-of-tree boards)
2. creating a new plat-ram-of driver, much like the physmap_of driver comes
from the physmap driver
3. extending the physmap_of driver to handle RAM devices (in which case
references to "flash" in the function names should probably be replaced
by "mtd")
I live option 3 better so far.
Has anyone already worked on this ? Is there any defined device tree mapping
for MTD RAM devices ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Luis Machado @ 2008-03-10 15:13 UTC (permalink / raw)
To: Jens Osterkamp
Cc: linuxppc-dev, Paul Mackerras, Roland McGrath, Arnd Bergmann,
Jan Kratochvil
In-Reply-To: <200803101501.34439.jens@de.ibm.com>
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
I will try it and will post the results back.
Thanks Jens.
Regards,
--
Luis Machado
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Confused about usercopy_64.c
From: Timur Tabi @ 2008-03-10 16:38 UTC (permalink / raw)
To: linuxppc-dev
I'm confused about something in usercopy_64.c:
unsigned long copy_from_user(void *to, const void __user *from, unsigned long n)
{
if (likely(access_ok(VERIFY_READ, from, n)))
n = __copy_from_user(to, from, n);
else
memset(to, 0, n);
return n;
}
If access_ok() returns false, then that means that we cannot copy the data from
user-space. So why are we returning 'n'? Shouldn't we return zero, to let the
caller know that the function failed?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Confused about usercopy_64.c
From: Olof Johansson @ 2008-03-10 16:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47D56419.6000704@freescale.com>
On Mon, Mar 10, 2008 at 11:38:49AM -0500, Timur Tabi wrote:
> I'm confused about something in usercopy_64.c:
>
> unsigned long copy_from_user(void *to, const void __user *from, unsigned long n)
> {
> if (likely(access_ok(VERIFY_READ, from, n)))
> n = __copy_from_user(to, from, n);
> else
> memset(to, 0, n);
> return n;
> }
>
> If access_ok() returns false, then that means that we cannot copy the data from
> user-space. So why are we returning 'n'? Shouldn't we return zero, to let the
> caller know that the function failed?
copy_from_user() returns number of bytes _not_ copied.
-Olof
^ 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