* Re: FPGA programming driver architecture
From: Hans J. Koch @ 2009-01-09 23:40 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Thiago Galesi, Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <20090109100725.77a07e74.hugo@hugovil.com>
On Fri, Jan 09, 2009 at 10:07:25AM -0500, Hugo Villeneuve wrote:
>
> I think that for the moment, I will focus on implementing the core
> module and the parallel/SPI interfaces only. Later we may want to add
> more fonctionality (vendors, JTAG, etc).
That's a good plan, but you'll have to make sure different FPGA programming
drivers can be added easily to some fpga-core no matter which interface they
use.
>
> But for now, my main problem is that I need to have some insight on how
> I actually implement the different modules:
>
> Bus driver?
> class driver?
> platform driver?
Those are not mutually exclusive. If you register an spi driver, it'll appear
on that bus. It would be a good idea to also create a class "fpga". And an
FPGA will likely be a platform device unless you create a complete subsystem
that offers something like register_fpga_device(). The latter would be a nice
thing to have, I had to write FPGA programming drivers and had to implement
them as some char device in drivers/misc because there was no place where
they could go...
IMHO, the ideal solution would be to have an FPGA programming subsystem.
Somewhere in my board support I'd setup some struct fpga_device that
contains an element "bus_type" which can be set to FPGA_BUS_PARALLEL or
FPGA_BUS_SPI or whatever. A "name" element declares which driver I'd like
to use for my chip. A call to some fpga_register_device() with a
pointer to that struct would make the fpga subsystem remember that device and
look for an apropriate driver. Drivers register themselves by a call to some
register_fpga_driver() function. The fpga core would then make sure the
drivers probe function is called with pointers to the struct fpga_device of
the registered devices. That's how other subsystems work.
Such a subsystem would solve any FPGA programming problems (and your "main
problem" mentioned above) once and for all.
Thanks,
Hans
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Hugo Villeneuve @ 2009-01-09 15:07 UTC (permalink / raw)
To: Thiago Galesi; +Cc: Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <82ecf08e0901081414u15af3c2dy9c88a242db024dc7@mail.gmail.com>
On Thu, 8 Jan 2009 20:14:36 -0200
"Thiago Galesi" <thiagogalesi@gmail.com> wrote:
> > > > Hi,
> > > > I have written some code to program a FPGA in Linux, for two
> > > > different types of boards: one uses a serial interface (SPI) and
> > > > the second a parallel interface. I have been able to sucessfully
> > > > program both boards. I'm now trying to clean my code and make it
> > > > more generic, as well as better in line with the Linux driver
> > > > model.
>
> Considering the several FPGA models available and ways to program it,
> I guess the important thing to consider is what can be made generic.
> (that is what will become fpgaload)
I have a pretty good idea of what goes into the core and
what goes into the specific interface modules (spi, parallel, etc).
> Also, there may be cases where after FPGA is programmed it "becomes a
> device" (PCI or whatever)
This is exactly the case for my board, but it doesn´t change anything
to the programming side of things, apart for the fact that the FPGA
must be configured before using any in-FPGA PCI bus for example.
> > > - fpgaload-core which contains all the code that can be shared
> > > between the drivers like requesting firmware, providing sysfs
> > > attributes,
> > > - fpgaload-spi would handle the low-level SPI connection
> > > - fpgaload-par would handle the low-level parallel connection
>
> I think this maybe split into three layers (maybe)
>
> 1 - low level connection: paralell / spi / i2c / whatever
> 2 - vendor: xylinx, altera, etc
> 3 - generic stuff
>
> Take a look at the MTD and SPI drivers and how they split things
I think that for the moment, I will focus on implementing the core
module and the parallel/SPI interfaces only. Later we may want to add
more fonctionality (vendors, JTAG, etc).
But for now, my main problem is that I need to have some insight on how
I actually implement the different modules:
Bus driver?
class driver?
platform driver?
Can anybody give some advice on that?
Thank-you, Hugo.
---------------
Hugo Villeneuve
www.hugovil.com
---------------
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Alexander Clouter @ 2009-01-09 12:24 UTC (permalink / raw)
To: linux-embedded; +Cc: linux-kernel
In-Reply-To: <4966C125.10604@duaneellis.com>
Duane Ellis <duane@duaneellis.com> wrote:
> >> [various FPGA config methods]
>
> Don't forget JTAG, and playing back an SVF files, or BIT files.
>
On the board we have, the FPGA is programmable over JTAG which is
conveniently strapped to the GPIO pins of the CPU.
http://www.embeddedarm.com/products/board-detail.php?product=TS-7800
Cheers
Alex
--
Alexander Clouter
.sigmonster says: This screen intentionally left blank.
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Duane Ellis @ 2009-01-09 3:14 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Florian Fainelli, Thiago Galesi, Hugo Villeneuve, linux-kernel,
linux-embedded
In-Reply-To: <c384c5ea0901081507v5d186eai5ec71d56b4c7a972@mail.gmail.com>
>> [various FPGA config methods]
Don't forget JTAG, and playing back an SVF files, or BIT files.
-Duane.
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Leon Woestenberg @ 2009-01-08 23:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: Thiago Galesi, Hugo Villeneuve, linux-kernel, linux-embedded
In-Reply-To: <200901082357.24432.florian@openwrt.org>
Hello,
On Thu, Jan 8, 2009 at 11:57 PM, Florian Fainelli <florian@openwrt.org> wrote:
> Le Thursday 08 January 2009 23:47:58 Leon Woestenberg, vous avez écrit :
>> The programming back end should be generic enough so that it can use
>> other subsystems.
>>
> That's the idea behind using request_firmware, which provides you with both a
> pointer to the data and the size of the blob.
I know, that's what I would call the front-end (near userspace).
I meant the low-level back-end (towards hardware):
> - fpgaload-core which contains all the code that can be shared
> between the drivers like requesting firmware, providing sysfs
> attributes,
> - fpgaload-spi would handle the low-level SPI connection
> - fpgaload-par would handle the low-level parallel connection
>
> fpgaload-ser and par would register with fpgaload-core and they could
> register a fpga loading callback which is low-level specific for
> instance.
My $0.02 was:
Those callbacks should also be able to accept chunks of data
(preferably in the same way using ptr/len).
Regards,
--
Leon
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Florian Fainelli @ 2009-01-08 22:57 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Thiago Galesi, Hugo Villeneuve, linux-kernel, linux-embedded
In-Reply-To: <c384c5ea0901081447i5ad807b3yb0ec3adebeaa46a0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
Hello,
Le Thursday 08 January 2009 23:47:58 Leon Woestenberg, vous avez écrit :
> Indeed.
>
> The programming back end should be generic enough so that it can use
> other subsystems.
>
> The FPGA configuration interface could be on the memory bus (and in
> many cases the DMA helpers can be used) or behind a PCI bus, or can
> even have SPI etc front-ends.
>
> In general the programming API should accept a blob of data,
> preferably in one chunk (pointer plus length) or at least 4kB chunks
> or so, so that configuration is not severy overheaded by a callback
> per byte (or even bit).
That's the idea behind using request_firmware, which provides you with both a
pointer to the data and the size of the blob.
--
Best regards, Florian Fainelli
Email : florian@openwrt.org
http://openwrt.org
-------------------------------
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Leon Woestenberg @ 2009-01-08 22:47 UTC (permalink / raw)
To: Thiago Galesi
Cc: Hugo Villeneuve, Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <82ecf08e0901081414u15af3c2dy9c88a242db024dc7@mail.gmail.com>
Hello,
On Thu, Jan 8, 2009 at 11:14 PM, Thiago Galesi <thiagogalesi@gmail.com> wrote:
>> > > Hi,
>> > > I have written some code to program a FPGA in Linux, for two
>> > > different types of boards: one uses a serial interface (SPI) and
>> > > the second a parallel interface. I have been able to sucessfully
>> > > program both boards. I'm now trying to clean my code and make it
>> > > more generic, as well as better in line with the Linux driver
>> > > model.
>
> Considering the several FPGA models available and ways to program it,
> I guess the important thing to consider is what can be made generic.
Indeed.
The programming back end should be generic enough so that it can use
other subsystems.
The FPGA configuration interface could be on the memory bus (and in
many cases the DMA helpers can be used) or behind a PCI bus, or can
even have SPI etc front-ends.
In general the programming API should accept a blob of data,
preferably in one chunk (pointer plus length) or at least 4kB chunks
or so, so that configuration is not severy overheaded by a callback
per byte (or even bit).
Regards,
--
Leon
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Thiago Galesi @ 2009-01-08 22:14 UTC (permalink / raw)
To: Hugo Villeneuve; +Cc: Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <20090108151827.72f50cee.hugo@hugovil.com>
> > > Hi,
> > > I have written some code to program a FPGA in Linux, for two
> > > different types of boards: one uses a serial interface (SPI) and
> > > the second a parallel interface. I have been able to sucessfully
> > > program both boards. I'm now trying to clean my code and make it
> > > more generic, as well as better in line with the Linux driver
> > > model.
Considering the several FPGA models available and ways to program it,
I guess the important thing to consider is what can be made generic.
(that is what will become fpgaload)
Also, there may be cases where after FPGA is programmed it "becomes a
device" (PCI or whatever)
> >
> > - fpgaload-core which contains all the code that can be shared
> > between the drivers like requesting firmware, providing sysfs
> > attributes,
> > - fpgaload-spi would handle the low-level SPI connection
> > - fpgaload-par would handle the low-level parallel connection
I think this maybe split into three layers (maybe)
1 - low level connection: paralell / spi / i2c / whatever
2 - vendor: xylinx, altera, etc
3 - generic stuff
Take a look at the MTD and SPI drivers and how they split things
--
-
Thiago Galesi
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Hugo Villeneuve @ 2009-01-08 20:18 UTC (permalink / raw)
To: Florian Fainelli; +Cc: linux-kernel, linux-embedded
In-Reply-To: <200812131358.03010.florian@openwrt.org>
On Sat, 13 Dec 2008 13:58:01 +0100
Florian Fainelli <florian@openwrt.org> wrote:
> (CC'ing linux-embedded)
>
> Salut Hugo,
>
> Le Friday 12 December 2008 21:03:14 Hugo Villeneuve, vous avez écrit :
> > Hi,
> > I have written some code to program a FPGA in Linux, for two
> > different types of boards: one uses a serial interface (SPI) and
> > the second a parallel interface. I have been able to sucessfully
> > program both boards. I'm now trying to clean my code and make it
> > more generic, as well as better in line with the Linux driver
> > model. I would also like to include it in the mainline kernel if
> > there is interest.
> ...
> What about something like that :
>
> - fpgaload-core which contains all the code that can be shared
> between the drivers like requesting firmware, providing sysfs
> attributes,
> - fpgaload-spi would handle the low-level SPI connection
> - fpgaload-par would handle the low-level parallel connection
>
> fpgaload-ser and par would register with fpgaload-core and they could
> register a fpga loading callback which is low-level specific for
> instance. Platform code would instantiate the core driver. That way,
> adding support for other loading protocols like slave serial or
> master serial can be done easily.
Yes, but how I actually implement fpgaload_core, fpgaload_ser and
fpgaload_par?
Bus driver?
class driver?
platform driver?
I am not sure how I should implement things and how each low-level
specific driver should register with the fpgaload_core driver...
Hugo V.
---------------
Hugo Villeneuve
www.hugovil.com
---------------
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Christian Gagneraud @ 2009-01-08 15:04 UTC (permalink / raw)
To: klaasjan gm
Cc: Rob Landley, Sam Ravnborg, Embedded Linux mailing list,
Paul Mundt, Andrew Morton, H. Peter Anvin
In-Reply-To: <33cac1200901080513k4df78751uc752c38e71486164@mail.gmail.com>
klaasjan gm wrote:
> Rob and to whom it may concern,
>
>> I didn't discover this topic independently. Somebody pinged me about it on
>> freenode back in February, and several other people sent me private email
>> about it, and it's been previously raised on several other mailing lists (such
>> as busybox and uclibc ones).
>>
>> Unfortunately, most of the embedded developers I know aren't subscribed to
>> linux-kernel.
>
> FWIW,
>
>> Hopefully the cc: to linux-embedded is helping get more embedded guys involved
>> in the discussion than just me. :)
>
> Having some experience with cross-compiling the kernel, and some of the basic
> toolsets:
> I'm with you on this one (and testing the waters at linux-embedded
> while I'm at it)
+1
Chris
>
> Regards,
> Klaasjan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mike Frysinger @ 2009-01-08 13:29 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Paul Mundt, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <c384c5ea0901040223l6e53f041s9f7cdea20c9d1d8d@mail.gmail.com>
On Sun, Jan 4, 2009 at 05:23, Leon Woestenberg wrote:
> On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt <lethal@linux-sh.org> wrote:
>> Let's look at the rationale presented so far in this thread:
>>
>> 2 - Cross-compiling perl is hard.
>
> 2 is not hard.
i dont know where you're getting this mythical version of perl, but
anything beyond micro-perl is a pita. and micro-perl is practically
worthless. maybe for kernel/
-mike
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: klaasjan gm @ 2009-01-08 13:13 UTC (permalink / raw)
To: Rob Landley
Cc: Sam Ravnborg, Embedded Linux mailing list, Paul Mundt,
Andrew Morton, H. Peter Anvin
In-Reply-To: <200901031348.46847.rob@landley.net>
Rob and to whom it may concern,
> I didn't discover this topic independently. Somebody pinged me about it on
> freenode back in February, and several other people sent me private email
> about it, and it's been previously raised on several other mailing lists (such
> as busybox and uclibc ones).
>
> Unfortunately, most of the embedded developers I know aren't subscribed to
> linux-kernel.
FWIW,
> Hopefully the cc: to linux-embedded is helping get more embedded guys involved
> in the discussion than just me. :)
Having some experience with cross-compiling the kernel, and some of the basic
toolsets:
I'm with you on this one (and testing the waters at linux-embedded
while I'm at it)
Regards,
Klaasjan
^ permalink raw reply
* Re: [PATCH V3 01/17] Squashfs: inode operations
From: Stephen Rothwell @ 2009-01-07 21:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Phillip Lougher, Andrew Morton, linux-embedded, linux-fsdevel,
Linux Kernel Development, Tim Bird, Linux/PPC Development
In-Reply-To: <Pine.LNX.4.64.0901071854210.32034@vixen.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
Hi Geert,
On Wed, 7 Jan 2009 19:00:24 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> Note that I get lots of
>
> | warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'u64'
>
> on ppc64, since you switched from `unsigned long long' to 'u64', as `u64' is
> (still -- this is being changed) `unsigned long' on pp64.
>
> I guess no action has to be taken, for now?
Correct, as we are in the process of changing u64 to unsigned long long for
powerpc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH V3 01/17] Squashfs: inode operations
From: Geert Uytterhoeven @ 2009-01-07 18:00 UTC (permalink / raw)
To: Phillip Lougher
Cc: Andrew Morton, linux-embedded, linux-fsdevel,
Linux Kernel Development, Tim Bird, sfr, Linux/PPC Development
In-Reply-To: <E1LJnJn-0002L2-GZ@dylan.lougher.demon.co.uk>
On Mon, 5 Jan 2009, Phillip Lougher wrote:
> diff --git a/fs/squashfs/inode.c b/fs/squashfs/inode.c
> new file mode 100644
> index 0000000..7a63398
> --- /dev/null
> +++ b/fs/squashfs/inode.c
> @@ -0,0 +1,346 @@
> +int squashfs_read_inode(struct inode *inode, long long ino)
> +{
> + struct super_block *sb = inode->i_sb;
> + struct squashfs_sb_info *msblk = sb->s_fs_info;
> + u64 block = SQUASHFS_INODE_BLK(ino) + msblk->inode_table;
^^^
> + TRACE("File inode %x:%x, start_block %llx, block_list_start "
^^^^
> + "%llx, offset %x\n", SQUASHFS_INODE_BLK(ino),
^^^^
> + offset, squashfs_i(inode)->start, block, offset);
Note that I get lots of
| warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'u64'
on ppc64, since you switched from `unsigned long long' to 'u64', as `u64' is
(still -- this is being changed) `unsigned long' on pp64.
I guess no action has to be taken, for now?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre 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/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH V3 10/17] Squashfs: cache operations
From: Geert Uytterhoeven @ 2009-01-07 16:17 UTC (permalink / raw)
To: Phillip Lougher
Cc: akpm, linux-embedded, linux-fsdevel, linux-kernel, tim.bird, sfr
In-Reply-To: <E1LJnJn-0002Lm-Va@dylan.lougher.demon.co.uk>
On Mon, 5 Jan 2009, Phillip Lougher wrote:
> diff --git a/fs/squashfs/cache.c b/fs/squashfs/cache.c
> new file mode 100644
> index 0000000..f29eda1
> --- /dev/null
> +++ b/fs/squashfs/cache.c
> +/*
> + * Copy upto length bytes from cache entry to buffer starting at offset bytes
> + * into the cache entry. If there's not length bytes then copy the number of
> + * bytes available. In all cases return the number of bytes copied.
> + */
> +int squashfs_copy_data(void *buffer, struct squashfs_cache_entry *entry,
^
const?
It also makes it clear from the prototype in which direction is copied.
> + int offset, int length)
^^^ ^^^
> +{
> + int remaining = length;
^^^
Shouldn't all of these be unsigned int?
> +
> + if (length == 0)
> + return 0;
> + else if (buffer == NULL)
> + return min(length, entry->length - offset);
> +
> + while (offset < entry->length) {
> + void *buff = entry->data[offset / PAGE_CACHE_SIZE]
> + + (offset % PAGE_CACHE_SIZE);
> + int bytes = min_t(int, entry->length - offset,
> + PAGE_CACHE_SIZE - (offset % PAGE_CACHE_SIZE));
> +
> + if (bytes >= remaining) {
> + memcpy(buffer, buff, remaining);
> + remaining = 0;
> + break;
> + }
> +
> + memcpy(buffer, buff, bytes);
> + buffer += bytes;
> + remaining -= bytes;
> + offset += bytes;
> + }
> +
> + return length - remaining;
> +}
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre 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/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
From: Grant Erickson @ 2009-01-07 2:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Stefan Roese, Wolfgang Denx, linux-embedded
In-Reply-To: <1231286642.14860.35.camel@pasglop>
On 1/6/09 4:04 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote:
>> This merges support for the previously DENX-only kernel feature of
>> specifying an alternative, "external" buffer for kernel printk
>> messages and their associated metadata. In addition, this ports
>> architecture support for this feature from arch/ppc to arch/powerpc.
>>
>> Signed-off-by: Grant Erickson <gerickson@nuovations.com>
>
> Considering the extensive changes to generic code, this patch will
> have to be submitted via the linux-kernel mailing list.
>
> I suggest you split the generic core change from the powerpc specific
> implementation.
>
> I'm not sure whether I like the idea myself or not there, so you'll have
> to convince the powers that be to take it.
Ben:
Thanks for the feedback. Matt Sealey had some good feedback
<http://ozlabs.org/pipermail/linuxppc-dev/2008-November/065594.html> which I
have on my to-do list to evaluate.
In the interim, I'll hold off on pushing up to linux-kernel until I've done
that.
Regards,
Grant
^ permalink raw reply
* Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
From: Grant Erickson @ 2009-01-07 2:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Stefan Roese, Wolfgang Denx, linux-embedded
In-Reply-To: <1231286642.14860.35.camel@pasglop>
On 1/6/09 4:04 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote:
>> This merges support for the previously DENX-only kernel feature of
>> specifying an alternative, "external" buffer for kernel printk
>> messages and their associated metadata. In addition, this ports
>> architecture support for this feature from arch/ppc to arch/powerpc.
>>
>> Signed-off-by: Grant Erickson <gerickson@nuovations.com>
>
> Considering the extensive changes to generic code, this patch will
> have to be submitted via the linux-kernel mailing list.
>
> I suggest you split the generic core change from the powerpc specific
> implementation.
>
> I'm not sure whether I like the idea myself or not there, so you'll have
> to convince the powers that be to take it.
Ben:
Thanks for the feedback. Matt Sealey had some good feedback
<http://ozlabs.org/pipermail/linuxppc-dev/2008-November/065594.html> which I
have on my to-do list to evaluate.
In the interim, I'll hold off on pushing up to linux-kernel until I've done
that.
Regards,
Grant
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Ben Nizette @ 2009-01-07 1:52 UTC (permalink / raw)
To: Robin Getz
Cc: Jaya Kumar, David Brownell, Eric Miao, Sam Ravnborg, Eric Miao,
Haavard Skinnemoen, Philipp Zabel, Russell King, Ben Gardner,
Greg KH, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <200901061802.39072.rgetz@blackfin.uclinux.org>
On Tue, 2009-01-06 at 18:02 -0500, Robin Getz wrote:
> On Sun 28 Dec 2008 17:00, Ben Nizette pondered:
> > On Sun, 2008-12-28 at 13:46 -0500, Robin Getz wrote:
> > > > gpio_set_batch(DB0, value, 0xFFFF, 16)
> > > >
> > > > which has the nice performance benefit of skipping all the bit
> > > > counting in the most common use case scenario.
> > >
> > > but has the requirement that the driver know exactly the board level
> > > impmentation details (something that doesn't sound generic).
> >
> > The original use case for these batch operations was in a fastpath -
> > setting data lines on a framebuffer. Sure it's arguably not as generic
> > as may be, but it optimises for speed and current usage patterns - I'm
> > OK with that. Other usage patterns which don't have a speed requirement
> > can be done using the individual pin operations and a loop.
>
> The tradeoff for speed is always made with extensibility. If you want best
> speed - you shouldn't be using the GPIO framework at all - just bang directly
> on the registers yourself...
>
> If you want something extensible/generic that serves multiple use cases -
> it will normally come with a performance tradeoff...
Yeah there's certainly a sliding scale here. At the speedy end you've
got register banging, $SUBJECT is one level higher, your concepts are
higher again.
If your concept can perform at a speed which solves the problem which
inspired $SUBJECT then IMO it's a better way to go. The thing which
worries me is that if we did end up sliding right up the Generic end of
the Generic-Performance slider then we'd end up with a sexy interface
which isn't actually usable for the case which inspired this activity in
the first place!
And yes the speed is primarily the concern of the implementation and
your comments really concern the interface. On paper the 2 are largely
orthogonal but until I see an alternate/competing patch I'm not prepared
to bet it'll all play nice.
>
> > > > While we are here, I was thinking about it, and its better if I give
> > > > gpio_request/free/direction_batch a miss for now. Nothing prevents
> > > > those features being added at a later point.
> > >
> > > I don't think that request/free are optional.
> > >
> > > For example - in most SoC implementations - gpios are implemented as
> > > banks of 16 or 32. (a 16 or 32 bit register).
> > >
> > > Are there facilities to span these registers?
> > > - can you request 64 gpios as a 'bank'?
> > > - can you request gpio_8 -> gpio_40 as a 'bank' on a 32-bit system?
> > >
> > > Are non-adjacent/non-contiguous gpios avaliable to be put into
> > > a 'bank/batch/bus'? can you use gpio_8 -> 11 & 28 -> 31 as a 8-bit
> > > 'bus'?
> > >
> > > How do you know what is avaliable to be talked to as a bank/bus/batch
> > > without the request/free operation?
> >
> > I think the read/write operations should be able to fail if you give
> > them invalid chunks of gpio, sure.
>
> Can you define "invalid"? what are the limitations?
>
> Can I use gpio_8 -> 11 & 28 -> 31 as a chunk?
With the $SUBJECT patch, I understand you can (they both fit in a u32
bitmask). The limitations aren't really the point though - no matter
what the final interface/implementation there will be some limitations.
Either there must be a bulk request interface which will fail if you try
and break the limitations or else the read/write will fail under these
circumstances.
A limitation which springs to mind for any implementation would be if
you specify that the chunk must be accessible in irq context but you
specify some gpios which must sleep. Yes this is a silly case and
totally the platform's responsibility but the fact is that if someone
makes this mistake an error should be returned *somewhere* rather than
just letting things explode.
In my own personal library of standalone code I've got a GPIO driver
which uses request() to build a cookie representing the gpios to be
driven; read/write then use this cookie. If the requested pins can't be
batched then it's the request which fails. I liked this approach. For
$SUBJECT's purposes though I think it's more symmetric with the single
bit operations to keep request as a refcount and have read/write able to
fail. Not too fussed though.
>
> > Request/free are not really designed
> > for that operation - they just ensure exclusive access to a gpio if
> > that's what the driver wants. In the batch case the
> > request/free/direction operations can once again be performed by single
> > pin operations and iteration.
>
> That depends on the semantics of "request".
>
> If it is "request & build up a monolithic chunk from xxx GPIO's" - then
> my definition works.
Indeed, see above.
>
>
> > > I have seen various hardware designs (both at the PCB and SoC level)
> > > require all of these options, and would like to see common infrastructure
> > > which handles this.
> >
> > Yeah the request/free operation doesn't deal with muxing or any other
> > platform-specific kinda gumph, that was an original design decision.
> > They're really just a usage counter.
>
> Sorry for bringing up the muxing - that wasn't the point.
>
> It was really the issue of being non-contiguous, spanning various implementations.
>
> > An example which comes to mind is the avr32-specific userspace gpio
> > interface. This takes a bitmask, loops over the set bits and fails if
> > any of the gpio are previously requested or have been assigned to
> > non-gpio peripherals.
>
> I'll have a look. I don't understand why everyone decided to make their own
> userspace GPIO interface - can't we all just get along? :)
Yeah for sure. Of course since .27 there's been a nice consistant
userspace gpio interface (/sys/class/gpio) so theoretically all the
others are deprecated. I know that at least on avrfreaks, the main
avr32 support forum, users have to have a good reason to be using the
avr32-specific interface if they expect to be helped.
>
> > I don't really see a need to streamline this.
>
>
>
> > > I would think that a 'bank' / 'bus' (whatever) would be a collection
> > > of random/multiple GPIOs (a struct of gpio_port_t) rather than a
> > > start/length (as you described) - or better yet - the request
> > > function takes a list (of individual GPIO's - defined in the
> > > platform data), and creates the struct itself.
> >
> > Hmm, this seems a little overengineered for the basic use-cases I can
> > think of.
>
> Not the ones I run into all the time...
>
> More complex pin multiplexing results in less contiguous free GPIO.
> (which again - has nothing to do with multiplexing - it is the result
> that is the important thing).
Which is why we're having this bit of a discussion! Jaya was the first
person to have this problem and has a patch which, in his case, solves
it. If you have other concrete cases which need to be solved at the
same time then now's the time to come forward and share with the class.
OK so I've got a board which collects the status of a number of gpio all
over a bunch of chips at a few 10s of Hz, encodes it and fires it across
a network. This works with single gpio ops but would be streamlined
with batch access. If the final solution to this problem can be used
for my pins then great, I'll move to it. However, if supporting my
use-case breaks Jaya's then it's not worth it.
>
> > If this can be cranked up to the same speed as the current
> > proposition then OK maybe someone will like it but otherwise, once
> > again, I think most people will be happy with individual operations and
> > iteration.
>
> It will be easier to maintain (from a end user perceptive - if someone
> wants a "chunk" of gpio's - they just define it in their platform data).
> It does put a bigger burden on the person writing things.
>
> I would think that the overhead would only be at init - runtime shouldn't
> be much different in the simple case, but allowing the complex usecases
> with the same interface is better (since we only have to teach people one
> thing) :)
Yeah I'll say again that if we can find an interface as generic as you
suggest and an implementation which performs as well as Jaya needs then
hells yeah, let's go for it. If however a sexy interface means Jaya's
original use case breaks then I for one won't support that interface.
--Ben.
>
> -Robin
^ permalink raw reply
* Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
From: Benjamin Herrenschmidt @ 2009-01-07 0:04 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev, Stefan Roese, Wolfgang Denx, linux-embedded
In-Reply-To: <1227638045-12862-1-git-send-email-gerickson@nuovations.com>
On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote:
> This merges support for the previously DENX-only kernel feature of
> specifying an alternative, "external" buffer for kernel printk
> messages and their associated metadata. In addition, this ports
> architecture support for this feature from arch/ppc to arch/powerpc.
>
> Signed-off-by: Grant Erickson <gerickson@nuovations.com>
Considering the extensive changes to generic code, this patch will
have to be submitted via the linux-kernel mailing list.
I suggest you split the generic core change from the powerpc specific
implementation.
I'm not sure whether I like the idea myself or not there, so you'll have
to convince the powers that be to take it.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Robin Getz @ 2009-01-06 23:02 UTC (permalink / raw)
To: Ben Nizette
Cc: Jaya Kumar, David Brownell, Eric Miao, Sam Ravnborg, Eric Miao,
Haavard Skinnemoen, Philipp Zabel, Russell King, Ben Gardner,
Greg KH, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <1230501634.16910.57.camel@linux-51e8.site>
On Sun 28 Dec 2008 17:00, Ben Nizette pondered:
> On Sun, 2008-12-28 at 13:46 -0500, Robin Getz wrote:
> > > gpio_set_batch(DB0, value, 0xFFFF, 16)
> > >
> > > which has the nice performance benefit of skipping all the bit
> > > counting in the most common use case scenario.
> >
> > but has the requirement that the driver know exactly the board level
> > impmentation details (something that doesn't sound generic).
>
> The original use case for these batch operations was in a fastpath -
> setting data lines on a framebuffer. Sure it's arguably not as generic
> as may be, but it optimises for speed and current usage patterns - I'm
> OK with that. Other usage patterns which don't have a speed requirement
> can be done using the individual pin operations and a loop.
The tradeoff for speed is always made with extensibility. If you want best
speed - you shouldn't be using the GPIO framework at all - just bang directly
on the registers yourself...
If you want something extensible/generic that serves multiple use cases -
it will normally come with a performance tradeoff...
> > > While we are here, I was thinking about it, and its better if I give
> > > gpio_request/free/direction_batch a miss for now. Nothing prevents
> > > those features being added at a later point.
> >
> > I don't think that request/free are optional.
> >
> > For example - in most SoC implementations - gpios are implemented as
> > banks of 16 or 32. (a 16 or 32 bit register).
> >
> > Are there facilities to span these registers?
> > - can you request 64 gpios as a 'bank'?
> > - can you request gpio_8 -> gpio_40 as a 'bank' on a 32-bit system?
> >
> > Are non-adjacent/non-contiguous gpios avaliable to be put into
> > a 'bank/batch/bus'? can you use gpio_8 -> 11 & 28 -> 31 as a 8-bit
> > 'bus'?
> >
> > How do you know what is avaliable to be talked to as a bank/bus/batch
> > without the request/free operation?
>
> I think the read/write operations should be able to fail if you give
> them invalid chunks of gpio, sure.
Can you define "invalid"? what are the limitations?
Can I use gpio_8 -> 11 & 28 -> 31 as a chunk?
> Request/free are not really designed
> for that operation - they just ensure exclusive access to a gpio if
> that's what the driver wants. In the batch case the
> request/free/direction operations can once again be performed by single
> pin operations and iteration.
That depends on the semantics of "request".
If it is "request & build up a monolithic chunk from xxx GPIO's" - then
my definition works.
> > I have seen various hardware designs (both at the PCB and SoC level)
> > require all of these options, and would like to see common infrastructure
> > which handles this.
>
> Yeah the request/free operation doesn't deal with muxing or any other
> platform-specific kinda gumph, that was an original design decision.
> They're really just a usage counter.
Sorry for bringing up the muxing - that wasn't the point.
It was really the issue of being non-contiguous, spanning various implementations.
> An example which comes to mind is the avr32-specific userspace gpio
> interface. This takes a bitmask, loops over the set bits and fails if
> any of the gpio are previously requested or have been assigned to
> non-gpio peripherals.
I'll have a look. I don't understand why everyone decided to make their own
userspace GPIO interface - can't we all just get along? :)
> I don't really see a need to streamline this.
> > I would think that a 'bank' / 'bus' (whatever) would be a collection
> > of random/multiple GPIOs (a struct of gpio_port_t) rather than a
> > start/length (as you described) - or better yet - the request
> > function takes a list (of individual GPIO's - defined in the
> > platform data), and creates the struct itself.
>
> Hmm, this seems a little overengineered for the basic use-cases I can
> think of.
Not the ones I run into all the time...
More complex pin multiplexing results in less contiguous free GPIO.
(which again - has nothing to do with multiplexing - it is the result
that is the important thing).
> If this can be cranked up to the same speed as the current
> proposition then OK maybe someone will like it but otherwise, once
> again, I think most people will be happy with individual operations and
> iteration.
It will be easier to maintain (from a end user perceptive - if someone
wants a "chunk" of gpio's - they just define it in their platform data).
It does put a bigger burden on the person writing things.
I would think that the overhead would only be at init - runtime shouldn't
be much different in the simple case, but allowing the complex usecases
with the same interface is better (since we only have to teach people one
thing) :)
-Robin
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Robin Getz @ 2009-01-06 22:41 UTC (permalink / raw)
To: Jaya Kumar
Cc: David Brownell, Eric Miao, Sam Ravnborg, Eric Miao,
Haavard Skinnemoen, Philipp Zabel, Russell King, Ben Gardner,
Greg KH, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <45a44e480812311005k709c410ao1116187e9427e452@mail.gmail.com>
On Wed 31 Dec 2008 13:05, Jaya Kumar pondered:
> On Thu, Jan 1, 2009 at 1:38 AM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> > On Tue 30 Dec 2008 23:58, Jaya Kumar pondered:
> >> On Tue, Dec 30, 2008 at 11:55 PM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> >> > Yeah, I hadn't thought about spanning more than one gpio_chip. That's a good
> >> > point.
> >>
> >> The currently posted code already supports spanning more than one gpio_chip.
> >>
> >
> > But doesn't do all the other things that David suggested/requested.
>
> Hi Robin,
>
> Yes, you are right. My implementation does not support a driver that
> needs to set/get more than 32-bits of gpio in a single call. I'm okay
> with that restriction as I don't see a concrete use case for that.
It's not the more than 32-bits that I'm concerned about - it is spanning
more than one register. (if all the GPIOs that are left on the board are
2, 64, and 128, where 2, and 64 are part of the SOC's GPIO, and 128 is on
a GPIO expander - which is a common use case - is this handled?)
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Rob Landley @ 2009-01-06 0:06 UTC (permalink / raw)
To: Jamie Lokier
Cc: Bernd Petrovitsch, Valdis.Kletnieks, Ingo Oeser,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
H. Peter Anvin, Sam Ravnborg
In-Reply-To: <20090105150156.GD14503@shareable.org>
On Monday 05 January 2009 09:01:56 Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
> > I assume that the NFS-mounted root filesystem is a real distribution.
>
> Not unless you call uClinux (MMU-less) a real distribution, no.
I want things to be orthogonal. The following should be completely separate
steps:
1) Creating a cross compiler
2) building a native development environment
3) booting a native development environment (on real hardware or under and
emulator)
4) natively building your target system.
You should be able to mix and match. Crosstool for #1, go download "fedora
for arm" instead of #2, qemu or real hardware is your choice for #3, and then
you should be able to natively build gentoo under an ubuntu host or vice
versa. (How is not currently properly documented, but I'm working on that.)
My objection to build systems like buildroot or uClinux is that they bundle
all this together into a big hairball. They create their own cross compiler,
build their own root file system, use their own packaging system, and you have
to take it all or nothing.
My build system is ruthlessly orthogonal. I try not to make it depend on
other bits of _itself_ more than necessary.
> > > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add
> > > proper shared libs. Feel free to fund this :-)
> >
> > The above mentioned ARMs have a MMU. Without MMU, it would be truly
> > insane IMHO.
>
> We have similar cross-build issues without MMUs... I.e. that a lot of
> useful packages don't cross-build properly (including many which use
> Autoconf), and it might be easier to make a native build environment
> than to debug and patch all the broken-for-cross-build packages.
> Especially as sometimes they build, but fail at run-time in some
> conditions.
If you can get a version of the same architecture with an mmu you can actually
build natively on that. It's not ideal (it's a bit like trying to build i486
code on an i686; the fact it runs on the host is no guarantee it'll run on the
target), but it's better than cross compiling. And most things have a broad
enough compatible "base architecture" that you can mostly get away with it.
> But you're right it's probably insane to try. I haven't dared as I
> suspect GCC and/or Binutils would break too :-)
Oh it does, but you can fix it. :)
> I'm sticking instead with "oh well cross-build a few packages by hand
> and just don't even _try_ to use most of the handy software out there".
Cross compiling doesn't scale, and it bit-rots insanely quickly.
> You mentioned ARM Debian. According to
> http://wiki.debian.org/ArmEabiPort one recommended method of
> bootstrapping it is building natively on an emulated ARM, because
> cross-building is fragile.
That's what my firmware linux project does too. (I believe I was one of the
first doing this back in 2006, but there are three or four others out there
doing it now.)
Native compiling under emulation is an idea whose time has come. Emulators on
cheap x86-64 laptops today are about as powerful as high end tricked out build
servers circa 2001, and Moore's Law continues to advance. More memory, more
CPU (maybe via SMP but distcc can take advantage of that today and qemu will
develop threading someday). You can throw engineering time at the problem
(making cross compiling work) or you can throw hardware at the problem (build
natively and buy fast native or emulator-hosting hardware). The balance used
to be in favor of the former; not so much anymore.
That said, my drive for reproducibility and orthogonality says that your
native development environment must be something you can reproduce entirely
from source on an arbitrary host. You can't make cross compiling go away
entirely, the best you can do is limit it to bootstrapping the native
environment. But I want to keep the parts I have to cross compile as small
and simple as possible, and then run a native build script to get a richer
environment. For the past 5+ years my definition has been "an environment
that can rebuild itself under itself is powerful enough, that's all I need to
cross compile", and from the first time I tried this (late 2002) up until
2.6.25 that was 7 packages. That's why I responded to the addition of perl as
a regression, because for my use case it was.
> -- Jamie
Rob
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Rob Landley @ 2009-01-05 21:07 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Jamie Lokier, Valdis.Kletnieks, Ingo Oeser,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
H. Peter Anvin, Sam Ravnborg
In-Reply-To: <1231152378.3326.14.camel@gimli.at.home>
On Monday 05 January 2009 04:46:18 Bernd Petrovitsch wrote:
> > My 850 Linux boxes are 166MHz ARMs and occasionally NFS-mounted.
> > Their /bin/sh does not do $((...)), and Bash is not there at all.
>
> I assume that the NFS-mounted root filesystem is a real distribution.
> And on the local flash is a usual busybox based firmware.
Building on an nfs mount is evil. Make cares greatly about timestamp
accuracy, and NFS's dentry cacheing doesn't really, especially when it
discards cached copies and re-fetches them, and the server and client's clocks
are a half-second off from each other.
Sometimes you haven't got a choice, but I hate having to debug the build
problems this intermittently causes. If you never do anything except "make
all" it should suck less.
> > If I were installing GCC natively on them, I'd install GNU Make and a
> > proper shell while I were at it. But I don't know if Bash works
>
> ACK.
>
> > properly without fork()* - or even if GCC does :-)
> >
> > Perl might be hard, as shared libraries aren't supported by the
> > toolchain which targets my ARMs* and Perl likes its loadable modules.
>
> The simplest way to go is probably to use CentOS or Debian or another
> ready binary distribution on ARM (or MIPS or PPC or whatever core the
> embedded system has) possibly on a custom build kernel (if necessary).
Building natively on target hardware or under QEMU is growing in popularity.
That's how the non-x86 versions of major distros build, and they even have
policy documents about it.
Here's Fedora's:
http://fedoraproject.org/wiki/Architectures/ARM#Native_Compilation
And here are the guys who opened the door for Ubuntu's official Arm port:
http://mojo.handhelds.org/files/HandheldsMojo_ELC2008.pdf
Of course hobbyists like myself haven't got the budget to buy a cluster of
high-end arm systems and they're not always even _available_ for things like
cris, and for new architectures (Xylinx microblaze anyone?) you'll always have
to cross compile to bootstrap the first development environment on 'em anyway,
and it's nice for your environment to be _reproducible_...
So a more flexible approach is to cross compile just enough to get a working
native development environment on the target, and then continue the build
natively (whether it's under qemu or on a sufficiently powerful piece of
target hardware). That's what my "art piece" Firmware Linux project does, and
there's a scratchbox rewrite (sbox2,
http://www.freedesktop.org/wiki/Software/sbox2 ) that does the same sort of
thing, and there are others out there in various states of development. With
x86 hardware so cheap and powerful, building under emulation for less powerful
targets starts to make sense.
Building natively under emulation (QEMU) is available to hobbyists like me and
avoids most of the fun cross compiling issues you don't find out about until
after you've shipped the system and somebody tries to do something with it you
didn't test. So far the record for diagnosing one of these is the two full-
time weeks my friend Garrett spent back at TimeSys tracking down why perl
signal handling wasn't working on mips; turned out it was using x86 signal
numbers rather which don't match the mips ones. The BSP had been shipping for
over a year at that point, but nobody had ever tried to do signal handling in
perl on mips before, and since the perl ./configure step is written in perl
finding the broken part took some doing. This was back in the mists of early
2007 so it's ancient history by now, of course...
If you have set up a cross compiler, you can configure QEMU to use distcc to
call out through its virtual network to the cross compiler running on the
host, which gives you a speed boost without reintroducing most of the horrible
cross compiling issues: there's still only a native toolchain so your build
doesn't have to keep two contexts (hostcc/targetcc) straight, ./configure
still runs natively so any binaries it builds can run and any questions it
asks about the host it's building on should give the right answers for the
target it's building for (including uname -m and friends), headers are
#included natively and libraries are linked natively (that's just how distcc
works, preprocessing and linking happen on the local machine) and there's only
one set so they can't accidentally mix and the cross compiler isn't even
_involved_ in that, make runs natively so it won't get confused by strange
environment variables (yeah, seen that one)...) Only the heavy lifting of
compiling preprocessed .c files to .o files gets exported, which is the one
thing the cross compiler can't really screw up.
But bootstraping a native build environment to run under the emulator is
something you want to keep down to as few packages as possible, because if
you're trying to get the same behavior across half a dozen boards, cross
compiling breaks every time you upgrade _anything_.
> [...]
>
> > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add
> > proper shared libs. Feel free to fund this :-)
>
> The above mentioned ARMs have a MMU. Without MMU, it would be truly
> insane IMHO.
Without an mmu you have a restricted set of packages that run anyway. No
variable length stacks, you have to use vfork() instead of fork() (no copy on
write), memory fragmentation is a big problem so malloc() fails way more
often...
So toolchain problems aren't a "hump" to get past on nommu systems: the area
past that it isn't necessarily any easier.
> Bernd
Rob
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Bernd Petrovitsch @ 2009-01-05 16:18 UTC (permalink / raw)
To: Jamie Lokier
Cc: Rob Landley, Valdis.Kletnieks, Ingo Oeser,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
H. Peter Anvin, Sam Ravnborg
In-Reply-To: <20090105150156.GD14503@shareable.org>
On Mon, 2009-01-05 at 15:01 +0000, Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
> > I assume that the NFS-mounted root filesystem is a real distribution.
>
> Not unless you call uClinux (MMU-less) a real distribution, no.
Not really.
> > > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add
> > > proper shared libs. Feel free to fund this :-)
> >
> > The above mentioned ARMs have a MMU. Without MMU, it would be truly
> > insane IMHO.
>
> We have similar cross-build issues without MMUs... I.e. that a lot of
Of course.
> useful packages don't cross-build properly (including many which use
> Autoconf), and it might be easier to make a native build environment
Tell me about it - AC_TRY_RUN() is the culprit.
And `pkg-config` supports cross-compilation only since 18 months or so.
Before one had to rewrite the generated .pc files.
[...]
> You mentioned ARM Debian. According to
> http://wiki.debian.org/ArmEabiPort one recommended method of
> bootstrapping it is building natively on an emulated ARM, because
> cross-building is fragile.
That's of course the other solution - if qemu supports your
$EMBEDDED_CPU good enough.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Jamie Lokier @ 2009-01-05 15:01 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Rob Landley, Valdis.Kletnieks, Ingo Oeser,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
H. Peter Anvin, Sam Ravnborg
In-Reply-To: <1231152378.3326.14.camel@gimli.at.home>
Bernd Petrovitsch wrote:
> I assume that the NFS-mounted root filesystem is a real distribution.
Not unless you call uClinux (MMU-less) a real distribution, no.
> > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add
> > proper shared libs. Feel free to fund this :-)
>
> The above mentioned ARMs have a MMU. Without MMU, it would be truly
> insane IMHO.
We have similar cross-build issues without MMUs... I.e. that a lot of
useful packages don't cross-build properly (including many which use
Autoconf), and it might be easier to make a native build environment
than to debug and patch all the broken-for-cross-build packages.
Especially as sometimes they build, but fail at run-time in some
conditions.
But you're right it's probably insane to try. I haven't dared as I
suspect GCC and/or Binutils would break too :-)
I'm sticking instead with "oh well cross-build a few packages by hand
and just don't even _try_ to use most of the handy software out there".
You mentioned ARM Debian. According to
http://wiki.debian.org/ArmEabiPort one recommended method of
bootstrapping it is building natively on an emulated ARM, because
cross-building is fragile.
-- Jamie
^ 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