Re: [Qemu-devel] [Qemu-arm] Beagle Board support

[Peter Maydell]

(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 <address@hidden> wrote:
> El sáb., 10 ago. 2019 23:01, Peter Maydell <address@hidden> escribió:
>> On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <address@hidden> 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