* signals handling in the kernel
From: Mirek23 @ 2007-08-07 11:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I would like to send signals from the interrupt handler routine (in the
kernel) to the user application (in user space).
I have googled on that net and I have found that it could be done with the
function:
kill_proc_info.
When I have compiled my module which uses the kill_proc_info I have got and
error messge:
WARNING: "kill_proc_info" [drivers/char/xilinx_gpio/xilinx_gpio.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
The kill_proc_info source code is in the kernel/signal.c file. Due to
unknown reason the kill_proc_info symbol is not exported with EXPORT_SYMBOL
entry.
I can modify the file kernel/signal.c adding the line
EXPORT_SYMBOL(kill_proc_info) but maybe it is a good reason in order not to
use this function straight. If so what would be the best way to send a
signal form the kernel interrupt handler routine to the user space together
with the siginfo data.
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12032525
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Josh Boyer @ 2007-08-07 12:15 UTC (permalink / raw)
To: David Gibson; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20070807062231.GB8351@localhost.localdomain>
On Tue, 7 Aug 2007 16:22:31 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> Based on BenH's earlier work, this is a new version of the EMAC driver
> for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> same ASIC is also found in the Axon bridge chip. This new version is
> designed to work in the arch/powerpc tree, using the device tree to
> probe the device, rather than the old and ugly arch/ppc OCP layer.
>
> This driver is designed to sit alongside the old driver (it lies in
> drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
> old driver is left in place to support arch/ppc until arch/ppc itself
> reaches its final demise (not too long now, with luck).
>
> This driver still has a number of things that could do with cleaning
> up, but I think they can be fixed up after merging. Specifically:
> - Should be adjusted to properly use the dma mapping API.
> Axon needs this.
> - Probe logic needs reworking, in conjuction with the general
> probing code for of_platform devices. The dependencies here between
> EMAC, MAL, ZMII etc. make this complicated. At present, it usually
> works, because we initialize and register the sub-drivers before the
> EMAC driver itself, and (being in driver code) runs after the devices
> themselves have been instantiated from the device tree.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Hm. Should this go through Jeff Garzik or Paul? If it's the latter,
I'll pull this into my git tree soon.
josh
^ permalink raw reply
* Were to start? With MPC8272 and embedded Linux.
From: Channy Tremblay @ 2007-08-07 12:36 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
Hi list!
First post for me.
We're starting a project with an MPC8272 that will eventually be on a custom
board we are building.
Here is a list of things I have:
- EmbeddedPlanet with MPC8272 but no BSP (do I need one?)
- VisionProbe II with VisionClick
I am planning on using DENX and U-Boot.
Can I put a Linux image with the VisionProbe II?
Thanks,
Channy
[-- Attachment #2: Type: text/html, Size: 441 bytes --]
^ permalink raw reply
* Re: [patch 04/10] 4xx bootwrapper reworks
From: Josh Boyer @ 2007-08-07 13:10 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070807030547.GC15619@localhost.localdomain>
On Tue, 7 Aug 2007 13:05:47 +1000
David Gibson <dwg@au1.ibm.com> wrote:
> > > Rather than just removing these defines and using hardcoded values,
> > > I'd prefer to see separate SPRN_DBCR0_40X and SPRN_DBCR0_44X defines.
> >
> > Ok. And place them where? In the same file since they aren't DCR defines?
> > Seems fairly trivial, but ok.
>
> Just where the old 44x specific define was. And yes, it is fairly
> trivial.
Fixed.
> > > [snip]
> > > > +#define EMAC_RESET 0x20000000
> > > > +#define MAL_RESET 0x80000000
> > >
> > > I think the MAL_RESET definition should go in the same place as the
> > > DCR number definition.
> >
> > Ok. Trivial.
>
> Yes.
Fixed.
> > > As I think I said before, I'm not really happy with this being
> > > hardcoded assuming exactly 2 ethernets.
> >
> > Well, it's hardcoded to assume one or two. I know of only one board that has
> > more than two EMACs. I was hoping we could get this in for 2.6.24 as-is and
> > change it when needs be. But I'll look at making it var-args or similar.
I'm going to hold off on this for now. I'm not disagreeing with you,
but there are no upcoming board ports that have more than two EMACs so
I'd like to focus on getting Bamboo (440EP) and Sequoia (440EPx)
in-tree first. Perhaps even Walnut, if there's time.
josh
^ permalink raw reply
* Re: [patch 08/10] Bamboo DTS
From: Josh Boyer @ 2007-08-07 13:11 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070806045332.GA11051@localhost.localdomain>
On Mon, 6 Aug 2007 14:53:32 +1000
David Gibson <dwg@au1.ibm.com> wrote:
> On Fri, Aug 03, 2007 at 11:09:08AM -0500, Josh Boyer wrote:
> > AMCC Bamboo board DTS
>
> All the compatible properties should have "XXXX-440ep" as the most
> precise version, in addition to the more general strings.
Done.
> > --- /dev/null
> > +++ linux-2.6/arch/powerpc/boot/dts/bamboo.dts
> > @@ -0,0 +1,248 @@
> > +/*
> > + * Device Tree Source for AMCC Bamboo
> > + *
> > + * Copyright (c) 2006, 2007 IBM Corp.
> > + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > + *
> > + * FIXME: Draft only!
> > + *
> > + * This file is licensed under the terms of the GNU General Public
> > + * License version 2. This program is licensed "as is" without
> > + * any warranty of any kind, whether express or implied.
> > + *
> > + * To build:
> > + * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
> > + * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
>
> Can we ditch this "to build" boilerplate. It's just another thing
> people frequently forget to update as they copy it from dts to dts.
Removed.
josh
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Scott Wood @ 2007-08-07 15:20 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.twol4cixnhx3hy@phoenix>
Alexandros Kostopoulos wrote:
> Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.h,
> I can seem to find anywhere the code regarding PCI Erratum 9. The
> defined macros(in io.h) for read/write are sufficient as a workaround
> for PCI9? Who does DMA and register initialization for this (it used to
> be done in arch/ppc/syslib/m8260_pci_erratum9.c in arc/ppc). Maybe
> u-boot or the bootwrapper?
I don't think the workaround exists yet in arch/powerpc, despite the
config option.
> Another question regarding resource allocation: when
> alloc_resource(pci_32.c), called from pcibios_allocate_resources(),
> during pcibios init, attempts to allocate resources using
> request_resource(), the request fails. This seems to happen because the
> previously scanned PCI devices request resources in the form, e.g.
> 00000- 0000f (i.e. starting from zero), and this should be mapped
> somewhere else in cpu mem space. My question (in order to find my bug)
> is, who performs this mapping, from PCI space to CPU space, the kernel
> (and if yes, where?) or the host bridge (in which case, I've probably
> failed to configure it properly).
If the error message is the one I'm thinking of (it always helps to post
the actual messages), that's normal for when the PCI bus hasn't been
probed by the firmware. Linux first tries to use the BARs as they're
already set, which will obviously fail because they haven't been set,
and then it will properly allocated them. It's harmless verbosity,
though it'd be nice to have a flag to tell the PCI layer to not bother
trying to preserve any existing BARs.
-Scott
^ permalink raw reply
* Linux PPC 8555--TSec initialisation
From: Shashikumar @ 2007-08-07 6:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.3.1186452002.23193.linuxppc-embedded@ozlabs.org>
Hi,
I am using PPC8555. I need to initialize TSEC. Can anybody help me How to
initialize TSEC on chip of ppc8555.
Thanks in advance
With regards
Shashi
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Scott Wood @ 2007-08-07 15:43 UTC (permalink / raw)
To: Sergei Shtylyov, linuxppc-dev
In-Reply-To: <20070807032806.GE15619@localhost.localdomain>
On Tue, Aug 07, 2007 at 01:28:06PM +1000, David Gibson wrote:
> It would be possible, I guess, to define a 'swizzled-ranges' property
> or something which allows child devices to be embedded in the parent's
> address range in a not-direct way. However, the swizzling on the
> flash bank is really a property of the flash bank, not of the parent
> bus - requiring it to be encoded in the parent is pretty yucky -
> especially if the flash bank is just part of a larger chunk of bus
> address space, defined by a single large ranges entry in the parent.
It's more a property of the connection between the bus and the flash
chips, and that connection could be described as its own "bus" node,
something like:
localbus {
#address-cells = <1>;
#size-cells = <1>;
ranges;
random-sane-device@ff000000 {
reg = <ff000000 800000>;
...
};
freaky-swizzle-bus@ff800000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "with-enough-lsd";
swizzle-bytes = <4>;
swizzle-ranges = <0 ff800000 00800000 2 3 0 1>;
flash@0 {
compatible = "cfi-flash";
reg = <0 800000>;
bank-width = <4>;
device-width = <2>;
};
};
};
Similar intermediary buses could be used for flashes with indirect
access (SPI and such).
-Scott
^ permalink raw reply
* Linux with data2mem
From: Glenn.G.Hart @ 2007-08-07 15:48 UTC (permalink / raw)
To: linuxppc-embedded
I have created a Linux kernel and file system into an ELF file. I have the
bit file from my Xilinx V4 FX12LC. According to the documentation I have
read I should be able to use data2mem to create one bit file which I can
program the FPGA with. I have not been able to get data2mem to work
correctly. Has anybody been able to do this? I started with my
system_bd.bmm file from implementation directory. Executing the command:
data2mem -2m system_bd.bmm -bt system.bit -bd zImage.initrd.elf -o b
newsys.bit
yields:
ERROR:Data2MEM:33 - Matching ADDRESS_SPACE for code segment #0 not found in
'sys
tem_bd.bmm'.
Code segment #0 occupies [0x00400000:0x0062AFFF]
This is my linux kernel I believe, but I cannot find any documentation I
what to do. I think I need to modify my system_bd.bmm file:
///////////////////////////////////////////////////////////////////////////////
//
// Processor 'ppc405_0', ID 100, memory map.
//
///////////////////////////////////////////////////////////////////////////////
ADDRESS_MAP ppc405_0 PPC405 100
///////////////////////////////////////////////////////////////////////////////
//
// Processor 'ppc405_0' address space
'plb_bram_if_cntlr_1_bram_combined' 0xFFFFC000:0xFFFFFFFF (16 KB).
//
///////////////////////////////////////////////////////////////////////////////
ADDRESS_SPACE plb_bram_if_cntlr_1_bram_combined RAMB16
[0xFFFFC000:0xFFFFFFFF]
BUS_BLOCK
plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/ramb16_0
[63:56] PLACED = X1Y9;
plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/ramb16_1
[55:48] PLACED = X2Y10;
plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/ramb16_2
[47:40] PLACED = X1Y10;
plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/ramb16_3
[39:32] PLACED = X2Y9;
plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/ramb16_4
[31:24] PLACED = X2Y13;
plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/ramb16_5
[23:16] PLACED = X2Y8;
plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/ramb16_6
[15:8] PLACED = X2Y12;
plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/ramb16_7
[7:0] PLACED = X2Y11;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
END_ADDRESS_MAP;
Thanks for any help you can offer.
Glenn
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Segher Boessenkool @ 2007-08-07 16:11 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070807105346.GB13606@localhost.localdomain>
>>>> The hardware should be described in the device tree. This isn't
>>>> the same as simply copying all your Linux code into it ;-)
>>>
>>> Ugh. SD/MMC slot is the hardware, isn't it? It have wired SPI pins,
>>> and chip select pin. To set up this pin, I need mmc node, which means
>>> that I can't completely move mmc definitions to the board file, as
>>> suggested by Kumar Gala.
>>>
>>> Advices?
>>
>> You need to declare in the SPI node which GPIOs it uses for
>> what. You shouldn't have the actual values to put into the
>> GPIO registers in the device tree; the kernel driver can
>> figure it out.
>
> Well, how SPI differs from UCC in that regard?
Not at all, I think. You just copied a bad example that
shouldn't exist like that at all :-(
> This is how mpc832x_mds.dts,
> mpc832x_rdb.dts, mpc836x_mds.dts, ... doing things already for UCC
> pins.
> And then what pio-map exists for?.. In my understanding pio-map tries
> to
> describe hardware (GPIO) wiring, exactly how SPI (and UCC) nodes trying
> to use it.
Yeah. It however contains lots more information that really
should be implicit in the driver using it (like, GPIO output
lines that are marked "no interrupt" -- what a surprise, duh).
As far as I can see the devices that need some GPIOs should
just say which GPIOs (on what GPIO controller) they use, and
that's about it, the kernel device drivers can handle the
rest (since they need to know lots more implicit information
_anyway_, there is no point in describing more details in the
device tree, esp. since many of those details describe only
how a device is used, not what it _is_).
Anyway, not your fault, I'd prefer not to see the madness
spread though :-)
> Heh.. anyway, it's really hard to find proper logic around device tree,
> do's and don'ts, so I'll just follow your suggestions in hope that I'll
> get it as time goes by. ;-)
:-)
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Matt Sealey @ 2007-08-07 16:21 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Alan Curry, linux-kernel
In-Reply-To: <f4545a576abeddf00f076a0cae9e3fdd@kernel.crashing.org>
Segher Boessenkool wrote:
>
> That's hardly the only reason. But yeah, that's one way to
> implement the workaround, but _we_ (the Linux community) cannot
> do it like that (easily) for all users.
But you're the guy who told us our firmware sucks and we should fix our
firmware rather than clutter Linux with too many fixups. There are about
200 lines of code required to bring the Efika device tree up to the
Linux "specification" of a 5200B device tree, which will never make it
into code. Pegasos is ostensibly the same way.
Linux is already a bad enough moving target, and none of these fixes help
other operating systems or developers, if we only patch Linux, and only
say, you must run the latest Linux kernel version, and the latest U-Boot,
and the latest FDT binary, and encourage users to upgrade it all regardless
of your worries.
So, there are two opinions here;
1) the reports as we had when Efika was released and continually levied
against Pegasos firmware, that the firmware is broken and must be fixed
to comply, and no fixes will be considered because "bplan sucks and must
fix it"
2) As long as the patches are 2 lines big, you will allow them in, because
it is too much for a user to update firmware or run a script to boot?
Would you guys rather we shipped a boot script that ran the OS, fixed
all these issues in-place in-firmware, so Linux did not have to have these
workarounds, or are you accepting patches now? Because I can write those
200 lines of code to work around Efika device tree mistakes you yourself
complained about at Christmas last year..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Matt Sealey @ 2007-08-07 16:27 UTC (permalink / raw)
To: Alan Curry; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200708070416.l774G3Qf728075@shell01.TheWorld.com>
Okay, you don't need to be an experienced Open Firmware developer.
In fact I know we have had experienced Open Firmware developers who have
said that our firmware sucks (some comment about "shitty German engineering",
I really did quit caring after that point) because they could not run probe-all
from the "ok" prompt.
In the first few pages of the OF spec, it very clearly states that this will
probably make your system explode.
So even experts do not know what they are doing. I don't expect users to.
But as an engineer, here, I think patching the device-type in the boot
wrapper (be it the chrp boot loader) is the wrong place, because we have
had real experts here (Ben, Segher etc.) complain that fixing the device
tree in the boot wrapper is no substitute for a correctly working
firmware.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Alan Curry wrote:
> I'm almost sorry I spoke up...
>
> Matt Sealey writes the following:
>> Okay before you add to the nvramrc you also need to add probe-all to build the
>> device tree first; I assumed this was common knowledge.
>
> Maybe for experienced OpenFirmware developers; this is the first time I've
> had to touch the stuff. So first I had to learn Forth. To patch the kernel
> you only need to know C. (Of course I already knew C -- it's common
> knowledge.)
>
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Segher Boessenkool @ 2007-08-07 16:33 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070807034136.GC13522@localhost.localdomain>
>>>>> Yeah, better names please -- if possible, something that someone
>>>>> without knowledge of this SoC will understand what it is.
>>>>
>>>> I think the names are probably ok - I'm assuming they're in keeping
>>>> with the convention I've used of using the same names /
>>>> abbreviations
>>>> as in the CPU user manual. I'm asking just for my own information,
>>>> although a comment might not be a bad idea.
>>
>> Fine with me -- I personally prefer "system-device-controller"
>> and "clock-power-controller" or similar, but that is mostly a
>> matter of taste. As long as it's human readable it's fine.
>
> Actually, it occurs to me that I've only sometimes been using that
> convention for the names: basically just for the weirdo chip control
> devices that don't have a more widespread generic name.
It's pretty darn hard to make good sensible "generic names" for
some of the devices on a SoC; using the acronym that's in the
documentation for that SoC certainly isn't the worst choice.
>>> + Flash partitions
>>> + - reg :
>>> + - read-only : (optional)
>>
>> I'll hold off commenting on this until you've finish writing it,
>> you probably know my opinion about it anyway :-)
>
> Heh.. actually I was kind of hoping for your input on what's still
> missing. For example, I don't know what the necessary extra
> properties for JEDEC chips are.
I meant for the "partitions" stuff only.
For the JEDEC chips, we need a "vendor-id" and "device-id"
property at least (or similar names -- whatever is general
practice for this); both are a single byte, encoded as with
encode-int.
>> One thing though -- what _exactly_ does "read-only" signify?
>
> That's... a good question.
Yeah. It seems to me that the way it is currently used is
pure policy enforcement, which doesn't belong in the device
tree.
Segher
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Segher Boessenkool @ 2007-08-07 16:43 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070807032806.GE15619@localhost.localdomain>
>>> Aha! Ok, now I understand the sorts of situations you're talking
>>> about. By "not direct mapped", I thought you were talking about some
>>> kind of access via address/data registers on some indirect bus
>>> controller, rather than weird variations on endianness and
>>> bit-swizzling.
>>
>> No, that would be just too ridiculous for a NOR flash -- I hope.
>> :-)
>
> Heh. In my experience, very little is so ridiculous that some
> embedded vendor won't do it.
True -- but if you can't map the NOR into the CPU address space,
there are cheaper alternatives. Most embedded vendors care about
that, too ;-)
>> So, you're saying that the 1:1 address correspondence rule stops
>> to apply
>> here?
>
> Well.. it all depends what exactly you consider the address space of
> the flash bank. By which I mean the whole shmozzle represented by the
> device node, not the individual flash chips. It's not immediately
> obvious whether or not that should include any swizzling done by the
> bus wiring.
The parent device/bus shouldn't care, from its viewpoint the flash
bank is just one linear hunk of address space. For reading or
writing the flash bank appears linear to the CPU as well (at least
that's the only thing our current proposed binding supports); the
only thing that gets "interesting" is sending commands to the flash
chips.
> It would be possible, I guess, to define a 'swizzled-ranges' property
> or something which allows child devices to be embedded in the parent's
> address range in a not-direct way.
Let's not even consider this please.
> However, the swizzling on the
> flash bank is really a property of the flash bank,
Yeah, it's the "fine structure" of the flash bank. Something
only the flash driver has to deal with. So no contaminating the
parent device node, thank you.
>>> Simplest option seems to me to add a property "endianness" or
>>
>> And we even have a precedent of "big-endian" prop in the MPIC
>> nodes
>> (although I'm not sure why it's needed there).
A single register read (32-bit registers) gives a big-endian value
on some MPIC implementations, and wrong-endian on others. The
device driver really needs to know -- it really should just figure
it out from the "compatible" property though.
Segher
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Segher Boessenkool @ 2007-08-07 16:51 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070807041259.GF13522@localhost.localdomain>
>> address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>;
>
> Yes, I was contemplating something like that.
Let's not define this until we need it though :-)
>> I haven't heard or thought of anything better either. Using "ranges"
>> is conceptually wrong, even ignoring the technical problems that come
>> with it.
>
> Why is "ranges" conceptually wrong?
The flash partitions aren't separate devices sitting on a
"flash bus", they are "sub-devices" of their parent.
> To be honest this looks rather to me like another case where having
> overlapping 'reg' and 'ranges' would actually make sense.
It never makes sense. You should give the "master" device
the full "reg" range it covers, and have it define its own
address space; "sub-devices" can carve out their little hunk
from that. You don't want more than one device owning the
same address range in the same address space.
Segher
^ permalink raw reply
* Re: signals handling in the kernel
From: David Hawkins @ 2007-08-07 16:54 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12032525.post@talk.nabble.com>
Hi Mirek,
> I would like to send signals from the interrupt handler
> routine (in the kernel) to the user application (in user space).
> I have googled on that net and I have found that it could be done with the
> function: kill_proc_info.
Look in Rubini for the section regarding asynchronous
notification, Ch 6.
The callback to generate SIGIO is fasync.
Cheers
Dave
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Segher Boessenkool @ 2007-08-07 16:58 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070807040918.GD13522@localhost.localdomain>
>> Most characters are allowed in the unit-address... The following
>> is just fine: "my-secret-base@the-moon". ISA uses letters to
>> distinguish between its different address spaces, for example.
>
> Yeah, I should probably make dtc a bit more flexible about accepting
> that, too. At present, it only takes hex digits and ',', since those
> are the common character.
Sounds good. And then the legacy ISA devices in existing
DTS files should be changed to say @i60 instead of @60, etc.
(@60 is correct since the default is legacy I/O space, but
it's good the be more verbose in those cases).
>> David, can multiple devices sit on the same chip-select
>> on EBC, or on the same "minor" address? If not, you can
>> simplify your unit address representation.
>
> As far as I know, multiple devices could sit on the same chip select:
> provided there was enough address decoding logic in or around the
> devices, and that there existing bus timing parameters which would
> work with all the devices on a chip select (or "bank" in the
> terminology of the EBC bridge documentation).
Ah, that's what multiple banks are for!
> Devices on different banks can certainly have the same address/offset
> within the bank - e.g. on Ebony most of the devices are at offset 0.
> The OPB address range for each bank is separately programmable in the
> EBC bridge DCRs.
Okay, seems like the <bank,offset> representation is the simplest
possible, then. Good. <rubber stamp>
> (Incidentally, this is why I created the binding in this way, rather
> than just using the firmware established addresses in OPB space, which
> are usually fixed for a particular board/platform. This way provides
> enough information that, if necessary, the kernel or another client
> can reprogram the EBC from scratch to access the various devices
> present. Well.. actually fully reprogramming would also need the the
> bus timing parameters, which I was thinking of adding information
> before, but I haven't gotten to it yet.)
It gives a full "as simple as possible but no simpler" description
of the hardware, so it's just fine independent of whether you want
to reprogram the EBC or not.
Segher
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Segher Boessenkool @ 2007-08-07 17:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070807154307.GA27504@ld0162-tx32.am.freescale.net>
>> It would be possible, I guess, to define a 'swizzled-ranges' property
>> or something which allows child devices to be embedded in the parent's
>> address range in a not-direct way. However, the swizzling on the
>> flash bank is really a property of the flash bank, not of the parent
>> bus - requiring it to be encoded in the parent is pretty yucky -
>> especially if the flash bank is just part of a larger chunk of bus
>> address space, defined by a single large ranges entry in the parent.
>
> It's more a property of the connection between the bus and the flash
> chips, and that connection could be described as its own "bus" node,
> something like:
But it's not a bus in reality. There is no need to introduce
a fake bus here, it won't help anything AFAICS.
> Similar intermediary buses could be used for flashes with indirect
> access (SPI and such).
There are perfectly good mechanisms already for describing
those, too (you make a device node for the controller, and
it defines its own address space).
Segher
^ permalink raw reply
* [PATCH] Remove dtc build cruft from DTS files
From: Josh Boyer @ 2007-08-07 17:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, david
The patch below removes the dtc incantation instructions from the
in-kernel DTS files. It's not needed, and is prone to being
out-of-date most of the time.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
diff --git a/arch/powerpc/boot/dts/ebony.dts
b/arch/powerpc/boot/dts/ebony.dts index c5f9961..b05a7a0 100644
--- a/arch/powerpc/boot/dts/ebony.dts
+++ b/arch/powerpc/boot/dts/ebony.dts
@@ -9,10 +9,6 @@
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without
* any warranty of any kind, whether express or implied.
- *
- * To build:
- * dtc -I dts -O asm -o ebony.S -b 0 ebony.dts
- * dtc -I dts -O dtb -o ebony.dtb -b 0 ebony.dts
*/
/ {
diff --git a/arch/powerpc/boot/dts/holly.dts
b/arch/powerpc/boot/dts/holly.dts index 80a4fab..1a4d0be 100644
--- a/arch/powerpc/boot/dts/holly.dts
+++ b/arch/powerpc/boot/dts/holly.dts
@@ -8,10 +8,6 @@
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without
* any warranty of any kind, whether express or implied.
- *
- * To build:
- * dtc -I dts -O asm -o holly.S -b 0 holly.dts
- * dtc -I dts -O dtb -o holly.dtb -b 0 holly.dts
*/
/ {
diff --git a/arch/powerpc/boot/dts/kuroboxHD.dts
b/arch/powerpc/boot/dts/kuroboxHD.dts index 1225374..b0eeff0 100644
--- a/arch/powerpc/boot/dts/kuroboxHD.dts
+++ b/arch/powerpc/boot/dts/kuroboxHD.dts
@@ -15,9 +15,6 @@
XXXX add flash parts, rtc, ??
-build with: "dtc -f -I dts -O dtb -o kuroboxHD.dtb -V 16 kuroboxHD.dts"
-
-
*/
/ {
diff --git a/arch/powerpc/boot/dts/kuroboxHG.dts
b/arch/powerpc/boot/dts/kuroboxHG.dts index 579aa8b..ccd15a2 100644
--- a/arch/powerpc/boot/dts/kuroboxHG.dts
+++ b/arch/powerpc/boot/dts/kuroboxHG.dts
@@ -15,9 +15,6 @@
XXXX add flash parts, rtc, ??
-build with: "dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16 kuroboxHG.dts"
-
-
*/
/ {
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts index 5300b50..e416ea6 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -9,10 +9,6 @@
*
* Property values that are labeled as "Default" will be updated by
bootwrapper
* if it can determine the exact PrPMC type.
- *
- * To build:
- * dtc -I dts -O asm -o prpmc2800.S -b 0 prpmc2800.dts
- * dtc -I dts -O dtb -o prpmc2800.dtb -b 0 prpmc2800.dts
*/
/ {
^ permalink raw reply
* Telnet on ML410
From: khollan @ 2007-08-07 18:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi
Im trying to get telnetd from busybox to work on my ML410. Im running the
telnetd in the init.d but when I connect to the ML410 with telnet I just get
a blank screen without any prompt or login. Any thoughts. Here is my
inittab file if that will help, I think it has to do with how my console is
setup since Im using the uartlite. Im new to this so any help would be
great.
::sysinit:/etc/init.d/rcS
# TERMINALS
#::askfirst:/bin/login
::askfirst:/sbin/getty -L 9600 ttyUL0
# What to do at the "Three Finger Salute"
# NOTE: This will not work over a serial port!
:12345:ctrlaltdel:/sbin/reboot
# What to do at shutdown/reboot
:6:shutdown:/bin/umount -a -r
:6:shutdown:/sbin/swapoff -a
# Stuff to do when restarting the init process
::restart:/sbin/init
--
View this message in context: http://www.nabble.com/Telnet-on-ML410-tf4231739.html#a12039337
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Linux PPC 8555--TSec initialisation
From: Kumar Gala @ 2007-08-07 18:11 UTC (permalink / raw)
To: shashikumar; +Cc: linuxppc-embedded
In-Reply-To: <20070807152644.73689DDE38@ozlabs.org>
On Aug 7, 2007, at 1:51 AM, Shashikumar wrote:
> Hi,
>
> I am using PPC8555. I need to initialize TSEC. Can anybody help me
> How to
> initialize TSEC on chip of ppc8555.
>
> Thanks in advance
It should be initialized by the driver in drivers/net/gianfar*
- k
^ permalink raw reply
* Re: signals handling in the kernel
From: David Hawkins @ 2007-08-07 18:31 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <46B8A3C9.7060806@ovro.caltech.edu>
Hi Mirek,
>> I would like to send signals from the interrupt handler
>> routine (in the kernel) to the user application (in user space).
>> I have googled on that net and I have found that it could be done with the
>> function: kill_proc_info.
>
> Look in Rubini for the section regarding asynchronous
> notification, Ch 6.
>
> The callback to generate SIGIO is fasync.
>
Actually, before you go off and implement something, can
you describe why you want to use signals.
I mistakenly used signals once to indicate notification of
an event. Then when I wanted multiple events from multiple
boards I found the problem with signals; you don't know
who sent it.
Using select() on multiple file descriptors ended up being
a more appropriate solution for my application. That
solution also works nicely with the ACE C++ ACE_Reactor
pattern.
Cheers,
Dave
^ permalink raw reply
* Re: BusyBox passwd requires root privileges
From: khollan @ 2007-08-07 18:39 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B3A44E.1030508@freescale.com>
Scott Wood-2 wrote:
>
>
> Make sure it's owned by root, and chmod 4755 the binary. I'm not sure
> how to go about telling busybox to drop suid when invoked as something
> else. It'd probably be better to build two busyboxes, one with all suid
> commands and the other with the rest.
>
> -Scott
>
>
I chmod 4755 to the passwd binary and it worked. Before I did that I also
added a Busybox.conf file in /etc with this in it...
[SUID]
passwd = ssx root.root
I don't know if I needed that or not but it works now. Thanks
--
View this message in context: http://www.nabble.com/BusyBox-passwd-requires-root-privileges-tf4214675.html#a12039968
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Embedded linux FTP Server
From: khollan @ 2007-08-07 18:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B06C8C.3030106@anagramm.de>
I chose vsftp, easy compile and configure and works great so far.
Thanks for the suggestions
--
View this message in context: http://www.nabble.com/Embedded-linux-FTP-Server-tf4196501.html#a12039969
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Fedora 7 on a non FPU system
From: Michael Brian Willis @ 2007-08-07 17:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070314065411.GD14658@moe.telargo.com>
Hello,
I'm trying to install a Fedora 7 Root File System on an MPC8540 based
embedded system with a Denx 2.6.21 kernel. I have read the Denx
Application note located at:
http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia.
However this App. Note says that the instructions apply only to
processors that have a full Floating Point Unit (FPU). My processor does
not have an FPU and I believe that this is causing some system hangs.
Has anybody every successfully installed Fedora(or another major distro)
on a non-FPU system? Or, does anybody know what is needed to get it
working properly on a non FPU system?
Any help is greatly appreciated.
Regards,
Michael Willis
Applied Research Labs-University of Texas
willis@arlut.utexas.edu
^ 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