* Re: linux-2.6.git: cannot build PS3 image
From: Geert Uytterhoeven @ 2007-10-17 13:23 UTC (permalink / raw)
To: Scott Wood, Kumar Gala; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0710121531250.757@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2283 bytes --]
On Fri, 12 Oct 2007, Geert Uytterhoeven wrote:
> On Fri, 12 Oct 2007, Geert Uytterhoeven wrote:
> > On current linux-2.6.git (782e3b3b3804c38d5130c7f21d7ec7bf6709023f), I get:
> >
> > | WRAP arch/powerpc/boot/zImage.ps3
> > | DTC: dts->dtb on file "/usr/people/geert.nba/ps3/ps3-linux-2.6/arch/powerpc/boot/dts/ps3.dts"
> > | ln: accessing `arch/powerpc/boot/zImage.ps3': No such file or directory
> >
> > `make V=1' gives:
> >
> > | /bin/sh ps3-linux-2.6/arch/powerpc/boot/wrapper -c -o arch/powerpc/boot/zImage.ps3 -p ps3 -C "ppu-" -s ps3-linux-2.6/arch/powerpc/boot/dts/ps3.dts vmlinux
> > | DTC: dts->dtb on file "ps3-linux-2.6/arch/powerpc/boot/dts/ps3.dts"
> > | ln: accessing `arch/powerpc/boot/zImage.ps3': No such file or directory
> >
> > I don't see a change to arch/powerpc/boot/Makefile that could explain this.
>
> After bisecting between 2.6.23 and current, I found the culprit:
>
> > commit 11c146cc19df337f4af42dade9e4fca33c5a54ee
> > Author: Scott Wood <scottwood@freescale.com>
> > Date: Fri Sep 14 14:58:25 2007 -0500
> >
> > [POWERPC] 8xx/wrapper: Embedded Planet EP88xC support
> Below is a quick and dirty temporary fix:
>
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index 39b27e5..795f988 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -232,7 +232,7 @@ base=0x`${CROSS}nm "$ofile" | grep ' _start$' | cut -d' ' -f1`
> entry=`${CROSS}objdump -f "$ofile" | grep '^start address ' | cut -d' ' -f3`
>
> if [ -n "$binary" ]; then
> - mv "$ofile" "$ofile".elf
> + cp "$ofile" "$ofile".elf
> ${CROSS}objcopy -O binary "$ofile".elf "$ofile".bin
> fi
No comments?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Josh Boyer @ 2007-10-17 13:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <18198.1222.253923.277227@cargo.ozlabs.ibm.com>
On Wed, 17 Oct 2007 22:49:10 +1000
Paul Mackerras <paulus@samba.org> wrote:
> Linus,
>
> Please do
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
Could you please pull this into your master and/or for-2.6.24
branches? It'll make it easier on those of us tracking your tree.
josh
^ permalink raw reply
* Re: [PATCH v3 2/9] ipic: add new interrupts introduced by new chip
From: Kumar Gala @ 2007-10-17 13:45 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1192195728-24189-3-git-send-email-leoli@freescale.com>
On Oct 12, 2007, at 8:28 AM, Li Yang wrote:
> These interrupts are introduced by the latest Freescale SoC such as
> MPC837x. The patch also adds comment to interrupts.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/sysdev/ipic.c | 224 +++++++++++++++++++++++++++++++++
> +----------
> arch/powerpc/sysdev/ipic.h | 7 +-
> include/asm-powerpc/ipic.h | 12 ++-
> 3 files changed, 186 insertions(+), 57 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
> index 05a56e5..cd8590d 100644
> --- a/arch/powerpc/sysdev/ipic.c
> +++ b/arch/powerpc/sysdev/ipic.c
> @@ -33,7 +33,31 @@ static struct ipic * primary_ipic;
> static DEFINE_SPINLOCK(ipic_lock);
>
> static struct ipic_info ipic_info[] = {
> - [9] = {
> + [1] = { /* PEX1 CNT */
Remove the comments, they are not correct for all IPIC users and thus
misleading.
> + .pend = IPIC_SIPNR_H,
> + .mask = IPIC_SIMSR_H,
> + .prio = IPIC_SIPRR_C,
> + .force = IPIC_SIFCR_H,
> + .bit = 16,
> + .prio_mask = 0,
> + },
[snip]
- k
^ permalink raw reply
* Re: [PATCH v3 4/9] add platform support for MPC837x MDS board
From: Kumar Gala @ 2007-10-17 13:47 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1192195728-24189-5-git-send-email-leoli@freescale.com>
On Oct 12, 2007, at 8:28 AM, Li Yang wrote:
> The MPC837x MDS is a new member of Freescale MDS reference system.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/83xx/Kconfig | 12 ++++
> arch/powerpc/platforms/83xx/Makefile | 1 +
> arch/powerpc/platforms/83xx/mpc837x_mds.c | 103 ++++++++++++++++++
> +++++++++++
> 3 files changed, 116 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/83xx/mpc837x_mds.c
>
> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
> platforms/83xx/Kconfig
> index ec305f1..0c61e7a 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -50,6 +50,11 @@ config MPC836x_MDS
> help
> This option enables support for the MPC836x MDS Processor Board.
>
> +config MPC837x_MDS
> + bool "Freescale MPC837x MDS"
> + select DEFAULT_UIMAGE
> + help
> + This option enables support for the MPC837x MDS Processor Board.
> endchoice
>
> config PPC_MPC831x
> @@ -75,3 +80,10 @@ config PPC_MPC836x
> select PPC_UDBG_16550
> select PPC_INDIRECT_PCI
> default y if MPC836x_MDS
> +
> +config PPC_MPC837x
> + bool
> + select PPC_UDBG_16550
> + select PPC_INDIRECT_PCI
> + select FSL_SERDES
> + default y if MPC837x_MDS
Do we really need this Kconfig option for anything?
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 64 bits vDSO dwarf info for CR register
From: Jakub Jelinek @ 2007-10-17 13:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Deepak Bhole, linuxppc-dev list, Andrew Haley, Paul Mackerras,
Alan Modra
In-Reply-To: <1192595210.11899.149.camel@pasglop>
On Wed, Oct 17, 2007 at 02:26:50PM +1000, Benjamin Herrenschmidt wrote:
> Unfortunately, a bug in gcc cause it to not quite work either, but that
> is being fixed separately with something around the lines of:
>
> linux-unwind.h:
>
> fs->regs.reg[R_CR2].loc.offset = (long) ®s->ccr - new_cfa;
> + /* CR? regs are just 32-bit and PPC is big-endian. */
> + fs->regs.reg[R_CR2].loc.offset += sizeof (long) - 4;
Small correction. If vdso is present, then fixing the vdso is all that is
needed, the above mentioned code is used only if the vdso is not present
(or if glibc doesn't support the vdso).
Jakub
^ permalink raw reply
* Re: [PATCH v4 9/9] add MPC837x MDS board default device tree
From: Kumar Gala @ 2007-10-17 13:54 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1192460210-26920-1-git-send-email-leoli@freescale.com>
On Oct 15, 2007, at 9:56 AM, Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts | 281 ++++++++++++++++++++++
> +++++++++
> arch/powerpc/boot/dts/mpc8378_mds.dts | 263 ++++++++++++++++++++++
> +++++++
> arch/powerpc/boot/dts/mpc8379_mds.dts | 299 ++++++++++++++++++++++
> +++++++++++
> 3 files changed, 843 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts
> create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts
> create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts
>
> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/
> boot/dts/mpc8377_mds.dts
> new file mode 100644
> index 0000000..d0bd326
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
> @@ -0,0 +1,281 @@
> +/*
> + * MPC8377E MDS Device Tree Source
> + *
> + * Copyright 2007 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +/ {
> + model = "fsl,mpc8377emds";
> + compatible = "fsl,mpc8377emds","fsl,mpc837xmds";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,837x@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>;
> + i-cache-line-size = <20>;
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + 32-bit;
remove 32-bit.
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <00000000 20000000>; // 512MB at 0
> + };
> +
> + soc837x@e0000000 {
make this just 'soc@e0000000'
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 e0000000 00100000>;
> + reg = <e0000000 00000200>;
> + bus-frequency = <0>;
> +
> +
> + i2c@3000 {
> + compatible = "fsl-i2c";
> + reg = <3000 100>;
> + interrupts = <e 8>;
> + interrupt-parent = < &ipic >;
> + dfsrr;
add #address-cells & #size-cells to i2c and device_type = "i2c" (Yes
I know there is discussion about this however the code still expects
it to be here for things to work properly).
> + };
> +
> + i2c@3100 {
> + compatible = "fsl-i2c";
> + reg = <3100 100>;
> + interrupts = <f 8>;
> + interrupt-parent = < &ipic >;
> + dfsrr;
ditto.
> + };
> +
> +
[snip]
> + serial@4500 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4500 100>;
> + clock-frequency = <0>;
> + interrupts = <9 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + serial@4600 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4600 100>;
> + clock-frequency = <0>;
> + interrupts = <a 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + crypto@30000 {
> + model = "SEC3";
> + compatible = "talitos";
> + reg = <30000 10000>;
> + interrupts = <b 8>;
> + interrupt-parent = < &ipic >;
> + /* Rev. 3.0 geometry */
> + num-channels = <4>;
> + channel-fifo-len = <18>;
> + exec-units-mask = <000009fe>;
> + descriptor-types-mask = <03ab0ebf>;
is this all correct for sec on 837x?
> + };
> +
[snip]
- k
^ permalink raw reply
* Re: [PATCH v3 9/9] add MPC837x MDS board default device tree
From: Kumar Gala @ 2007-10-17 13:59 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <20071015003703.GA14108@localhost.localdomain>
On Oct 14, 2007, at 7:37 PM, David Gibson wrote:
> On Fri, Oct 12, 2007 at 09:28:48PM +0800, Li Yang wrote:
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> arch/powerpc/boot/dts/mpc8377_mds.dts | 288 +++++++++++++++++++++
>> +++++++++
>> arch/powerpc/boot/dts/mpc8378_mds.dts | 268 +++++++++++++++++++++
>> +++++++
>> arch/powerpc/boot/dts/mpc8379_mds.dts | 308 +++++++++++++++++++++
>> ++++++++++++
>> 3 files changed, 864 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts
>> create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts
>> create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts
>>
>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
>> b/arch/powerpc/boot/dts/mpc8377_mds.dts
> [snip]
>> + soc837x@e0000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>> + ranges = <0 e0000000 00100000>;
>> + reg = <e0000000 00000200>;
>> + bus-frequency = <0>;
>> +
>> + wdt@200 {
>> + device_type = "watchdog";
>
> Drop this device_type.
>
>> + compatible = "mpc83xx_wdt";
>> + reg = <200 100>;
>> + };
>> +
>> + i2c@3000 {
>> + device_type = "i2c";
>
> And this one.
I've asked Leo to leave this one as all other fsl boards do this and
the code depends on it. There was some discussion about this but I
wasn't sure if it was closed or not.
>> + compatible = "fsl-i2c";
>> + reg = <3000 100>;
>> + interrupts = <e 8>;
>> + interrupt-parent = < &ipic >;
>> + dfsrr;
>> + };
>> +
- k
^ permalink raw reply
* Re: [PATCH 3/4] [POWERPC] Add restart support for mpc52xx based platforms
From: Stephen Rothwell @ 2007-10-17 14:02 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <471607A8.6050203@semihalf.com>
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
On Wed, 17 Oct 2007 15:01:28 +0200 Marian Balakowicz <m8@semihalf.com> wrote:
>
> +void __init
> +mpc52xx_map_wdt(void)
> +{
> + const void *has_wdt;
^^^^^^^^
white space damage
> + struct device_node *np;
> +
> + /* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
> + * possibly from a interrupt context. */
> +
> + for (np = NULL;
> + (np = of_find_compatible_node(np, NULL, "fsl,mpc5200-gpt")) != NULL;
> + ) {
for_each_compatible_node(np, NULL, "fsl,mpc5200-gpt") {
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/9] add Freescale SerDes PHY support
From: Kumar Gala @ 2007-10-17 14:13 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1192195728-24189-4-git-send-email-leoli@freescale.com>
> diff --git a/arch/powerpc/sysdev/fsl_serdes.c b/arch/powerpc/sysdev/
> fsl_serdes.c
> new file mode 100644
> index 0000000..5e91eb7
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_serdes.c
> @@ -0,0 +1,152 @@
> +/*
> + * arch/powerpc/sysdev/fsl_serdes.c
> + *
> + * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights
> reserved.
> + *
> + * Author: Li Yang <leoli@freescale.com>
> + *
> + * Freescale SerDes initialization routines
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as published
> by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/delay.h>
> +#include <linux/of.h>
> +
> +#include <asm/system.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +
> +#include "fsl_serdes.h"
just move the #defines into the .c file and kill the header.
> +
> +static int __init setup_serdes(struct device_node *np)
> +{
> + void __iomem *regs;
> + const void *prot;
> + const unsigned int *freq;
> + struct resource res;
> + u32 rfcks;
> +
> + of_address_to_resource(np, 0, &res);
> + regs = ioremap(res.start, res.end - res.start + 1);
you don't unmap this ever (on error or exit of the function).
> +
> + prot = of_get_property(np, "protocol", NULL);
> + if (!prot)
> + return -EINVAL;
> + freq = of_get_property(np, "clock", NULL);
> + switch (*freq) {
> + case 100:
> + rfcks = FSL_SRDSCR4_RFCKS_100;
> + break;
> + case 125:
> + rfcks = FSL_SRDSCR4_RFCKS_125;
> + break;
> + case 150:
> + rfcks = FSL_SRDSCR4_RFCKS_150;
> + break;
> + default:
> + printk(KERN_ERR "SerDes: Wrong frequency\n");
> + return -EINVAL;
> + }
> +
> + /* Use default prescale and counter */
> +
> + /* 1.0V corevdd */
> + if (of_get_property(np, "vdd-1v", NULL)) {
> + /* DPPE/DPPA = 0 */
> + clrbits32(regs + FSL_SRDSCR0_OFFS, FSL_SRDSCR0_DPP_1V2);
> +
> + /* VDD = 0 */
> + clrbits32(regs + FSL_SRDSCR2_OFFS, FSL_SRDSCR2_VDD_1V2);
> + }
> +
> + /* protocol specific configuration */
> + if (!strcmp(prot, "sata")) {
> + /* Set and clear reset bits */
> + setbits32(regs + FSL_SRDSRSTCTL_OFFS,
> + FSL_SRDSRSTCTL_SATA_RESET);
> + mdelay(1);
> + clrbits32(regs + FSL_SRDSRSTCTL_OFFS,
> + FSL_SRDSRSTCTL_SATA_RESET);
> +
> + /* Configure SRDSCR1 */
> + clrbits32(regs + FSL_SRDSCR1_OFFS, FSL_SRDSCR1_PLLBW);
> +
> + /* Configure SRDSCR2 */
> + clrsetbits_be32(regs + FSL_SRDSCR2_OFFS,
> + FSL_SRDSCR2_SEIC_MASK, FSL_SRDSCR2_SEIC_SATA);
> +
> + /* Configure SRDSCR3 */
> + out_be32(regs + FSL_SRDSCR3_OFFS, FSL_SRDSCR3_KFR_SATA |
> + FSL_SRDSCR3_KPH_SATA |
> + FSL_SRDSCR3_SDFM_SATA_PEX |
> + FSL_SRDSCR3_SDTXL_SATA);
> +
> + /* Configure SRDSCR4 */
> + out_be32(regs + FSL_SRDSCR4_OFFS, rfcks |
> + FSL_SRDSCR4_PROT_SATA);
> +
> + } else if (!strcmp(prot, "pcie")) {
> + /* Configure SRDSCR1 */
> + setbits32(regs + FSL_SRDSCR1_OFFS, FSL_SRDSCR1_PLLBW);
> +
> + /* Configure SRDSCR2 */
> + clrsetbits_be32(regs + FSL_SRDSCR2_OFFS, FSL_SRDSCR2_SEIC_MASK,
> + FSL_SRDSCR2_SEIC_PEX);
> +
> + /* Configure SRDSCR3 */
> + out_be32(regs + FSL_SRDSCR3_OFFS, FSL_SRDSCR3_SDFM_SATA_PEX);
> +
> + /* Configure SRDSCR4 */
> + if (of_get_property(np, "pcie-x2", NULL))
> + out_be32(regs + FSL_SRDSCR4_OFFS, rfcks |
> + FSL_SRDSCR4_PROT_PEX | FSL_SRDSCR4_PLANE_X2);
> + else
> + out_be32(regs + FSL_SRDSCR4_OFFS, rfcks |
> + FSL_SRDSCR4_PROT_PEX);
> +
> + } else if (!strcmp(prot, "sgmii")) {
> + /* Configure SRDSCR1 */
> + clrbits32(regs + FSL_SRDSCR1_OFFS, FSL_SRDSCR1_PLLBW);
> +
> + /* Configure SRDSCR2 */
> + clrsetbits_be32(regs + FSL_SRDSCR2_OFFS, FSL_SRDSCR2_SEIC_MASK,
> + FSL_SRDSCR2_SEIC_SGMII);
> +
> + /* Configure SRDSCR3 */
> + out_be32(regs + FSL_SRDSCR3_OFFS, 0);
> +
> + /* Configure SRDSCR4 */
> + out_be32(regs + FSL_SRDSCR4_OFFS, rfcks |
> + FSL_SRDSCR4_PROT_SGMII);
> +
> + } else {
> + printk(KERN_ERR "SerDes: Wrong protocol\n");
> + return -EINVAL;
> + }
> +
> + /* Do a software reset */
> + setbits32(regs + FSL_SRDSRSTCTL_OFFS, FSL_SRDSRSTCTL_RST);
> +
> + printk(KERN_INFO "Freescale SerDes at %8x initialized\n",
> res.start);
> +
> + return 0;
> +}
> +
> +static int __init fsl_serdes_init(void) {
> + struct device_node *np;
> +
> + for (np = NULL; (np = of_find_compatible_node(np, NULL,
> "fsl,serdes")) != NULL;)
use for_each_compatible_node
> + setup_serdes(np);
> +
> + return 0;
> +}
> +
> +arch_initcall(fsl_serdes_init);
>
- k
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-17 14:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <18195.64334.985238.848522@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
>> I don't see my own signoff or at least a reference to my prior work in
>>this patch or even at -rt patch -- despite this code ha clearly borrowed from
>>it. And I'm not sure why this crippled version (lacking 40x/ Book E specific
>>clockevents implementation) is preferred over mine, unless this implementation
>>was only aimed at PPC64 machines...
> Tony started from an earlier patch by John Stultz, not from your
> patches.
Well, that I can believe, yet the clockevents patch has traces of my
former work, and looking at read_persisitent_time() it looks suspiciously
close to my version too...
> The main reason your patches were rejected were that you completely
> broke the VDSO and the deterministic time accounting, and made no
That's just not true!
They didn't broke vDSO (to be precise it was John's patch that broke it),
they just removed the vDSO code known to already be broken by -rt patch for
several months by then. And they didn't broke determinictic accounting --
they just made two things mutually exclusive. I haven't yet seen how the
patches that were preferred dealt with it at all.
> attempt to fix them.
I lacked time to do this, so did what I could.
> As for 40x/Book E, the main thing there is the auto-reload. However,
> since the generic core can use a oneshot clock event source to
> generate periodic ticks, there is no advantage to using the
> auto-reload.
Really? IMO, the harware does keep a constant interrupt rate better than
software.
>> Also, have the deterministic CPU accounting incompatibility with
>>clockevents been dealt with?
> The S390 guys looked at that and solved it with Ingo's and Thomas's
> help (although I did see something on linux-kernel about some further
> problems).
Good to hear. Nobody offered any help to me (except maybe Thomas -- but we
never came to any viable approach).
>> I'd use (evt - 1) since the interrupt gets generated at 0xffffffff count,
>>not 0 (on classic CPUs). With you removing of the code that compensated for
> See commit d968014b7280e2c447b20363e576999040ac72ef; I already fixed
> that.
Good to hear this has been dealt with, along with that PowerMAC "IRQ
simulation" nuisance -- I didn't care about it, sorry. :-)
>>the errors, they will accumulate. And no, this wouldn't be enough anyway,
> No, they don't accumulate. See tick_setup_periodic(). The interval
> until the next tick is determined using ktime_get() rather than just
> being a constant.
The interrupt always happens 1 clock later depsite what value
have been selected for the decrementer. Well, OK, that should still get
compensated by the tick_setup_periodic() by selecting shorter next period.
Well, I'm taking comfot in that you've finally had to sutract 1. :-)
>>since on 40x and Book E you'll need to set it for evt anyway, since the
>>interrupt happens at 0 count...
>> NAK the patch. And I really don't understand why you're throwing alway
>>already tested/working code...
> Because you broke important features
That is *not true*.
And nobody had interest to fix them for months (quite strange if they're
so important) while I had neither time nor interest to deal with them anymore
having written the code that *did work*, and not only for me.
> and because you seem to have some
> fundamental misconceptions (e.g. the comment about errors accumulating
Where's the misconception in the patch? ;-)
> you just made).
I see, I'm a bad guy... but still not convinced. :-)
> Paul.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-17 14:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <18195.64334.985238.848522@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
>> I'd use (evt - 1) since the interrupt gets generated at 0xffffffff count,
>>not 0 (on classic CPUs). With you removing of the code that compensated for
> See commit d968014b7280e2c447b20363e576999040ac72ef; I already fixed
> that.
BTW, while fixing that for classic PPC, but you've broke it for 40x / book
E CPU which interrupt at 0. Congratulations. :-)
WBR, Sergei
^ permalink raw reply
* Re: can and mpc5200b
From: S. Fricke @ 2007-10-17 14:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <f87351060710150705l5e4d1ba5v6806686cd25418bb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
Hello list,
> > Hello Friends,
> > what is the reasonable can-driver for a mpc5200b?
> >
> > I have seen for the peak-3.17 driver a port for the mpc5200 from denx on their
> > website, but with kernel 2.6.23 I dont have a chance to use this?
>
> Check this out http://developer.berlios.de/projects/socketcan/ . This
> is the CAN driver we use and it works pretty well for us. It is very
> updated and supports the mscan chipset that is available with the
> mpc5200b.
Socketcan works for me perfectly with the canconfig tool.
Thank you.
Silvio
Mit freundlichen Gruessen
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-10-17 14:54 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <13252272.post@talk.nabble.com>
On 10/17/07, aauer1 <aauer1@gmx.at> wrote:
> I was able to look at the __log_buf variable with the JTAG cable. So, I
> recognized that the kernel doesn't halt after the "No booting the kernel"
> message. There are many output messages in the __log_buf variable until it
> stops at with a "Kernel panic" because the rootfs is not found (but this is
> the minor problem).
> Now, I know that the kernel boots but I don't get an output with my Xilinx
> UartLite module. Are there some kernel modules which must be activated??
> Btw. I have used the Linux-2.6-virtex kernel from
> http://git.secretlab.ca/git/ and another Kernel (2.6.23 from kernel.org) -
> both with the same result.
Post the output of __log_buf here please.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 01/15] [POWERPC] TQM5200 DTS
From: Grant Likely @ 2007-10-17 14:57 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4715ED92.80503@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
> Grant Likely wrote:
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <00000000 04000000>; // 64MB
> >> + };
> >> +
> >> + soc5200@f0000000 {
> >
> > I think we're moving to the convetion of naming these nodes
> > "soc@<addr>" now. (You can drop the 5200 for the node name)
>
> Seems that this will not be painless, U-boot uses hardcoded
> paths with 'soc5200', so the appropriate patch will be needed.
> That may be ok for new boards but what do we do with lite5200,
> where U-boot upgrade is not always an option?
Hmm; yeah I guess there are probably already deployed tqm5200 boards
with hard coded soc5200. Alright; leave it as is.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 64 bits vDSO dwarf info for CR register
From: Andrew Haley @ 2007-10-17 14:00 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Deepak Bhole, linuxppc-dev list, Benjamin Herrenschmidt,
Paul Mackerras, Alan Modra
In-Reply-To: <20071017135055.GP5451@devserv.devel.redhat.com>
Jakub Jelinek writes:
> On Wed, Oct 17, 2007 at 02:26:50PM +1000, Benjamin Herrenschmidt wrote:
> > Unfortunately, a bug in gcc cause it to not quite work either, but that
> > is being fixed separately with something around the lines of:
> >
> > linux-unwind.h:
> >
> > fs->regs.reg[R_CR2].loc.offset = (long) ®s->ccr - new_cfa;
> > + /* CR? regs are just 32-bit and PPC is big-endian. */
> > + fs->regs.reg[R_CR2].loc.offset += sizeof (long) - 4;
>
> Small correction. If vdso is present, then fixing the vdso is all that is
> needed, the above mentioned code is used only if the vdso is not present
> (or if glibc doesn't support the vdso).
Perhaps we should test this change with a hacked libgcc, just to make
sure it fixes the bug.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
^ permalink raw reply
* Re: [PATCH 04/15] [POWERPC] CM5200 DTS
From: Grant Likely @ 2007-10-17 14:59 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <4715FE6C.2070201@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
> David Gibson wrote:
> > [snip]
> >> + flash@c000000 {
> >> + device_type = "rom";
> >> + compatible = "direct-mapped";
> >> + reg = <0c000000 02000000>;
> >> + probe-type = "CFI";
> >> + bank-width = <2>;
> >> + partitions = <00000000 00060000
> >> + 00060000 00020000
> >> + 00080000 00020000
> >> + 000a0000 00020000
> >> + 000c0000 00200000
> >> + 002c0000 01b40000
> >> + 01e00000 00200000>;
> >> + partition-names = "uboot\0env\0redund_env\0dtb\0kernel\0rootfs\0config";
> >> + };
> >
> > First, this is the old flash binding, please use the new one.
>
> Ok.
>
> > Second, is the flash really part of the SoC?
>
> Not directly, it is attached to LocalPlus Bus Controller, which is
> part of the SoC. And the soc@ is currently the only recognized of bus
> for mpc5200, so if we want to move it to some other place new bindings
> will need to be defined for lpc (LocalPlus Controller) bus. But I am
> not quite sure where this should be attached. Bus is under LPC which
> is a part of the SoC, but on the other hand Soc address range covers
> only device control registers not the address space LPC may handle
> (that may be varied). Any ideas?
My vote is for an lpc node off the root of the tree for devices like
this to hang off.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/4] [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions
From: Grant Likely @ 2007-10-17 15:02 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <47160709.5020002@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add helper routine mpc52xx_find_and_map_path(). Extract common code to
> mpc52xx_map_node() and refactor mpc52xx_find_and_map().
>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
> Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Yeah, this is probably okay. Eventually these util functions should
be refactored to be usable by any platform.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/4] [POWERPC] Update device tree binding for mpc5200 gpt
From: Grant Likely @ 2007-10-17 15:12 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4716074E.80903@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add 'fsl,' prefix to 'compatible' property for gpt nodes.
> Add 'fsl,' prefix to empty, GPT0 specific 'has-wdt' property.
>
> diff --git a/drivers/char/watchdog/mpc5200_wdt.c b/drivers/char/watchdog/mpc5200_wdt.c
> index 564143d..9aaba7a 100644
> --- a/drivers/char/watchdog/mpc5200_wdt.c
> +++ b/drivers/char/watchdog/mpc5200_wdt.c
> @@ -174,7 +174,7 @@ static int mpc5200_wdt_probe(struct of_d
> const void *has_wdt;
> int size;
>
> - has_wdt = of_get_property(op->node, "has-wdt", NULL);
> + has_wdt = of_get_property(op->node, "fsl,has-wdt", NULL);
> if (!has_wdt)
> return -ENODEV;
Do this instead:
has_wdt = of_get_property(op->node, "has-wdt", NULL);
+ if (!has_wdt)
+ has_wdt = of_get_property(op->node, "fsl,has-wdt", NULL);
if (!has_wdt)
return -ENODEV;
This will allow it to still work with older device trees.
>
> @@ -253,7 +253,7 @@ static int mpc5200_wdt_shutdown(struct o
> }
>
> static struct of_device_id mpc5200_wdt_match[] = {
> - { .compatible = "mpc5200-gpt", },
> + { .compatible = "fsl,mpc5200-gpt", },
Keep both the old and new in the match table for now for the same reason.
Otherwise, looks good. Thanks.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Joachim Fenkes @ 2007-10-17 15:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Q Klein, Jeff Garzik, Paul Mackerras, netdev,
Jan-Bernd Themann, LKML, LinuxPPC-Dev, Christoph Raisch,
Paul Mackerras, Marcus Eder, Stefan Roscher
In-Reply-To: <20071017012706.adbd3188.sfr@canb.auug.org.au>
On Tuesday 16 October 2007 17:27, Stephen Rothwell wrote:
> One small change - I intend to remove the name and owner fields from
> struct of_platform_driver, so you should not bother initialising the name
> field and just initialise the name field of the embedded struct
> device_driver instead. This, of course, means that you don't need
>
> drv->driver.name = drv->name;
>
> in ibmebus_register_driver.
I'd prefer to let this line stay in place until you actually make your
change, to keep the data structures consistent as long as the name field is
present. You could remove it in your patch then.
Regards,
Joachim
^ permalink raw reply
* Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Kumar Gala @ 2007-10-17 15:30 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev list, Timur Tabi
In-Reply-To: <24BADA7A-1716-43B1-BC92-F4DB7ED0D331@kernel.crashing.org>
On May 25, 2007, at 7:15 AM, Kumar Gala wrote:
>
> On May 24, 2007, at 9:45 PM, Li Yang-r58472 wrote:
>
>>
>>> -----Original Message-----
>>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>>> Sent: Thursday, May 24, 2007 7:44 PM
>>> To: Li Yang-r58472
>>> Cc: Paul; linuxppc-dev@ozlabs.org
>>> Subject: Re: [PATCH] qe_lib: export symbols to fix compile error
>>> when
>> QE drivers
>>> compile as modules
>>>
>>>
>>> On May 24, 2007, at 4:14 AM, Li Yang wrote:
>>>
>>>> Export symbols of qe_lib to be used by QE drivers.
>>>>
>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>> ---
>>>> arch/powerpc/sysdev/qe_lib/ucc.c | 7 +++++++
>>>> arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
>>>> arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++++++++++--
>>>> 3 files changed, 25 insertions(+), 2 deletions(-)
>>>
>>> A number of the EXPORT_SYMBOL() are not used by any in kernel
>>> drivers
>>> and thus should not be added. See comments below. Also, should
>>> these be EXPORT_SYMBOL_GPL().
>>
>> Some of them are not used by in kernel driver, but they are used by
>> some
>> off kernel drivers and driver in development. Shouldn't we export
>> them?
>
> Nope, its been a pretty established rule that we don't export symbols
> for drivers not in the kernel. These drivers should really be
> submitted for acceptance into the kernel and than we can export the
> symbols they need.
>
> While I can see a need for the *slow* symbols to be exported until
> there is a driver needing them we shouldn't export the symbols.
>
>> I know Linux is again non-GPL modules, but Freescale won't be forcing
>> customers to use GPL as long as Linux doesn't ban non-GPL module
>> completely.
>
> That's fine.
>
>>>> static void get_cmxucr_reg(int ucc_num, volatile u32 ** p_cmxucr,
>>>> u8 * reg_num,
>>>> u8 * shift)
>>>> @@ -122,6 +126,7 @@ static void get_cmxucr_reg(int ucc_num,
>>>> volatile u32 ** p_cmxucr, u8 * reg_num,
>>>> break;
>>>> }
>>>> }
>>>> +EXPORT_SYMBOL(get_cmxucr_reg);
>>>
>>> remove, you shouldn't be exporting something marked static.
>>
>> Good catch.
>>
>> Thanks,
>> Leo
What happened with this?
- k
^ permalink raw reply
* Re: [PATCH 3/4] [POWERPC] Add restart support for mpc52xx based platforms
From: Grant Likely @ 2007-10-17 15:30 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <471607A8.6050203@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add common helper routines: mpc52xx_map_wdt() and mpc52xx_restart().
>
> This patch relies on Sascha Hauer's patch published in:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 45 +++++++++++++++++++++++++++
> include/asm-powerpc/mpc52xx.h | 3 +
> 2 files changed, 48 insertions(+)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> index 74b4b41..553937b 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -18,6 +18,13 @@ #include <asm/io.h>
> #include <asm/prom.h>
> #include <asm/mpc52xx.h>
>
> +/*
> + * This variable is mapped in mpc52xx_map_wdt() and used in mpc52xx_restart().
> + * Permanent mapping is required because mpc52xx_restart() can be called
> + * from interrupt context while node mapping (which calls iorenmap())
> + * cannot be used at such point.
> + */
> +static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
>
> static void __iomem *
> mpc52xx_map_node(struct device_node *ofn)
> @@ -126,3 +133,41 @@ mpc52xx_declare_of_platform_devices(void
> "Error while probing of_platform bus\n");
> }
>
> +void __init
> +mpc52xx_map_wdt(void)
> +{
> + const void *has_wdt;
> + struct device_node *np;
> +
> + /* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
> + * possibly from a interrupt context. */
> +
> + for (np = NULL;
> + (np = of_find_compatible_node(np, NULL, "fsl,mpc5200-gpt")) != NULL;
> + ) {
> + /* wdt is only implement on gpt0, check has-wdt property. */
> + has_wdt = of_get_property(np, "fsl,has-wdt", NULL);
Test for both "has-wdt" and "fsl,has-wdt" for now.
Otherwise, looks good.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 4/4] [POWERPC] Enable restart support for lite5200 board
From: Grant Likely @ 2007-10-17 15:31 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <471607DB.4060509@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Looks good; I'll pick this one up when you respin the others.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Stephen Hemminger @ 2007-10-17 15:31 UTC (permalink / raw)
To: benh; +Cc: netdev, Roland Dreier, David S. Miller, Jeff Garzik,
linuxppc-dev list
In-Reply-To: <1192591481.11899.134.camel@pasglop>
Please don't use double underscore, for this function name. There is no
reason to not make it a normal API call.
The sky2 fix I am working on will use napi_synchronize as well.
--- a/include/linux/netdevice.h 2007-10-16 16:48:20.000000000 -0700
+++ b/include/linux/netdevice.h 2007-10-17 08:29:55.000000000 -0700
@@ -407,6 +407,24 @@ static inline void napi_enable(struct na
clear_bit(NAPI_STATE_SCHED, &n->state);
}
+#ifdef CONFIG_SMP
+/**
+ * napi_synchronize - wait until NAPI is not running
+ * @n: napi context
+ *
+ * Wait until NAPI is done being scheduled on this context.
+ * Any outstanding processing completes but
+ * does not disable future activations.
+ */
+static inline void napi_synchronize(const struct napi_struct *n)
+{
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep(1);
+}
+#else
+# define napi_synchronize(n) barrier()
+#endif
+
/*
* The DEVICE structure.
* Actually, this whole structure is a big mistake. It mixes I/O
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-17 15:31 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <85100356-D95B-4343-98BE-66080EA9887D@embeddedalley.com>
Dan Malek wrote:
>
> On Oct 16, 2007, at 12:18 PM, Scott Wood wrote:
>
>> Upgrading to the latest u-boot certainly shouldn't hurt, but I don't
>> think there's any device tree support for 8xx yet,
>
> Have you tried it? Works for me. In fact, most
> of the development you see today was done
> by Pantelis on the 8xx.
I just pulled Wolfgang's latest u-boot tree, and I don't see any fdt or
ft_ calls in cpu/mpc8xx, nor in any 8xx board that I recognize.
I may have been unclear in that I was talking about device tree support
in u-boot, not the kernel. Obviously there's device tree support in the
kernel, as evidenced by my reference to using cuImage.
-Scott
^ permalink raw reply
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Scott Wood @ 2007-10-17 15:33 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4715F51D.2060000@semihalf.com>
Marian Balakowicz wrote:
> Scott Wood wrote:
>>> +void tqm5200_show_cpuinfo(struct seq_file *m)
>>> +{
>>> + struct device_node* np = of_find_all_nodes(NULL);
>>> + const char *model = NULL;
>>> +
>>> + if (np)
>>> + model = of_get_property(np, "model", NULL);
>>> +
>>> + seq_printf(m, "vendor\t\t: Freescale Semiconductor\n");
>>> + seq_printf(m, "machine\t\t: %s\n", model ? model : "unknown");
>>> +
>>> + of_node_put(np);
>>> +}
>> Get rid of this.
>
> Agree, that may be overhead in some cases. But there would be also
> cases where printing out a machine name would be informative. CM5200
> is one such example, there are several variants of the hw and platform
> name is too generic.
Maybe, though if we're going to do that it'd be better to just print
/model in the generic cpuinfo (or somewhere else generic). And there's
always /proc/device-tree/model...
-Scott
^ 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