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 (< [email protected]>) escribió: > Hello Philippe and Esteban, > > On Tue, Dec 10, 2019 at 10:55 AM Philippe Mathieu-Daudé <[email protected]> > wrote: > >> Hi Esteban, >> >> On 12/3/19 4:24 PM, Esteban Bosse wrote: >> > Ping >> > >> > El mié., 6 nov. 2019 16:04, Esteban Bosse <[email protected] >> > <mailto:[email protected]>> 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/[email protected]/msg636936.html >> >> Or you can use the schema followed by Niek when adding the Allwinner H3: >> https://www.mail-archive.com/[email protected]/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 > >
