Date: Tue, 17 Jun 2014 17:11:49 +0400 From: Alexander Tarasikov <alexander.tarasikov@gmail.com> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, freebsd-hackers@freebsd.org, Gavin Atkinson <gavin@freebsd.org>, soc-status@freebsd.org Subject: FreeBSD on ARM Android Emulator [June 9 - 16] Message-ID: <CAMChaFzUhnhXZL-17OV07v6kOhhfb%2BVzY2qMRsVZggOooesnHw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi! I'll summarize what I've been up to recently. I have done a relatively large part of work at the start of May prior to the start of coding period but was unfortunately unable to work at the end of May due to my studies. Tonight I've pushed the code to my svn branch and updated the wiki. Here is my report on what has been done and what I want to work on next. I now have the FreeBSD 10 kernel starting up and writing text to emulator's UART (I was using fbsd10 during development to avoid switching versions in process. I have migrated the code to 'HEAD' yesterday, but it doesn't boot yet, I'm investigating). The following drivers are implemented: PIC (Interrupt controller), Timer, UART, Ethernet (the emulator emulates SMSC91xx, it's just MMIO). I have implemented the framebuffer driver, but have not fully tested it yet. I have tested that it initializes the device and the screen turns white when I memset framebuffer memory with 0xff, but I was unable to get SYSCONS working. If I attach the fb driver to sysbus, it doesn't register - I suppose it would if I actually mounted rootfs, but since I don't, it is just too early. On the other hand, if I attach it to fdtbus, I get a null pointer dereference in sc_attach_unit because syscons driver is not installed that early. Regarding the rootfs boot, I have discovered that Android Emulator uses the virtual NAND chip to access "system.img" file, which is what the user gets when they download an image for Android Emulator. Virtual MMC is only used to access user data image, which is generated at the user's machine. I could probably try NFS boot or booting from an MD ramdisk, but I want to have NAND working first. I have a question regarding the Device Tree. Android Emulator has a virtual device called "pdev" which allows to get the list of available devices and their MMIO ranges. Although this data is unlikely to change, it would be nice to implement it because this is an interesting use case. What is the advised way to do it? Should I register the PDEV as a simple-bus device and patch the FDT inside its probe function or will it not work? During the next two weeks I want to have the driver for NAND and get the kernel to boot the userland. After that I'll build an image which one can load into the emulator for testing. Next I'll write drivers for some peripherals. Android Emulator provides several virtual devices. Most interesting are sensors (accelerometer/gyroscope), multiple input event sources (keyboard, touchscreen), audio driver. I think they are important because only a few boards (rPI, IMX6, OMAP3) provide the support for display and I'm not sure if any board supports audio or sensors. Writing drivers for uncommon features will provide a set of sample code which can be used to bring up real boards. If I have spare time before the end of GSoC, I will start porting FreeBSD to Google Nexus 5 phone with Qualcomm MSM8974 CPU, I want to have at least framebuffer and touchscreen working. If I don't have extra time, I don't think I will port FreeBSD to Nexus after GSoC because writing drivers is rather boring, and since Qemu has recently gained support for AArch64 (which is 64-bit ARM), I think it is a more interesting area to experiment with. Overall I have found that some drivers like syscons (framebuffer), UART, become unnecessarily complicated with a lot of dummy functions which need to be implemented, but looks like some cleanup was done in HEAD as compared to 10.0. I think I'll look into it after I'm done with the emulator project. Maybe it would be good to factor out some common code into a generic driver ? -- Regards, Alexander
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMChaFzUhnhXZL-17OV07v6kOhhfb%2BVzY2qMRsVZggOooesnHw>