* Re: [PATCH v2] qe: add ability to upload QE firmware
From: Arnd Bergmann @ 2007-12-05 23:31 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <11968944871776-git-send-email-timur@freescale.com>
On Wednesday 05 December 2007, Timur Tabi wrote:
> Define the layout of a binary blob that contains a QE firmware and instru=
ctions
> on how to upload it. =A0Add function qe_upload_firmware() to parse the bl=
ob
> and perform the actual upload. =A0Fully define 'struct rsp' in immap_qe.h=
to
> include the actual RISC Special Registers.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
The code looks entirely fine to me, but after looking at it, it occurred to
me that you may want to think about having support for autoloading
the firmware based on a property in the device tree. For the spidernet
driver on the Cell blade, we first also did an implementation that called
request_firmware to load the microcode into the spider chip, but we later
added a property (24kb long in our case) that simply contained the whole
blob in the the device tree.
This made it _much_ easier to support things like NFS root and distribution
installers and avoided all licensing problems because the blob can now
be shipped with the board instead of as part of the GPL software.
Of course, that approach does not help you if the blob is not GPL compatible
and you are relying on the dts file to be linked into the kernel, but it
may be good if your driver supports it anyway so you can pass it down from
the system boot loader to the kernel. In your driver, it's just a few lines
of extra code and you can of course still leave the request_firmware call
in place for other scenarios.
Arnd <><
^ permalink raw reply
* Re: dtc: RFC: Fix some lexical problems with references
From: Josh Boyer @ 2007-12-05 22:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20071205163409.77fba42b@zod.rchland.ibm.com>
On Wed, 5 Dec 2007 16:34:09 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Thu, 22 Nov 2007 17:10:07 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > The recent change to the lexer to only recognize property and node
> > names in the appropriate context removed a number of lexical warts in
> > our language that would have gotten ugly as we add expression support
> > and so forth.
> >
> > But there's one nasty one remaining: references can contain a full
> > path, including the various problematic node name characters (',', '+'
> > and '-', for example). This would cause trouble with expressions, and
> > it also causes trouble with the patch I'm working on to allow
> > expanding references to paths rather than phandles. This patch
> > therefore reworks the lexer to mitigate these problems.
> >
> > - References to labels cause no problems. These are now
> > recognized separately from references to full paths. No syntax change
> > here.
> >
> > - References to full paths, including problematic characters
> > are allowed by "quoting" the path with braces
> > e.g. &{/pci@10000/somedevice@3,8000}. The braces protect any internal
> > problematic characters from being confused with operators or whatever.
> >
> > - For compatibility with existing dts files, in v0 dts files
> > we allow bare references to paths as before &/foo/bar/whatever - but
> > *only* if the path contains no troublesome characters. Specifically
> > only [a-zA-Z0-9_@/] are allowed.
> >
> > This is an incompatible change to the dts-v1 format, but since AFAIK
> > no-one has yet switched to dts-v1 files, I think we can get away with
> > it. Better to make the transition when people to convert to v1, and
> > get rid of the problematic old syntax.
> >
> > Strictly speaking, it's also an incompatible change to the v0 format,
> > since some path references that were allowed before are no longer
> > allowed. I suspect no-one has been using the no-longer-supported
> > forms (certainly none of the kernel dts files will cause trouble). We
> > might need to think about this harder, though.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> So this breaks some of the in-kernel DTS files. Example, bamboo.dts on
> line 19 produces:
>
> bamboo.dts: 19 syntax error
> FATAL ERROR: Couldn't read input tree
>
> I tried quoting the path with {} but that didn't seem to work.
Nevermind, the quoting worked.
josh
^ permalink raw reply
* [PATCH v2] qe: add ability to upload QE firmware
From: Timur Tabi @ 2007-12-05 22:41 UTC (permalink / raw)
To: arnd, galak, linuxppc-dev; +Cc: Timur Tabi
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.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
Updated to add information on a new 'firmware' child node to the QE node,
and added code to parse that node. This allows U-Boot to upload a firmware
and pass the data to the kernel.
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/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 +++++++
6 files changed, 632 insertions(+), 2 deletions(-)
create mode 100644 Documentation/powerpc/qe_firmware.txt
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 94a3c57..3be84aa 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -28,3 +28,6 @@ sound.txt
- info on sound support under Linux/PPC
zImage_layout.txt
- info on the kernel images for Linux/PPC
+qe_firmware.txt
+ - describes the layout of firmware binaries for the Freescale QUICC
+ Engine and the code that parses and uploads the microcode therein.
diff --git a/Documentation/powerpc/qe_firmware.txt b/Documentation/powerpc/qe_firmware.txt
new file mode 100644
index 0000000..8962664
--- /dev/null
+++ b/Documentation/powerpc/qe_firmware.txt
@@ -0,0 +1,295 @@
+ Freescale QUICC Engine Firmware Uploading
+ -----------------------------------------
+
+(c) 2007 Timur Tabi <timur at freescale.com>,
+ Freescale Semiconductor
+
+Table of Contents
+=================
+
+ I - Software License for Firmware
+
+ II - Microcode Availability
+
+ III - Description and Terminology
+
+ IV - Microcode Programming Details
+
+ V - Firmware Structure Layout
+
+ VI - Sample Code for Creating Firmware Files
+
+Revision Information
+====================
+
+November 30, 2007: Rev 1.0 - Initial version
+
+I - Software License for Firmware
+=================================
+
+Each firmware file comes with its own software license. For information on
+the particular license, please see the license text that is distributed with
+the firmware.
+
+II - Microcode Availability
+===========================
+
+Firmware files are distributed through various channels. Some are available on
+http://opensource.freescale.com. For other firmware files, please contact
+your Freescale representative or your operating system vendor.
+
+III - Description and Terminology
+================================
+
+In this document, the term 'microcode' refers to the sequence of 32-bit
+integers that compose the actual QE microcode.
+
+The term 'firmware' refers to a binary blob that contains the microcode as
+well as other data that
+
+ 1) describes the microcode's purpose
+ 2) describes how and where to upload the microcode
+ 3) specifies the values of various registers
+ 4) includes additional data for use by specific device drivers
+
+Firmware files are binary files that contain only a firmware.
+
+IV - Microcode Programming Details
+===================================
+
+The QE architecture allows for only one microcode present in I-RAM for each
+RISC processor. To replace any current microcode, a full QE reset (which
+disables the microcode) must be performed first.
+
+QE microcode is uploaded using the following procedure:
+
+1) The microcode is placed into I-RAM at a specific location, using the
+ IRAM.IADD and IRAM.IDATA registers.
+
+2) The CERCR.CIR bit is set to 0 or 1, depending on whether the firmware
+ needs split I-RAM. Split I-RAM is only meaningful for SOCs that have
+ QEs with multiple RISC processors, such as the 8360. Splitting the I-RAM
+ allows each processor to run a different microcode, effectively creating an
+ asymmetric multiprocessing (AMP) system.
+
+3) The TIBCR trap registers are loaded with the addresses of the trap handlers
+ in the microcode.
+
+4) The RSP.ECCR register is programmed with the value provided.
+
+5) If necessary, device drivers that need the virtual traps and extended mode
+ data will use them.
+
+Virtual Microcode Traps
+
+These virtual traps are conditional branches in the microcode. These are
+"soft" provisional introduced in the ROMcode in order to enable higher
+flexibility and save h/w traps If new features are activated or an issue is
+being fixed in the RAM package utilizing they should be activated. This data
+structure signals the microcode which of these virtual traps is active.
+
+This structure contains 6 words that the application should copy to some
+specific been defined. This table describes the structure.
+
+ ---------------------------------------------------------------
+ | Offset in | | Destination Offset | Size of |
+ | array | Protocol | within PRAM | Operand |
+ --------------------------------------------------------------|
+ | 0 | Ethernet | 0xF8 | 4 bytes |
+ | | interworking | | |
+ ---------------------------------------------------------------
+ | 4 | ATM | 0xF8 | 4 bytes |
+ | | interworking | | |
+ ---------------------------------------------------------------
+ | 8 | PPP | 0xF8 | 4 bytes |
+ | | interworking | | |
+ ---------------------------------------------------------------
+ | 12 | Ethernet RX | 0x22 | 1 byte |
+ | | Distributor Page | | |
+ ---------------------------------------------------------------
+ | 16 | ATM Globtal | 0x28 | 1 byte |
+ | | Params Table | | |
+ ---------------------------------------------------------------
+ | 20 | Insert Frame | 0xF8 | 4 bytes |
+ ---------------------------------------------------------------
+
+
+Extended Modes
+
+This is a double word bit array (64 bits) that defines special functionality
+which has an impact on the softwarew drivers. Each bit has its own impact
+and has special instructions for the s/w associated with it. This structure is
+described in this table:
+
+ -----------------------------------------------------------------------
+ | Bit # | Name | Description |
+ -----------------------------------------------------------------------
+ | 0 | General | Indicates that prior to each host command |
+ | | push command | given by the application, the software must |
+ | | | assert a special host command (push command)|
+ | | | CECDR = 0x00800000. |
+ | | | CECR = 0x01c1000f. |
+ -----------------------------------------------------------------------
+ | 1 | UCC ATM | Indicates that after issuing ATM RX INIT |
+ | | RX INIT | command, the host must issue another special|
+ | | push command | command (push command) and immediately |
+ | | | following that re-issue the ATM RX INIT |
+ | | | command. (This makes the sequence of |
+ | | | initializing the ATM receiver a sequence of |
+ | | | three host commands) |
+ | | | CECDR = 0x00800000. |
+ | | | CECR = 0x01c1000f. |
+ -----------------------------------------------------------------------
+ | 2 | Add/remove | Indicates that following the specific host |
+ | | command | command: "Add/Remove entry in Hash Lookup |
+ | | validation | Table" used in Interworking setup, the user |
+ | | | must issue another command. |
+ | | | CECDR = 0xce000003. |
+ | | | CECR = 0x01c10f58. |
+ -----------------------------------------------------------------------
+ | 3 | General push | Indicates that the s/w has to initialize |
+ | | command | some pointers in the Ethernet thread pages |
+ | | | which are used when Header Compression is |
+ | | | activated. The full details of these |
+ | | | pointers is located in the software drivers.|
+ -----------------------------------------------------------------------
+ | 4 | General push | Indicates that after issuing Ethernet TX |
+ | | command | INIT command, user must issue this command |
+ | | | for each SNUM of Ethernet TX thread. |
+ | | | CECDR = 0x00800003. |
+ | | | CECR = 0x7'b{0}, 8'b{Enet TX thread SNUM}, |
+ | | | 1'b{1}, 12'b{0}, 4'b{1} |
+ -----------------------------------------------------------------------
+ | 5 - 31 | N/A | Reserved, set to zero. |
+ -----------------------------------------------------------------------
+
+V - Firmware Structure Layout
+==============================
+
+QE microcode from Freescale is typically provided as a header file. This
+header file contains macros that define the microcode binary itself as well as
+some other data used in uploading that microcode. The format of these files
+do not lend themselves to simple inclusion into other code. Hence,
+the need for a more portable format. This section defines that format.
+
+Instead of distributing a header file, the microcode and related data are
+embedded into a binary blob. This blob is passed to the qe_upload_firmware()
+function, which parses the blob and performs everything necessary to upload
+the microcode.
+
+All integers are big-endian. See the comments for function
+qe_upload_firmware() for up-to-date implementation information.
+
+This structure supports versioning, where the version of the structure is
+embedded into the structure itself. To ensure forward and backwards
+compatibility, all versions of the structure must use the same 'qe_header'
+structure at the beginning.
+
+'header' (type: struct qe_header):
+ The 'length' field is the size, in bytes, of the entire structure,
+ including all the microcode embedded in it, as well as the CRC (if
+ present).
+
+ The 'magic' field is an array of three bytes that contains the letters
+ 'Q', 'E', and 'F'. This is an identifier that indicates that this
+ structure is a QE Firmware structure.
+
+ The 'version' field is a single byte that indicates the version of this
+ structure. If the layout of the structure should ever need to be
+ changed to add support for additional types of microcode, then the
+ version number should also be changed.
+
+The 'id' field is a null-terminated string(suitable for printing) that
+identifies the firmware.
+
+The 'count' field indicates the number of 'microcode' structures. There
+must be one and only one 'microcode' structure for each RISC processor.
+Therefore, this field also represents the number of RISC processors for this
+SOC.
+
+The 'soc' structure contains the SOC numbers and revisions used to match
+the microcode to the SOC itself. Normally, the microcode loader should
+check the data in this structure with the SOC number and revisions, and
+only upload the microcode if there's a match. However, this check is not
+made on all platforms.
+
+Although it is not recommended, you can specify '0' in the soc.model
+field to skip matching SOCs altogether.
+
+The 'model' field is a 16-bit number that matches the actual SOC. The
+'major' and 'minor' fields are the major and minor revision numbrs,
+respectively, of the SOC.
+
+For example, to match the 8323, revision 1.0:
+ soc.model = 8323
+ soc.major = 1
+ soc.minor = 0
+
+'padding' is neccessary for structure alignment. This field ensures that the
+'extended_modes' field is aligned on a 64-bit boundary.
+
+'extended_modes' is a bitfield that defines special functionality which has an
+impact on the device drivers. Each bit has its own impact and has special
+instructions for the driver associated with it. This field is stored in
+the QE library and available to any driver that calles qe_get_firmware_info().
+
+'vtraps' is an array of 8 words that contain virtual trap values for each
+virtual traps. As with 'extended_modes', this field is stored in the QE
+library and available to any driver that calles qe_get_firmware_info().
+
+'microcode' (type: struct qe_microcode):
+ For each RISC processor there is one 'microcode' structure. The first
+ 'microcode' structure is for the first RISC, and so on.
+
+ The 'id' field is a null-terminated string suitable for printing that
+ identifies this particular microcode.
+
+ 'traps' is an array of 16 words that contain hardware trap values
+ for each of the 16 traps. If trap[i] is 0, then this particular
+ trap is to be ignored (i.e. not written to TIBCR[i]). The entire value
+ is written as-is to the TIBCR[i] register, so be sure to set the EN
+ and T_IBP bits if necessary.
+
+ 'eccr' is the value to program into the ECCR register.
+
+ 'iram_offset' is the offset into IRAM to start writing the
+ microcode.
+
+ 'count' is the number of 32-bit words in the microcode.
+
+ 'code_offset' is the offset, in bytes, from the beginning of this
+ structure where the microcode itself can be found. The first
+ microcode binary should be located immediately after the 'microcode'
+ array.
+
+ 'major', 'minor', and 'revision' are the major, minor, and revision
+ version numbers, respectively, of the microcode. If all values are 0,
+ then these fields are ignored.
+
+ 'reserved' is necessary for structure alignment. Since 'microcode'
+ is an array, the 64-bit 'extended_modes' field needs to be aligned
+ on a 64-bit boundary, and this can only happen if the size of
+ 'microcode' is a multiple of 8 bytes. To ensure that, we add
+ 'reserved'.
+
+After the last microcode is a 32-bit CRC. It can be calculated using
+this algorithm:
+
+u32 crc32(const u8 *p, unsigned int len)
+{
+ unsigned int i;
+ u32 crc = 0;
+
+ while (len--) {
+ crc ^= *p++;
+ for (i = 0; i < 8; i++)
+ crc = (crc >> 1) ^ ((crc & 1) ? 0xedb88320 : 0);
+ }
+ return crc;
+}
+
+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.
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index ea22cad..18f101b 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -265,6 +265,7 @@ config TAU_AVERAGE
config QUICC_ENGINE
bool
select PPC_LIB_RHEAP
+ select CRC32
help
The QUICC Engine (QE) is a new generation of communications
coprocessors on Freescale embedded CPUs (akin to CPM in older chips).
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 1df3b4a..497eb88 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -25,6 +25,7 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/ioport.h>
+#include <linux/crc32.h>
#include <asm/irq.h>
#include <asm/page.h>
#include <asm/pgtable.h>
@@ -362,3 +363,242 @@ void *qe_muram_addr(unsigned long offset)
return (void *)&qe_immr->muram[offset];
}
EXPORT_SYMBOL(qe_muram_addr);
+
+/* The maximum number of RISCs we support */
+#define MAX_QE_RISC 2
+
+/* Firmware information stored here for qe_get_firmware_info() */
+static struct qe_firmware_info qe_firmware_info;
+
+/*
+ * Set to 1 if QE firmware has been uploaded, and therefore
+ * qe_firmware_info contains valid data.
+ */
+static int qe_firmware_uploaded;
+
+/*
+ * Upload a QE microcode
+ *
+ * This function is a worker function for qe_upload_firmware(). It does
+ * the actual uploading of the microcode.
+ */
+static void qe_upload_microcode(const void *base,
+ const struct qe_microcode *ucode)
+{
+ const __be32 *code = base + be32_to_cpu(ucode->code_offset);
+ unsigned int i;
+
+ if (ucode->major || ucode->minor || ucode->revision)
+ printk(KERN_INFO "qe-firmware: "
+ "uploading microcode '%s' version %u.%u.%u\n",
+ ucode->id, ucode->major, ucode->minor, ucode->revision);
+ else
+ printk(KERN_INFO "qe-firmware: "
+ "uploading microcode '%s'\n", ucode->id);
+
+ /* Use auto-increment */
+ out_be32(&qe_immr->iram.iadd, be32_to_cpu(ucode->iram_offset) |
+ QE_IRAM_IADD_AIE | QE_IRAM_IADD_BADDR);
+
+ for (i = 0; i < be32_to_cpu(ucode->count); i++)
+ out_be32(&qe_immr->iram.idata, be32_to_cpu(code[i]));
+}
+
+/*
+ * Upload a microcode to the I-RAM at a specific address.
+ *
+ * See Documentation/powerpc/qe-firmware.txt for information on QE microcode
+ * uploading.
+ *
+ * Currently, only version 1 is supported, so the 'version' field must be
+ * set to 1.
+ *
+ * The SOC model and revision are not validated, they are only displayed for
+ * informational purposes.
+ *
+ * 'calc_size' is the calculated size, in bytes, of the firmware structure and
+ * all of the microcode structures, minus the CRC.
+ *
+ * 'length' is the size that the structure says it is, including the CRC.
+ */
+int qe_upload_firmware(const struct qe_firmware *firmware)
+{
+ unsigned int i;
+ unsigned int j;
+ u32 crc;
+ size_t calc_size = sizeof(struct qe_firmware);
+ size_t length;
+ const struct qe_header *hdr;
+
+ if (!firmware) {
+ printk(KERN_ERR "qe-firmware: invalid pointer\n");
+ return -EINVAL;
+ }
+
+ hdr = &firmware->header;
+ length = be32_to_cpu(hdr->length);
+
+ /* Check the magic */
+ if ((hdr->magic[0] != 'Q') || (hdr->magic[1] != 'E') ||
+ (hdr->magic[2] != 'F')) {
+ printk(KERN_ERR "qe-firmware: not a microcode\n");
+ return -EPERM;
+ }
+
+ /* Check the version */
+ if (hdr->version != 1) {
+ printk(KERN_ERR "qe-firmware: unsupported version\n");
+ return -EPERM;
+ }
+
+ /* Validate some of the fields */
+ if ((firmware->count < 1) || (firmware->count >= MAX_QE_RISC)) {
+ printk(KERN_ERR "qe-firmware: invalid data\n");
+ return -EINVAL;
+ }
+
+ /* Validate the length and check if there's a CRC */
+ calc_size += (firmware->count - 1) * sizeof(struct qe_microcode);
+
+ for (i = 0; i < firmware->count; i++)
+ /*
+ * For situations where the second RISC uses the same microcode
+ * as the first, the 'code_offset' and 'count' fields will be
+ * zero, so it's okay to add those.
+ */
+ calc_size += sizeof(__be32) *
+ be32_to_cpu(firmware->microcode[i].count);
+
+ /* Validate the length */
+ if (length != calc_size + sizeof(__be32)) {
+ printk(KERN_ERR "qe-firmware: invalid length\n");
+ return -EPERM;
+ }
+
+ /* Validate the CRC */
+ crc = be32_to_cpu(*(__be32 *)((void *)firmware + calc_size));
+ if (crc != crc32(0, firmware, calc_size)) {
+ printk(KERN_ERR "qe-firmware: firmware CRC is invalid\n");
+ return -EIO;
+ }
+
+ /*
+ * If the microcode calls for it, split the I-RAM.
+ */
+ if (!firmware->split)
+ setbits16(&qe_immr->cp.cercr, QE_CP_CERCR_CIR);
+
+ if (firmware->soc.model)
+ printk(KERN_INFO
+ "qe-firmware: firmware '%s' for %u V%u.%u\n",
+ firmware->id, be16_to_cpu(firmware->soc.model),
+ firmware->soc.major, firmware->soc.minor);
+ else
+ printk(KERN_INFO "qe-firmware: firmware '%s'\n",
+ firmware->id);
+
+ /*
+ * The QE only supports one microcode per RISC, so clear out all the
+ * saved microcode information and put in the new.
+ */
+ memset(&qe_firmware_info, 0, sizeof(qe_firmware_info));
+ strcpy(qe_firmware_info.id, firmware->id);
+ qe_firmware_info.extended_modes = firmware->extended_modes;
+ memcpy(qe_firmware_info.vtraps, firmware->vtraps,
+ sizeof(firmware->vtraps));
+
+ /* Loop through each microcode. */
+ for (i = 0; i < firmware->count; i++) {
+ const struct qe_microcode *ucode = &firmware->microcode[i];
+
+ /* Upload a microcode if it's present */
+ if (ucode->code_offset)
+ qe_upload_microcode(firmware, ucode);
+
+ /* Program the traps for this processor */
+ for (j = 0; j < 16; j++) {
+ u32 trap = be32_to_cpu(ucode->traps[j]);
+
+ if (trap)
+ out_be32(&qe_immr->rsp[i].tibcr[j], trap);
+ }
+
+ /* Enable traps */
+ out_be32(&qe_immr->rsp[i].eccr, be32_to_cpu(ucode->eccr));
+ }
+
+ qe_firmware_uploaded = 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(qe_upload_firmware);
+
+/*
+ * Get info on the currently-loaded firmware
+ *
+ * This function also checks the device tree to see if the boot loader has
+ * uploaded a firmware already.
+ */
+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 {
+ 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");
+ if (!qe)
+ break;
+
+ /* Find the 'firmware' child node */
+ while ((fw = of_get_next_child(qe, fw)))
+ if (strcmp(fw->name, "firmware") == 0)
+ break;
+
+ /* 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);
+ if (iprop)
+ qe_firmware_info.extended_modes =
+ (u64) iprop[0] << 32 | iprop[1];
+
+ iprop = of_get_property(fw, "virtual_traps", NULL);
+ if (iprop) {
+ unsigned int i = 0;
+
+ for (; i < ARRAY_SIZE(qe_firmware_info.vtraps); i++)
+ qe_firmware_info.vtraps[i] = iprop[i];
+ }
+
+ of_node_put(fw);
+ of_node_put(qe);
+ } while (0);
+
+ return qe_firmware_uploaded ? &qe_firmware_info : NULL;
+}
+EXPORT_SYMBOL(qe_get_firmware_info);
+
diff --git a/include/asm-powerpc/immap_qe.h b/include/asm-powerpc/immap_qe.h
index aba9806..82a4526 100644
--- a/include/asm-powerpc/immap_qe.h
+++ b/include/asm-powerpc/immap_qe.h
@@ -393,9 +393,39 @@ struct dbg {
u8 res2[0x48];
} __attribute__ ((packed));
-/* RISC Special Registers (Trap and Breakpoint) */
+/*
+ * RISC Special Registers (Trap and Breakpoint). These are described in
+ * the QE Developer's Handbook.
+ */
struct rsp {
- u32 reg[0x40]; /* 64 32-bit registers */
+ __be32 tibcr[16]; /* Trap/instruction breakpoint control regs */
+ u8 res0[64];
+ __be32 ibcr0;
+ __be32 ibs0;
+ __be32 ibcnr0;
+ u8 res1[4];
+ __be32 ibcr1;
+ __be32 ibs1;
+ __be32 ibcnr1;
+ __be32 npcr;
+ __be32 dbcr;
+ __be32 dbar;
+ __be32 dbamr;
+ __be32 dbsr;
+ __be32 dbcnr;
+ u8 res2[12];
+ __be32 dbdr_h;
+ __be32 dbdr_l;
+ __be32 dbdmr_h;
+ __be32 dbdmr_l;
+ __be32 bsr;
+ __be32 bor;
+ __be32 bior;
+ u8 res3[4];
+ __be32 iatr[4];
+ __be32 eccr; /* Exception control configuration register */
+ __be32 eicr;
+ u8 res4[0x100-0xf8];
} __attribute__ ((packed));
struct qe_immap {
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index bcf60be..35c7b8d 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -93,6 +93,58 @@ unsigned long qe_muram_alloc_fixed(unsigned long offset, int size);
void qe_muram_dump(void);
void *qe_muram_addr(unsigned long offset);
+/* Structure that defines QE firmware binary files.
+ *
+ * See Documentation/powerpc/qe-firmware.txt for a description of these
+ * fields.
+ */
+struct qe_firmware {
+ struct qe_header {
+ __be32 length; /* Length of the entire structure, in bytes */
+ u8 magic[3]; /* Set to { 'Q', 'E', 'F' } */
+ u8 version; /* Version of this layout. First ver is '1' */
+ } header;
+ u8 id[62]; /* Null-terminated identifier string */
+ u8 split; /* 0 = shared I-RAM, 1 = split I-RAM */
+ u8 count; /* Number of microcode[] structures */
+ struct {
+ __be16 model; /* The SOC model */
+ u8 major; /* The SOC revision major */
+ u8 minor; /* The SOC revision minor */
+ } __attribute__ ((packed)) soc;
+ u8 padding[4]; /* Reserved, for alignment */
+ __be64 extended_modes; /* Extended modes */
+ __be32 vtraps[8]; /* Virtual trap addresses */
+ u8 reserved[4]; /* Reserved, for future expansion */
+ struct qe_microcode {
+ u8 id[32]; /* Null-terminated identifier */
+ __be32 traps[16]; /* Trap addresses, 0 == ignore */
+ __be32 eccr; /* The value for the ECCR register */
+ __be32 iram_offset; /* Offset into I-RAM for the code */
+ __be32 count; /* Number of 32-bit words of the code */
+ __be32 code_offset; /* Offset of the actual microcode */
+ u8 major; /* The microcode version major */
+ u8 minor; /* The microcode version minor */
+ u8 revision; /* The microcode version revision */
+ u8 padding; /* Reserved, for alignment */
+ u8 reserved[4]; /* Reserved, for future expansion */
+ } __attribute__ ((packed)) microcode[1];
+ /* All microcode binaries should be located here */
+ /* CRC32 should be located here, after the microcode binaries */
+} __attribute__ ((packed));
+
+struct qe_firmware_info {
+ char id[64]; /* Firmware name */
+ u32 vtraps[8]; /* Virtual trap addresses */
+ u64 extended_modes; /* Extended modes */
+};
+
+/* Upload a firmware to the QE */
+int qe_upload_firmware(const struct qe_firmware *firmware);
+
+/* Obtain information on the uploaded firmware */
+struct qe_firmware_info *qe_get_firmware_info(void);
+
/* Buffer descriptors */
struct qe_bd {
__be16 status;
@@ -328,6 +380,15 @@ enum comm_dir {
#define QE_SDEBCR_BA_MASK 0x01FFFFFF
+/* Communication Processor */
+#define QE_CP_CERCR_MEE 0x8000 /* Multi-user RAM ECC enable */
+#define QE_CP_CERCR_IEE 0x4000 /* Instruction RAM ECC enable */
+#define QE_CP_CERCR_CIR 0x0800 /* Common instruction RAM */
+
+/* I-RAM */
+#define QE_IRAM_IADD_AIE 0x80000000 /* Auto Increment Enable */
+#define QE_IRAM_IADD_BADDR 0x00080000 /* Base Address */
+
/* UPC */
#define UPGCR_PROTOCOL 0x80000000 /* protocol ul2 or pl2 */
#define UPGCR_TMS 0x40000000 /* Transmit master/slave mode */
--
1.5.2.4
^ permalink raw reply related
* Re: dtc: RFC: Fix some lexical problems with references
From: Josh Boyer @ 2007-12-05 22:34 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122061007.GA22888@localhost.localdomain>
On Thu, 22 Nov 2007 17:10:07 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/pci@10000/somedevice@3,8000}. The braces protect any internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
So this breaks some of the in-kernel DTS files. Example, bamboo.dts on
line 19 produces:
bamboo.dts: 19 syntax error
FATAL ERROR: Couldn't read input tree
I tried quoting the path with {} but that didn't seem to work.
josh
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: David Gibson @ 2007-12-05 22:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20071205222816.GA3725@mag.az.mvista.com>
On Wed, Dec 05, 2007 at 03:28:16PM -0700, Mark A. Greer wrote:
> On Wed, Dec 05, 2007 at 11:32:50AM -0600, Jon Loeliger wrote:
>
> > diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > index abb26dc..b039f21 100644
> > --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > @@ -16,6 +16,17 @@
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > + aliases {
> > + ethernet0 = &enet0;
> > + ethernet1 = &enet1;
> > + ethernet2 = &enet2;
> > + ethernet3 = &enet3;
> > + serial0 = &serial0;
> > + serial1 = &serial1;
> > + pci0 = &pci0;
> > + pci1 = &pci1;
> > + };
> > +
> > cpus {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > @@ -107,7 +118,7 @@
> > };
> > };
> >
> > - ethernet@24000 {
> > + enet0: ethernet@24000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > device_type = "network";
>
> This is probably a dumb question but I'll ask it anyway.
>
> What's the point of 'aliases' when you already have labels?
> E.g., why not just use enet0 instead of making an ethernet0 alias?
The aliase information is available in the output tree, whereas labels
are only internal to dtc (well, except for asm output).
I'm planning to add support later to automatically generate aliases
from specially marked labels.
--
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] Add aliases node to 8641hpcn DTS file.
From: Mark A. Greer @ 2007-12-05 22:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196875970.8544.12.camel@ld0161-tx32>
On Wed, Dec 05, 2007 at 11:32:50AM -0600, Jon Loeliger wrote:
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index abb26dc..b039f21 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -16,6 +16,17 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + aliases {
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + ethernet2 = &enet2;
> + ethernet3 = &enet3;
> + serial0 = &serial0;
> + serial1 = &serial1;
> + pci0 = &pci0;
> + pci1 = &pci1;
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -107,7 +118,7 @@
> };
> };
>
> - ethernet@24000 {
> + enet0: ethernet@24000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
This is probably a dumb question but I'll ask it anyway.
What's the point of 'aliases' when you already have labels?
E.g., why not just use enet0 instead of making an ethernet0 alias?
Mark
^ permalink raw reply
* RE: Uboot and ML410
From: John Hahn @ 2007-12-05 21:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14177109.post@talk.nabble.com>
We are also using 3.81 make (Centos 5 distro) with ELDK 4.1 version
downloaded from www.denx.de and have had no problems using the u-boot.zip
srcs from www.xilinx.com/ml410_p, though we use uboot for our ml403 based
development, we can build u-boot for ml403_config as well as ml410_config.
Cheers
John
_________________
John S Hahn
BCF Semiconductor
> -----Original Message-----
> From: linuxppc-embedded-bounces+jhahn=bcfsemi.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+jhahn=bcfsemi.com@ozlabs.org] On
> Behalf Of khollan
> Sent: Wednesday, December 05, 2007 10:00 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Uboot and ML410
>
>
> Hi
>
> Is there a patch to include support for the ml410 in the Main git tree
> of u-boot? I tried compiling Xilinx's tree but it seems it won't
> compile correctly with my version of make (3.81). Also is there any
> support for the Hard TEMAC in u-boot? I tried looking for both of
> these questions but a lot of the threads were unanswered questions.
> Thanks for your help
>
> kholland
> --
^ permalink raw reply
* Re: drivers/net/iseries_veth.c dubious sysfs usage
From: Greg KH @ 2007-12-05 21:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Kyle A. Lucke, paulus, linux-kernel, David Gibson
In-Reply-To: <1196853031.6759.7.camel@concordia>
On Wed, Dec 05, 2007 at 10:10:31PM +1100, Michael Ellerman wrote:
> On Wed, 2007-12-05 at 01:30 -0800, Greg KH wrote:
> > In doing a massive kobject cleanup of the kernel tree, I ran across the
> > iseries_veth.c driver.
> >
> > It looks like the driver is creating a number of subdirectories under
> > the driver sysfs directory. This is odd and probably wrong. You want
> > these virtual connections to show up in the main sysfs device tree, not
> > under the driver directory.
> >
> > I'll be glad to totally guess and try to move it around in the sysfs
> > tree, but odds are I'll get it all wrong as I can't really test this
> > out :)
> >
> > Any hints on what this driver is trying to do in this sysfs directories?
>
> I wrote the code, I think, but it's been a while - I'll have a look at
> it tomorrow.
Yes, can you send me the sysfs tree output of the driver directory, and
what exactly the different files in there are supposed to be used for?
> Why is it "odd and probably wrong" to create subdirectories under the
> driver in sysfs?
Because a driver does not have "devices" under it in the sysfs tree.
All devices liven in the /sys/devices/ tree so we can properly manage
them that way. A driver will then bind to a device, and the driver core
will set up the linkages in sysfs properly so that everthing looks
uniform.
By creating subdirectories associated with a driver, this breaks the
model that the entire rest of the kernel is using, which is something
that you really don't want to be doing :)
How about describing what you were trying to achieve with these
directories and files?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
From: Scott Wood @ 2007-12-05 18:39 UTC (permalink / raw)
To: Paul Mundt
Cc: Olof Johansson, linux-ide, Jeff Garzik, Arnd Bergmann,
linuxppc-dev
In-Reply-To: <20071205004841.GA25905@linux-sh.org>
On Wed, Dec 05, 2007 at 09:48:41AM +0900, Paul Mundt wrote:
> On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > > tristate "Generic platform device PATA support"
> > > - depends on EMBEDDED || ARCH_RPC
> > > + depends on EMBEDDED || ARCH_PPC
> >
> > It needs to be || PPC, not || ARCH_PPC.
> >
> Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC.
Why is it dependent on anything other than platform bus support and ATA?
-Scott
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Josh Boyer @ 2007-12-05 18:31 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196877907.8544.15.camel@ld0161-tx32>
On Wed, 05 Dec 2007 12:05:07 -0600
Jon Loeliger <jdl@freescale.com> wrote:
> On Wed, 2007-12-05 at 11:38, Grant Likely wrote:
>
> > >
> > > + aliases {
> > > + ethernet0 = &enet0;
> > > + ethernet1 = &enet1;
> > > + ethernet2 = &enet2;
> > > + ethernet3 = &enet3;
> > > + serial0 = &serial0;
> > > + serial1 = &serial1;
> > > + pci0 = &pci0;
> > > + pci1 = &pci1;
> > > + };
> >
> > I had thought aliases were supposed to be full paths to nodes instead
> > of phandles. Was I wrong?
>
> Indeed, that is correct. And they are!
>
> => fdt addr c00000
> => fdt print /aliases
> aliases {
> ethernet0 = "/soc8641@f8000000/ethernet@24000";
> ethernet1 = "/soc8641@f8000000/ethernet@25000";
> ethernet2 = "/soc8641@f8000000/ethernet@26000";
> ethernet3 = "/soc8641@f8000000/ethernet@27000";
> serial0 = "/soc8641@f8000000/serial@4500";
> serial1 = "/soc8641@f8000000/serial@4600";
> pci0 = "/pcie@f8008000";
> pci1 = "/pcie@f8009000";
> };
> => bootm 1000000 - c00000
>
> Grant, you need to keep up, man. Just this morning
> I pushed Gibson's patch to DTC to support this. :-)
So now the in-kernel version of DTC needs to support this.
josh
^ permalink raw reply
* Re: Uboot and ML410
From: Grant Likely @ 2007-12-05 18:16 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <14177109.post@talk.nabble.com>
On 12/5/07, khollan <khollan@daktronics.com> wrote:
>
> Hi
>
> Is there a patch to include support for the ml410 in the Main git tree of
> u-boot? I tried compiling Xilinx's tree but it seems it won't compile
> correctly with my version of make (3.81).
I don't think there is.
> Also is there any support for the
> Hard TEMAC in u-boot? I tried looking for both of these questions but a lot
> of the threads were unanswered questions. Thanks for your help
No, unfortunately nobody has got a hard TEMAC driver into u-boot mainline.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Grant Likely @ 2007-12-05 18:15 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196877907.8544.15.camel@ld0161-tx32>
On 12/5/07, Jon Loeliger <jdl@freescale.com> wrote:
> On Wed, 2007-12-05 at 11:38, Grant Likely wrote:
> > I had thought aliases were supposed to be full paths to nodes instead
> > of phandles. Was I wrong?
>
> Indeed, that is correct. And they are!
>
> Grant, you need to keep up, man. Just this morning
> I pushed Gibson's patch to DTC to support this. :-)
Heh; I'm so behind. Thanks for the clarification.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Vitaly Bordug @ 2007-12-05 18:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <fa686aa40712050938j2d286655o94534a00131872e2@mail.gmail.com>
On Wed, 5 Dec 2007 10:38:38 -0700
Grant Likely wrote:
> >
> > + aliases {
> > + ethernet0 = &enet0;
> > + ethernet1 = &enet1;
> > + ethernet2 = &enet2;
> > + ethernet3 = &enet3;
> > + serial0 = &serial0;
> > + serial1 = &serial1;
> > + pci0 = &pci0;
> > + pci1 = &pci1;
> > + };
>
> I had thought aliases were supposed to be full paths to nodes instead
> of phandles. Was I wrong?
no, but dwg did a patch for dtc to do that dirty work for you, resolving labels. I am also curious if such a change made it in
dtc git (working with full path aliases now). dtc should prolly get tagged and next sub-rev to be clear if it supports aliases or not.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Jon Loeliger @ 2007-12-05 18:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <fa686aa40712050938j2d286655o94534a00131872e2@mail.gmail.com>
On Wed, 2007-12-05 at 11:38, Grant Likely wrote:
> >
> > + aliases {
> > + ethernet0 = &enet0;
> > + ethernet1 = &enet1;
> > + ethernet2 = &enet2;
> > + ethernet3 = &enet3;
> > + serial0 = &serial0;
> > + serial1 = &serial1;
> > + pci0 = &pci0;
> > + pci1 = &pci1;
> > + };
>
> I had thought aliases were supposed to be full paths to nodes instead
> of phandles. Was I wrong?
Indeed, that is correct. And they are!
=> fdt addr c00000
=> fdt print /aliases
aliases {
ethernet0 = "/soc8641@f8000000/ethernet@24000";
ethernet1 = "/soc8641@f8000000/ethernet@25000";
ethernet2 = "/soc8641@f8000000/ethernet@26000";
ethernet3 = "/soc8641@f8000000/ethernet@27000";
serial0 = "/soc8641@f8000000/serial@4500";
serial1 = "/soc8641@f8000000/serial@4600";
pci0 = "/pcie@f8008000";
pci1 = "/pcie@f8009000";
};
=> bootm 1000000 - c00000
Grant, you need to keep up, man. Just this morning
I pushed Gibson's patch to DTC to support this. :-)
jdl
^ permalink raw reply
* Uboot and ML410
From: khollan @ 2007-12-05 18:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi
Is there a patch to include support for the ml410 in the Main git tree of
u-boot? I tried compiling Xilinx's tree but it seems it won't compile
correctly with my version of make (3.81). Also is there any support for the
Hard TEMAC in u-boot? I tried looking for both of these questions but a lot
of the threads were unanswered questions. Thanks for your help
kholland
--
View this message in context: http://www.nabble.com/Uboot-and-ML410-tf4951335.html#a14177109
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: Scott Wood @ 2007-12-05 17:50 UTC (permalink / raw)
To: michael.firth; +Cc: linuxppc-embedded
In-Reply-To: <4756E3E8.8090102@freescale.com>
Scott Wood wrote:
> michael.firth@bt.com wrote:
>> This seems to leave only 1GB of addressing space for all the
>> physically addressable memory (RAM + ioremapped + registers), while
>> reserving 3GB of space for user processes. The 3GB is presumably
>> mostly unusable on a system without a large amount of swap, as the
>> 1GB limit on memory will prevent much more than that being available
>> for user space.
>
> Well, it's also useful for sparse mappings, but I agree that the 3/1
> split is probably suboptimal for most workloads.
Oh, and the 3G user is also useful for accessing highmem, of course.
-Scott
^ permalink raw reply
* RE: [PATCH v2] [POWERPC] Optimize counting distinct entries in the relocation sections
From: Medve Emilian @ 2007-12-05 17:47 UTC (permalink / raw)
To: paulus, rusty, ntl, sfr, behlendorf1, galak, linuxppc-dev,
linuxppc-embedded
In-Reply-To: <1194971044-28840-1-git-send-email-Emilian.Medve@Freescale.com>
> -----Original Message-----
> From: Medve Emilian=20
> Sent: Tuesday, November 13, 2007 10:24 AM
> To: paulus@samba.org; rusty@rustcorp.com.au; ntl@pobox.com;
sfr@canb.auug.org.au; behlendorf1@llnl.gov; galak@kernel.crashing.org;
linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Cc: Medve Emilian
> Subject: [PATCH v2] [POWERPC] Optimize counting distinct entries in
the relocation sections
Hello Paul,
I don't mean to annoy you, but I seem not to be sure if this patch
(http://patchwork.ozlabs.org/linuxppc/patch?id=3D14707) got rejected or
not.
Thanks,
Emil.
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: Scott Wood @ 2007-12-05 17:46 UTC (permalink / raw)
To: michael.firth; +Cc: linuxppc-embedded
In-Reply-To: <36D7B34A3A79F84F82FA0C154F299F2506080F6F@E03MVX1-UKDY.domain1.systemhost.net>
michael.firth@bt.com wrote:
> My main queries are: 1) Why did changing the kernel base address to
> 0x80000000 make the system unstable?
Because there's a bug somewhere. :-)
> 2) Currently IMMRBAR has the same physical and virtual address. Does
> this need to be the case?
No, and it is not done that way in arch/powerpc.
> 3) Why the kernel is designed to run at 0xc0000000?
My guess is because it's a number that Linus pulled out of thin air back
when a gig of RAM was unimaginably large. :-P
> This seems to leave only 1GB of addressing space for all the
> physically addressable memory (RAM + ioremapped + registers), while
> reserving 3GB of space for user processes. The 3GB is presumably
> mostly unusable on a system without a large amount of swap, as the
> 1GB limit on memory will prevent much more than that being available
> for user space.
Well, it's also useful for sparse mappings, but I agree that the 3/1
split is probably suboptimal for most workloads.
-Scott
^ permalink raw reply
* Re: [PATCH] Add aliases node to 8641hpcn DTS file.
From: Grant Likely @ 2007-12-05 17:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196875970.8544.12.camel@ld0161-tx32>
On 12/5/07, Jon Loeliger <jdl@freescale.com> wrote:
>
> The addition of the aliases node is needed for U-Boot
> and, eventually, cuImage, to help locate the proper
> nodes reliably when using the libfdt approach.
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 28 ++++++++++++++++++++--------
> 1 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index abb26dc..b039f21 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -16,6 +16,17 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + aliases {
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + ethernet2 = &enet2;
> + ethernet3 = &enet3;
> + serial0 = &serial0;
> + serial1 = &serial1;
> + pci0 = &pci0;
> + pci1 = &pci1;
> + };
I had thought aliases were supposed to be full paths to nodes instead
of phandles. Was I wrong?
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -107,7 +118,7 @@
> };
> };
>
> - ethernet@24000 {
> + enet0: ethernet@24000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> @@ -127,7 +138,7 @@
> phy-connection-type = "rgmii-id";
> };
>
> - ethernet@25000 {
> + enet1: ethernet@25000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> @@ -147,7 +158,7 @@
> phy-connection-type = "rgmii-id";
> };
>
> - ethernet@26000 {
> + enet2: ethernet@26000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> @@ -167,7 +178,7 @@
> phy-connection-type = "rgmii-id";
> };
>
> - ethernet@27000 {
> + enet3: ethernet@27000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> @@ -186,7 +197,8 @@
> phy-handle = <&phy3>;
> phy-connection-type = "rgmii-id";
> };
> - serial@4500 {
> +
> + serial0: serial@4500 {
> device_type = "serial";
> compatible = "ns16550";
> reg = <4500 100>;
> @@ -195,7 +207,7 @@
> interrupt-parent = <&mpic>;
> };
>
> - serial@4600 {
> + serial1: serial@4600 {
> device_type = "serial";
> compatible = "ns16550";
> reg = <4600 100>;
> @@ -222,7 +234,7 @@
> };
> };
>
> - pcie@f8008000 {
> + pci0: pcie@f8008000 {
> compatible = "fsl,mpc8641-pcie";
> device_type = "pci";
> #interrupt-cells = <1>;
> @@ -430,7 +442,7 @@
>
> };
>
> - pcie@f8009000 {
> + pci1: pcie@f8009000 {
> compatible = "fsl,mpc8641-pcie";
> device_type = "pci";
> #interrupt-cells = <1>;
> --
> 1.5.2.1.126.g6abd0
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] Add aliases node to 8641hpcn DTS file.
From: Jon Loeliger @ 2007-12-05 17:32 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
The addition of the aliases node is needed for U-Boot
and, eventually, cuImage, to help locate the proper
nodes reliably when using the libfdt approach.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 28 ++++++++++++++++++++--------
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index abb26dc..b039f21 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -16,6 +16,17 @@
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ ethernet3 = &enet3;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -107,7 +118,7 @@
};
};
- ethernet@24000 {
+ enet0: ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -127,7 +138,7 @@
phy-connection-type = "rgmii-id";
};
- ethernet@25000 {
+ enet1: ethernet@25000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -147,7 +158,7 @@
phy-connection-type = "rgmii-id";
};
- ethernet@26000 {
+ enet2: ethernet@26000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -167,7 +178,7 @@
phy-connection-type = "rgmii-id";
};
- ethernet@27000 {
+ enet3: ethernet@27000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -186,7 +197,8 @@
phy-handle = <&phy3>;
phy-connection-type = "rgmii-id";
};
- serial@4500 {
+
+ serial0: serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>;
@@ -195,7 +207,7 @@
interrupt-parent = <&mpic>;
};
- serial@4600 {
+ serial1: serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <4600 100>;
@@ -222,7 +234,7 @@
};
};
- pcie@f8008000 {
+ pci0: pcie@f8008000 {
compatible = "fsl,mpc8641-pcie";
device_type = "pci";
#interrupt-cells = <1>;
@@ -430,7 +442,7 @@
};
- pcie@f8009000 {
+ pci1: pcie@f8009000 {
compatible = "fsl,mpc8641-pcie";
device_type = "pci";
#interrupt-cells = <1>;
--
1.5.2.1.126.g6abd0
^ permalink raw reply related
* Re: Regarding MPC8641D
From: Christopher Fester @ 2007-12-05 17:06 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <14166848.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
On Tue, 2007-12-04 at 23:51 -0800, sivaji wrote:
> We have designed a MPC8641D based AMC card. We are using the
> kernel (2.6.23-rc4) and uboot (1.2.0). When we disable the core1 Low Memory
> offset mode the kernel was up and when we enable this core1 Low Memory
> offset mode kernel was not up, It was hang after MPIC initialization.
[snip!]
> After this the kernel was hang, i want to know why
> kernel was hang when we enalbe Low memory Offset mode. Please help me to fix
> this issue.
Have you compiled your kernel for SMP mode? I believe the Low memory
offset mode is only for AMP mode (vxworks can use this, probably other
OSes). I don't know if the kernel has support for any multiprocessing
mode other than SMP.
Hope that helps,
Chris
[-- Attachment #2: Type: text/html, Size: 1438 bytes --]
^ permalink raw reply
* Re: Kernel symbol version history
From: Jean-Christophe Dubois @ 2007-12-05 17:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4756CF15.2090805@dlasys.net>
Hi David,
You could try the various "linux cross reference" web site out there. It is
not necessarily complete (some linux version might be missing) but it can be
usefull to lookup if some symbols/define/typedef were available in a
particular Linux version.
Have a look there.
http://free-electrons.com/community/kernel/lxr
Regards
JC
On Wednesday 05 December 2007 17:17:25 David H. Lynch Jr. wrote:
> This might be slightly OT here, but would anyone know where there
> might be a reference that indicates at precisely what version a given
> symbol either appeared or disappeared within the Linux kernel ?
>
> As an example if a driver is supposed to work for 2.6 and 2.4 and
> uses sysfs, or cdev, or alloc_chr_dev_region or ...
> How can one tell at what point that api or symbol appeared so that
> the proper conditionals appear within the driver.
>
> The last one that bit me was I made a collection of casting changes
> to address 64bit vs. 32bit targets, and found that using the C99 fixed
> size types - uint32_t, ... made life much more pleasant, after putting
> them I nobody else could build because uintptr_t did not appear until
> 2.6.24, and I still have not figured out exactly when uint32_t etc.
> appeared.
>
> I would think there ought to be some resource besides group memory
> to look this up ?
> Is there a way to use git to look back through the history of a
> symbol rather than a file.
^ permalink raw reply
* Re: ucc_uart: add support for Freescale QUICCEngine UART
From: Timur Tabi @ 2007-12-05 17:06 UTC (permalink / raw)
To: Arnd Bergmann, PowerPC dev list
In-Reply-To: <200712050037.11489.arnd@arndb.de>
Arnd Bergmann wrote:
> In that case, I think the right solution would be to have different properties
> in the device tree, depending on whether or not you have a soft-uart and whether
> you need to download the microcode.
> Having only a compile time option is very bad because it prevents you from
> using the driver on a multi-platform kernel.
I can see putting the option to need Soft-UART in the device, because this is an
attribute of the hardware. The silicon is broken and UART functionality is
provided via a secondary mechanism.
I'm not so crazy about an option to tell the driver to upload the firmware. So
look at this:
ucc@2400 {
device_type = "serial";
compatible = "ucc_uart";
model = "UCC";
device-id = <5>; /* The UCC number, 1-7*/
port-number = <0>; /* Which ttyQEx device */
soft-uart; /* We need Soft-UART */
upload-firmware; /* Driver should upload FW */
...
In a sense, this is just a message from U-Boot to the driver. It's not really
an attribute of the hardware.
One thing I could do is create a new node under the QE node that describes any
uploaded microcode. The nature of the QE microcode is that only one can be
present at any time. So I could do this:
qe@e0100000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "qe";
model = "QE";
ranges = <0 e0100000 00100000>;
...
microcode@100 { /* 100 is offset within I-RAM where the microcode was uploaded */
name = "Soft-UART";
extended_modes = <0 0>;
vtraps = <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
}
The extended_modes and vtraps are data that the driver needs any way (for
Soft-UART, it's all zeros, but not for other microcodes). I currently don't
have a way to pass this information from U-Boot to the kernel. The driver could
then look for this node, and if it finds it, it would know *not* to try to
upload the microcode itself. And it would also have the extended_modes and
vtraps information that it might need.
This would solve your problem and mine.
> gcc tries to use only aligned accesses, depending on the the target CPU, so
> you may end up accessing a member as bytes instead of words.
Would it do that even if the member were naturally aligned? I find that hard to
believe, since the compiler always knows the alignment of its members.
OTOH, if this
> structure is always in __iomem and you use in_be32() and the like, there is
> no problem at all.
I do. I generally only pack structures that are defined by external hardware,
and this is one.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Kernel symbol version history
From: Grant Likely @ 2007-12-05 16:49 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <4756CF15.2090805@dlasys.net>
On 12/5/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> This might be slightly OT here, but would anyone know where there
> might be a reference that indicates at precisely what version a given
> symbol either appeared or disappeared within the Linux kernel ?
>
> As an example if a driver is supposed to work for 2.6 and 2.4 and
> uses sysfs, or cdev, or alloc_chr_dev_region or ...
> How can one tell at what point that api or symbol appeared so that
> the proper conditionals appear within the driver.
the 'gitk' tool allows you to search for the addition or removal of a
string. You
>
> The last one that bit me was I made a collection of casting changes
> to address 64bit vs. 32bit targets, and found that using the C99 fixed
> size types - uint32_t, ... made life much more pleasant, after putting
> them I nobody else could build because uintptr_t did not appear until
> 2.6.24, and I still have not figured out exactly when uint32_t etc.
> appeared.
>
> I would think there ought to be some resource besides group memory
> to look this up ?
> Is there a way to use git to look back through the history of a
> symbol rather than a file.
grant@trillian:~/hacking/linux-2.6$ grep "uint32_t" include/* -r | grep typedef
include/linux/types.h:typedef __u32 uint32_t;
grant@trillian:~/hacking/linux-2.6$ git log -p include/linux/types.h | vim -
(Search for the string uint32_t)
Looks like it was there before Linus started using git.
>
>
>
> --
> Dave Lynch DLA Systems
> Software Development: Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
> fax: 1.253.369.9244 Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too numerous to list.
>
> "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
> Albert Einstein
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Kernel symbol version history
From: David H. Lynch Jr. @ 2007-12-05 16:17 UTC (permalink / raw)
To: linuxppc-embedded
This might be slightly OT here, but would anyone know where there
might be a reference that indicates at precisely what version a given
symbol either appeared or disappeared within the Linux kernel ?
As an example if a driver is supposed to work for 2.6 and 2.4 and
uses sysfs, or cdev, or alloc_chr_dev_region or ...
How can one tell at what point that api or symbol appeared so that
the proper conditionals appear within the driver.
The last one that bit me was I made a collection of casting changes
to address 64bit vs. 32bit targets, and found that using the C99 fixed
size types - uint32_t, ... made life much more pleasant, after putting
them I nobody else could build because uintptr_t did not appear until
2.6.24, and I still have not figured out exactly when uint32_t etc.
appeared.
I would think there ought to be some resource besides group memory
to look this up ?
Is there a way to use git to look back through the history of a
symbol rather than a file.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ 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