(I've added qemu-devel to the cc list; some people don't read the qemu-arm list.)
On Sat, 10 Aug 2019 at 16:24, Esteban Bosse <estebanbo...@gmail.com> wrote: > El sáb., 10 ago. 2019 23:01, Peter Maydell <peter.mayd...@linaro.org> > escribió: >> On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbo...@gmail.com> wrote: >> > I am new in this world, but I want to port the old beagle support for >> > qemu-linaro to mainstream. >> >> That would certainly be nice. The major issue is that the >> patchset in that tree is (a) often in an older style >> of API that would need to be updated to use the current >> recommended-practice APIs to go upstream, and (b) in >> some places still has multiple changes tangled together >> that would need to be disentangled to form a clean >> reviewable patchset. > > (a) Sounds "not impossible" then for a beginer, hahaha. > I am looking other boards like Musca to use it as example > > (b) I don't know yet how to make the patches I have to learn everything. > >> >> I'm happy to provide advice and code review if you're >> interested in doing this work and helping to maintain >> it in the upstream tree. > > > Yes! I am interested, I have a repo where I am doing my firsts trys to > understand how qemu and the beagle are. > > How do you recommend to start? Here's something I wrote up in 2015 the last time somebody talked about maybe trying to get the beagle/omap3 changes into master: The initial steps here would be: 1) rebase the patchset on to qemu master and fix up the breakage due to API changes in qemu [this will be moderately painful if you haven't been following the API changes as they happened; if you're interested in taking on the omap3 patches then I could maybe do this step for you] 2) add support for direct boot of a guest kernel via "-kernel" (currently only "boot via an SD card image" is supported, which is awkward because the u-boot image insists on checking every device on the board and won't boot if any are missing) 3) build a cut-down minimally configured kernel that only needs the smallest possible set of devices [in particular, no SPI, I2C, MMC or graphics] 4) reorder the patchstack so that it starts with those relating to the required minimal device set and the SoC model and the board model, and the complicated ones to do with I2C etc are afterwards; check the kernel boots on this initial set 5) update the patches to correspond to current QEMU practice for QOM device modelling (the code in that tree is somewhat old and does many things in out of date ways) 6) submit the minimal-device patches and get them through code review and into QEMU 7) then start trying to clean up the remaining patches one device at a time You'll need (or will learn :-)) familiarity with handling stacks of patches in git, rebasing them, reordering them, splitting them, and so on. Personally I use 'stgit' as a frontend to doing that, but you can do it all with raw git too. Back in 2014 or whenever it was I abandoned the idea of doing this upstreaming work I reckoned it was probably a couple of months worth of (full-time) work to get everything upstream. thanks -- PMM