From owner-freebsd-arm@FreeBSD.ORG Sat Jun 13 13:59:12 2015 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E7016BC for ; Sat, 13 Jun 2015 13:59:12 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDCEDA97 for ; Sat, 13 Jun 2015 13:59:11 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by wifx6 with SMTP id x6so38389996wif.0 for ; Sat, 13 Jun 2015 06:59:10 -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=AfPgGNi2+4wqo2U5hcDRyq8IDwJ4V3e6oaov45D+6bA=; b=UbvvNfQemD6u406WW212BTGmfGuolHusZUauUCpikPaClRpH1/50otRB55rR7iGMSc HGoUwQ4djwUPNOB6SYocFo5RzPJdSG/iMs6AkR411QHdApRBY44KzXOS4Q9Sugfp1yW6 ksuMGQ+fXV/vDIUF7hPFsCfWMCE5a6PdPEiyRZLo5qVhuPwpjOW+vO5E9snsR+m406QA bZPgw1thYF6MRgQmnrC86fZ6k9fwM8jEa3titoOXwSI4NfHbh2HANBAxvSdXCthLyN5I L5nJ2gbDu7bsp1ORVGF2aqho1OFfPlweQnG89aUe3X1fkmtFLAIzKHLCuwVVcBC8kAgf Jbyg== MIME-Version: 1.0 X-Received: by 10.194.78.134 with SMTP id b6mr35685445wjx.13.1434203950089; Sat, 13 Jun 2015 06:59:10 -0700 (PDT) Received: by 10.28.21.134 with HTTP; Sat, 13 Jun 2015 06:59:09 -0700 (PDT) Date: Sat, 13 Jun 2015 16:59:09 +0300 Message-ID: Subject: porting freebsd-arm on FastModels - CortexA15 From: Mihai Carabas To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 13:59:12 -0000 Hello, My name is Mihai Carabas and I am a GSoC student this year on porting bhyve over ARM. Right now I'm working on booting FreeBSD ARM on an CortexA15 emulated platform running with FastModels. I have two problems until now: a) I used the DTS from sys/gnu/dts/arm/vexpress-v2p-ca15-tc1.dts and I build the FDT directly in the kernel. I have a problem with the address calculated for the serial0 console. The DTB parser selects the first range from the bus: 228 >------->-------ranges = <0 0 0 0x08000000 0x04000000>, 229 >------->------->------- <1 0 0 0x14000000 0x04000000>, 230 >------->------->------- <2 0 0 0x18000000 0x04000000>, 231 >------->------->------- <3 0 0 0x1c000000 0x04000000>, 232 >------->------->------- <4 0 0 0x0c000000 0x04000000>, 233 >------->------->------- <5 0 0 0x10000000 0x04000000>; The valid range for this platform is the entry starting with 3 (the console is mapped at address 0x1c090000). But the parser ellects the first range. The console is declared like this (as a child to iofpga root node): 68 >------->-------iofpga@3,00000000 { 69 >------->------->-------compatible = "arm,amba-bus", "simple-bus"; 70 >------->------->-------#address-cells = <1>; 71 >------->------->-------#size-cells = <1>; 72 >------->------->-------ranges = <0 3 0 0x200000>; ........ 156 >------->------->-------v2m_serial0: uart@090000 { 157 >------->------->------->-------compatible = "arm,pl011", "arm,primecell"; 158 >------->------->------->-------reg = <0x090000 0x1000>; 159 >------->------->------->-------interrupts = <5>; 160 >------->------->------->-------clocks = <&v2m_oscclk2>, <&smbclk>; 161 >------->------->------->-------clock-names = "uartclk", "apb_pclk"; 162 >------->------->-------}; As you can see the iofgpa selects the chip number 3, which is ok, but the final address computed by the FreeBSD parser isn't. Any thoughts on this? b) To force the things, I've delete the other ranges, and just let the 0x1c000000. Until now I've managed to get to message buffer initialization in initarm. If I initialize the message buffers (in particular set msgbufmapped = 1;), the next printf is being trashed: it prints only the first letter and than the 's' char for a couple of times and than it gets into a data abort exception. It seems that the message buffer gets corrupted. I've checked the memory allocated and mapped for the message buffer (msgbufp in initarm [pmap_new]) and is ok. Are there other parts of the machine dependent code that could affect the message buffer? If I don't initialize the message buffer it goes further without any problems, ending up in the mi_startup and about the end. Thank you, Mihai