qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Esteban Bosse <estebanbosse@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"Daniel P . Berrange" <berrange@redhat.com>,
	Joaquin de Andres <me@xcancerberox.com.ar>,
	Markus Armbruster <armbru@redhat.com>,
	Niek Linnenbank <nieklinnenbank@gmail.com>,
	Cleber Rosa <crosa@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: BeagleBone support, omap1, omap2, omap3, etc.
Date: Tue, 10 Dec 2019 10:55:47 +0100	[thread overview]
Message-ID: <a579e1c4-fe3f-d8d0-3064-96473eb24e3a@redhat.com> (raw)
In-Reply-To: <CAGbAg_A5G2trFWEuAL2da169v=XFrS44g64F6yZo5phLC+T=PQ@mail.gmail.com>

Hi Esteban,

On 12/3/19 4:24 PM, Esteban Bosse wrote:
> Ping
> 
> El mié., 6 nov. 2019 16:04, Esteban Bosse <estebanbosse@gmail.com 
> <mailto:estebanbosse@gmail.com>> escribió:
> 
>     Hello!
> 
>     Some months ago I started to work trying to port the Beaglebone
>     support from the old qemu-linaro fork to the new QEMU mainstream.
> 
>     During my work I found that the Beaglebone have an OMAP3 mpu this
>     mpu has very strong relation with the OMAP2 and OMAP1 in qemu, they
>     implement a lot of functions in common.
> 
>     Then I understood that the omap1 and omap2 don't implement things
>     like QOM and needs a lot of work to upgrade it, at the same time
>     they are some boards like: omap1_sx, palm, nseries that implement
>     this mpus.
> 
>     Looking the datasheet of the omap1 I realized that it's an very old
>     device and some questions like "make sense work with this old
>     device?" comes to my mind.

The OMAP3 reuse various components of the OMAP1/2.
Although in old shape, the OMAP1/2 are in the codebase and work.
It make sense to me to start upgrading the OMAP1/2 to new QOM standard, 
then add the OMAP3 missing parts.

The previous recommendations from Peter are still valid:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg636936.html

Or you can use the schema followed by Niek when adding the Allwinner H3:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg662591.html

That is:

- Add tests using old code (booting Linux, network access in guest)
- Add an empty board
- Plug an empty OMAP SoC into the board, add the PoP LPDRAM
- Add a ARM926 core into the SoC
- Add most of the devices as UnimplementedDevice
- Add the interrupt controller in the SoC
- Add the UART in the SoC
- Add the Timers in the SoC
- Try to boot a Linux kernel (UART, TMR, then IRQ tested)
- Add the SD controller in the SoC
- Plug a drive to the SD in the board
- Try to boot u-boot
- You can now start the OMAP2 using a ARM1136 core
- Add the missing UNIMP devices (loop to previous steps)
- Add network controller
- Run tests (booting Linux, network access in guest)
- Remove old code

>     When I went to the KVM Forum the last week I talked with some of
>     you, and you help my with different ideas and proposal to make this
>     task, but I can't see the right way to make this work because it is
>     a lot of work.
> 
>     My motivation is learn more about embedded devices, architecture,
>     kernel, etc. and of course contribute to the community.
> 
>     I would love to hear your opinions about this 3 related devices with
>     they respected boards.
> 
>     Maybe someone is interested to work with me.
>     I dream to make this work beautiful (like the musca board with the
>     armsse and armv7m modules) with a good variety of tests. And in the
>     same time I would like to write some documentation about the process
>     with the final idea to "make an easier way for new contributors".

Very good idea.

Niek, since you recently did the same, do you mind sharing your 
experience, tell us what was not clear or hard to understand, so we can 
have a better idea what part of the documentation/process we should 
improve first, to help and welcome new contributors?

> 
>     If someone want to work with me in this task, should know that I
>     don't have to much experience and I'm doing this job in my free time
>     (this means that I work only in my free time).
> 
>     I appreciate any kind of comment or advice.
> 
>     Thanks for your time ;)
>     EstebanB
> 



  reply	other threads:[~2019-12-10  9:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 15:04 BeagleBone support, omap1, omap2, omap3, etc Esteban Bosse
2019-12-03 15:24 ` Esteban Bosse
2019-12-10  9:55   ` Philippe Mathieu-Daudé [this message]
2019-12-10 19:51     ` Niek Linnenbank
2019-12-11 10:24       ` Esteban Bosse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a579e1c4-fe3f-d8d0-3064-96473eb24e3a@redhat.com \
    --to=philmd@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=crosa@redhat.com \
    --cc=estebanbosse@gmail.com \
    --cc=me@xcancerberox.com.ar \
    --cc=nieklinnenbank@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).