* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-26 20:38 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <20071226162943.GB11230@localhost.localdomain>
On Wed, Dec 26, 2007 at 07:29:44PM +0300, Anton Vorontsov wrote:
> On Tue, Dec 25, 2007 at 02:44:46PM -0600, Timur Tabi wrote:
> > Anton Vorontsov wrote:
> >
> > >Yup. I've seen it, thanks. I'm going to test it as well. ;-)
> >
> > If they work for you, please let Kumar know.
>
> Unfortunately they don't.
>
> root@mpc8360erdk:~# echo abc > /dev/ttyQE0
>
> And hang. No interrupts.
I've just tried to set CD and CTS to GPIO functions (for loopbacking),
as suggested in the ref manual.. and still it doesn't work. Hm..
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCHv2] powerpc: DBox2 Board Support
From: Arnd Bergmann @ 2007-12-26 19:53 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Scott Wood, linuxppc-dev, linux-kernel, linuxppc-embedded
In-Reply-To: <47726DB5.2030507@scram.de>
On Wednesday 26 December 2007, Jochen Friedrich wrote:
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0 2000000>;
> >> + };
> >
> > I thought there are both models with 32MB and 16MB available.
> > If that's true, shouldn't this be filled out by the boot loader?
>
> IIRC, the cuImage wrapper overwrites this with the boot loader
> parameters.
Then maybe set it to zero size in the dts file, and add a comment.
> OTOH, the memory is part of the localbus (CS1). Should it be a child
> of localbus in this case?
No, memory nodes are required to be at the root of the device tree
for historic reasons.
> I didn't check FB_OF. On Dbox2, the avia driver creates a
> framebuffer device.
fb_of needs some properties in the device tree set up correctly,
but is very simple otherwise. If it does all you need, it's
probably a good idea to use that and get rid of the avia framebuffer
driver
> There are two mods available using the block layer, although currently i don't
> support any of them:
>
> 1. using the GPIO lines of the modem port, it's possible to connect a SD card.
> It might be possible to use it using the GPIO SPI driver (but it would need
> some glue code to create a platform device).
>
> 2. using the memory expansion port and CS2, there is an IDE interface available
> with a CPLD acting as localbus/IDE bridge. There is a device driver for
> ARCH=ppc.
>
> Unfortunately, i don't own any of these modifications.
If neither of these is in the mainline kernel, it doesn't make sense to
have support for the block layer in defconfig, so just try how much
memory you can free up with this.
> >> +static void __init dbox2_setup_arch(void)
> >> +{
> >> + struct device_node *np;
> >> + static u8 __iomem *config;
> >> +
> >> + cpm_reset();
> >> + init_ioports();
> >> +
> >> + /* Enable external IRQs for AVIA chips */
> >> + clrbits32(&mpc8xx_immr->im_siu_conf.sc_siumcr, 0x00000c00);
> >
> > This smells like a hack. What are AVIA chips, and shouldn't
> > their driver enable the IRQs?
>
> No. This just configures the Pin as IRQ input. Maybe, the new GPIO
> functions could be used for this, instead. Then it could be done
> in the driver (the driver should't directly mess with SIU internals).
Maybe it should then be done in the boot wrapper. If the device
tree lists this line as an interrupt, I'd say that is what it should
be.
> >> +static struct of_device_id __initdata of_bus_ids[] = {
> >> + { .name = "soc", },
> >> + { .name = "cpm", },
> >> + { .name = "localbus", },
> >> + {},
> >> +};
> >
> > Shouldn't this check for 'compatible' properties instead of 'name'?
>
> I copied this from mpc885ads_setup.c.
Right, I noticed before that we're rather inconsistent with this.
It would really be good to have more common standards on this.
> > I also once did a patch that let you have a default 'of_bus_ids'
> > member in the ppc_md. I never got around to submitting that, but
> > if there is interest, I can dig it out again.
>
> That would be nice :)
The reason I haven't submitted it yet is that I'm not sure whether
there are cases where we actually _need_ to test for 'name' instead
of 'compatible' because of existing device trees in firmware.
I might just do a patch and see if someone complains about the
idea.
Arnd <><
^ permalink raw reply
* Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
From: Anton Vorontsov @ 2007-12-26 16:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <11970458703666-git-send-email-timur@freescale.com>
On Fri, Dec 07, 2007 at 10:44:30AM -0600, Timur Tabi wrote:
> Add support for UART serial ports using a Freescale QUICC Engine
> (found on some MPC83xx and MPC85xx SOCs).
>
> Updated booting-without-of.txt to define new properties for a QE UART node,
> and a new node definition that describes uploaded QE firmware.
>
> Because of a silicon bug in some QE-enabled SOCs (e.g. 8323 and 8360), a new
> microcode is required. This microcode implements UART via a work-around,
> hence it's called "Soft-UART". This driver can use the QE firmware upload
> feature to upload the correct microcode to the QE.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> @@ -250,6 +279,26 @@
> pio-handle = < &pio4 >;
> };
>
> + ucc@2400 {
> + device_type = "serial";
> + compatible = "ucc_uart";
> + model = "UCC";
model isn't used, is it needed at all?
> + device-id = <5>; /* The UCC number, 1-7*/
> + port-number = <0>; /* Which ttyQEx device */
> + soft-uart; /* We need Soft-UART */
> + reg = <2400 200>;
> + interrupts = <28>; /* From Table 18-12 */
> + interrupt-parent = < &qeic >;
> + /*
> + * For Soft-UART, we need to set TX to 1X, which
> + * means specifying separate clock sources.
> + */
> + rx-clock-name = "brg5";
> + tx-clock-name = "brg6";
> + pio-handle = < &pio5 >;
[...]
> + if (soft_uart) {
> + struct qe_firmware_info *qe_fw_info;
> +
> + qe_fw_info = qe_get_firmware_info();
> +
> + /* Check if the firmware has been uploaded. */
> + if (strstr(qe_fw_info->id, "Soft-UART")) {
qe_fw_info used w/o NULL checking.
> + firmware_loaded = 1;
> + } else {
> + char filename[32];
> + unsigned int soc;
> + unsigned int rev_h;
> + unsigned int rev_l;
> +
> + soc = soc_info(&rev_h, &rev_l);
> + if (!soc) {
> + dev_err(&ofdev->dev, "unknown CPU model\n");
> + return -ENXIO;
> + }
> + sprintf(filename, "fsl_qe_ucode_uart_%u_%u%u.bin",
> + soc, rev_h, rev_l);
> +
> + dev_info(&ofdev->dev, "waiting for firmware %s\n",
> + filename);
> +
> + /*
> + * We call request_firmware_nowait instead of
> + * request_firmware so that the driver can load and
> + * initialize the ports without holding up the rest of
> + * the kernel. If hotplug support is enabled in the
[...]
> +
> + qe_port->port.irq = irq_of_parse_and_map(np, 0);
> + if (qe_port->port.irq == NO_IRQ) {
> + dev_err(&ofdev->dev, "could not map IRQ for UCC%u\n",
> + qe_port->ucc_num + 1);
> + kfree(qe_port);
> + return -EINVAL;
> + }
> +
> + np = of_find_node_by_type(NULL, "qe");
Please, add "fsl,qe" compatible matching.
> + if (!np) {
> + dev_err(&ofdev->dev, "could not find parent 'qe' node\n");
> + kfree(qe_port);
> + return -EINVAL;
> + }
> +
[...]
> +static struct of_platform_driver ucc_uart_of_driver = {
> + .owner = THIS_MODULE,
> + .name = "ucc_uart",
Maybe better fsl,ucc_uart?
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v5] qe: add ability to upload QE firmware
From: Anton Vorontsov @ 2007-12-26 16:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <11970422334145-git-send-email-timur@freescale.com>
On Fri, Dec 07, 2007 at 09:43:53AM -0600, Timur Tabi wrote:
> Define the layout of a binary blob that contains a QE firmware and instructions
> on how to upload it. Add function qe_upload_firmware() to parse the blob
> and perform the actual upload. Fully define 'struct rsp' in immap_qe.h to
> include the actual RISC Special Registers. Added description of a new
> QE firmware node to booting-without-of.txt.
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> Argh, another booting-without-of.txt fix. There are 8 virtual traps, not 16.
>
> This patch is for Kumar's for-2.6.25 branch. This code is necessary for
> my QE UART driver.
>
> Documentation/powerpc/00-INDEX | 3 +
> Documentation/powerpc/booting-without-of.txt | 33 +++-
> Documentation/powerpc/qe_firmware.txt | 295 ++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig | 1 +
> arch/powerpc/sysdev/qe_lib/qe.c | 240 +++++++++++++++++++++
> include/asm-powerpc/immap_qe.h | 34 +++-
> include/asm-powerpc/qe.h | 61 ++++++
> 7 files changed, 663 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/powerpc/qe_firmware.txt
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..8b27711 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
...
> +
> + Example:
> +
> + firmware {
> + id = "Soft-UART";
> + extended_modes = <0 0>;
> + virtual_traps = <0 0 0 0 0 0 0 0>;
I believe using underscores for the property name is discouraged.
> + }
> +
...
> +VI - Sample Code for Creating Firmware Files
> +============================================
> +
> +A Python program that creates firmware binaries from the header files normally
> +distributed by Freescale can be found on http://opensource.freescale.com.
Hm... I didn't find it there. Could you provide more specific pointer?
...
> index 1df3b4a..497eb88 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
...
> +struct qe_firmware_info *qe_get_firmware_info(void)
> +{
> + static int initialized;
> +
> + /*
> + * If we haven't checked yet, and a driver hasn't uploaded a firmware
> + * yet, then check the device tree for information.
> + */
> + do {
^^^^
This is very unusual method of error handling. You could stick
to gotos and lower the indentation level.
> + struct device_node *qe;
> + struct device_node *fw = NULL;
> + const char *sprop;
> + const u32 *iprop;
> +
> + if (initialized || qe_firmware_uploaded)
> + break;
> +
> + initialized = 1;
> +
> + qe = of_find_node_by_type(NULL, "qe");
Please, add compatible "fsl,qe" matching, so this code could
work with new device trees.
> + if (!qe)
> + break;
> +
> + /* Find the 'firmware' child node */
> + while ((fw = of_get_next_child(qe, fw)))
> + if (strcmp(fw->name, "firmware") == 0)
> + break;
Hmm. Maybe of_find_node_by_name? Or better by compatible.
> +
> + /* Did we find the 'firmware' node? */
> + if (!fw) {
> + of_node_put(qe);
> + break;
> + }
> +
> + qe_firmware_uploaded = 1;
> +
> + /* Copy the data into qe_firmware_info*/
> + sprop = of_get_property(fw, "id", NULL);
> + if (sprop)
> + strncpy(qe_firmware_info.id, sprop,
> + sizeof(qe_firmware_info.id) - 1);
> +
> + iprop = of_get_property(fw, "extended_modes", NULL);
Checking for size?
> + if (iprop)
> + qe_firmware_info.extended_modes =
> + (u64) iprop[0] << 32 | iprop[1];
> +
> + iprop = of_get_property(fw, "virtual_traps", NULL);
size?
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-26 16:29 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47716BBE.5090000@freescale.com>
On Tue, Dec 25, 2007 at 02:44:46PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >Yup. I've seen it, thanks. I'm going to test it as well. ;-)
>
> If they work for you, please let Kumar know.
Unfortunately they don't.
root@mpc8360erdk:~# echo abc > /dev/ttyQE0
And hang. No interrupts.
After ^C:
ucc_uart e0102400.ucc: shutdown timeout
The same for ttyQE1 (just for testing I set it up to not use
Soft-UART).
The same for loopback mode.
I wonder what are the symptoms if microcode is at fault? According
to errata description, hang isn't something I should get on the
transmit attempt.
> >MPC8360E, Rev: 21. Are you aware of any known issues on this chip
> >regarding UCC serials?
>
> Yep. You need a microcode upload. My patches describe everything.
Well. All I've found is: QERAMPTCH.zip ("RAM Microcode Patches for
PowerQUICC II Pro Family QE Errata"), which should fix QE_UART5 errata
for MPC8323 Rev 1.1. Can I assume it works for MPC8360 too? I've tried
it. No luck.
Here are dts entries I use:
firmware {
id = "Soft-UART";
extended_modes = <0 0>;
virtual_traps = <0 0 0 0 0 0 0 0>;
};
ucc@2400 {
device_type = "serial";
compatible = "ucc_uart";
reg = <0x2400 0x200>;
device-id = <5>;
port-number = <0>;
rx-clock-name = "brg7";
tx-clock-name = "brg8";
interrupts = <40>;
interrupt-parent = <&qeic>;
soft-uart;
};
ucc@3400 {
device_type = "serial";
compatible = "ucc_uart";
reg = <0x3400 0x200>;
device-id = <6>;
port-number = <1>;
rx-clock-name = "brg14";
tx-clock-name = "brg14";
interrupts = <41>;
interrupt-parent = <&qeic>;
};
Any ideas?
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-26 16:19 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, paulus, linuxppc-dev
In-Reply-To: <200712261708.51432.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
>> Michael Buesch <mb@bu3sch.de> writes:
>>
>> > + set +e
>> > mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
>> > $uboot_version -d "$vmz" "$ofile"
>> > + [ $? -eq 0 ] || exit 0
>> > + set -e
>>
>> mkimage ... || exit 0
>
> Could you PLEASE increase your verbosity?
> Why is mkimage || exit 0 any better than my test?
Many roads lead to Rome. Take the one you like most.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-26 16:16 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <200712261712.59237.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> On Wednesday 26 December 2007 17:08:55 Andreas Schwab wrote:
>> > I even posted it for review on this list and nobody complained,
>> > including you.
>>
>> ??? I did point out an error in your patch just now.
>
> I posted it for review a few days ago and the only response
> I got was "This is probably OK for now..." from Josh.
And what does this have to do with me? I didn't see your mail at all.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-26 16:12 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <jeve6l1lrc.fsf@sykes.suse.de>
On Wednesday 26 December 2007 17:08:55 Andreas Schwab wrote:
> > I even posted it for review on this list and nobody complained,
> > including you.
>
> ??? I did point out an error in your patch just now.
I posted it for review a few days ago and the only response
I got was "This is probably OK for now..." from Josh.
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-26 16:08 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Andrew Morton, paulus, linuxppc-dev
In-Reply-To: <jezlvx1m00.fsf@sykes.suse.de>
On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
> Michael Buesch <mb@bu3sch.de> writes:
>
> > + set +e
> > mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
> > $uboot_version -d "$vmz" "$ofile"
> > + [ $? -eq 0 ] || exit 0
> > + set -e
>
> mkimage ... || exit 0
Could you PLEASE increase your verbosity?
Why is mkimage || exit 0 any better than my test?
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-26 16:08 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <200712261701.33669.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> I tested this and it obviously works very well for me.
Obviously your tests were incomplete.
> I even posted it for review on this list and nobody complained,
> including you.
??? I did point out an error in your patch just now.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-26 16:03 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, paulus, linuxppc-dev
In-Reply-To: <200712261655.56432.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> + set +e
> mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
> $uboot_version -d "$vmz" "$ofile"
> + [ $? -eq 0 ] || exit 0
> + set -e
mkimage ... || exit 0
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-26 16:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <je4pe530vq.fsf@sykes.suse.de>
On Wednesday 26 December 2007 16:56:57 Andreas Schwab wrote:
> > That would help a lot not wasting my time.
>
> How about testing your changes first?
Stop the bullshit, please.
I tested this and it obviously works very well for me.
I even posted it for review on this list and nobody complained,
including you.
But I see what you are complaining about, now.
It would also error out, if mkimage was installed (which is not the
case for me. That's the whole reason for me making this patch!).
Are you OK with the new version I just sent?
--
Greetings Michael.
^ permalink raw reply
* [PATCH v2] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-26 15:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: paulus, linuxppc-dev
This fixes the boot image wrapper script to not fail the kernel
build if mkimage is not available.
As some distributions don't ship the mkimage program and some people are not
interested in uboot images anyway, we don't want to fail the whole kernel
build process because of this unneeded dependency.
Simply drop an error message, but don't fail the build.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Josh Boyer is working on merging mkimage into the kernel tree.
Until that happened, please merge the patch below into the mainline kernel
to avoid build breakage for people without installed uboot tools.
Index: wireless-2.6/arch/powerpc/boot/wrapper
===================================================================
--- wireless-2.6.orig/arch/powerpc/boot/wrapper 2007-12-26 16:48:47.000000000 +0100
+++ wireless-2.6/arch/powerpc/boot/wrapper 2007-12-26 16:52:58.000000000 +0100
@@ -197,8 +197,11 @@ fi
case "$platform" in
uboot)
rm -f "$ofile"
+ set +e
mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
$uboot_version -d "$vmz" "$ofile"
+ [ $? -eq 0 ] || exit 0
+ set -e
if [ -z "$cacheit" ]; then
rm -f "$vmz"
fi
@@ -254,8 +257,11 @@ coff)
;;
cuboot*)
gzip -f -9 "$ofile"
+ set +e
mkimage -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \
$uboot_version -d "$ofile".gz "$ofile"
+ [ $? -eq 0 ] || exit 0
+ set -e
;;
treeboot*)
mv "$ofile" "$ofile.elf"
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-26 15:56 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <200712261635.43188.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> On Wednesday 26 December 2007 16:33:57 Andreas Schwab wrote:
>> Michael Buesch <mb@bu3sch.de> writes:
>>
>> > On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote:
>> >> Michael Buesch <mb@bu3sch.de> writes:
>> >>
>> >> > + if ! [ -x mkimage ]; then
>> >>
>> >> What is this supposed to test?
>> >
>> > from man test:
>>
>> You didn't answer my question.
>
> I'm not sure how I can make the manual text any clearer
I know very well what it *does*, thank you. But that does mean that is
does what it is *supposed* to do.
> -x FILE
> FILE exists and execute (or search) permission is granted
^^^^
> It tests if the program exists and is executable.
^^^^^^^
Observe the fine difference in the choice of words.
> That would help a lot not wasting my time.
How about testing your changes first?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-26 15:35 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <je8x3h31y2.fsf@sykes.suse.de>
On Wednesday 26 December 2007 16:33:57 Andreas Schwab wrote:
> Michael Buesch <mb@bu3sch.de> writes:
>
> > On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote:
> >> Michael Buesch <mb@bu3sch.de> writes:
> >>
> >> > + if ! [ -x mkimage ]; then
> >>
> >> What is this supposed to test?
> >
> > from man test:
>
> You didn't answer my question.
I'm not sure how I can make the manual text any clearer
-x FILE
FILE exists and execute (or search) permission is granted
It tests if the program exists and is executable.
Could you please be more specific about what you don't understand?
That would help a lot not wasting my time.
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-26 15:33 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <200712261610.28489.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote:
>> Michael Buesch <mb@bu3sch.de> writes:
>>
>> > + if ! [ -x mkimage ]; then
>>
>> What is this supposed to test?
>
> from man test:
You didn't answer my question.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: Jochen Friedrich @ 2007-12-26 15:12 UTC (permalink / raw)
To: Jochen Friedrich, Scott Wood, linuxppc-dev
In-Reply-To: <20071225010412.GL21311@localhost.localdomain>
Hi David,
>>>> + // Port D is LCD exclusive. Don't export as GPIO
>>>> + CPM1_PIO: pio@970 {
>>>> + compatible = "fsl,cpm1-pario";
>>>> + reg = <970 180>;
>>>> + num-ports = <3>;
>>>> + #gpio-cells = <2>;
>>>> + };
>>>> +
>>>> + lcd@970 {
>>>> + reg = <970 10>;
>>>> + compatible = "samsung,ks0713";
>>> Is this representing an LCD controller, or the display itself. Either
>>> way I'm surprised there's something here in the SoC that has a
>>> compatible string that's not "fsl,something"
>> It's a LCD controller wired to PortD. PortD is used for four 1bit lines
>> and one 8bit bus.
>
> I'm still kind of confused here. Does the pio@970 node above
> represent the PortD controller? If the LCD controller is accessed
> solely through PortD, then it should be a child of the PortD node.
>
> At present, pio and lcd have overlapping reg resources which is
> certainly wrong.
>
pio@970 represent 4 ports (A-D). Ports A-C are used as GPIO lines. Port D
is exclusively used for the LCD, but it needs an 8bit accessor. Unfortunately,
the GPIO API doesn't have such an accessor, so the LCD driver needs to access
Port D itself and needs to make sure no other driver can access Port D via the
GPIO API. The representation as child of pio seems reasonable.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-26 15:10 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <jed4st3446.fsf@sykes.suse.de>
On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote:
> Michael Buesch <mb@bu3sch.de> writes:
>
> > + if ! [ -x mkimage ]; then
>
> What is this supposed to test?
from man test:
-x FILE
FILE exists and execute (or search) permission is granted
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCHv2] powerpc: DBox2 Board Support
From: Jochen Friedrich @ 2007-12-26 15:05 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Scott Wood, linuxppc-dev, linux-kernel, linuxppc-embedded
In-Reply-To: <200712241318.02299.arnd@arndb.de>
Hi Arnd,
>> This patch adds device tree source, default config and setup code for
>> DBox2 devices.
>
ia > Cool stuff. I used to have one of these boxes myself, maybe I should
> get one again when it's hitting mainline.
>
> Is this already a complete port, or do you also need some device
> drivers or boot wrapper code to go along with it?
Currently, it needs the u-boot patches from cvs.tuxbox.org and some
external device drivers (however, they can all be loaded as modules).
The port is complete enough to get a console on the serial port and
a rootfs either on flash or on nfs.
>> + memory {
>> + device_type = "memory";
>> + reg = <0 2000000>;
>> + };
>
> I thought there are both models with 32MB and 16MB available.
> If that's true, shouldn't this be filled out by the boot loader?
IIRC, the cuImage wrapper overwrites this with the boot loader
parameters.
OTOH, the memory is part of the localbus (CS1). Should it be a child
of localbus in this case?
>> +#
>> +# Frame buffer hardware drivers
>> +#
>> +# CONFIG_FB_OF is not set
>> +# CONFIG_FB_VGA16 is not set
>> +# CONFIG_FB_S1D13XXX is not set
>> +# CONFIG_FB_IBM_GXT4500 is not set
>> +# CONFIG_FB_VIRTUAL is not set
>> +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
>
> No hardware framebuffer driver? Can't you use
> the FB_OF driver by default? I'd guess that a
> set-top box without output is rather pointless ;-)
I didn't check FB_OF. On Dbox2, the avia driver creates a
framebuffer device.
>> +# DOS/FAT/NT Filesystems
>> +#
>> +CONFIG_FAT_FS=y
>> +CONFIG_MSDOS_FS=y
>> +CONFIG_VFAT_FS=y
>> +CONFIG_FAT_DEFAULT_CODEPAGE=437
>> +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
>> +# CONFIG_NTFS_FS is not set
>
> What media can you connect that use the FAT file system?
>
> I'd guess that if you can get rid of these, you can also
> disable the entire block layer, which should free up
> some kernel memory.
There are two mods available using the block layer, although currently i don't
support any of them:
1. using the GPIO lines of the modem port, it's possible to connect a SD card.
It might be possible to use it using the GPIO SPI driver (but it would need
some glue code to create a platform device).
2. using the memory expansion port and CS2, there is an IDE interface available
with a CPLD acting as localbus/IDE bridge. There is a device driver for
ARCH=ppc.
Unfortunately, i don't own any of these modifications.
>> +
>> +/* Vendor information in BR Bootloader
>> + */
>> +
>> +#define DBOX2_VENDOR_OFFSET (0x1ffe0)
>> +
>> +enum dbox2_mid {
>> + DBOX2_MID_NOKIA = 1,
>> + DBOX2_MID_PHILIPS = 2,
>> + DBOX2_MID_SAGEM = 3,
>> +};
>> +
>> +enum dbox2_mid dbox2_get_mid(void);
>
> Can you move this functionality from the kernel to the boot wrapper?
> It looks like this is something that really belongs into the device
> tree.
OK.
>> + if (dbox2_manuf_id == DBOX2_MID_NOKIA)
>> + np = of_find_node_by_path("/localbus@8000000/enx@0");
>> + else
>> + np = of_find_node_by_path("/localbus@8000000/gtx@0");
>> +
>> + if (np) {
>> + of_detach_node(np);
>> + of_node_put(np);
>> + }
>> +
>> + if (dbox2_manuf_id == DBOX2_MID_PHILIPS)
>> + np = of_find_node_by_path("/localbus@8000000/cam@4000000");
>> + else
>> + np = of_find_node_by_path("/localbus@8000000/cam@4040000");
>> +
>> + if (np) {
>> + of_detach_node(np);
>> + of_node_put(np);
>> + }
>> +}
>
> What is this code for? Why do you want to detach nodes from the device
> tree that have been put in there by the boot loader?
There are small differences between the 3 manufacturers. I guess this
should go to the boot wrapper, as well.
This is even more important if the localbus uses #address-cells = <2>, as
the differen manufacturers set up the address mapping for CS3, CS5 and CS7
differently.
>> +static void __init dbox2_setup_arch(void)
>> +{
>> + struct device_node *np;
>> + static u8 __iomem *config;
>> +
>> + cpm_reset();
>> + init_ioports();
>> +
>> + /* Enable external IRQs for AVIA chips */
>> + clrbits32(&mpc8xx_immr->im_siu_conf.sc_siumcr, 0x00000c00);
>
> This smells like a hack. What are AVIA chips, and shouldn't
> their driver enable the IRQs?
No. This just configures the Pin as IRQ input. Maybe, the new GPIO
functions could be used for this, instead. Then it could be done
in the driver (the driver should't directly mess with SIU internals).
>> +static struct of_device_id __initdata of_bus_ids[] = {
>> + { .name = "soc", },
>> + { .name = "cpm", },
>> + { .name = "localbus", },
>> + {},
>> +};
>
> Shouldn't this check for 'compatible' properties instead of 'name'?
I copied this from mpc885ads_setup.c.
>> +static int __init declare_of_platform_devices(void)
>> +{
>> + /* Publish the QE devices */
>> + if (machine_is(dbox2))
>> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
>> +
>> + return 0;
>> +}
>> +device_initcall(declare_of_platform_devices);
>
> This is a candidate for the new platform_initcall stuff.
>
> I also once did a patch that let you have a default 'of_bus_ids'
> member in the ppc_md. I never got around to submitting that, but
> if there is interest, I can dig it out again.
That would be nice :)
>> --- a/include/asm-powerpc/mpc8xx.h
>> +++ b/include/asm-powerpc/mpc8xx.h
>> @@ -23,6 +23,10 @@
>> #include <platforms/8xx/mpc885ads.h>
>> #endif
>>
>> +#if defined(CONFIG_DBOX2)
>> +#include <platforms/8xx/dbox2.h>
>> +#endif
>> +
>
> Don't hide #includes or platform specific #defines in #ifdef.
As soon as the manufacturer info is included in the device tree,
dbox2.h is no longer needed.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-26 14:47 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <200712261453.41849.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> + if ! [ -x mkimage ]; then
What is this supposed to test?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-26 13:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: paulus, linuxppc-dev
This fixes the boot image wrapper script to not fail the kernel
build if mkimage is not available.
As some distributions don't ship the mkimage program and some people are not
interested in uboot images anyway, we don't want to fail the whole kernel
build process because of this unneeded dependency.
Simply drop an error message, but don't fail the build.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Josh Boyer is working on merging mkimage into the kernel tree.
Until that happened, please merge the patch below into the mainline kernel
to avoid build breakage for people without installed uboot tools.
Index: wireless-2.6/arch/powerpc/boot/wrapper
===================================================================
--- wireless-2.6.orig/arch/powerpc/boot/wrapper 2007-12-23 20:10:07.000000000 +0100
+++ wireless-2.6/arch/powerpc/boot/wrapper 2007-12-23 20:22:41.000000000 +0100
@@ -195,6 +195,14 @@ if [ -n "$version" ]; then
fi
case "$platform" in
+cuboot* | uboot)
+ if ! [ -x mkimage ]; then
+ echo "mkimage not available. Can not create $platform image."
+ exit 0
+ fi
+esac
+
+case "$platform" in
uboot)
rm -f "$ofile"
mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
^ permalink raw reply
* Re: Time for cell code reshuffle?
From: Ishizaki Kou @ 2007-12-26 11:42 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, cbe-oss-dev, arnd, jk
In-Reply-To: <1198357215.6686.8.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2007-12-21 at 20:15 +0100, Arnd Bergmann wrote:
> > > It seems platforms/cell should have the shared and/or generic code,
> > and the other
> > > stuff moved into a new platform directory, but is it worth the
> > effort?
> >
> > There is very little code in platforms/cell that can not be generic,
> > so I think
> > it's not worth splitting it. The only IBM blade specific files are
> > cbe_cpufreq_pmi.c and parts of setup.c and pervasive.c. Everything
> > else could
> > be shared by about any generic implementation without a hypervisor.
>
> Another option is to have:
>
> platforms/celleb -> platforms/beat
>
> and withing platforms/cell, rename blade specific files to
> something (can't find what, works on CAB too) and add celleb
> "bare metal" files.
>
> A platform directly doesn't have to deal with one platform. For example,
> platforms/44x contains a lot of board support.
>
> Now, one question is how far can we merge celleb support with the common
> blade/CAB code...
Celleb-native needs own machine definition and setup code due to HW
and FW deferences between CellBlade and Celleb. Of course, because
Celleb-native and Celleb-Beat use some codes commonly, we need a place
to put Celleb common codes.
But I don't know your idea is better or not.
Best regards,
Kou Ishizaki
^ permalink raw reply
* (no subject)
From: chengk_thomson @ 2007-12-26 9:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 61 bytes --]
linuxppc-embedded@ozlabs.org
2007-12-26
chengk_thomson
[-- Attachment #2: Type: text/html, Size: 882 bytes --]
^ permalink raw reply
* Re: [PATCH] Add information on enabling sound on the MPC8641 HPCN
From: Olof Johansson @ 2007-12-26 2:18 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47716B3A.9050008@freescale.com>
On Tue, Dec 25, 2007 at 02:42:34PM -0600, Timur Tabi wrote:
> Olof Johansson wrote:
>
>> Are freescale customers really used to going to the linux device tree
>> sources to find out how to modify their boards to achieve certain
>> functionality with their eval boards?! I guess you guys are taking the
>> "device trees are used to describe the hardware" statement to it's
>> fullest extent.
>
> Well, I've always been a rebel.
>
> Honestly, I just thought it would be harmless and a lot easier (for me)
> than trying to convince some documentation dude to write it up and publish
> it.
Heh. Well, it's up to Kumar what to do about this one upstream, it
just seemed like a weird choice to document board reworks in the device
tree comments.
Having it somewhere that sticks to google's database is better than
nothing at all, I suppose. :)
-Olof
^ permalink raw reply
* Re: More patches added to for-2.6.25 and master branches of powerpc.git
From: Benjamin Herrenschmidt @ 2007-12-25 21:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18282.19253.485799.233476@cargo.ozlabs.ibm.com>
> [POWERPC] Disable PCI IO/Mem on a device when resources can't be allocated
Can you revert that one ? I messed up the flags (mixed up IORESOURCE_*
flags with command register bits).
I'll send a fixed up version when I'm back.
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox