Re: BeagleBone support, omap1, omap2, omap3, etc.

[Esteban Bosse <estebanbosse@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 --]