From: Esteban Bosse <estebanbosse@gmail.com>
To: Niek Linnenbank <nieklinnenbank@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P . Berrange" <berrange@redhat.com>,
"Joaquin de Andres" <me@xcancerberox.com.ar>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Markus Armbruster" <armbru@redhat.com>,
"Cleber Rosa" <crosa@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: BeagleBone support, omap1, omap2, omap3, etc.
Date: Wed, 11 Dec 2019 11:24:57 +0100 [thread overview]
Message-ID: <CAGbAg_CX62Ds3yYZUx2Q2_53FEFO26+WZ8okPBxzfTWBbAbyQA@mail.gmail.com> (raw)
In-Reply-To: <CAPan3Wq=ru496SOb93YA6ytTJJbSFtTuXC_B-MPETC5_ipdE6A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5876 bytes --]
Hello Niek and Philippe,
Thank you very much for your support and all the information provided,
I will create a new "roadmap" with all this excellent information and try
again.
Thank you again and best regards,
Esteban Bosse
El mar., 10 dic. 2019 a las 20:51, Niek Linnenbank (<
nieklinnenbank@gmail.com>) escribió:
> Hello Philippe and Esteban,
>
> On Tue, Dec 10, 2019 at 10:55 AM Philippe Mathieu-Daudé <philmd@redhat.com>
> wrote:
>
>> 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?
>>
>
> Sure! Based on my own experience with the Allwinner H3, I can fully
> recommend the steps
> described above by Philippe to get the work done. Those are mostly the
> things I did as well.
>
> I think the best advice I can give you to get started is, start with the
> bare minimum: kernel output.
> What I mean by that is, get the linux source and compile it for your
> target machine. Next, take the QEMU source and choose
> any existing machine that come closest to the machine or SoC that you want
> to implement.
> Then, just try to get the kernel output working via the serial console by
> loading it with -kernel, -append and -dtb arguments.
>
> If you are lucky, serial output already works since the machine is similar
> to the one you want to implement. If not,
> you may need to check for things like the load address and DRAM addresses
> first and try to get output
> by reading the kernel dmesg via GDB [1]. If you start QEMU with -s -S
> arguments, connect with gdb
> and give the 'lx-dmesg' command you'll read the kernel output before it
> goes to the serial device.
> If you at least selected the right processor and things like the load
> address are OK, chances are good
> that you at least get some logging. And then, you have a starting point
> to start the real work using the
> steps described above by Philippe.
>
> Regards,
> Niek
>
> [1]
> https://www.kernel.org/doc/html/v4.10/dev-tools/gdb-kernel-debugging.html
>
>
>
>>
>> >
>> > 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
>> >
>>
>>
>
> --
> Niek Linnenbank
>
>
[-- Attachment #2: Type: text/html, Size: 7741 bytes --]
prev parent reply other threads:[~2019-12-11 10:25 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é
2019-12-10 19:51 ` Niek Linnenbank
2019-12-11 10:24 ` Esteban Bosse [this message]
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=CAGbAg_CX62Ds3yYZUx2Q2_53FEFO26+WZ8okPBxzfTWBbAbyQA@mail.gmail.com \
--to=estebanbosse@gmail.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=crosa@redhat.com \
--cc=me@xcancerberox.com.ar \
--cc=nieklinnenbank@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--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).