On Sun, Sep 1, 2013 at 9:24 AM, Elvis Dowson <elvis.dow...@gmail.com> wrote: > > On Sep 1, 2013, at 8:08 AM, Bruce Ashfield <bruce.ashfi...@windriver.com> > wrote: > >> On 13-08-31 2:46 PM, Elvis Dowson wrote: >>> Hi, >>> In preparation for adding additional qemuarm machine configurations >>> to the linux-yocto kernels, can we rename the existing >>> standard/arm-versatile-926ejs branch to standard/qemuarm? >>> >> >> As I've mentioned before, there's absolutely no reason to do this, >> the branch name represents the machine support for the versatile >> and qemuarm re-uses it. So it can stay as is. > > If we add QEMU support for newer ARM architectures, like Cortex A8, A9 and > A15, it's a bit confusing, and not immediately obvious if one should using a > kernel branch intended for an old ARM v5 instruction set branch. > > At least for me, the first time I saw it, my first reaction was "this must be > old and incompatible".
Understandable. > > Changing it to a generic form such as standard/qemuarm, like it's done for > the other architectures, e.g. standard/qemuppc, gives a better indication > that it can potentially support a set of generic arm architectures, purely > from a naming perspective. qemux86 builds and boots from standard/common-pc qemumips builds and boots from standard/mti-malta32 qemumips64 builds and boots from standard/mti-malta64 qemuppc builds from a specially named branch, since there is no real hardware that backs it. Don't get me wrong, we can change it, but I won't be changing it at this point in the yocto dev cycle, and the real point I'm trying to make is that it doesn't matter. In fact, Darren and I have been trying to remove board branches when possible and just build and boot boards from standard/base. The only time we really need board branches is when they make changes that are unsafe for other boards and platforms .. and we really do try to limit that. So my suggestion would be that we either re-use the arm-versatile branch for now, or use standard/base, since these emulated platforms shouldn't be breaking other boards. > > I would strive for branch naming consistency, for the qemu architectures. > >> >>> Also, can we merge all the changes from the standard/base branch into this >>> branch? >> >> This happens for every single branch in the repository. >> >>> >>> I'm preparing a set of patches for qemuarma9 support for linux-yocto-3.10, >>> and would like the qemuarm branch updated, before releasing the patches, if >>> possible. >> >> It's full up to date .. at all times :) > > Ok, I've just built and tested a qemuarma9 machine configuration, with a > separate defconfig, shall I send across the patches? kernel patches, definitely, send them here. If you are talking about patches to runqemu, and related infrastructure, to start the boot, then send them to oe-core, and chances are they won't be accepted at this point in the dev cycle. If you have a machine.conf and board layer, then we need to find it a home while we figure out how to get the support into core. But I'd definitely like to see those changes as well, even if they are from a github or other externally hosted layer. As for the configuration, you can send it along as a defconfig, but I'll need to factor it out into a board fragment, since we don't maintain full defconfigs for boards that boot from linux-yocto. I can demonstrate how to factor it down to a fragment, if you haven't already done it. Cheers, Bruce > > Elvis Dowson > > > > > _______________________________________________ > linux-yocto mailing list > linux-yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/linux-yocto -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
