The project itself. We are doing a lot of industrial automation projects, and over the years, everyone invents the typical IO framework stuff over and over again. Even worse, people with a different b

" Use autotools - Every custom config/makefile/build system is worse for everybody than autotools is. - We are all used to autotools, it works, nobody cares. - It's only two simple files to edit and i

rsc@callisto:soletta$ make -j 4 ARCH=arm CROSS_COMPILE=/opt/OSELAS.Toolchain-2014.12.0/arm-cortexa8-linux-gnueabihf/gcc-4.9.2-glibc-2.20-binutils-2.24-kernel-3.16-sanitized/bin/arm-cortexa8-linux-gnue

I don't think so. Let's stay here for the moment :-) Our first impression when we saw soletta was: wow, they did it right. And now you are removing autotools and replace that by Kconfig. I don't think

Hi Gustavo, Is there already a mailing list for soletta? rsc

Hi, Will you be at ELC-E? Sascha has a barebox talk there: http://embeddedlinuxconferenceeu2013.sched.org/event/d7296221f5c9c177a2f84f5da58ece9b#.Ujh1HR_Yo7Y System updating is an important feature fo

Yes. It's the first time that we have the permissions right in nfsroot :) rsc

Another nice thing if you work with (recent) ptxdist and with barebox: Barebox is not only able to load a kernel via tftp, but also via NFS. And ptxdist builds a userspace nfs server. So you can remot

Ack. "git add -p" is also pretty useful in the context of sorting work and rebaseinteractiveing ;) it into proper patches. rsc

We have a nice git+quilt feature in ptxdist: - You can configure a switch to extract quilt series into git repositories: that way ptxdist extracts a tar ball, checks the initial state into a git repos

Hi Tim, I wouldn't worry too much, elinux.org is still a great site! Just organize a few sprints with nice giveaways at ELC-E from time to time :) Last year after ELC-E after a mini-crossbuild-summit,

The EnergyMicro EFM32 port runs with devicetree. We put it into the onchip RAM, because it turned out that, when we tried to use sparse memory to make use of the 128 kB, Linux created 16 MB of data st

Uwe has posted our most recent patches, which are based on these, to ALKML recently. rsc

Seconded. However, this is all not true if you care about industrial projects and their quality requirements; you need chips with long term availability there, with reliable operation at the specified

We have been running with about 1 MB when working on the Cortex-M3 and EFM32 port recently, but it turned out that, even with xip, real work (more than a booting kernek) was only possible with 4 MB. r

Hi Stefan, Not related to this proposal, but note that we have used the openmoko DFU patches for adding support in Barebox: http://www.barebox.org/documentation/barebox-2010.12.0/dfu_command.html Chee

Tim, I like the idea in general, because could reduce the zoo of "old versions" to at least only a few versions, which might also get security updates, an rt patch etc. Maybe it is possible to align t

What I mean is that in the past we had more than once the case that we've found showstopper bugs in upstream gcc, binutils etc. (ARM has much less coverage than x86). It was never a problem in the pro

If you don't step into for example toolchain problems or other crazy things... Yes, that's a valuable option. The oftree is currently provided by the bootloader, and much of what it contains is unprob

Hi Andi, That's probably also a matter of taste. I still find it a feature to be able to cross compile the systems - we can still recompile whole systems consistently in just a few (ten) minutes, i.e.