Sorry I'm not threading this right, just subscribed to the list and don't have the old posts to reply to. Reading the web archive... Bios issues like this come up in the context of qemu sometimes: htt

Are you just taking proposals, or are you taking expressions of interest in being sponsored to do the work? Because if nobody else has taken this one yet, I could probably pull it off. :) http://tree.

Linux may not run on it, but being able to control/program cheap plastic embedded devices from a Linux host might be interesting too. (Allowing Linux to be part of an embedded manufacturing process ma

Would such a library potentially be something that Linux distros install openly (instead of surreptitiously ala libdecss), and thus support playback out of the box instead of "google for a wiki page,

Hence the need for some legal entity (like the SFLC) to analyze the result, issue an opinion statement about it, and put out the "oh _please_ bring this thing to trial so I can defend it" offer. (Just

Does u-boot acknowledge your status as u-boot-v2? The u-boot project seems to be the dominant bootloader out there right now for non-x86 stuff. It would be nice if it could be simplified and genericiz

Ok, I'd like to propopse something I'm not likely to be able to _do_ but which SOMEBODY should. Integrate device tree support into QEMU. What I mean by that is allow qemu to take a flattened device tr

Oh dear. That does make barebox a heck of a lot more interesting. I'm sorry to hear about the end of u-boot as a Linux-kernel compatible project. It's a pity, it _was_ close to becoming a de-facto Lin

For background of CELF project proposals, see: http://elinux.org/CELF_Open_Project_Proposal_2010 Summary: Integrate a flattened device tree parser into the emulator QEMU, so QEMU can create board emul

Which bits does it do? Every piece of software needs something to initialize the DRAM controller. After that, they could presumably just jump to a known location in flash that the kernel lives at, and

Constant propogation is actually required by c99. (I had to learn this stuff back when I was maintaining a tinycc fork, before the original version relaunched itself as a windows-only project.) Also,

The QEMU project has a fairly general purpose "Tiny Code Generator" which is capable of producing machine code for every target QEMU supports. This code generator is well maintained (by the qemu devel

Ok, not aiming to be a generic bootloader then. You're only trying to support hardware that has the flash equivalent of a floppy drive. Got it. Because if they didn't you wouldn't support them? Bit of

Actually I was referring to section 6.6, "constant expressions" http://busybox.net/~landley/c99-draft.html#6.6 You're referring to remembering that a constant value assigned to a variable can't have b

That's one of the few optimizations tinycc already did, so I tend to assume it's in everything. :) It would be nice. I'm building self-bootstrapping Linux systems for various targets so I can regressi

He'd be a great person to sponsor to get it finished/updated and checked in, then. (Or his company, code sourcry, would.) Me, I just want to use the result. By the way, device trees were a topic at th

QEMU: it's not just for breakfast anymore. Rob

Because boards that use things like uClibc and busybox just aren't interesting to you? Please don't confuse "development environment" with "build environment". A development environment has xterms and

Before replying, I note that Mark Miller and I gave a presentation entitled "Developing for non-x86 targets using QEMU" Ohio LinuxFest in October. http://impactlinux.com/fwl/downloads/presentation.pdf

I started programming on a commodore 64. By modern standards, that system is so far down into "embedded" territory it's barely a computer. And yet people did development on it. http://landley.net/hist