* Semaphores in eldk4.1
From: Stuart Hodgson @ 2007-11-30 16:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have been suing the eldk4.1 tool chain for a few months now and have
not not encountered any problems with building until now. I build for
two slightly different archs, ppc_85xx and ppx_82xx.
The problem I have come up against is related to some of the semaphore
functions in semaphore.h, namely sem_wait, sem_post. This was originally
noticed in a third party driver I am porting from one board to another
but a small test program has shown the same results.
Calls to these functions on the ppc_82xx platform return -1 with an
error code of 38, in this case meaning ENOSYS (not implemented). On the
ppc_85xx the same program executes fine, thus I conclude that it is
specific to the libc-2.3.5 for ppc_82xx. Has anyone else come across
this problem, I did find one thread but there was no conclusion listed.
I also can not find anything stating that these functions are not
implemented for the 82xx arch compared with others for the eldk4.1
Thanks
Stuart
^ permalink raw reply
* Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-30 18:12 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <20071130122055.729dd3f8@i1501.lan.towertech.it>
Hi, Alessandro!
Alessandro Zummo schrieb:
> On Fri, 30 Nov 2007 12:04:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>> Modular doesn't make sense to me, because the filesystem check starts
>> to complain when last mount time was way to far in the past or in
>> the future. But I will try...
>
> It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc.
> it should work anyway, but who knows...
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod
Module Size Used by
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod
Module Size Used by
rtc_ds1307 6944 0
i2c_core 29936 1 rtc_ds1307
rtc_core 24248 1 rtc_ds1307
rtc_lib 3456 2 rtc_ds1307,rtc_core
i2c_core doesn't pull in i2c_mpc (the MPC107/85xx i2c driver)!
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe i2c-mpc
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod
Module Size Used by
i2c_mpc 8128 0
rtc_ds1307 6944 0
i2c_core 29936 2 i2c_mpc,rtc_ds1307
rtc_core 24248 1 rtc_ds1307
rtc_lib 3456 2 rtc_ds1307,rtc_core
it's still unused.
Doing it the other way around:
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod
Module Size Used by
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe i2c-mpc
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod
Module Size Used by
i2c_mpc 8128 0
i2c_core 29936 1 i2c_mpc
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod
Module Size Used by
rtc_ds1307 6944 0
rtc_core 24248 1 rtc_ds1307
rtc_lib 3456 2 rtc_ds1307,rtc_core
i2c_mpc 8128 0
i2c_core 29936 2 rtc_ds1307,i2c_mpc
root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/i2c/busses$ cd /dev
root@fox_1:/dev$ ls -la r*
crw-rw-rw- 1 root root 1, 8 Jan 1 1970 random
I guess I'll have to dig in the code now since this is a
100% road block for my project. :-(
Does it make sense to pickup some I2C people here?
Same story, next week... Have a nice weekend.
If you come up with some idea / patches, still let me know,
I'll be able to login remotely.
Thank you,
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: Semaphores in eldk4.1
From: Ben Warren @ 2007-11-30 18:10 UTC (permalink / raw)
To: Stuart Hodgson; +Cc: linuxppc-embedded
In-Reply-To: <47503B5A.6090604@quadrics.com>
HI Stuart,
Stuart Hodgson wrote:
> Hi,
>
> I have been suing the eldk4.1 tool chain for a few months now and have
> not not encountered any problems with building until now. I build for
> two slightly different archs, ppc_85xx and ppx_82xx.
>
> The problem I have come up against is related to some of the semaphore
> functions in semaphore.h, namely sem_wait, sem_post. This was originally
> noticed in a third party driver I am porting from one board to another
> but a small test program has shown the same results.
>
> Calls to these functions on the ppc_82xx platform return -1 with an
> error code of 38, in this case meaning ENOSYS (not implemented). On the
> ppc_85xx the same program executes fine, thus I conclude that it is
> specific to the libc-2.3.5 for ppc_82xx. Has anyone else come across
> this problem, I did find one thread but there was no conclusion listed.
>
>
These work fine for me with ppc_6xx architecture and ELDK 4.1, although
they didn't with ELDK 4.0. In that case, I was getting ENOSYS on
sem_open() and sem_init(). Do these functions return 0 for you? I assume
you're using a kernel that supports POSIX semaphores (I think that
started at 2.6.12) and that you're using the glibc version of ELDK and
not ulibc.
> I also can not find anything stating that these functions are not
> implemented for the 82xx arch compared with others for the eldk4.1
>
> Thanks
>
> Stuart
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
regards,
Ben
^ permalink raw reply
* PCI configuration registers(BARs)
From: mike zheng @ 2007-11-30 18:33 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
I set PCI configuration registers(BARs) of a PCI adapter as following in Uboot:
base address 0 = 0xf4000001
base address 1 = 0xf4000041
base address 2 = 0xf4000081
base address 3 = 0xa0000000
base address 4 = 0xa0020000
base address 5 = 0x00000000
However when I start Linux2.4 kernel, the same adapter's PCI
configuration registers have following values:
BaseAddr[0]=0x3ffffc0
BaseAddr[1]=0x3ffffb0
BaseAddr[2]=0x3ffff00
After ioremap BaseAddr[3]=0xa1002000
BaseAddr[3]=0xa1002000
After ioremap BaseAddr[4]=0xa1004000
BaseAddr[4]=0xa1004000
BaseAddr[5]=0x0
This is a working system on MPC8548, everything including PCI adapter
works fine. My question is why the values are different in Uboot and
Linux? The value under Uboot is reasonable, since the PCI outbound
window is set up as 0xA0000000 and 0XF4000000. In addition, the value
seems falling into the outbound window after the ioremap() is called
on BAR3 and BAR4. The ioremap() will failed if I try to convert BAR0,
BAR1, BAR2.
Thanks in advance,
Mike
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: T Ziomek @ 2007-11-30 19:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071130061200.4BAF9DDFAE@ozlabs.org>
On Fri, 30 Nov 2007, Benjamin Herrenschmidt wrote:
>
> This patch makes the early debug option force the console loglevel
> to the max. The early debug option is meant to catch messages very
> early in the kernel boot process, in many cases, before the kernel
> has a chance to parse the "debug" command line argument. Thus it
> makes sense when CONFIG_PPC_EARLY_DEBUG is set, to force the console
> log level to the max at boot time.
. . .
> +#ifdef CONFIG_PPC_EARLY_DEBUG
> + console_loglevel = 10;
> +#endif
> }
The change makes sense, but wouldn't it also make sense to note it in
arch/powerpc/Kconfig.debug? Otherwise it's really hard to figure out why,
after bringing up a new board, removing "debug" from the kernel cmd line
does, well, nothing.
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Mike Strosaker @ 2007-11-30 19:26 UTC (permalink / raw)
To: will_schmidt; +Cc: Stephen Rothwell, paulus, linuxppc-dev
In-Reply-To: <1196439093.11297.52.camel@farscape.rchland.ibm.com>
Will Schmidt wrote:
>>From my reading of the papr, I've got the impression that there are two
> possibilities.
>
> First, the os-term never returns, and it's up to the service processor
> to do whatever it's going to do. (call home, dump, something else).
> Nothing we can do there.
>
> Second, os-term returns, and it's up to the OS to call into power-off or
> system-reboot.
> I think this is more likely. I havn't followed the path back from
> machine_restart to see exactly how we got there, but probably means a
> bit more logic to decide whether to call into rtas_restart() or
> pSeries_power_off() after the call to machine_shutdown.
My understanding was that os-term is supposed to indicate an "abnormal"
termination, which is why it was initially only associated with a panic.
The os-term behavior is kind of complex; there is both a standard behavior, and
an "extended" behavior. You can determine if the extended behavior will be used
by looking for the ibm,extended-os-term property. I think POWER5 largely uses
the older behavior, and POWER6 uses the extended behavior.
I've never seen os-term return using the old behavior. Whether the partition
reboots after calling os-term depends on the setting of the
partition_auto_restart RTAS parameter. If partition_auto_restart is 1 when
os-term is called, the hypervisor will restart the partition and reset
partition_auto_restart to 0. The OS is supposed to set partition_auto_restart
back to 1 after it boots; that way, if the OS is failing to boot, the hypervisor
won't continually try to restart the partition without any hope of success.
That's why Linas sent a patch with a pSeries_auto_restart routine.
If the extended os-term behavior is used, the os-term call is supposed to return
unless the ibm,configure-kernel-dump call was previously used (to prepare for a
PHYP assisted dump). Would that explain why Linas and Will are seeing different
behaviors? I may have missed it, but I don't see a check for
ibm,extended-os-term anywhere.
- Mike
^ permalink raw reply
* qe: add ability to upload QE firmware
From: Timur Tabi @ 2007-11-30 19:50 UTC (permalink / raw)
To: linuxppc-dev, galak; +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>
---
This patch is for Kumar's for-2.6.25 branch. This code is necessary for
my QE UART driver, which I will be posting soon.
Documentation/powerpc/00-INDEX | 3 +
Documentation/powerpc/qe_firmware.txt | 295 +++++++++++++++++++++++++++++++++
arch/powerpc/platforms/Kconfig | 1 +
arch/powerpc/sysdev/qe_lib/qe.c | 169 +++++++++++++++++++
include/asm-powerpc/immap_qe.h | 34 ++++-
include/asm-powerpc/qe.h | 61 +++++++
6 files changed, 561 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..865277b 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,171 @@ 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;
+
+/*
+ * 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));
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(qe_upload_firmware);
+
+struct qe_firmware_info *qe_get_firmware_info(void)
+{
+ return &qe_firmware_info;
+}
+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: [PATCH 18/24] powerpc: Base support for 440GX Taishan eval board
From: Josh Boyer @ 2007-11-30 20:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071130061203.B6239DDED7@ozlabs.org>
On Fri, 30 Nov 2007 17:11:01 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> From: Hugh Blemings <hugh@blemings.org>
>
>
> Signed-off-by: Hugh Blemings <hugh@blemings.org>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> This needs a bit of cleanup still, probably not to be merged as-is
> just yet (like using mtdcri/mfdcri for CPR access).
>
> arch/powerpc/Kconfig.debug | 6
> arch/powerpc/boot/44x.h | 1
> arch/powerpc/boot/Makefile | 7
Small conflict in the Makefile keeps this from applying cleanly.
josh
^ permalink raw reply
* Re: [PATCH 24/24] powerpc: Base support for 440SPe "Katmai" eval board
From: Josh Boyer @ 2007-11-30 20:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071130061209.497F3DE03A@ozlabs.org>
On Fri, 30 Nov 2007 17:11:06 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This adds base support for the Katmai board, including PCI-X and
> PCI-Express (but no RTC, nvram, etc... yet).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> As for Taishan, the bootwrapper code can be simplified. In fact,
> we probably don't need to probe clocks & memsize off the chip and
> just trust what uboot tells us.
>
> arch/powerpc/boot/44x.h | 1
> arch/powerpc/boot/Makefile | 7
Same small conflict as taishan.
josh
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Josh Boyer @ 2007-11-30 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196403038.569525.367459803520.qpush@grosgo>
On Fri, 30 Nov 2007 17:10:38 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Here's a set of patches that bring PCI, PCI-X and PCI-Express
> support to 4xx on arch/powerpc. It also changes/fixed various
> bits and pieces, such as a bit of rework of arch/powerpc/boot
> 4xx code, adding a couple of new platforms along the way.
>
> There are some issues with the SCSI stack vs. non-coherent
> DMA that I'm working on fixing separately, and there's a
> problem I noticed with the e1000 driver vs. 64 bits resources
> on 32 bits architectures for which I also have a patch that
> I posted separately. Appart from that, I got it working fine
> with a USB2 card in an ebony and 2 USB storage devices.
>
> Some of these patches are _NOT_ yet candidate for merging
> (mostly the board support ones), but you can review them and
> Josh can put them in an experimental tree.
I've added these to the 2.6.25-candidates branch in my tree. Fixed up
the few conflicts manually. I'll expect refreshes before merging
anyway, but I'd like to get these out there for people to play with.
josh
^ permalink raw reply
* Re: [RFC][PATCH] [POWERPC] Allow caching of kmap_atomic page
From: Benjamin Herrenschmidt @ 2007-11-30 20:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0711300311490.1799@blarg.am.freescale.net>
On Fri, 2007-11-30 at 03:14 -0600, Kumar Gala wrote:
> Skip updating the kmap_pte and flushing the TLB if the pte we
> are about to write is the same as the one we wrote last time we
> called kmap_atomic for this km_type.
>
> Also expose the flags to allow a caller to specify their own
> flags for things like non-cacheable IO memory.
>
> ---
>
> This is the starts of some work Ben and I were discussion to allow us to
> use kmap_atomic to access a page size region of PCI CFG space when its
> provided as direct MMIO.
>
> We also intend to provide a means to preload the TLB for SW managed TLB
> machines.
We probably need to move that outside of highmem though...
Cheers,
Ben.
> - k
>
> include/asm-powerpc/highmem.h | 16 +++++++++++++---
> 1 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/asm-powerpc/highmem.h b/include/asm-powerpc/highmem.h
> index f7b21ee..a50bb00 100644
> --- a/include/asm-powerpc/highmem.h
> +++ b/include/asm-powerpc/highmem.h
> @@ -73,10 +73,12 @@ static inline void kunmap(struct page *page)
> * be used in IRQ contexts, so in some (very limited) cases we need
> * it.
> */
> -static inline void *kmap_atomic(struct page *page, enum km_type type)
> +static inline void *__kmap_atomic(struct page *page,
> + enum km_type type, unsigned long flags)
> {
> unsigned int idx;
> unsigned long vaddr;
> + pte_t pte;
>
> /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
> pagefault_disable();
> @@ -88,12 +90,20 @@ static inline void *kmap_atomic(struct page *page, enum km_type type)
> #ifdef HIGHMEM_DEBUG
> BUG_ON(!pte_none(*(kmap_pte+idx)));
> #endif
> - set_pte_at(&init_mm, vaddr, kmap_pte+idx, mk_pte(page, kmap_prot));
> - flush_tlb_page(NULL, vaddr);
> + pte = mk_pte(page, flags);
> + if (!pte_same(kmap_pte[idx], pte)) {
> + set_pte_at(&init_mm, vaddr, kmap_pte+idx, pte);
> + flush_tlb_page(NULL, vaddr);
> + }
>
> return (void*) vaddr;
> }
>
> +static inline void *kmap_atomic(struct page *page, enum km_type type)
> +{
> + return __kmap_atomic(page, type, kmap_prot);
> +}
> +
> static inline void kunmap_atomic(void *kvaddr, enum km_type type)
> {
> #ifdef HIGHMEM_DEBUG
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: Benjamin Herrenschmidt @ 2007-11-30 20:56 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711301306520.5450@gauley.ddna.labs.mot.com>
On Fri, 2007-11-30 at 13:10 -0600, T Ziomek wrote:
> > This patch makes the early debug option force the console loglevel
> > to the max. The early debug option is meant to catch messages very
> > early in the kernel boot process, in many cases, before the kernel
> > has a chance to parse the "debug" command line argument. Thus it
> > makes sense when CONFIG_PPC_EARLY_DEBUG is set, to force the console
> > log level to the max at boot time.
> . . .
> > +#ifdef CONFIG_PPC_EARLY_DEBUG
> > + console_loglevel = 10;
> > +#endif
> > }
>
> The change makes sense, but wouldn't it also make sense to note it in
> arch/powerpc/Kconfig.debug? Otherwise it's really hard to figure out
> why,
> after bringing up a new board, removing "debug" from the kernel cmd
> line
> does, well, nothing.
Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
once you are done debugging :-)
Ben.
^ permalink raw reply
* Re: [PATCH 18/24] powerpc: Base support for 440GX Taishan eval board
From: Benjamin Herrenschmidt @ 2007-11-30 20:57 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071130140825.67721825@zod.rchland.ibm.com>
On Fri, 2007-11-30 at 14:08 -0600, Josh Boyer wrote:
> On Fri, 30 Nov 2007 17:11:01 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > From: Hugh Blemings <hugh@blemings.org>
> >
> >
> > Signed-off-by: Hugh Blemings <hugh@blemings.org>
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > This needs a bit of cleanup still, probably not to be merged as-is
> > just yet (like using mtdcri/mfdcri for CPR access).
> >
> > arch/powerpc/Kconfig.debug | 6
> > arch/powerpc/boot/44x.h | 1
> > arch/powerpc/boot/Makefile | 7
>
> Small conflict in the Makefile keeps this from applying cleanly.
Can you tell me more ? doesn't conflict here.
Ben.
^ permalink raw reply
* Re: [PATCH 2/11] ibm_newemac: Add ET1011c PHY support
From: Benjamin Herrenschmidt @ 2007-11-30 20:59 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071130142904.GC3117@lixom.net>
On Fri, 2007-11-30 at 08:29 -0600, Olof Johansson wrote:
> Hi,
>
> On Fri, Nov 30, 2007 at 04:40:24PM +1100, Benjamin Herrenschmidt wrote:
>
> > This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
> > board.
>
> The whole patch has whitespace messed up (tabs vs spaces).
Thanks for noticing it on the ...3rd time those are sent to the list...
Ben.
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Benjamin Herrenschmidt @ 2007-11-30 20:54 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071130141540.GA3117@lixom.net>
On Fri, 2007-11-30 at 08:15 -0600, Olof Johansson wrote:
> On Fri, Nov 30, 2007 at 05:10:38PM +1100, Benjamin Herrenschmidt wrote:
>
> > There will be further cleanups and fixes before 2.6.25 opens
>
> May I suggest running them through checkpatch.pl? It finds stuff in over
> half of the ones I tried it on :)
and I don't give a shit about checkpatch.pl
Ben.
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Olof Johansson @ 2007-11-30 21:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196456043.13230.96.camel@pasglop>
On Sat, Dec 01, 2007 at 07:54:03AM +1100, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 08:15 -0600, Olof Johansson wrote:
> > On Fri, Nov 30, 2007 at 05:10:38PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > There will be further cleanups and fixes before 2.6.25 opens
> >
> > May I suggest running them through checkpatch.pl? It finds stuff in over
> > half of the ones I tried it on :)
>
> and I don't give a shit about checkpatch.pl
That's up to you, but I've found that it saves a handful of nitpicky
comments about whitespace, etc, after posting. It doesn't mean every
single warning from it has to be followed.
Since you said you'd post this series again I figured it could be useful
to fix the whitespace it finds, instead of having people find it by hand
when reading the patches.
That's all.
-Olof
^ permalink raw reply
* Re: [PATCH 2/11] ibm_newemac: Add ET1011c PHY support
From: Olof Johansson @ 2007-11-30 21:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <1196456356.13230.104.camel@pasglop>
On Sat, Dec 01, 2007 at 07:59:16AM +1100, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 08:29 -0600, Olof Johansson wrote:
> > Hi,
> >
> > On Fri, Nov 30, 2007 at 04:40:24PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
> > > board.
> >
> > The whole patch has whitespace messed up (tabs vs spaces).
>
> Thanks for noticing it on the ...3rd time those are sent to the list...
Yeah, sorry about that. Should have caught it sooner.
Anyway, can be fixed up with incremental patch, doesn't need to hold up
the whole series.
-Olof
^ permalink raw reply
* Re: [PATCH 18/24] powerpc: Base support for 440GX Taishan eval board
From: Josh Boyer @ 2007-11-30 21:32 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196456229.13230.102.camel@pasglop>
On Sat, 01 Dec 2007 07:57:09 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Fri, 2007-11-30 at 14:08 -0600, Josh Boyer wrote:
> > On Fri, 30 Nov 2007 17:11:01 +1100
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > From: Hugh Blemings <hugh@blemings.org>
> > >
> > >
> > > Signed-off-by: Hugh Blemings <hugh@blemings.org>
> > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > ---
> > >
> > > This needs a bit of cleanup still, probably not to be merged as-is
> > > just yet (like using mtdcri/mfdcri for CPR access).
> > >
> > > arch/powerpc/Kconfig.debug | 6
> > > arch/powerpc/boot/44x.h | 1
> > > arch/powerpc/boot/Makefile | 7
> >
> > Small conflict in the Makefile keeps this from applying cleanly.
>
> Can you tell me more ? doesn't conflict here.
You have cuImage.bamboo with a comment in front of it.
josh
^ permalink raw reply
* Re: [PATCH 18/24] powerpc: Base support for 440GX Taishan eval board
From: Benjamin Herrenschmidt @ 2007-11-30 21:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071130153242.6ea7e5ae@zod.rchland.ibm.com>
On Fri, 2007-11-30 at 15:32 -0600, Josh Boyer wrote:
> On Sat, 01 Dec 2007 07:57:09 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > On Fri, 2007-11-30 at 14:08 -0600, Josh Boyer wrote:
> > > On Fri, 30 Nov 2007 17:11:01 +1100
> > > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > >
> > > > From: Hugh Blemings <hugh@blemings.org>
> > > >
> > > >
> > > > Signed-off-by: Hugh Blemings <hugh@blemings.org>
> > > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > > ---
> > > >
> > > > This needs a bit of cleanup still, probably not to be merged as-is
> > > > just yet (like using mtdcri/mfdcri for CPR access).
> > > >
> > > > arch/powerpc/Kconfig.debug | 6
> > > > arch/powerpc/boot/44x.h | 1
> > > > arch/powerpc/boot/Makefile | 7
> > >
> > > Small conflict in the Makefile keeps this from applying cleanly.
> >
> > Can you tell me more ? doesn't conflict here.
>
> You have cuImage.bamboo with a comment in front of it.
Oh... yeah, ok, my bad, I see where that comes from. I'll fix it up.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/11] ibm_newemac: Add ET1011c PHY support
From: Kumar Gala @ 2007-11-30 21:56 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, netdev, jgarzik, linuxppc-dev
In-Reply-To: <1196456356.13230.104.camel@pasglop>
On Nov 30, 2007, at 2:59 PM, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 08:29 -0600, Olof Johansson wrote:
>> Hi,
>>
>> On Fri, Nov 30, 2007 at 04:40:24PM +1100, Benjamin Herrenschmidt
>> wrote:
>>
>>> This adds support for the Agere ET1011c PHY as found on the AMCC
>>> Taishan
>>> board.
>>
>> The whole patch has whitespace messed up (tabs vs spaces).
>
> Thanks for noticing it on the ...3rd time those are sent to the
> list...
Clearly if you used checkpatch.pl you'd have noticed this by now. :)
- k
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: T Ziomek @ 2007-11-30 22:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196456185.13230.100.camel@pasglop>
On Sat, 1 Dec 2007, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 13:10 -0600, T Ziomek wrote:
>>> This patch makes the early debug option force the console loglevel
>>> to the max. The early debug option is meant to catch messages very
>>> early in the kernel boot process, in many cases, before the kernel
>>> has a chance to parse the "debug" command line argument. Thus it
>>> makes sense when CONFIG_PPC_EARLY_DEBUG is set, to force the console
>>> log level to the max at boot time.
>> . . .
>>> +#ifdef CONFIG_PPC_EARLY_DEBUG
>>> + console_loglevel = 10;
>>> +#endif
>>> }
>>
>> The change makes sense, but wouldn't it also make sense to note it in
>> arch/powerpc/Kconfig.debug? Otherwise it's really hard to figure out
>> why,
>> after bringing up a new board, removing "debug" from the kernel cmd
>> line
>> does, well, nothing.
>
> Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
> once you are done debugging :-)
I'm probably not the only person that would turn it on when needed, think
"well, no harm in leaving it on for the rest of my development, and it
might be handy; just turn it off when we're done".
It's these kind of non-obvious but undocumented things that make a lot of
OSS code a pain to work with for non-experts [1]. What's the harm in
giving folks a heads-up?
[1] : And I don't just mean newbies...I mean anybody who doesn't live in
the code on a daily basis year-round.
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: Scott Wood @ 2007-11-30 22:14 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711301605540.5450@gauley.ddna.labs.mot.com>
T Ziomek wrote:
> On Sat, 1 Dec 2007, Benjamin Herrenschmidt wrote:
>> Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
>> once you are done debugging :-)
>
> I'm probably not the only person that would turn it on when needed, think
> "well, no harm in leaving it on for the rest of my development, and it
> might be handy; just turn it off when we're done".
>
> It's these kind of non-obvious but undocumented things that make a lot of
> OSS code a pain to work with for non-experts [1]. What's the harm in
> giving folks a heads-up?
Well, the config text does say "(dangerous)"...
-Scott
^ permalink raw reply
* Re: ppcboot and powerpc branch question
From: Wolfgang Denk @ 2007-11-30 22:15 UTC (permalink / raw)
To: fabien; +Cc: linuxppc-embedded
In-Reply-To: <f8f856500711300533t3bad1c1dxb4ff137534acbccb@mail.gmail.com>
In message <f8f856500711300533t3bad1c1dxb4ff137534acbccb@mail.gmail.com> you wrote:
>
> instead of bd_t struct. I'm a bit disappointed because i also see that
> older u-boot (in my case
> ppcboot 1.1.5) aren't capable to pass dts to kernel.
PPCBoot was a in a distant past before U-Boot. Actually, PPCBoot
1.1.5 is more than 5 and a half years old. You cannot really expect a
Neanderthal man to drive a space shuttle.
> Is there a way to keep my old bootloader to boot a powerpc branch kernel ?
No. Please use a current U-Boot (i. e. at least U-Boot 1.3.0).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
As in certain cults it is possible to kill a process if you know its
true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: Benjamin Herrenschmidt @ 2007-11-30 22:15 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711301605540.5450@gauley.ddna.labs.mot.com>
On Fri, 2007-11-30 at 16:11 -0600, T Ziomek wrote:
> > Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
> > once you are done debugging :-)
>
> I'm probably not the only person that would turn it on when needed,
> think
> "well, no harm in leaving it on for the rest of my development, and it
> might be handy; just turn it off when we're done".
>
> It's these kind of non-obvious but undocumented things that make a lot
> of
> OSS code a pain to work with for non-experts [1]. What's the harm in
> giving folks a heads-up?
There is no harm, I didn't say I wasn't going to document it, you do
have a point there, I was just mentioning by the way, that leaving
EARLY_DEBUG is generally not a good idea in production.
One of the things that arhc/powerpc provides is the ability for you to
have a single kernel image boot boards with different 4xx processors for
example, or different fsl booke processors. You lose that if you leave
early debug on as it usually contain hard coded addresses for a given
board.
This is typically useful if you have several revisions / versions of
your product, which could use different processor revisions or even
model, and want a single kernel image to support them.
Ben.
^ permalink raw reply
* current ARCH=powerpc for v2pro.
From: Stephen Neuendorffer @ 2007-11-30 22:21 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded
Grant,
I'm trying to bring up your arch/powerpc work, using a compiled in
device tree. I added this:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..48f745d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -53,7 +53,7 @@ src-wlib :=3D string.S crt0.S stdio.c main.c
flatdevtree.c flatd
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c
uartlite.c \
fsl-soc.c mpc8xx.c pq2.c
src-plat :=3D of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+ virtex.c cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c=20
fixed-head.S ep88xc.c cuboot-hpc2.c
@@ -159,6 +159,7 @@ image-$(CONFIG_EBONY) +=3D
treeImage.ebo
image-$(CONFIG_BAMBOO) +=3D treeImage.bamboo
cuImage.bamboo
image-$(CONFIG_SEQUOIA) +=3D cuImage.sequoia
image-$(CONFIG_WALNUT) +=3D treeImage.walnut
+image-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) +=3D
zImage.virtex
endif
=20
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/virtex.c b/arch/powerpc/boot/virtex.c
new file mode 100644
index 0000000..32cebc1
--- /dev/null
+++ b/arch/powerpc/boot/virtex.c
@@ -0,0 +1,20 @@
+
+
+#include "ops.h"
+#include "stdio.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "io.h"
+
+BSS_STACK(4096);
+
+void platform_init(void)
+{
+ unsigned long end_of_ram =3D 0xfffffff;
+ unsigned long avail_ram =3D end_of_ram - (unsigned long) _end;
+
+ simple_alloc_init(_end, avail_ram, 32, 32);
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ printf("booting virtex\n");
+}
and got as far as:
---
booting virtex
zImage starting: loaded at 0x00400000 (sp: 0x00551f14)
Allocating 0x2d7324 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040b000:0x00550d74)...done 0x2b35ec bytes
Linux/PowerPC load: root=3D/dev/xsysace/disc0/part2
Finalizing device tree... flat tree at 0x409870
---
Tracing through the code, it appears that there is a machine check in
memset_io in early_init():
unsigned long __init early_init(unsigned long dt_ptr)
{
unsigned long offset =3D reloc_offset();
struct cpu_spec *spec;
/* First zero the BSS -- use memset_io, some platforms don't
have
* caches on yet */
memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
__bss_stop - __bss_start);
/*
* Identify the CPU type and fix up code sections
* that depend on which cpu we have.
*/
spec =3D identify_cpu(offset, mfspr(SPRN_PVR));
do_feature_fixups(spec->cpu_features,
PTRRELOC(&__start___ftr_fixup),
PTRRELOC(&__stop___ftr_fixup));
return KERNELBASE + offset;
}
Which seems bizarre, because that code is very simple. I'm guessing
that something in the memory configuration is wierd (or maybe
zImage.virtex is not the right way to do this?) but I'm a little lost
where to look from here. I also tried it with both paulus_master and
your virtex-for-2.6.24 branch.
Any ideas?
Steve
^ permalink raw reply related
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