From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0973BC43603 for ; Wed, 11 Dec 2019 10:25:55 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B94EE2073B for ; Wed, 11 Dec 2019 10:25:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gjgjS+6O" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B94EE2073B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:40554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iezBp-0000RM-Qv for qemu-devel@archiver.kernel.org; Wed, 11 Dec 2019 05:25:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43160) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iezBB-0008Ky-Lg for qemu-devel@nongnu.org; Wed, 11 Dec 2019 05:25:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iezB8-00055Y-KY for qemu-devel@nongnu.org; Wed, 11 Dec 2019 05:25:13 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:36875) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iezB8-00051S-7P for qemu-devel@nongnu.org; Wed, 11 Dec 2019 05:25:10 -0500 Received: by mail-ed1-x535.google.com with SMTP id cy15so18957144edb.4 for ; Wed, 11 Dec 2019 02:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rXhwFMG0BL17nGwkzk9W9CSbQJZYitzRX1dD1vccva8=; b=gjgjS+6OpeEo2LgclRLcH8qUXWj6mRIqdgebvqPEErQWDykbaLpL18R/NKAnz5M2AM FwkYZulewN1Wq3dD13EYWQo62TD1OhJEsZ3eipLtgDMqW0LY5CY1mpa8NPbP6N8cqlGP vRRdEB882uTHh67eF6WwAEr43DQg8gJMgMQTFPDOHrlngBu7MSWijT5/dX2kBeHgaxVz r0mWlZScSo1C3XXQGTga+aOguBQgFpzWS+Ik3hQcA8sZvwQGKU15iAZpUmWRuYjNsF6K GoXhCP/V4qnRHkGg4m827yJqyHgqRfjGlwJ+IeZyQG9yKmi59C4Ss8qMIZQFkfwzyfIJ S2LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rXhwFMG0BL17nGwkzk9W9CSbQJZYitzRX1dD1vccva8=; b=KtzHrR22qwkmJazD3Bj4uunhMEDGR7ORZvO1vmRIDJA/Nv66uLyoQuzlIAQkUmKTxz j2N2y2hhtc8mh2Z0M9E4eFQZI+ZqltUj1Wj6qvGm1sAZI45o/Yu3gl8eixwCCmpY/17b 8YzkrY0az+QZC/TYLjgdZyw3nXkfsWuKBgRIsSIyQzEoKI83IvmaVILu4KOMRfsaEm2s TOfE2Gxg8dwtR1VtHw1AfEmZ/ae0CssYS81dhVdNyx2OcuIbJwyjJ7cDE6F4uXvD6rSH Pmi/ZVn2K3pRvrG9wX/bSP1NFO4GTBoCkueOSmwK80gIIicIa5C/w/szm+pxBUJZnmWf eWZw== X-Gm-Message-State: APjAAAWx8Qyxr6vP3x1EfYkchdpsoVzRrQOB7tL5dxLLZKqlblMkDnCy t2XuPiBfjSUv/NEuFvDby2DSVc+LOAuI9MExn2M= X-Google-Smtp-Source: APXvYqyLnYzegmmERscotwEokNTnTKcTl+ccwWsBJbfZ4UU80dZQ0szbRZJRyiwm2CU0BBjM/gDNX5p3TqhpNi0EHp0= X-Received: by 2002:a17:906:5246:: with SMTP id y6mr2387461ejm.330.1576059908214; Wed, 11 Dec 2019 02:25:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Esteban Bosse Date: Wed, 11 Dec 2019 11:24:57 +0100 Message-ID: Subject: Re: BeagleBone support, omap1, omap2, omap3, etc. To: Niek Linnenbank Content-Type: multipart/alternative; boundary="000000000000f953d105996b0ae5" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::535 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , "Daniel P . Berrange" , Joaquin de Andres , QEMU Developers , Markus Armbruster , Cleber Rosa , Paolo Bonzini , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000f953d105996b0ae5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=B3: > Hello Philippe and Esteban, > > On Tue, Dec 10, 2019 at 10:55 AM Philippe Mathieu-Daud=C3=A9 > wrote: > >> Hi Esteban, >> >> On 12/3/19 4:24 PM, Esteban Bosse wrote: >> > Ping >> > >> > El mi=C3=A9., 6 nov. 2019 16:04, Esteban Bosse > > > escribi=C3=B3: >> > >> > 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, the= y >> > 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 ol= d >> > 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 thi= s >> > task, but I can't see the right way to make this work because it i= s >> > 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 wi= th >> > 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 th= e >> > same time I would like to write some documentation about the proce= ss >> > 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 wan= t > 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 simila= r > 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 ti= me >> > (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 > > --000000000000f953d105996b0ae5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Niek and Philippe,

Thank you very much for yo= ur support and all the information provided,=C2=A0
I will create a new &= quot;roadmap" with all this excellent=C2=A0information and try again.<= br>
Thank you again and best=C2=A0regards,
Esteban Bosse
=
El mar= ., 10 dic. 2019 a las 20:51, Niek Linnenbank (<nieklinnenbank@gmail.com>) escribi=C3=B3:
Hello Philippe and Esteban,

On Tue, Dec 10,= 2019 at 10:55 AM Philippe Mathieu-Daud=C3=A9 <philmd@redhat.com> wrote:
Hi Esteban,

On 12/3/19 4:24 PM, Esteban Bosse wrote:
> Ping
>
> El mi=C3=A9., 6 nov. 2019 16:04, Esteban Bosse <estebanbosse@gmail.com
> <mailto:estebanbosse@gmail.com>> escribi=C3=B3:
>
>=C2=A0 =C2=A0 =C2=A0Hello!
>
>=C2=A0 =C2=A0 =C2=A0Some months ago I started to work trying to port th= e Beaglebone
>=C2=A0 =C2=A0 =C2=A0support from the old qemu-linaro fork to the new QE= MU mainstream.
>
>=C2=A0 =C2=A0 =C2=A0During my work I found that the Beaglebone have an = OMAP3 mpu this
>=C2=A0 =C2=A0 =C2=A0mpu has very strong relation with the OMAP2 and OMA= P1 in qemu, they
>=C2=A0 =C2=A0 =C2=A0implement a lot of functions in common.
>
>=C2=A0 =C2=A0 =C2=A0Then I understood that the omap1 and omap2 don'= t implement things
>=C2=A0 =C2=A0 =C2=A0like QOM and needs a lot of work to upgrade it, at = the same time
>=C2=A0 =C2=A0 =C2=A0they are some boards like: omap1_sx, palm, nseries = that implement
>=C2=A0 =C2=A0 =C2=A0this mpus.
>
>=C2=A0 =C2=A0 =C2=A0Looking the datasheet of the omap1 I realized that = it's an very old
>=C2=A0 =C2=A0 =C2=A0device and some questions like "make sense wor= k with this old
>=C2=A0 =C2=A0 =C2=A0device?" 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-d= evel@nongnu.org/msg636936.html

Or you can use the schema followed by Niek when adding the Allwinner H3: https://www.mail-archive.com/qemu-d= evel@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

>=C2=A0 =C2=A0 =C2=A0When I went to the KVM Forum the last week I talked= with some of
>=C2=A0 =C2=A0 =C2=A0you, and you help my with different ideas and propo= sal to make this
>=C2=A0 =C2=A0 =C2=A0task, but I can't see the right way to make thi= s work because it is
>=C2=A0 =C2=A0 =C2=A0a lot of work.
>
>=C2=A0 =C2=A0 =C2=A0My motivation is learn more about embedded devices,= architecture,
>=C2=A0 =C2=A0 =C2=A0kernel, etc. and of course contribute to the commun= ity.
>
>=C2=A0 =C2=A0 =C2=A0I would love to hear your opinions about this 3 rel= ated devices with
>=C2=A0 =C2=A0 =C2=A0they respected boards.
>
>=C2=A0 =C2=A0 =C2=A0Maybe someone is interested to work with me.
>=C2=A0 =C2=A0 =C2=A0I=C2=A0dream to make this work beautiful (like the = musca board with the
>=C2=A0 =C2=A0 =C2=A0armsse and armv7m modules) with a good variety of t= ests. And in the
>=C2=A0 =C2=A0 =C2=A0same time I would like to write some documentation = about the process
>=C2=A0 =C2=A0 =C2=A0with 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?
<= br>
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 t= he bare minimum: kernel output.
What I mean by that is, get the l= inux source and compile it for your target machine. Next, take the QEMU sou= rce and choose
any existing machine that come closest to the mach= ine 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, -a= ppend and -dtb arguments.

If you are lucky, serial= output already works since the machine is similar to the one you want to i= mplement. 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, conn= ect with gdb
and give the 'lx-dmesg' command you'll r= ead 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.=C2=A0 A= nd then, you have a starting point to start the real work using the
steps described above by Philippe.

Regards,=
Niek


=C2=A0

>
>=C2=A0 =C2=A0 =C2=A0If someone want to work with me in this task, shoul= d know that I
>=C2=A0 =C2=A0 =C2=A0don't have to much experience and I'm doing= this job in my free time
>=C2=A0 =C2=A0 =C2=A0(this means that I work only in my free time).
>
>=C2=A0 =C2=A0 =C2=A0I appreciate any kind of comment or advice.
>
>=C2=A0 =C2=A0 =C2=A0Thanks for your time ;)
>=C2=A0 =C2=A0 =C2=A0EstebanB
>



--
Niek Linnenbank

--000000000000f953d105996b0ae5--