From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 17 13:11:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47C07C2F; Tue, 17 Jun 2014 13:11:52 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DC722E0F; Tue, 17 Jun 2014 13:11:51 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id bs8so5786452wib.15 for ; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BpgIXHVI7jRjLWvQ86n0Ath3bIjTWLFMFYwEwZmK8EU=; b=ZHyx6CeskynsnoyY6A2zDBVU/1q7/QGIYCMVGqgdg2bjWCOP0qPZTMn+K5qDkewkwS DLT3Qpym1Nt0hmEBKlt1x5+XmfJogxV53Me6twdYGQmba1rwYhSm3bmM+KDslpuH14G8 tLN0lQDNcB+ahsi28qsFPZzX6AftI+Cptr/8j1NSM/0dFmVi3iucJE1rs4H9QLNfMXG1 wM2Wv4mTV8Jt7dwsUIfjjyd3VqFq7KQeddCtB7VnmLoe0GfgxsLtQ60MYs+bjQMaTQSV Osaj9tLH5/MZlpYopthecgrDB+58qi9c/vQRisrz2CVqdZi3nnId5wthR6vvvDjsAxA0 Zk9g== MIME-Version: 1.0 X-Received: by 10.180.84.226 with SMTP id c2mr36625484wiz.50.1403010709514; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) Received: by 10.180.90.15 with HTTP; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) Date: Tue, 17 Jun 2014 17:11:49 +0400 Message-ID: Subject: FreeBSD on ARM Android Emulator [June 9 - 16] From: Alexander Tarasikov To: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org, Gavin Atkinson , soc-status@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:11:52 -0000 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