Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list

2008-06-10 Thread Jamie Lokier
Wolfgang Denk wrote: Being unable to do this just because we now also would need a native Perl is indeed a PITA... You can run the Perl bit with ssh remote perl, and still do the rest of the compile natively. It's not pretty, but workable. -- Jamie -- To unsubscribe from this list: send the

Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list

2008-06-10 Thread Jamie Lokier
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: I would be surprised if it was possible to compile Linux with gcc 4.2 with 32MiB of total system memory. Hint: if memory really gets tight, you can use swap space. Either to a local drive (either through PCI or

Re: cross-compiling alternatives

2008-06-13 Thread Jamie Lokier
Bernd Petrovitsch wrote: Actually the size of ints (or any other type) can be easily deduced without running a (for the target) compiled binary: - compile the binary (for the target) with an initialized variable with that value. - use cross nm (or a similar tool) to read it from there. Or

Re: Cross Compiler and loads of issues

2008-06-13 Thread Jamie Lokier
Bill Traynor wrote: Maybe I'm being dense, but what's specifically wrong with the current toolchain universe? Back in ye olde days, you could download GCC and Binutils from gnu.org, configure for whatever is your architecture, and most times it just worked. For some reason, that stopped a

Re: cross-compiling alternatives

2008-06-13 Thread Jamie Lokier
Enrico Weigelt wrote: But: the question is whether you'll need such a test at all or if just using sizeof() at the right place won't do the trick ;-P It's best to do that if you can, and nearly always possible. There are a few coding techniques - especially performance sensitive - where that's

Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

2008-06-13 Thread Jamie Lokier
Robert Schwebel wrote: On Fri, Jun 13, 2008 at 08:30:52AM +0200, Alexander Neundorf wrote: Battle of Wesnoth is currently converted to both Scons and CMake, and in the end they will decide about the winner. (since Eric is good at arguing I guess it will be scons). The thing is that

Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

2008-06-13 Thread Jamie Lokier
Robert Schwebel wrote: On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote: A trouble with that is some packages have hundreds of user-selectable options - or even thousands. I've not seen a package with thousands of user selectable options. It's not even desirable, because

Re: about size optimizations (Re: Not as much ccache win as I expected)

2008-06-15 Thread Jamie Lokier
David Woodhouse wrote: On Sat, 2008-06-14 at 10:56 +0100, Oleg Verych wrote: I saw that. My point is pure text processing. But as it seems doing `make` is a lot more fun than to do `sh` `sed`. The problem is that it _isn't_ pure text processing. There's more to building with --combine

Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

2008-06-16 Thread Jamie Lokier
Enrico Weigelt wrote: Most times I've seen those checks, they silently enable some features, eg. if it looks for certain kernel devices. Definitively the wrong way! Agreed. Though, you do often have to check for headers etc., otherwise you won't have the definitions needed to work with those

Re: cross-compiling alternatives

2008-06-16 Thread Jamie Lokier
Bernd Petrovitsch wrote: _check_ for many installed libraries. Get them wrong, and you have the same problems of untested combinations. As long as I can specify that libfoo support must be compiled in (and thus libfoo must be present) and the tools throw an error if it doesn't find it, I

Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

2008-06-16 Thread Jamie Lokier
Enrico Weigelt wrote: Reality is that Kconfig front end to autotools does work - as you've proved. It's a good idea. :-) Now, we just need an autoconf-alike frontend for Kconfig ;-) I agree and would support: ./configure --menu Invokes a configuration menu / wizard for

Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

2008-06-16 Thread Jamie Lokier
David Woodhouse wrote: On Mon, 2008-06-16 at 11:49 +0100, Jamie Lokier wrote: But here's the thing: do you really want every package have code calling every different variation on a system call, at run time, until it finds one that works? No. That functionality lives in libc, if you want

Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

2008-06-16 Thread Jamie Lokier
Alexander Neundorf wrote: On Monday 16 June 2008 13:39:46 you wrote: ... If you're going to rewrite Autotools using GNU Make, why not ask if another tool would be better, perhaps a tool specially designed for the job? Go ahead. The first part of going ahead is to brainstorm

Re: prevalence of C++ in embedded linux?

2008-07-30 Thread Jamie Lokier
Bernd Petrovitsch wrote: If GOLD is as old and flexible (and portable?) as binutils, The author says it will only work with ELF, and he does not intend to add support for all the other things binutils does. gcc and/or other huge software maintained to death, it is probably similar complex and

Re: [PATCH 00/10] AXFS: Advanced XIP filesystem

2008-08-21 Thread Jamie Lokier
Jared Hulbert wrote: The biggest improvement is in the way AXFS allows for each page to be XIP or not. First, a user collects information about which pages are accessed on a compressed image for each mmap()ed region from /proc/axfs/volume0. That 'profile' is used as an input to the image

Re: [PATCH 00/10] AXFS: Advanced XIP filesystem

2008-08-22 Thread Jamie Lokier
Jared Hulbert wrote: On Fri, Aug 22, 2008 at 11:13 AM, Jamie Lokier [EMAIL PROTECTED] wrote: Greg Ungerer wrote: One thing for sure is that many people who do non-MMU setups are interested in XIP to get the space savings. These are very often small devices with very constrained RAM

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-27 Thread Jamie Lokier
Bernd Petrovitsch wrote: If you develop an embedded system (which is partly system integration of existing apps) to be installed in the field, you don't have that many conceivable work loads compared to a desktop/server system. And you have a fixed list of drivers and applications. Hah! Not

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-27 Thread Jamie Lokier
Linus Torvalds wrote: Most LOCs of the kernel are not written by people like you or Al Viro or David Miller, and the average kernel developer is unlikely to do it as good as gcc. Sure. But we do have tools. We do have checkstack.pl, it's just that it hasn't been an issue in a long

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-27 Thread Jamie Lokier
Bernd Petrovitsch wrote: 32MB no-MMU ARM boards which people run new things and attach new devices to rather often - without making new hardware. Volume's too low per individual application to get new hardware designed and made. Yes, you may have several products on the same hardware

Re: [PATCH 00/10] AXFS: Advanced XIP filesystem

2008-09-15 Thread Jamie Lokier
Jared Hulbert wrote: What kind of NOR you using? That is not what I measure with fast synchronous burst NOR's. I think the fast in fast synchronous gives it away :-) I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s. By the way, what speeds do you get on

Re: Power cut in management

2008-10-18 Thread Jamie Lokier
[EMAIL PROTECTED] wrote: I'm working with a board where the power is turn on/off through a key as in a car. Is there any design pattern to afford that? It's the first time I have to manage a situation where the power can suddenly cut in anytime. Hardware guys are working to get time to do a

Re: Power cut in management

2008-10-18 Thread Jamie Lokier
David Woodhouse wrote: On Sat, 2008-10-18 at 12:49 +0100, Jamie Lokier wrote: Can you use a journalling filesystem like ext3, reiserfs, xfs, or even UBIFS on the card, or does it have to be FAT? With a journalling filesystem, they vary on the details but basically if you can finish

Re: Power cut in management

2008-10-18 Thread Jamie Lokier
David Woodhouse wrote: On Sat, 2008-10-18 at 13:56 +0100, Jamie Lokier wrote: Trouble is, that's not suitable for a dashboard unit where users plug in their own media card. Marco didn't say if the SD card is for users to plug in their own media, or if it's internal storage

Re: LZMA inclusion

2008-12-08 Thread Jamie Lokier
Phillip Lougher wrote: One-shot LZMA decoding therefore isn't going to work very well with future versions of Squashfs, obviously a solution (as is currently done with the Squashfs-LZMA patches) is to use separately allocated contiguous input/output buffers, and memcpy into and out of them,

Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

2008-12-29 Thread Jamie Lokier
David Brownell wrote: The reason single-bit operations don't provide error paths is twofold. First, they started as wrappers for can't-fail register accessors. Second, it's extremely unrealisitic to expect much code to handle any kind of faults in the middle of bitbanging loops ... or even

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-03 Thread Jamie Lokier
Rob Landley wrote: This doesn't _need_ bignum support. It maxes out around 72 bits and the _result_ can't use more than about $SHIFT bits because you're dividing by the amount you shifted, so just chop off the bottom 32 bits, do a normal 64 bit division on the top (it has to fit), and then

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

2009-01-04 Thread Jamie Lokier
Rob Landley wrote: In a private email, Bernd Petrovitsch suggested set -- $i and then using NAME=$1; PERIOD=$2. (I keep getting private email responses to these sort of threads, and then getting dismissed as the only one who cares about the issue. Less so this time around, but still...)

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

2009-01-04 Thread Jamie Lokier
Bernd Petrovitsch wrote: (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) Believe it or not, but there are folks out there who build the firmware on ARM 200 MHz NFS-mounted systems natively (and not simply

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-13 Thread Jamie Lokier
Paul Mundt wrote: This happens in a lot of places, like embedded gentoo ports, where almost all of the work is sent across distcc to a cross-compilation machine. In systems that use package management, it is done on the host through emulation, or painfully cross-compiled. Ah yes, I remember

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-15 Thread Jamie Lokier
Pádraig Brady wrote: The $(( ... )) construct is standard POSIX shell syntax, see http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html#tag_02_06_04 Bash supports $[ ... ] as an alternate syntax for the same thing. Perhaps you were thinking of that. I think the

Re: Wait for console to become available, v3.2

2009-04-22 Thread Jamie Lokier
Alan Cox wrote: To start with there is no reason that the USB console can't implement a maybe we have hardware, maybe I buffer 64K until it shows up behaviour and bind to hardware as and when USB serial devices get inserted. Ah, that doesn't work, when you want to use the USB serial console

Re: Wait for console to become available, v3.2

2009-04-22 Thread Jamie Lokier
Linus Torvalds wrote: [ Actually, looking closer we should not use that particular name: we already have something called a console_driver which is really the current VT driver. Speaking of names... The word console is used to mean three different things in the kernel. Last time I had

Re: Wait for console to become available, v3.2

2009-04-22 Thread Jamie Lokier
Alan Cox wrote: It would be a sensible though boring cleanup to change all the VC (virtual console) stuff to use the name VT (virtual terminal) consistently. Then we would have two completely different meanings for virtual terminal in the kernel. As opposed to three meanings for console

Re: Wait for console to become available, v3.2

2009-04-24 Thread Jamie Lokier
David VomLehn wrote: This looks like a good plan and not hard to implement. It even should be possible to fit USB disk drives into the scheme. That would definitely rock. How about this, perhaps in the generic device model: 1. Whenever a device's existence is detected by its parent

Re: Wait for console to become available, v3.2

2009-04-24 Thread Jamie Lokier
David VomLehn wrote: I think this is over-engineered. This focused on boot devices, so you really don't care about things like buses, and I don't perceive a broader use. What really matters is particular boot device types, wherever they came from. I'm thinking this broader use: - My boot

Re: Wait for console to become available, v3.2

2009-04-26 Thread Jamie Lokier
Alan Stern wrote: On Sat, 25 Apr 2009, Jamie Lokier wrote: I'm thinking this broader use: - My boot _script_ is waiting for a disk which identifies as UUID=392852908752345749857 to appear before it can mount it on /data. If there's no such disk, it proceeds without

Re: Wait for console to become available, v3.2

2009-04-26 Thread Jamie Lokier
Alan Stern wrote: On Sun, 26 Apr 2009, Jamie Lokier wrote: Are you suggesting this new interface be exported to userspace somehow? Not directly. Only in the same way that open(/dev/console) delays until there's a console, so reading the keyboard can delay until we know if we had

Re: Wait for console to become available, v3.2

2009-04-26 Thread Jamie Lokier
Kay Sievers wrote: _If_ the system doesn't wait for all block devices present at boot to be enumerated before the boot script, then when the script looks in that directory for a specific UUID, it would be good to wait until has everything present at boot been enumerated? says yes.

Re: Wait for console to become available, v3.2

2009-04-26 Thread Jamie Lokier
Kay Sievers wrote: On Mon, Apr 27, 2009 at 01:12, Jamie Lokier ja...@shareable.org wrote: Kay Sievers wrote: _If_ the system doesn't wait for all block devices present at boot to be enumerated before the boot script, then when the script looks in that directory for a specific UUID

Re: Can I run an application compiled with gcc ABI 2.95 on a kernel compiled with gcc ABI 3.4?

2009-05-15 Thread Jamie Lokier
George G. Davis wrote: On Fri, May 15, 2009 at 02:55:57PM +0100, Ben Dooks wrote: On Fri, May 15, 2009 at 02:51:05PM +0100, Jamie Lokier wrote: Eek, can you say a bit more about the ARM EABI mismatch? I would like to run a shiny modern ARM EABI kernel and userspace, but also need

Re: Can I run an application compiled with gcc ABI 2.95 on a kernel compiled with gcc ABI 3.4?

2009-05-15 Thread Jamie Lokier
Jamie Lokier wrote: Structure packing: Isn't that basically the same set of fixups that need to be done for 32-bit compatibility on 64-bit kernels? Could it even use the same code - sneakily replacing 32 with OABI and 64 with EABI? On second thoughts, I guess there may be a few fixups

Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

2009-06-13 Thread Jamie Lokier
Marco wrote: Linux traditionally had no support for a persistent, non-volatile RAM-based filesystem, persistent meaning the filesystem survives a system reboot or power cycle intact. The RAM-based filesystems such as tmpfs and ramfs have no actual backing store but exist entirely in the page

Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

2009-06-14 Thread Jamie Lokier
Marco wrote: Simply because the ramdisk was not designed to work in a persistent environment. One thing with persistent RAM disks is you _really_ want it to be robust if the system crashes for any reason while it is being modified. The last thing you want is to reboot, and find various

Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

2009-06-16 Thread Jamie Lokier
Marco wrote: There's the checksum, but the most important feature of this fs is the write protection. The page table entries that map the backing-store RAM are normally marked read-only. Write operations into the filesystem temporarily mark the affected pages as writeable, the write operation

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-16 Thread Jamie Lokier
Grant Likely wrote: http://patchwork.ozlabs.org/patch/24152/ I never actually pushed through and finished it because it turned out to be a non-issue for Ethernet devices in the end. However, I can see the value. With this approach, a driver can use a bus_register_notifier() variant

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-16 Thread Jamie Lokier
Grant Likely wrote: On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote: Something which lets you specify a dependency in a one-line MODULE_INIT_PREREQS() macro would be much nicer. That would work for some cases, but a lot of cases the problem is not module init

Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

2009-06-24 Thread Jamie Lokier
Marco wrote: Second question: what happens if the system crashing _during_ a write to a file. Does it mean that file will fail it's checksum when it's read at the next boot? Maybe files aren't so important. What about when you write a file, and then rename it over an existing file

Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

2009-06-24 Thread Jamie Lokier
Pavel Machek wrote: On Tue 2009-06-23 20:07:23, Marco wrote: You are talked about journaling. This schema works well for a disk, but what about a piece of ram? What about a crazy kernel that write in that area for a bug? Do you remember for example the e1000e bug? It's not I believe you

Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

2009-06-26 Thread Jamie Lokier
Marco Stornelli wrote: 2009/6/24 Jamie Lokier ja...@shareable.org: Marco wrote: Second question: what happens if the system crashing _during_ a write to a file.  Does it mean that file will fail it's checksum when it's read at the next boot? Maybe files aren't so important.  What

Re: 2.6.27- Sending uevent from a driver

2009-07-03 Thread Jamie Lokier
Alan Cox wrote: Or, maybe the userspace program can receive some sort of interrupt from the TTY device when it is ready for I/O. Perhaps there is another way to avoid continued polling? TIOCMIWAIT ioctl for modem signals, and just using poll/select() on the tty for I/O. Ah yes, the

Re: flicker free booting

2009-08-01 Thread Jamie Lokier
Bill Gatliff wrote: Actually, I'd rather that drivers look at the hardware itself, and verify that the configuration matches what the parameter specifies before making changes. That way you could use framebuffer= to communicate the desired setup to the driver in cases where the hardware

Re: New fast(?)-boot results on ARM

2009-08-14 Thread Jamie Lokier
Zan Lynx wrote: Or maybe its cheap and slow flash. In that case I think your only hope is to make all the code as small as possible and/or find a different flash filesystem that does not have to read so much of the device to mount. Perhaps use a read-only compressed filesystem for the

Re: new ipdelay= option for faster netboot

2009-08-19 Thread Jamie Lokier
Tim Bird wrote: David Miller wrote: From: Tim Bird tim.b...@am.sony.com Date: Mon, 17 Aug 2009 18:24:26 -0700 David Miller wrote: I have card/switch combinations that take up to 10 seconds to negotiate a proper link. What types of delays are these timeouts supposed to cover?

Re: 100Mbit ethernet performance on embedded devices

2009-08-19 Thread Jamie Lokier
Johannes Stezenbach wrote: a while ago I was working on a SoC with 200MHz ARM926EJ-S CPU and integrated 100Mbit ethernet core, connected on internal (fast) memory bus, with DMA. With iperf I measured: TCP RX ~70Mbit/sec (iperf -s on SoC, iperf -c on destop PC) TCP TX ~56Mbit/sec

Re: [PATCH 7/7] printk: provide a filtering macro for printk

2009-09-01 Thread Jamie Lokier
Marc Andre Tanner wrote: + * The check with sizeof(void*) should make sure that we don't operate on + * pointers, which the compiler wouldn't be able to optimize out, but only + * on string constants. Take a look at __builtin_constant_p in the GCC manual. You'll probably find that wrapping

Re: [PATCH 7/7] printk: provide a filtering macro for printk

2009-09-02 Thread Jamie Lokier
Mike Frysinger wrote: it depends completely on how the macro is intended to be used. if you want to maintain the this macro has a return value, then you have to use ({...}). if you want the macro to return a void, then you have to use do{...}while(0). Actually no. The difference is do

Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader

2009-12-22 Thread Jamie Lokier
Rob Landley wrote: However, if that's your minimum then you can't use the bootloader to re-flash the device, which is kind of handy. (It gives you an un-bricking fallback short of pulling out a jtag.) But doing that requires things like a network driver, TCP/IP stack, tftp implementation,

Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader

2009-12-29 Thread Jamie Lokier
Andy Green wrote: No TCP/IP, no TFTP, not even BOOTP (but it's a nice bonus), no command line interpreter (just a GPIO on board to boot into unbrick me mode :-), and most strikingly _no_ flash driver for flash chip du jour. To flash it you send a kernel to boot from RAM which is capable of

Re: [PATCH v2] char drivers: Ram oops/panic logger

2010-03-12 Thread Jamie Lokier
Andrew Morton wrote: I meant with the classic use of mtdoops, therefore with a flash partition without use MTD_RAM. Using MTD_RAM, it's more or less the same thing, with the exception of where you want deploy the log. For example: if in your system you have got a nvram you can use it

Re: [PATCH v2] char drivers: Ram oops/panic logger

2010-03-14 Thread Jamie Lokier
Marco Stornelli wrote: Il 13/03/2010 00:31, Jamie Lokier ha scritto: That'd be fine if the kernel link scripts choose the address, as long as it's consistent between different compiles and similar configurations. That'd be a bit simpler than the admin having to know the memory map well