* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: Scott Wood @ 2008-01-14 22:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080115093149.39a1d703.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
>> +++ b/libfdt/libfdt.h
>
>> +#define FDT_ERR_BADDEPTH 8
>
> Wouldn't it have been less intrusive to just use the next error number
> rather than inserting this here?
Yes, but then either the order in errtable[] wouldn't match the order in
the header file, or the error type grouping would be broken.
If we want to maintain such a grouping, we should probably leave some
number space between the groups.
>> + * fdt_getprop_offset - retrieve the value of a given property by offset
>> + * @fdt: pointer to the device tree blob
>> + * @propoffset: offset of the property to read
>> + * @name: pointer to a character pointer (will be overwritten) or NULL
> ^^^^^^^^^^^^^^^^^
> "string"?
"pointer to a string" could be interpreted as "char *", not "char **".
I'll fix the others; thanks for pointing them out.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Bryan O'Donoghue @ 2008-01-14 22:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080114152859.GA26907@ld0162-tx32.am.freescale.net>
On Mon, 2008-01-14 at 09:28 -0600, Scott Wood wrote:
> On Sun, Jan 13, 2008 at 02:26:12PM +0000, Bryan O'Donoghue wrote:
> > I've applied your code against Linus' git v2.6.26-rc7 as at today.
> > I have to apply
>
> It should apply against paulus's tree.
>
> > make adder87x-uboot_defconfig
> >
> > make uImage
>
> make zImage, not uImage.
Will try.
> > cp arch/powerpc/boot/uImage /tftpboot - which is my tftpd root
> > directory.
>
> Use cuImage.8xx, not uImage.
>
> > In U-Boot then.
> >
> > => tftpboot 0x400000 uImage
> > => bootm 0x400000
>
> 0x400000 is where u-boot is going to want to relocate the image to, so
> loading the uImage there may not work.
Hmm, some old code I did to make Linux boot from the former ppc stuff
works fine to the loading and booting @ 0x4000000 - this step is pretty
much fine, I think.
> Yes, a uImage target will be expecting to be handed a device tree. The
> cuImage target has a device tree embedded and accepts the old-style bd_t.
Ah.
This explains eveything then.. there _is_ a magic image and I haven't
been booting it !
Typical.
I'll give the 8xx-centric ucImage a go.
> > /* pass open firmware flat tree */
> > #define CONFIG_OF_LIBFDT 1
> > #undef CONFIG_OF_FLAT_TREE
> > #define CONFIG_OF_BOARD_SETUP 1
> > #define CONFIG_OF_HAS_BD_T 1
> > #define CONFIG_OF_HAS_UBOOT_ENV 1
> >
> > #define OF_CPU "PowerPC,875 at 0"
> > #define OF_SOC "soc875 at ff000000"
> > #define OF_TBCLK (bd->bi_busfreq / 4)
>
> You'll probably need some 8xx-specific code if you want to go this route.
> You'd also need to change the bootm command line to the three-argument
> version, with the third argument being the address of the device tree
> blob (the second argument can be - if there's no initrd).
Ah OK, I see so the procedure would be to dtc a dts representing the
Adder.
Download both this and a uImage ... and then as you say pass the address
of the blob to Linux via U-Boot.
It occurs to me that this type of procedure should really be added to
the Documentation...
There's no mention of it in the Linux documentation, nor in the u-boot
documentation and uncle Google was not informative for the types of
searches I was doing....
Somebody - possibly even me, since I'm mentioning it - should write a
copule of paragraphs on booting a ucImage with a of-blob and add it to
both U-Boot and Linux..
> If you're not comfortable with the device tree stuff, I recommend just
> using cuImage for now.
Indeed.
Thanks for the response Scott. I'll try out the ucImage and all going
well with that will try the three parameter Linux + blob based on
the .dts, hopefully over the next three or four days....
If I'm unlucky I might bug you again... and if I have more luck, I'll do
a follow up on the list.
Happy Monday !
Regards,
Bryan
^ permalink raw reply
* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: Stephen Rothwell @ 2008-01-14 22:31 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080114163004.GA27880@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]
Hi Scott,
On Mon, 14 Jan 2008 10:30:04 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> ft_get_next_node() enumerates children of a given node.
> ft_get_next_prop() enumerates propreties of a given node.
^^^^^^^^^^
typo.
> ft_getprop_offset() is like ft_getprop(), but takes a property offset rather
> than a node offset and property name; it is primarily intended for use
> with ft_get_next_prop().
All the "ft_" above should be "fdt_".
> +const void *fdt_getprop_offset(const void *fdt, int propoffset,
> + const char **name, int *lenp)
> +{
> + tag = fdt_next_tag(fdt,propoffset, NULL);
^
space after ','
> +++ b/libfdt/libfdt.h
> +#define FDT_ERR_BADDEPTH 8
Wouldn't it have been less intrusive to just use the next error number
rather than inserting this here?
> + * fdt_getprop_offset - retrieve the value of a given property by offset
> + * @fdt: pointer to the device tree blob
> + * @propoffset: offset of the property to read
> + * @name: pointer to a character pointer (will be overwritten) or NULL
^^^^^^^^^^^^^^^^^
"string"?
> + * @lenp: pointer to an integer variable (will be overwritten) or NULL
> + *
> + * fdt_getprop() retrieves a pointer to the value of the property
fdt_getprop_offset
> + * named 'name' of the node at offset nodeoffset (this will be a
> + * pointer to within the device blob itself, not a copy of the value).
> + * If lenp is non-NULL, the length of the property value also
> + * returned, in the integer pointed to by lenp.
> + *
> + * returns:
> + * pointer to the property's value
if name is non-NULL, *name points to ...
> + * if lenp is non-NULL, *lenp contains the length of the property
> + * value (>=0)
--
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 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
From: Andrew Morton @ 2008-01-14 21:14 UTC (permalink / raw)
To: Poonam_Aggrwal-b10812
Cc: kumar.gala, michael.barkowski, netdev, linux-kernel, rubini,
linuxppc-dev, ashish.kalra, rich.cutler
In-Reply-To: <Pine.LNX.4.64.0712101710270.29623@linux121>
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 <b10812@freescale.com> wrote:
> From: Poonam Aggrwal <b10812@freescale.com>
>
> The UCC TDM driver basically multiplexes and demultiplexes data from
> different channels. It can interface with for example SLIC kind of devices
> to receive TDM data demultiplex it and send to upper applications. At the
> transmit end it receives data for different channels multiplexes it and
> sends them on the TDM channel. It internally uses TSA( Time Slot Assigner)
> which does multiplexing and demultiplexing, UCC to perform SDMA between
> host buffers and the TSA, CMX to connect TSA to UCC.
>
> This driver will run on MPC8323E-RDB platforms.
>
> ...
>
> +#define PREV_PHASE(x) ((x == 0) ? MAX_PHASE : (x - 1))
> +#define NEXT_PHASE(x) (((x + 1) > MAX_PHASE) ? 0 : (x + 1))
These macros can reference their arg more than once and are hence
dangerous. What does PREV_PHASE(foo++) do to foo?
And, in general: do not implement in cpp that which could have been
implemented in C.
> +static struct ucc_tdm_info utdm_primary_info = {
> + .uf_info = {
> + .tsa = 1,
> + .cdp = 1,
> + .cds = 1,
> + .ctsp = 1,
> + .ctss = 1,
> + .revd = 1,
> + .urfs = 0x128,
> + .utfs = 0x128,
> + .utfet = 0,
> + .utftt = 0x128,
> + .ufpt = 256,
> + .ttx_trx = UCC_FAST_GUMR_TRANSPARENT_TTX_TRX_TRANSPARENT,
> + .tenc = UCC_FAST_TX_ENCODING_NRZ,
> + .renc = UCC_FAST_RX_ENCODING_NRZ,
> + .tcrc = UCC_FAST_16_BIT_CRC,
> + .synl = UCC_FAST_SYNC_LEN_NOT_USED,
> + },
> + .ucc_busy = 0,
> +};
> +
> +static struct ucc_tdm_info utdm_info[8];
> +
> +static void dump_siram(struct tdm_ctrl *tdm_c)
> +{
> +#if defined(DEBUG)
Microscopic note: kernel code tends to do
#ifdef FOO
if only one identifier is being tested and
#if defined(FOO) && defined(BAR)
if more than one is being tested.
There is no rational reason for this ;)
> + int i;
> + u16 phy_num_ts;
> +
> + phy_num_ts = tdm_c->physical_num_ts;
> +
> + pr_debug("SI TxRAM dump\n");
> + /* each slot entry in SI RAM is of 2 bytes */
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.tx[i]));
> + pr_debug("\nSI RxRAM dump\n");
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.rx[i]));
> + pr_debug("\n");
> +#endif
> +}
> +
> +/*
> + * converts u-law compressed samples to linear PCM
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver receives u-law compressed data from the
> + * SLIC device. This function converts the compressed
> + * data to linear PCM and sends it to upper layers.
> + */
> +static inline int ulaw2int(unsigned char log)
> +{
> + u32 sign, segment, temp, quant;
> + int val;
> +
> + temp = log ^ 0xFF;
> + sign = (temp & 0x80) >> 7;
> + segment = (temp & 0x70) >> 4;
> + quant = temp & 0x0F;
> + quant <<= 1;
> + quant += 33;
> + quant <<= segment;
> + if (sign)
> + val = 33 - quant;
> + else
> + val = quant - 33;
> +
> + val *= 4;
> + return val;
> +}
> +
> +/*
> + * converts linear PCM samples to u-law compressed format.
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver calls this function to convert the PCM samples
> + * to u-law compressed format before sending them to SLIC
> + * device.
> + */
> +static inline u8 int2ulaw(short linear)
> +{
> + u8 quant, ret;
> + u16 output, absol, temp;
> + u32 i, sign;
> + char segment;
> +
> + ret = 0;
> + if (linear >= 0)
> + linear = (linear >> 2);
> + else
> + linear = (0xc000 | (linear >> 2));
> +
> + absol = abs(linear) + 33;
> + temp = absol;
> + sign = (linear >= 0) ? 1 : 0;
> + for (i = 0; i < 16; i++) {
> + output = temp & 0x8000;
> + if (output)
> + break;
> + temp <<= 1;
> + }
> + segment = 11 - i;
> + quant = (absol >> segment) & 0x0F;
> + segment--;
> + segment <<= 4;
> + output = segment + quant;
> + if (absol > 8191)
> + output = 0x7F;
> + if (sign)
> + ret ^= 0xFF;
> + else
> + ret ^= 0x7F;
> + return ret;
> +}
hrm, how many copies of ulaw/alaw conversion functions do we need in the
tree before someone writes a library function for it?
> + out_be16(&rx_bd->status, bd_status);
> + out_be32(&rx_bd->buf,
> + tdm_c->dma_input_addr + i * SAMPLE_DEPTH * act_num_ts);
> +
> + bd_status = (u16) ((T_R | T_CM | T_W) >> 16);
> + bd_len = SAMPLE_DEPTH * act_num_ts;
> + out_be16(&tx_bd->length, bd_len);
> + out_be16(&tx_bd->status, bd_status);
> + out_be32(&tx_bd->buf,
> + tdm_c->dma_output_addr + i * SAMPLE_DEPTH * act_num_ts);
> +
> + config_si(tdm_c);
> +
> + setbits32(&qe_immr->ic.qimr, (0x80000000 >> ucc));
The compiler treats 0xNNN constants as unsigned so this works OK. I'd have
put a UL on the end of the constant to be sure ;)
> +static int tdm_start(struct tdm_ctrl *tdm_c)
> +{
> + if (request_irq(tdm_c->ut_info->uf_info.irq, tdm_isr,
> + 0, "tdm", tdm_c)) {
> + printk(KERN_ERR "%s: request_irq for tdm_isr failed\n",
> + __FUNCTION__);
> + return -ENODEV;
> + }
> +
> + ucc_fast_enable(tdm_c->uf_private, COMM_DIR_RX | COMM_DIR_TX);
> +
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + pr_info("%s 8-bit u-law compressed mode active\n", __FUNCTION__);
> +#else
> + pr_info("%s 16-bit linear pcm mode active with"
> + " slots 0 & 2\n", __FUNCTION__);
> +#endif
Is this the sort of thing which should be controlled at compile-time? I'd
have thought that a runtime control would be more appropriate (a sysfs knob
or a module parameter). Or just work it out automagically?
> + dump_siram(tdm_c);
> + dump_ucc(tdm_c);
> +
> + setbits8(&(qe_immr->si1.siglmr1_h), (0x1 << tdm_c->tdm_port));
> + pr_info("%s UCC based TDM enabled\n", __FUNCTION__);
> +
> + return 0;
> +}
>
> ...
>
> +static void tdm_read(u32 driver_handle, short chn_id, short *pcm_buffer,
> + short len)
> +{
> + int i;
> + u32 phase_rx;
> + /* point to where to start for the current phase data processing */
> + u32 temp_rx;
> +
> + struct tdm_ctrl *tdm_c = (struct tdm_ctrl *)(driver_handle);
eek. What are we doing here, casting a 32-bit quantity to a kernel pointer?
a) Seems to rule out ever using this driver on a 64-bit system
b) It's generally suspicious and indicates that some rethinking is needed.
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + u8 *input_tdm_buffer = tdm_c->tdm_input_data;
> +
> +#else
> + u16 *input_tdm_buffer =
> + (u16 *)tdm_c->tdm_input_data;
> +
> +#endif
> + phase_rx = tdm_c->phase_rx;
> + phase_rx = PREV_PHASE(phase_rx);
> +
> + temp_rx = phase_rx * SAMPLE_DEPTH * EFF_ACTIVE_CH;
> +
> +#if defined(UCC_CACHE_SNOOPING_DISABLED)
> + flush_dcache_range((size_t) &input_tdm_buffer[temp_rx],
> + (size_t) &input_tdm_buffer[temp_rx +
> + SAMPLE_DEPTH * ACTIVE_CH]);
> +#endif
Again, is it appropriate that this behaviour be determined at compile-time?
This is very user- and packager- and distributor-unfriendly.
> + for (i = 0; i < len; i++) {
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + pcm_buffer[i] =
> + ulaw2int(input_tdm_buffer[i * EFF_ACTIVE_CH +
> + temp_rx + chn_id]);
> +#else
> + pcm_buffer[i] =
> + input_tdm_buffer[i * EFF_ACTIVE_CH + temp_rx + chn_id];
> +#endif
> +
> + }
> +
> +}
> +
> +static int ucc_tdm_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct device_node *np = ofdev->node;
> + struct resource res;
> + const unsigned int *prop;
> + u32 ucc_num, device_num, err, ret = 0;
> + struct device_node *np_tmp = NULL;
> + dma_addr_t physaddr;
> + void *tdm_buff;
> + struct ucc_tdm_info *ut_info;
> +
> + prop = of_get_property(np, "device-id", NULL);
> + ucc_num = *prop - 1;
> + if ((ucc_num < 0) || (ucc_num > 7))
> + return -ENODEV;
> +
> + ut_info = &utdm_info[ucc_num];
> + if (ut_info == NULL) {
> + printk(KERN_ERR "additional data missing\n");
> + return -ENODEV;
> + }
> + if (ut_info->ucc_busy) {
> + printk(KERN_ERR "UCC in use by another TDM driver instance\n");
> + return -EBUSY;
> + }
> +
> + ut_info->ucc_busy = 1;
> + tdm_ctrl[num_tdm_devices++] =
> + kzalloc(sizeof(struct tdm_ctrl), GFP_KERNEL);
Shouldn't this check for (num_tdm_devices > MAX_NUM_TDM_DEVICES))?
> + if (!tdm_ctrl[num_tdm_devices - 1]) {
> + printk(KERN_ERR "%s: no memory to allocate for"
> + " tdm control structure\n", __FUNCTION__);
> + num_tdm_devices--;
> + return -ENOMEM;
> + }
> + device_num = num_tdm_devices - 1;
> +
> + tdm_ctrl[device_num]->device = &ofdev->dev;
> + tdm_ctrl[device_num]->ut_info = ut_info;
> +
> + tdm_ctrl[device_num]->ut_info->uf_info.ucc_num = ucc_num;
> +
> + prop = of_get_property(np, "fsl,tdm-num", NULL);
> + if (prop == NULL) {
> + ret = -EINVAL;
> + goto get_property_error;
> + }
>
> ...
>
> +
> +#define SET_RX_SI_RAM(n, val) \
> + out_be16((u16 *)&qe_immr->sir.rx[(n)*2], (u16)(val))
> +
> +#define SET_TX_SI_RAM(n, val) \
> + out_be16((u16 *)&qe_immr->sir.tx[(n)*2], (u16)(val))
I don't think there's anything which requires that these be imlemented in
the preprocessor?
> +struct tdm_cfg {
> + u8 com_pin; /* Common receive and transmit pins
> + * 0 = separate pins
> + * 1 = common pins
> + */
> +
> + u8 fr_sync_level; /* SLx bit Frame Sync Polarity
> + * 0 = L1R/TSYNC active logic "1"
> + * 1 = L1R/TSYNC active logic "0"
> + */
> +
> + u8 clk_edge; /* CEx bit Tx Rx Clock Edge
> + * 0 = TX data on rising edge of clock
> + * RX data on falling edge
> + * 1 = TX data on falling edge of clock
> + * RX data on rising edge
> + */
> +
> + u8 fr_sync_edge; /* FEx bit Frame sync edge
> + * Determine when the sync pulses are sampled
> + * 0 = Falling edge
> + * 1 = Rising edge
> + */
> +
> + u8 rx_fr_sync_delay; /* TFSDx/RFSDx bits Frame Sync Delay
> + * 00 = no bit delay
> + * 01 = 1 bit delay
> + * 10 = 2 bit delay
> + * 11 = 3 bit delay
> + */
> +
> + u8 tx_fr_sync_delay; /* TFSDx/RFSDx bits Frame Sync Delay
> + * 00 = no bit delay
> + * 01 = 1 bit delay
> + * 10 = 2 bit delay
> + * 11 = 3 bit delay
> + */
> +
> + u8 active_num_ts; /* Number of active time slots in TDM
> + * assume same active Rx/Tx time slots
> + */
> +};
Nice commenting.
^ permalink raw reply
* RE: Problem booting Linux 2.6 on Virtex-4
From: Stephen Neuendorffer @ 2008-01-14 21:09 UTC (permalink / raw)
To: David Baird, linuxppc-embedded
In-Reply-To: <440abda90801141211m52bd0a3bk67014c6df2bf406c@mail.gmail.com>
What kernel version are you targeting? Are you using arch/powerpc or =
arch/ppc? V4 has a data cache errata, which isn't currently in mainline =
arch/powerpc.
if((mfpvr() & 0xfffff000) =3D=3D 0x20011000) {
/* PPC errata 213: only for Virtex-4 FX */
__asm__("mfccr0 0\n\t"
"oris 0,0,0x50000000@h\n\t"
"mtccr0 0"
: : : "0");
}
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org =
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of David =
Baird
> Sent: Monday, January 14, 2008 12:12 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Problem booting Linux 2.6 on Virtex-4
>=20
> On Jan 14, 2008 1:37 AM, Enno L=FCbbers <enno.luebbers@upb.de> wrote:
> > Hello David,
> >
> > Am 14.01.2008 um 06:12 schrieb David Baird:
> >
> > > I'm having trouble with getting Linux to boot farther than =
early_init.
> > > [...]
> > > So, I experimented further and discovered that different memory
> > > regions seem to be aliased on to each other every 2*32*256 bytes.
> >
> >
> > This sounds either like a wrong programming of an BRx/ORx memory
> > controller register pair (which, AFAIK, the PPC405 does not have), =
or
> > like a messed up address map in EDK. My guess is that an optimized/
> > sloppy implementation of the address decoder for some peripheral in =
an
> > EDK system could produce something like you described; or there's a
> > block RAM that's attached to a controller in the wrong way; or the
> > bank/address parameters of the DDR controller don't match the =
physical
> > setup... there's a lot that can go wrong obviously on a configurable
> > SoC.
>=20
> What has been confusing me is that I am unable to reproduce the
> problem in real mode. I can only reproduce the problem in virtual
> mode. This leads me to believe, perhaps mistakenly, that the hardware
> is implemented okay. OTOH, neither can I see anything wrong with the
> software.
>=20
> > Can you be more specific about your hardware platform? Is this a
> > reference design? What board are you using?
>=20
> I am currently testing code on the ML403 evaluation board. I used the
> Base System Builder in EDK to create the hardware design and DDR SDRAM
> is being used as the main RAM starting at address 0x00000000 and also
> with OCM BRAM mapped at the very end of the address space (so that
> 0xfffffffc can contain code to execute on startup).
>=20
> I am now trying to experiment with the hardware and see if I can find
> a hardware reference design. I will let you know what I figure out.
>=20
> -David
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Problem booting Linux 2.6 on Virtex-4
From: David Baird @ 2008-01-14 20:11 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <62D97388-4D65-4B40-A0D1-847963FF0A16@upb.de>
On Jan 14, 2008 1:37 AM, Enno L=FCbbers <enno.luebbers@upb.de> wrote:
> Hello David,
>
> Am 14.01.2008 um 06:12 schrieb David Baird:
>
> > I'm having trouble with getting Linux to boot farther than early_init.
> > [...]
> > So, I experimented further and discovered that different memory
> > regions seem to be aliased on to each other every 2*32*256 bytes.
>
>
> This sounds either like a wrong programming of an BRx/ORx memory
> controller register pair (which, AFAIK, the PPC405 does not have), or
> like a messed up address map in EDK. My guess is that an optimized/
> sloppy implementation of the address decoder for some peripheral in an
> EDK system could produce something like you described; or there's a
> block RAM that's attached to a controller in the wrong way; or the
> bank/address parameters of the DDR controller don't match the physical
> setup... there's a lot that can go wrong obviously on a configurable
> SoC.
What has been confusing me is that I am unable to reproduce the
problem in real mode. I can only reproduce the problem in virtual
mode. This leads me to believe, perhaps mistakenly, that the hardware
is implemented okay. OTOH, neither can I see anything wrong with the
software.
> Can you be more specific about your hardware platform? Is this a
> reference design? What board are you using?
I am currently testing code on the ML403 evaluation board. I used the
Base System Builder in EDK to create the hardware design and DDR SDRAM
is being used as the main RAM starting at address 0x00000000 and also
with OCM BRAM mapped at the very end of the address space (so that
0xfffffffc can contain code to execute on startup).
I am now trying to experiment with the hardware and see if I can find
a hardware reference design. I will let you know what I figure out.
-David
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-14 20:04 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801142042.56847.sr@denx.de>
Stefan Roese wrote:
> And the EBC0_BxCR & EBC0BxAP registers for the CS where the NAND is connected?
> How are they configured?
>
EBC0_B1CR d001c000
EBC0_B1AP 18003c0
Which matches the defines in include/configs/warp.h:
#define CFG_EBC_PB1AP 0x018003c0
#define CFG_EBC_PB1CR (CFG_NAND_ADDR | 0x1c000)
It also matches the defines in sequoia.h except that we are on CS1 and
the sequoia is on CS3.
Cheers,
Sean
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jean Delvare @ 2008-01-14 19:46 UTC (permalink / raw)
To: Kay Sievers; +Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, i2c
In-Reply-To: <3ae72650801141138t27666bcerd66e96f836d1ab2b@mail.gmail.com>
On Mon, 14 Jan 2008 20:38:28 +0100, Kay Sievers wrote:
> On Jan 14, 2008 6:50 PM, Jean Delvare <khali@linux-fr.org> wrote:
> > I am under the impression that modules.*map are the old way to get
> > automatic driver loading and aliases are the new way to do the same.
> > But maybe that's just me.
>
> Right, nothing on recent systems is using the map files. This patch
> should not be needed.
> The plan is to deprecate the creation of these files in depmod.
OK, great. Thanks for the info, Kay!
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Stefan Roese @ 2008-01-14 19:42 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <478B9CB6.7000408@pikatech.com>
On Monday 14 January 2008, Sean MacLennan wrote:
> Josh Boyer wrote:
> > But did you go back and verify the EBC settings were correct on your
> > board? This shouldn't be needed at all if the EBC bank settings and
> > timings are correct.
> >
> > josh
>
> In the EBC0_CFG register we set the RTC (Ready Timeout Count) to 0 and
> the sequoia uses 7. Also we set the EMS (External Master Size) to none
> and the sequoia sets it to 8 bit.
>
> This is in uboot, the dts are basically the same.
And the EBC0_BxCR & EBC0BxAP registers for the CS where the NAND is connected?
How are they configured?
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Kay Sievers @ 2008-01-14 19:38 UTC (permalink / raw)
To: Jean Delvare; +Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, i2c
In-Reply-To: <20080114185056.05b75fd1@hyperion.delvare>
On Jan 14, 2008 6:50 PM, Jean Delvare <khali@linux-fr.org> wrote:
> On Mon, 14 Jan 2008 18:08:16 +0100 (CET), Geert Uytterhoeven wrote:
> > On Mon, 14 Jan 2008, Jean Delvare wrote:
> > > I thought that the module aliases were generated by
> > > scripts/mod/modpost? As a matter of fact, I did not apply Jon's patch
> >
> > Sorry, you're right. Too early in the morning :-)
> >
> > > to module-init-tools, and "modinfo" shows me module aliases properly
> > > for i2c drivers that call MODULE_DEVICE_TABLE():
> >
> > I've just looked it up again (I had to do a similar thing for Zorro bus
> > support). Module-init-tools (depmod) also creates the modules.*map files,
> > which are used to map from device IDs to module names. I think these are used
> > by udev to load the appropriate module when a device with a specific device ID
> > pops up in sysfs.
>
> Ah, right. I see it now, there's modules.isapnpmap,
> modules.ieee1394map, modules.pcimap etc. but no modules.i2cmap.
> However, there is modules.alias which contains the i2c aliases for all
> device types (including one ieee1394 and many pci aliases) which seems
> somewhat redundant with the modules.*map files.
>
> > > $ /sbin/modinfo lm90
> > > filename: /lib/modules/2.6.24-rc7-git4/kernel/drivers/hwmon/lm90.ko
> > > author: Jean Delvare <khali@linux-fr.org>
> > > description: LM90/ADM1032 driver
> > > license: GPL
> > > vermagic: 2.6.24-rc7-git4 mod_unload
> > > depends: hwmon
> > > alias: i2c:Nlm90*
> > > alias: i2c:Nadm1032*
> > > alias: i2c:Nlm99*
> > > alias: i2c:Nlm86*
> > > alias: i2c:Nmax6657*
> > > alias: i2c:Nadt7461*
> > > alias: i2c:Nmax6680*
> > > $
> > >
> > > "modprobe i2c:Nadm1032" loads the lm90 driver as expected.
> >
> > Yes, it's also still not 100% clear to me when `i2c:Nadm1032' is used, and when
> > modules.i2cmap would be used...
>
> I am under the impression that modules.*map are the old way to get
> automatic driver loading and aliases are the new way to do the same.
> But maybe that's just me.
Right, nothing on recent systems is using the map files. This patch
should not be needed.
The plan is to deprecate the creation of these files in depmod.
Thanks,
Kay
^ permalink raw reply
* Re: I2C and CAN bus on MPC5200B device tree
From: Scott Wood @ 2008-01-14 19:04 UTC (permalink / raw)
To: Olof Johansson; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <20080114044216.GA23349@lixom.net>
On Sun, Jan 13, 2008 at 10:42:16PM -0600, Olof Johansson wrote:
> I think simple devices might have been agreed upon (but it's been a
> while since it was covered). Muxed busses probably hasn't. Either that
> or I completely missed the emails.
I posted something in one of the i2c device tree threads a while ago:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036353.html
Basically, you just have a node that is both an i2c device and an i2c
controller, and the mux driver binds to it and registers the subordinate
buses as new i2c controllers.
-Scott
^ permalink raw reply
* RE: Linux for ml310
From: Stephen Neuendorffer @ 2008-01-14 18:47 UTC (permalink / raw)
To: greenlean, linuxppc-embedded
In-Reply-To: <14808605.post@talk.nabble.com>
If you are using the secretlab.ca or git.xilinx.com trees, then you
should *not* follow the normal BSP generation process. You need to
generate the BSP in a dummy location and then copy only the
xparameters_*.h file over the appropriate one in
arch/ppc/platforms/4xx/xparameters and make menuconfig.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of greenlean
> Sent: Monday, January 14, 2008 10:42 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux for ml310
>=20
>=20
> Hi, I was reading this post and a question came to my mind.
>=20
> When I try to compile, did I have to copy the EDK driver folder to my
Xilinx
> 2.6 kernel tree and run the cow.tcl script generated by EDK?? Or this
is
> unnecesay??
>=20
>=20
>=20
>=20
> Grant Likely-2 wrote:
> >
> > On 1/9/08, Joachim Meyer <Jogi95@web.de> wrote:
> >> Hi
> >>
> >> I switched "Xilinx uartlite serieal port support" and "Support for
> >> console on Xilinxuartlite serialport" on and "8250/16550 and
compatible
> >> serial support" off, in the kernel config.
> >> Then I removed the things I added in the xparameters.h and compiled
> >> successfully.
> >> But I have yet a few Questions:
> >>
> >> - What would you recommend to use? UART-Lite or a 16550 serial
port. Can
> >> I get a console running on the RS232 Port of the Board with both
> >> possibilities?
> >
> > if you don't need to change the baud rate at runtime then use the
> > uartlite.
> >
> > Console works on both.
> >
> >>
> >> - Can you recommend anything for my next steps to get an running
linux
> >> (rootfs usw.)? So far I oriented myself on the Klingauf page, but I
think
> >> it is perhaps not the best one because its too old and some things
will
> >> probably not work the way he did it anymore.
> >
> > Use either ELDK or buildroot. Personally, I'd like to be using
> > OpenEmbedded, but I haven't been successful with that yet.
> >
> > Cheers,
> > g.
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>=20
> --
> View this message in context:
http://www.nabble.com/Linux-for-ml310-tp14675554p14808605.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Linux for ml310
From: greenlean @ 2008-01-14 18:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40801091410k5d83f124ve009c96683f78ad2@mail.gmail.com>
Hi, I was reading this post and a question came to my mind.
When I try to compile, did I have to copy the EDK driver folder to my Xilinx
2.6 kernel tree and run the cow.tcl script generated by EDK?? Or this is
unnecesay??
Grant Likely-2 wrote:
>
> On 1/9/08, Joachim Meyer <Jogi95@web.de> wrote:
>> Hi
>>
>> I switched "Xilinx uartlite serieal port support" and "Support for
>> console on Xilinxuartlite serialport" on and "8250/16550 and compatible
>> serial support" off, in the kernel config.
>> Then I removed the things I added in the xparameters.h and compiled
>> successfully.
>> But I have yet a few Questions:
>>
>> - What would you recommend to use? UART-Lite or a 16550 serial port. Can
>> I get a console running on the RS232 Port of the Board with both
>> possibilities?
>
> if you don't need to change the baud rate at runtime then use the
> uartlite.
>
> Console works on both.
>
>>
>> - Can you recommend anything for my next steps to get an running linux
>> (rootfs usw.)? So far I oriented myself on the Klingauf page, but I think
>> it is perhaps not the best one because its too old and some things will
>> probably not work the way he did it anymore.
>
> Use either ELDK or buildroot. Personally, I'd like to be using
> OpenEmbedded, but I haven't been successful with that yet.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Linux-for-ml310-tp14675554p14808605.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jean Delvare @ 2008-01-14 17:50 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-kernel, i2c
In-Reply-To: <Pine.LNX.4.64.0801141752450.3058@vixen.sonytel.be>
On Mon, 14 Jan 2008 18:08:16 +0100 (CET), Geert Uytterhoeven wrote:
> On Mon, 14 Jan 2008, Jean Delvare wrote:
> > I thought that the module aliases were generated by
> > scripts/mod/modpost? As a matter of fact, I did not apply Jon's patch
>
> Sorry, you're right. Too early in the morning :-)
>
> > to module-init-tools, and "modinfo" shows me module aliases properly
> > for i2c drivers that call MODULE_DEVICE_TABLE():
>
> I've just looked it up again (I had to do a similar thing for Zorro bus
> support). Module-init-tools (depmod) also creates the modules.*map files,
> which are used to map from device IDs to module names. I think these are used
> by udev to load the appropriate module when a device with a specific device ID
> pops up in sysfs.
Ah, right. I see it now, there's modules.isapnpmap,
modules.ieee1394map, modules.pcimap etc. but no modules.i2cmap.
However, there is modules.alias which contains the i2c aliases for all
device types (including one ieee1394 and many pci aliases) which seems
somewhat redundant with the modules.*map files.
> > $ /sbin/modinfo lm90
> > filename: /lib/modules/2.6.24-rc7-git4/kernel/drivers/hwmon/lm90.ko
> > author: Jean Delvare <khali@linux-fr.org>
> > description: LM90/ADM1032 driver
> > license: GPL
> > vermagic: 2.6.24-rc7-git4 mod_unload
> > depends: hwmon
> > alias: i2c:Nlm90*
> > alias: i2c:Nadm1032*
> > alias: i2c:Nlm99*
> > alias: i2c:Nlm86*
> > alias: i2c:Nmax6657*
> > alias: i2c:Nadt7461*
> > alias: i2c:Nmax6680*
> > $
> >
> > "modprobe i2c:Nadm1032" loads the lm90 driver as expected.
>
> Yes, it's also still not 100% clear to me when `i2c:Nadm1032' is used, and when
> modules.i2cmap would be used...
I am under the impression that modules.*map are the old way to get
automatic driver loading and aliases are the new way to do the same.
But maybe that's just me.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-14 17:32 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080114024432.1dcba2f7@vader.jdub.homelinux.org>
Josh Boyer wrote:
>
> But did you go back and verify the EBC settings were correct on your
> board? This shouldn't be needed at all if the EBC bank settings and
> timings are correct.
>
> josh
>
In the EBC0_CFG register we set the RTC (Ready Timeout Count) to 0 and
the sequoia uses 7. Also we set the EMS (External Master Size) to none
and the sequoia sets it to 8 bit.
This is in uboot, the dts are basically the same.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 1/5] Warp Base Platform
From: Sean MacLennan @ 2008-01-14 17:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080113113545.f08d9199.sfr@canb.auug.org.au>
This should have all of Stephen Rothwell's recommended changes.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x && !CPM2 && !8xx && !PPC_83xx \
&& !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool "PIKA Warp"
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
+ Telephony Developers" link for more information.
+
#config LUAN
# bool "Luan"
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..7aaee9d 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,5 @@ obj-$(CONFIG_BAMBOO) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
+#obj-$(CONFIG_WARP) += warp-nand.o
diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
new file mode 100644
index 0000000..0053958
--- /dev/null
+++ b/arch/powerpc/platforms/44x/warp-nand.c
@@ -0,0 +1,92 @@
+/*
+ * PIKA Warp(tm) NAND flash specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ */
+
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/ndfc.h>
+
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD0000000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+ .name = "nand",
+ .offset = 0,
+ .size = MTDPART_SIZ_FULL,
+ }
+};
+
+struct ndfc_controller_settings warp_ndfc_settings = {
+ .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
+ .ndfc_erpn = 0,
+};
+
+static struct ndfc_chip_settings warp_chip0_settings = {
+ .bank_settings = 0x80002222,
+};
+
+struct platform_nand_ctrl warp_nand_ctrl = {
+ .priv = &warp_ndfc_settings,
+};
+
+static struct platform_device warp_ndfc_device = {
+ .name = "ndfc-nand",
+ .id = 0,
+ .dev = {
+ .platform_data = &warp_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+};
+
+static struct nand_ecclayout nand_oob_16 = {
+ .eccbytes = 3,
+ .eccpos = { 0, 1, 2, 3, 6, 7 },
+ .oobfree = { {.offset = 8, .length = 16} }
+};
+
+static struct platform_nand_chip warp_nand_chip0 = {
+ .nr_chips = 1,
+ .chip_offset = CS_NAND_0,
+ .nr_partitions = ARRAY_SIZE(nand_parts),
+ .partitions = nand_parts,
+ .chip_delay = 50,
+ .ecclayout = &nand_oob_16,
+ .priv = &warp_chip0_settings,
+};
+
+static struct platform_device warp_nand_device = {
+ .name = "ndfc-chip",
+ .id = 0,
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+ .dev = {
+ .platform_data = &warp_nand_chip0,
+ .parent = &warp_ndfc_device.dev,
+ }
+};
+
+static int warp_setup_nand_flash(void)
+{
+ platform_device_register(&warp_ndfc_device);
+ platform_device_register(&warp_nand_device);
+
+ return 0;
+}
+device_initcall(warp_setup_nand_flash);
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
new file mode 100644
index 0000000..2c8c064
--- /dev/null
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -0,0 +1,186 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
+ * 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/init.h>
+#include <linux/of_platform.h>
+#include <linux/kthread.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+
+#include "44x.h"
+
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "pika,warp");
+}
+
+define_machine(warp) {
+ .name = "Warp",
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+
+#define LED_GREEN (0x80000000 >> 0)
+#define LED_RED (0x80000000 >> 1)
+
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void __iomem *gpio_base = NULL;
+ unsigned leds;
+
+ if (gpio_base == NULL) {
+ struct device_node *np;
+
+ /* Power LEDS are on the second GPIO controller */
+ np = of_find_compatible_node(NULL, NULL, "ibm,gpio-440EP");
+ if (np)
+ np = of_find_compatible_node(np, NULL, "ibm,gpio-440EP");
+ if (np == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find gpio\n");
+ return;
+ }
+
+ gpio_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (gpio_base == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map gpio");
+ return;
+ }
+ }
+
+ leds = in_be32(gpio_base);
+
+ switch (green) {
+ case 0: leds &= ~LED_GREEN; break;
+ case 1: leds |= LED_GREEN; break;
+ }
+ switch (red) {
+ case 0: leds &= ~LED_RED; break;
+ case 1: leds |= LED_RED; break;
+ }
+
+ out_be32(gpio_base, leds);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+#ifdef CONFIG_SENSORS_AD7414
+static int pika_dtm_thread(void __iomem *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while (!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ return 0;
+}
+
+static int pika_dtm_start(void __iomem *fpga)
+{
+ struct task_struct *dtm_thread;
+
+ dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
+ if (IS_ERR(dtm_thread)) {
+ printk(KERN_ERR __FILE__ ": Unable to start PIKA DTM thread\n");
+ return PTR_ERR(dtm_thread);
+ }
+
+ return 0;
+}
+#else
+static int pika_dtm_start(void __iomem *fpga)
+{
+ printk(KERN_WARNING "PIKA DTM disabled\n");
+ return 0;
+}
+#endif
+
+
+static int __devinit warp_fpga_init(void)
+{
+ struct device_node *np;
+ struct resource res;
+ void __iomem *fpga;
+ int irq;
+
+ np = of_find_compatible_node(NULL, NULL, "pika,fpga");
+ if (np == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find fpga\n");
+ return -ENOENT;
+ }
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ of_node_put(np);
+ printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
+ return -EBUSY;
+ }
+
+ /* We do not call of_iomap here since it would map in the entire
+ * fpga space, which is over 8k.
+ */
+ if (of_address_to_resource(np, 0, &res)) {
+ of_node_put(np);
+ printk(KERN_ERR __FILE__ ": Unable to get FPGA address\n");
+ return -ENOENT;
+ }
+ of_node_put(np);
+
+ fpga = ioremap(res.start, 0x24);
+ if (fpga == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map FPGA\n");
+ return -ENOENT;
+ }
+
+ if (pika_dtm_start(fpga)) {
+ iounmap(fpga);
+ return -ENOENT;
+ }
+
+ /* SAM TODO: Start the watchdog here */
+
+ return 0;
+}
+device_initcall(warp_fpga_init);
^ permalink raw reply related
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Geert Uytterhoeven @ 2008-01-14 17:08 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, linux-kernel, i2c
In-Reply-To: <20080114173835.5fe907db@hyperion.delvare>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2475 bytes --]
On Mon, 14 Jan 2008, Jean Delvare wrote:
> On Mon, 14 Jan 2008 11:57:52 +0100 (CET), Geert Uytterhoeven wrote:
> > On Sun, 13 Jan 2008, Jon Smirl wrote:
> > > I don't know exactly what those modules tables are used for. I just
> > > copied what the other subsystems do. Maybe they are used when you make
> > > an initrd to know which drivers to copy into the image.
> >
> > Module-init-tools needs those table to create module aliases in the *.ko
> > files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
> > on the device IDs when the devices appear in sysfs.
>
> I thought that the module aliases were generated by
> scripts/mod/modpost? As a matter of fact, I did not apply Jon's patch
Sorry, you're right. Too early in the morning :-)
> to module-init-tools, and "modinfo" shows me module aliases properly
> for i2c drivers that call MODULE_DEVICE_TABLE():
I've just looked it up again (I had to do a similar thing for Zorro bus
support). Module-init-tools (depmod) also creates the modules.*map files,
which are used to map from device IDs to module names. I think these are used
by udev to load the appropriate module when a device with a specific device ID
pops up in sysfs.
> $ /sbin/modinfo lm90
> filename: /lib/modules/2.6.24-rc7-git4/kernel/drivers/hwmon/lm90.ko
> author: Jean Delvare <khali@linux-fr.org>
> description: LM90/ADM1032 driver
> license: GPL
> vermagic: 2.6.24-rc7-git4 mod_unload
> depends: hwmon
> alias: i2c:Nlm90*
> alias: i2c:Nadm1032*
> alias: i2c:Nlm99*
> alias: i2c:Nlm86*
> alias: i2c:Nmax6657*
> alias: i2c:Nadt7461*
> alias: i2c:Nmax6680*
> $
>
> "modprobe i2c:Nadm1032" loads the lm90 driver as expected.
Yes, it's also still not 100% clear to me when `i2c:Nadm1032' is used, and when
modules.i2cmap would be used...
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: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jean Delvare @ 2008-01-14 16:38 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-kernel, i2c
In-Reply-To: <Pine.LNX.4.64.0801141154420.3058@vixen.sonytel.be>
Hi Geert,
On Mon, 14 Jan 2008 11:57:52 +0100 (CET), Geert Uytterhoeven wrote:
> On Sun, 13 Jan 2008, Jon Smirl wrote:
> > I don't know exactly what those modules tables are used for. I just
> > copied what the other subsystems do. Maybe they are used when you make
> > an initrd to know which drivers to copy into the image.
>
> Module-init-tools needs those table to create module aliases in the *.ko
> files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
> on the device IDs when the devices appear in sysfs.
I thought that the module aliases were generated by
scripts/mod/modpost? As a matter of fact, I did not apply Jon's patch
to module-init-tools, and "modinfo" shows me module aliases properly
for i2c drivers that call MODULE_DEVICE_TABLE():
$ /sbin/modinfo lm90
filename: /lib/modules/2.6.24-rc7-git4/kernel/drivers/hwmon/lm90.ko
author: Jean Delvare <khali@linux-fr.org>
description: LM90/ADM1032 driver
license: GPL
vermagic: 2.6.24-rc7-git4 mod_unload
depends: hwmon
alias: i2c:Nlm90*
alias: i2c:Nadm1032*
alias: i2c:Nlm99*
alias: i2c:Nlm86*
alias: i2c:Nmax6657*
alias: i2c:Nadt7461*
alias: i2c:Nmax6680*
$
"modprobe i2c:Nadm1032" loads the lm90 driver as expected.
> That's the generic part. How this applies to i2c devices on platforms
> without Open Firmware device trees is another question. I guess that's
> where Jean gets confused (i2c_device_id got _removed_ last year,
> because it didn't make sense (at the time?)).
The way it was implemented back then did not make sense. As it was not
clear whether we would implement something different or nothing at all,
I decided to plain remove it. Now that it seems that we want to
implement it differently, I'm looking into it again.
--
Jean Delvare
^ permalink raw reply
* [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: Scott Wood @ 2008-01-14 16:30 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
ft_get_next_node() enumerates children of a given node.
ft_get_next_prop() enumerates propreties of a given node.
ft_getprop_offset() is like ft_getprop(), but takes a property offset rather
than a node offset and property name; it is primarily intended for use
with ft_get_next_prop().
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
libfdt/fdt_ro.c | 134 +++++++++++++++++++++++++++++++++++++++++++++++++
libfdt/fdt_strerror.c | 1 +
libfdt/libfdt.h | 123 ++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 251 insertions(+), 7 deletions(-)
diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c
index 12a37d5..27c943a 100644
--- a/libfdt/fdt_ro.c
+++ b/libfdt/fdt_ro.c
@@ -293,6 +293,51 @@ const void *fdt_getprop(const void *fdt, int nodeoffset,
return prop->data;
}
+const void *fdt_getprop_offset(const void *fdt, int propoffset,
+ const char **name, int *lenp)
+{
+ uint32_t tag;
+ const struct fdt_property *prop;
+ int namestroff;
+ int err, len;
+
+ err = fdt_check_header(fdt);
+ if (err)
+ goto fail;
+
+ tag = fdt_next_tag(fdt,propoffset, NULL);
+ if (tag != FDT_PROP) {
+ err = -FDT_ERR_BADOFFSET;
+ goto fail;
+ }
+
+ err = -FDT_ERR_BADSTRUCTURE;
+ prop = fdt_offset_ptr(fdt, propoffset, sizeof(*prop));
+ if (!prop)
+ goto fail;
+
+ if (name) {
+ namestroff = fdt32_to_cpu(prop->nameoff);
+ *name = fdt_string(fdt, namestroff);
+ }
+
+ len = fdt32_to_cpu(prop->len);
+ if (lenp)
+ *lenp = len;
+
+ prop = fdt_offset_ptr(fdt, propoffset, sizeof(*prop) + len);
+ if (!prop)
+ goto fail;
+
+ return prop->data;
+
+fail:
+ if (lenp)
+ *lenp = err;
+
+ return NULL;
+}
+
uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
{
const uint32_t *php;
@@ -581,3 +626,92 @@ int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
return -FDT_ERR_NOTFOUND;
}
+
+int fdt_get_next_node(const void *fdt, int startoffset,
+ int *depth, int recursive)
+{
+ uint32_t tag;
+ int offset, nextoffset;
+
+ CHECK_HEADER(fdt);
+
+ if (startoffset >= 0) {
+ tag = fdt_next_tag(fdt, startoffset, &nextoffset);
+ if (tag != FDT_BEGIN_NODE)
+ return -FDT_ERR_BADOFFSET;
+ } else {
+ nextoffset = 0;
+ }
+
+ do {
+ offset = nextoffset;
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+ switch (tag) {
+ case FDT_BEGIN_NODE:
+ if ((*depth)++ == 0 || recursive) {
+ return offset;
+ }
+
+ break;
+
+ case FDT_END_NODE:
+ if (--*depth < 0)
+ return -FDT_ERR_NOTFOUND;
+
+ break;
+
+ case FDT_PROP:
+ case FDT_END:
+ case FDT_NOP:
+ break;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (tag != FDT_END);
+
+ if (depth != 0)
+ return -FDT_ERR_BADSTRUCTURE;
+
+ return -FDT_ERR_NOTFOUND;
+}
+
+int fdt_get_next_prop(const void *fdt, int startoffset)
+{
+ uint32_t tag;
+ int offset, nextoffset;
+
+ CHECK_HEADER(fdt);
+
+ if (startoffset >= 0) {
+ tag = fdt_next_tag(fdt, startoffset, &nextoffset);
+ if (tag != FDT_BEGIN_NODE && tag != FDT_PROP)
+ return -FDT_ERR_BADOFFSET;
+ } else {
+ nextoffset = 0;
+ }
+
+ do {
+ offset = nextoffset;
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+ switch (tag) {
+ case FDT_BEGIN_NODE:
+ case FDT_END_NODE:
+ return -FDT_ERR_NOTFOUND;
+
+ case FDT_PROP:
+ return offset;
+
+ case FDT_END:
+ case FDT_NOP:
+ break;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (tag != FDT_END);
+
+ return -FDT_ERR_BADSTRUCTURE;
+}
diff --git a/libfdt/fdt_strerror.c b/libfdt/fdt_strerror.c
index f9d32ef..4e87550 100644
--- a/libfdt/fdt_strerror.c
+++ b/libfdt/fdt_strerror.c
@@ -70,6 +70,7 @@ static struct errtabent errtable[] = {
ERRTABENT(FDT_ERR_BADOFFSET),
ERRTABENT(FDT_ERR_BADPATH),
ERRTABENT(FDT_ERR_BADSTATE),
+ ERRTABENT(FDT_ERR_BADDEPTH),
ERRTABENT(FDT_ERR_TRUNCATED),
ERRTABENT(FDT_ERR_BADMAGIC),
diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index d053689..6c5d4a9 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -85,25 +85,28 @@
/* FDT_ERR_BADSTATE: Function was passed an incomplete device
* tree created by the sequential-write functions, which is
* not sufficiently complete for the requested operation. */
+#define FDT_ERR_BADDEPTH 8
+ /* FDT_ERR_BADDEPTH: Function was passed a negative
+ * (or otherwise invalid) depth. */
/* Error codes: codes for bad device tree blobs */
-#define FDT_ERR_TRUNCATED 8
+#define FDT_ERR_TRUNCATED 9
/* FDT_ERR_TRUNCATED: Structure block of the given device tree
* ends without an FDT_END tag. */
-#define FDT_ERR_BADMAGIC 9
+#define FDT_ERR_BADMAGIC 10
/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
* device tree at all - it is missing the flattened device
* tree magic number. */
-#define FDT_ERR_BADVERSION 10
+#define FDT_ERR_BADVERSION 11
/* FDT_ERR_BADVERSION: Given device tree has a version which
* can't be handled by the requested operation. For
* read-write functions, this may mean that fdt_open_into() is
* required to convert the tree to the expected version. */
-#define FDT_ERR_BADSTRUCTURE 11
+#define FDT_ERR_BADSTRUCTURE 12
/* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt
* structure block or other serious error (e.g. misnested
* nodes, or subnodes preceding properties). */
-#define FDT_ERR_BADLAYOUT 12
+#define FDT_ERR_BADLAYOUT 13
/* FDT_ERR_BADLAYOUT: For read-write functions, the given
* device tree has it's sub-blocks in an order that the
* function can't handle (memory reserve map, then structure,
@@ -111,12 +114,12 @@
* into a form suitable for the read-write operations. */
/* "Can't happen" error indicating a bug in libfdt */
-#define FDT_ERR_INTERNAL 13
+#define FDT_ERR_INTERNAL 14
/* FDT_ERR_INTERNAL: libfdt has failed an internal assertion.
* Should never be returned, if it is, it indicates a bug in
* libfdt itself. */
-#define FDT_ERR_MAX 13
+#define FDT_ERR_MAX 14
/**********************************************************************/
/* Low-level functions (you probably don't need these) */
@@ -409,6 +412,41 @@ static inline void *fdt_getprop_w(void *fdt, int nodeoffset,
}
/**
+ * fdt_getprop_offset - retrieve the value of a given property by offset
+ * @fdt: pointer to the device tree blob
+ * @propoffset: offset of the property to read
+ * @name: pointer to a character pointer (will be overwritten) or NULL
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * fdt_getprop() retrieves a pointer to the value of the property
+ * named 'name' of the node at offset nodeoffset (this will be a
+ * pointer to within the device blob itself, not a copy of the value).
+ * If lenp is non-NULL, the length of the property value also
+ * returned, in the integer pointed to by lenp.
+ *
+ * returns:
+ * pointer to the property's value
+ * if lenp is non-NULL, *lenp contains the length of the property
+ * value (>=0)
+ * NULL, on error
+ * if lenp is non-NULL, *lenp contains an error code (<0):
+ * -FDT_ERR_NOTFOUND, node does not have named property
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
+const void *fdt_getprop_offset(const void *fdt, int propoffset,
+ const char **name, int *lenp);
+static inline void *fdt_getprop_offset_w(void *fdt, int propoffset,
+ const char **name, int *lenp)
+{
+ return (void *)fdt_getprop_offset(fdt, propoffset, name, lenp);
+}
+
+/**
* fdt_get_phandle - retreive the phandle of a given node
* @fdt: pointer to the device tree blob
* @nodeoffset: structure block offset of the node
@@ -651,6 +689,77 @@ int fdt_node_check_compatible(const void *fdt, int nodeoffset,
int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
const char *compatible);
+/**
+ * fdt_get_next_node - enumerate children of a node
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ * @depth: depth of the node, should be zero upon first call
+ * @recursive: only find immediate children if zero
+ *
+ * fdt_get_next_node() returns the offset of the first node after
+ * startoffset, until depth returns to zero.
+ *
+ * To iterate through all children, the following idiom can be used:
+ * depth = 0;
+ * offset = parent node offset;
+ * while (1) {
+ * offset = fdt_get_next_node(fdt, offset, &depth, recursive);
+ * if (offset < 0)
+ * break;
+ *
+ * // other code here
+ * }
+ *
+ * To find all the children of the root node, set the initial
+ * offset to zero. To find all nodes *including* the root
+ * node, set the initial offset and depth to -1.
+ *
+ * returns:
+ * structure block offset of the located node (>= 0, >startoffset),
+ * on success
+ * -FDT_ERR_NOTFOUND, no more child nodes exist after startoffset
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADDEPTH, standard meanings
+ */
+int fdt_get_next_node(const void *fdt, int startoffset,
+ int *depth, int recursive);
+
+/**
+ * fdt_get_next_prop - enumerate properties of a node
+ * @fdt: pointer to the device tree blob
+ * @startoffset: only find nodes after this offset
+ *
+ * fdt_get_next_prop() returns the offset of the first property after
+ * startoffset.
+ *
+ * To iterate through all properties, the following idiom can be used:
+ * offset = node offset;
+ * while (1) {
+ * offset = fdt_get_next_prop(fdt, offset);
+ * if (offset < 0)
+ * break;
+ *
+ * // other code here
+ * }
+ *
+ * returns:
+ * structure block offset of the located property (>= 0, >startoffset),
+ * on success
+ * -FDT_ERR_NOTFOUND, no more properties exist in the current node
+ * after startoffset
+ * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
+ * or a PROP tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE, standard meanings
+ */
+int fdt_get_next_prop(const void *fdt, int startoffset);
+
/**********************************************************************/
/* Write-in-place functions */
/**********************************************************************/
--
1.5.3
^ permalink raw reply related
* [PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
From: Scott Wood @ 2008-01-14 16:29 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The reg property in fsl soc nodes should be removed.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/fsl_soc.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..7502e03 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -54,10 +54,18 @@ phys_addr_t get_immrbase(void)
soc = of_find_node_by_type(NULL, "soc");
if (soc) {
int size;
- const void *prop = of_get_property(soc, "reg", &size);
+ u32 naddr;
+ const u32 *prop = of_get_property(soc, "#address-cells", &size);
+
+ if (prop && size == 4)
+ naddr = *prop;
+ else
+ naddr = 2;
+
+ prop = of_get_property(soc, "ranges", &size);
+ if (prop && size == 12)
+ immrbase = of_translate_address(soc, prop + naddr);
- if (prop)
- immrbase = of_translate_address(soc, prop);
of_node_put(soc);
}
--
1.5.3
^ permalink raw reply related
* Re: Quick Engine Support on Kernel 2.4
From: Timur Tabi @ 2008-01-14 15:59 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-dev
In-Reply-To: <5c9cd53b0801111521v25d0c1dt21ee59373826298@mail.gmail.com>
mike zheng wrote:
> Is there any BSP on Linux Kernel 2.4 support Quick Engine of MPC8568?
> If not, which BSP shall I start the porting? The BSP(on Kernel2.6) of
> MPC8568MDS from Freescale supports CPM2, but not QE. What the
> difference between CPM2 and QE?
Think of the QE as CPM3.
"Supporting the QE" means many things. The 2.6 kernel has core support for the
QE as well as support for several QE devices. You'll need to be more specific.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Scott Wood @ 2008-01-14 15:28 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-dev
In-Reply-To: <1200234372.3990.24.camel@neuromancer.mindspace>
On Sun, Jan 13, 2008 at 02:26:12PM +0000, Bryan O'Donoghue wrote:
> I've applied your code against Linus' git v2.6.26-rc7 as at today.
> I have to apply
It should apply against paulus's tree.
> make adder87x-uboot_defconfig
>
> make uImage
make zImage, not uImage.
> cp arch/powerpc/boot/uImage /tftpboot - which is my tftpd root
> directory.
Use cuImage.8xx, not uImage.
> In U-Boot then.
>
> => tftpboot 0x400000 uImage
> => bootm 0x400000
0x400000 is where u-boot is going to want to relocate the image to, so
loading the uImage there may not work.
> Which doesn't boot.
>
> Attaching a BDI2000 to the target board I see that the kernel is
> panicing somewhere around line 104 of arch/powerpc/kernel/prom.c in
> of_scan_flat_dt - presumably because the kernel cannot find an
> OpenFirmware tree..
Yes, a uImage target will be expecting to be handed a device tree. The
cuImage target has a device tree embedded and accepts the old-style bd_t.
> I admit not understanding everything I should about where the output
> of .dts & dtc "go" with respect to booting Linux.... but, didn't want to
> ask on the list - lest I display a "lack of knowledge" ...
Nothing wrong with asking... doing so on the list just means a larger
pool of people to respond, and that others with the same question can see
the answer.
> /* pass open firmware flat tree */
> #define CONFIG_OF_LIBFDT 1
> #undef CONFIG_OF_FLAT_TREE
> #define CONFIG_OF_BOARD_SETUP 1
> #define CONFIG_OF_HAS_BD_T 1
> #define CONFIG_OF_HAS_UBOOT_ENV 1
>
> #define OF_CPU "PowerPC,875 at 0"
> #define OF_SOC "soc875 at ff000000"
> #define OF_TBCLK (bd->bi_busfreq / 4)
You'll probably need some 8xx-specific code if you want to go this route.
You'd also need to change the bootm command line to the three-argument
version, with the third argument being the address of the device tree
blob (the second argument can be - if there's no initrd).
If you're not comfortable with the device tree stuff, I recommend just
using cuImage for now.
-Scott
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Linas Vepstas @ 2008-01-14 15:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: lkessler, linuxppc-dev, Nathan Lynch, mahuja, strosake
In-Reply-To: <20080114052402.GA23786@lixom.net>
On 13/01/2008, Olof Johansson <olof@lixom.net> wrote:
>
> How do you expect to have it in full production if you don't have all
> resources available for it? It's not until the dump has finished that you
> can return all memory to the production environment and use it.
With the PHYP dump, each chunk of RAM is returned for
general use immediately after being dumped; so its not
an all-or-nothing proposition. Production systems don't
often hit 100% RAM use right out of the gate, they often
take hours or days to get there, so again, there should
be time to dump.
> This can very easily be argued in both direction, with no clear winner:
> If the crash is stress-induced (say a slashdotted website), for those
> cases it seems more rational to take the time, collect _good data_ even
> if it takes a little longer, and then go back into production. Especially
> if the alternative is to go back into production immediately, collect
> about half of the data, and then crash again. Rinse and repeat.
Again, the mode of operation for the phyp dump is that you'll
always have all of the data from the *first* crash, even if there
are multiple crashes. That's because the the as-yet undumped
RAM is not put back into production.
> really surprises me that there's no way to reset a device through PHYP
> though. Seems like such a fundamental feature.
I don't know who said that; that's not right. The EEH function
certainly does allow you to halt/restart PCI traffic to a particular
device and also to reset the device. So, yes, the pSeries
kexec code should call into the eeh subsystem to rationalize
the device state.
> I think people are overly optimistic if they think it'll be possible
> to do all of this reliably (as in with consistent performance) without
> a second reboot though.
The NUMA issues do concern me. But then, the whole virtualized,
fractional-cpu, tickless operation stuff sounds like a performance
tuning nightmare to begin with.
> At least without similar amounts of work being
> done as it would have taken to fix kdump's reliability in the first place.
:-)
> Speaking of reboots. PHYP isn't known for being quick at rebooting a
> partition, it used to take in the order of minutes even on a small
> machine. Has that been fixed?
Dunno. Probably not.
> If not, the avoiding an extra reboot
> argument hardly seems like a benefit versus kdump+kexec, which reboots
> nearly instantly and without involvement from PHYP.
OK, let me tell you what I'm up against right now.
I'm dealing with sporadic corruption on my home box.
About a month ago, I bought a whizzy ASUS M2NE
motherboard & an AMD64 2-core cpu, and two sticks
of RAM, 1GB per stick. I have one new hard drive,
SATA, and one old hard drive, from my old machine,
the PATA. The two disks are mirrored in a RAID-1
config. Running Ubuntu.
During install/upgrade a month ago, I noticed some of
the install files seemed to have gotten corrupted, but
that downloading them again got me a working version.
This put a serious frown on my face: maybe a bad ethernet
card or connection !?
Two weeks ago, gcc stopped working one morning, although
it worked fine the night before. I'd done nothing in the interim
but sleep. Reinstalling it made it work again. Yesterday,
something else stopped working. I found the offending
library, I compared file checksums against a known-good
version, and they were off. (!!!) Disk corruption?
Then apt-get stopped working. The /var/lib/dpkg/status file
had randomly corrupted single bytes. Its ascii, I hand
repaired it; it had maybe 10 bad bytes out of 2MB total size.
I installed tripwire. Between the first run of tripwire, and the
second, less than an hour later, it reported several dozen
files have changed checksums. Manual inspection of some
of these files against known-good versions show that, at least
this morning, that's no longer the case.
System hasn't crashed in a month, since first boot. So
what's going on? Is it possible that one of the two disks
is serving up bad data, which explains the funny checksum
behaviour? Or maybe its bad RAM, so that a fresh disk
read shows good data? If its bad ram, why doesn't the
system crash? I forced fsck last night, fsck came back
spotless.
So ... moral of the story: If phyp is doing some sort of
hardware checks and validation, that's great. I wish I could
afford a pSeries system for my home computer, because
my impression is that they are very stable, and don't do
things like data corruption. I'm such a friggin cheapskate
that I can't bear to spend many thousands instead of many
hundreds of dollars. However, I will trade a longer boot
for the dream of higher reliability.
--linas
^ permalink raw reply
* Re: I2C and CAN bus on MPC5200B device tree
From: Grant Likely @ 2008-01-14 14:28 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded, ppc-dev
In-Reply-To: <478B18D9.6020201@grandegger.com>
On 1/14/08, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Grant Likely wrote:
> > On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
> >> Hi guys,
> >>
> >> I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> >> for it) and have not found any CAN bus documentation for device trees.
> >>
> >> I want to update the firmware tree to add these but, am basically looking
> >> for those docs, or someone to go over a few points.. is there some kind of
> >> tree standard I should be looking at, or some patch I missed which has
> >> a driver which implements something that looks at a compatible tree?
> >
> > I think some consensus has been achieved for describing i2c busses and
> > their attached devices, but I don't think booting-without-of.txt has
> > been updated with the details yet. I need to look into that more.
> >
> > I don't think anyone has tackled CAN. Best bet is to draft a tree in
> > the way you think it should be described and post it to the list.
> > That will give a starting point for us to discuss it and come to
> > consensus.
>
> For MSCAN on the MPC5200 we currently have:
>
> mscan@900 {
> device_type = "mscan";
> compatible = "mpc5200b-mscan","mpc5200-mscan";
> cell-index = <0>;
> interrupts = <2 11 0>;
> interrupt-parent = <&mpc5200_pic>;
> reg = <900 80>;
> };
>
> mscan@980 {
> device_type = "mscan";
> compatible = "mpc5200b-mscan","mpc5200-mscan";
> cell-index = <1>;
> interrupts = <2 12 0>;
> interrupt-parent = <&mpc5200_pic>;
> reg = <980 80>;
> };
>
> The only thing missing is a property defining the routing of the CAN
> signals, CAN 1 on I2C1 pins or CAN 2 on TMR01 pins. I think it does not
> make sense to describe CAN devices on the CAN bus like for I2C.
I don't think that pin routing matters much for the device tree.
Ideally, firmware should be responsible for port_config, and as long
as it is already configured, the CAN device can find it's devices.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jon Smirl @ 2008-01-14 14:25 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Jean Delvare, linuxppc-dev, i2c, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0801141154420.3058@vixen.sonytel.be>
On 1/14/08, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Sun, 13 Jan 2008, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
> > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > > > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > > > > > Follow on to: "Series to add device tree naming to i2c"
> > > > > > > > Teach module-init-tools about the i2c subsystem.
> > > > > > >
> > > > > > > Can you please explain what this patch does and why it is nee=
ded?
> > > > > >
> > > > > > It generates the entries needed for the user space module tools=
to
> > > > > > work with the aliases. For example modprobe/depmod. It is a sta=
ndard
> > > > > > part of the kernel module system.
> > > > >
> > > > > What entries, where? What can you do after applying your patch th=
at you
> > > > > couldn't do before?
> > > >
> > > > The drivers you are testing with don't depend on other drivers.
> > >
> > > They do. I'm testing with the lm90 driver, which depends on the hwmon
> > > driver. Both load automatically when the underlying i2c-parport drive=
r
> > > instantiate an "adm1032" i2c device.
> >
> > I don't know exactly what those modules tables are used for. I just
> > copied what the other subsystems do. Maybe they are used when you make
> > an initrd to know which drivers to copy into the image.
>
> Module-init-tools needs those table to create module aliases in the *.ko
> files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
> on the device IDs when the devices appear in sysfs.
>
> That's the generic part. How this applies to i2c devices on platforms
> without Open Firmware device trees is another question. I guess that's
> where Jean gets confused (i2c_device_id got _removed_ last year,
> because it didn't make sense (at the time?)).
Last year i2c modules weren't dynamically loadable so it wasn't needed.
>
> With kind regards,
>
> Geert Uytterhoeven
> Software Architect
>
> Sony Network and Software Technology Center Europe
> The Corporate Village =B7 Da Vincilaan 7-D1 =B7 B-1935 Zaventem =B7 Belgi=
um
>
> 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 =B7 B-1840 Londerzeel =B7 Belgium
> VAT BE 0413.825.160 =B7 RPR Brussels
> Fortis Bank Zaventem =B7 Swift GEBABEBB08A =B7 IBAN BE39001382358619
--=20
Jon Smirl
jonsmirl@gmail.com
^ 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