[Qemu-arm] Beagle Board support

[Qemu-arm] Beagle Board support

[Esteban Bosse]

[-- Attachment #1: Type: text/plain, Size: 155 bytes --]

Hi,

I am new in this world, but I want to port the old beagle support for
qemu-linaro to mainstream.

Someone is actually working on it or is interested?

[-- Attachment #2: Type: text/html, Size: 214 bytes --]

Re: [Qemu-arm] Beagle Board support

[Alex Bennée]

Esteban Bosse <estebanbosse@gmail.com> writes:

> Hi,
>
> I am new in this world, but I want to port the old beagle support for
> qemu-linaro to mainstream.

I think the main problem is the chip is no longer supported by TI and I
guess less likely to be supported in upstream OSes in the future.

> Someone is actually working on it or is interested?

Not that I'm aware of. If you want to do the port and are willing to be
a maintainer of it going forward then I guess it would be doable. Is
there any particular reason you want it in upstream rather than just
using the old qemu-linaro branch for your use case?

--
Alex Bennée

Re: [Qemu-arm] Beagle Board support

[Peter Maydell]

On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbosse@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.

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.

thanks
-- PMM

Re: [Qemu-arm] Beagle Board support

[Esteban Bosse]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

El sáb., 10 ago. 2019 19:07, Alex Bennée <alex.bennee@linaro.org> escribió:

>
> Esteban Bosse <estebanbosse@gmail.com> writes:
>
> > Hi,
> >
> > I am new in this world, but I want to port the old beagle support for
> > qemu-linaro to mainstream.
>
> I think the main problem is the chip is no longer supported by TI and I
> guess less likely to be supported in upstream OSes in the future.
>
:/

>
> > Someone is actually working on it or is interested?
>
> Not that I'm aware of. If you want to do the port and are willing to be
> a maintainer of it going forward then I guess it would be doable. Is
> there any particular reason you want it in upstream rather than just
> using the old qemu-linaro branch for your use case?
>
There is no big reason, I just want to learn and I believe that is a good
project  to start beacouse it "works" (with the old api) and I can use it
as base.

>
> --
> Alex Bennée
>
>

[-- Attachment #2: Type: text/html, Size: 1752 bytes --]

Re: [Qemu-arm] Beagle Board support

[Esteban Bosse]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

El sáb., 10 ago. 2019 23:01, Peter Maydell <peter.maydell@linaro.org>
escribió:

> On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbosse@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?
I think that I can understand some things in the old beagle.c file but the
omap3.c it's more heavy.
Maybe I can start with de omap3.c trying to refactor and split it in more
files styled for the new API.

What files do you recommend to read to try to understand more about the CPU
model?


> thanks
> -- PMM
>
Thank you!

>

[-- Attachment #2: Type: text/html, Size: 2936 bytes --]

Re: [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 <estebanbosse@gmail.com> wrote:
> El sáb., 10 ago. 2019 23:01, Peter Maydell <peter.maydell@linaro.org> escribió:
>> On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbosse@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

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 <estebanbosse@gmail.com> wrote:
> El sáb., 10 ago. 2019 23:01, Peter Maydell <peter.maydell@linaro.org> escribió:
>> On Sat, 10 Aug 2019 at 04:39, Esteban Bosse <estebanbosse@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