From owner-freebsd-arm@FreeBSD.ORG Mon Jun 15 15:55:08 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 792755C9; Mon, 15 Jun 2015 15:55:08 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 69C68E41; Mon, 15 Jun 2015 15:55:08 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8A4F2E4B; Mon, 15 Jun 2015 15:55:08 +0000 (UTC) Date: Mon, 15 Jun 2015 15:55:08 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-arm@freebsd.org Message-ID: <692156571.3.1434383708402.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: $PROJECT_NAME - Build #$BUILD_NUMBER - $BUILD_STATUS MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 15:55:08 -0000 $PROJECT_NAME - Build #$BUILD_NUMBER - $BUILD_STATUS: Check console output at $BUILD_URL to view the results. From owner-freebsd-arm@FreeBSD.ORG Mon Jun 15 16:25:09 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 6ADE8966 for ; Mon, 15 Jun 2015 16:25:09 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 E8E6A97D for ; Mon, 15 Jun 2015 16:25:08 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by wicnd19 with SMTP id nd19so29973547wic.1 for ; Mon, 15 Jun 2015 09:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8PXr6o2seqYvukS+I7jKYbxGeVKwN/I7g9u8H4wok7A=; b=x9Q1ie4f5Nan4Z1oP3ghr+Mg5XyKKZPFLDATmltvDY7NmeJIlifkxuZ6/tk0hq0bVL bPdk2h5UQf7LNqJf2ab6B6TOqx73zwDKr+t52M5TuMZKtkegptbp0EKPYWwglzFhH9EQ Tq0hX7Dt9FZjuHqU+6MCZE94ERUs92N4PSpoGlX/Bs+SNAAWLIeTL6Istdy6LxWZ2+1l rlI8c3CUj6j1oU8S+P2itrxnNOKtrmdsQIGAr3CzPxlJ4k0gGgI8wNX59GCCfy2KESy9 josmKTeOqar/eI0Eq+So5OeR8G2hvvc98ca/BUTzxFaFE3CqNRrF2KCehX4eyTzCITuo YyWA== MIME-Version: 1.0 X-Received: by 10.194.77.179 with SMTP id t19mr52282414wjw.30.1434385507450; Mon, 15 Jun 2015 09:25:07 -0700 (PDT) Received: by 10.28.21.134 with HTTP; Mon, 15 Jun 2015 09:25:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 19:25:07 +0300 Message-ID: Subject: Re: 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: Mon, 15 Jun 2015 16:25:09 -0000 Hello, On Sun, Jun 14, 2015 at 8:45 PM, Mihai Carabas wrote: > Hello, > > On Sat, Jun 13, 2015 at 4:59 PM, Mihai Carabas > wrote: > >> 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? >> > > I've found the issue with DTS parsing (a bug in the FDT parsing I guess). > The ranges value contains the address of the child node (the first value: 0 > in this case), the address of the parent (3 0 - the parent address-cells is > 2) and the size of the range for the child node (0x200000). > > The problem appears at the parent, because it has two values. If we > analyze the "fdt_get_range" from sys/dev/fdt/fdt_common.c we will see the > following line: > par_bus_addr = fdt_data_get((void *)rangesptr, par_addr_cells); > > All seems ok (par_addr_cells is 2), but par_bus_addr is of type u_long, > which means unsigned long and a length of 32bits and can't accomodate the > two values in the parent address space. > > 415 u_long > 416 fdt_data_get(void *data, int cells) > 417 { > 418 > 419 >-------if (cells == 1) > 420 >------->-------return (fdt32_to_cpu(*((uint32_t *)data))); > 421 > 422 >-------return (fdt64_to_cpu(*((uint64_t *)data))); > > If we look at fdt64_to_cpu: > 29 static inline uint64_t fdt64_to_cpu(uint64_t x) > 30 { > 31 >-------return (EXTRACT_BYTE(0) << 56) | (EXTRACT_BYTE(1) << 48) | > (EXTRACT_BYTE(2) << 40) | (EXTRACT_BYTE(3) << 32) > 32 >------->-------| (EXTRACT_BYTE(4) << 24) | (EXTRACT_BYTE(5) << 16) | > (EXTRACT_BYTE(6) << 8) | EXTRACT_BYTE(7); > 33 } > > It returns a 64bit variable which doesn't fit in the u_long par_bus_addr > and the compiler selects only the least significant bits, meaning "0". The > "3" is left out and this is why the parsing code doesn't select the third > chip from the bus. > Hello, I've found another bug in simplebus_alloc_resource function (sys/dev/fdt/simplebus.c). We have the following code block: 357 >-------if (type == SYS_RES_MEMORY) { 358 >------->-------/* Remap through ranges property */ 360 361 >------->-------for (j = 0; j < sc->nranges; j++) { 363 >------->------->-------if (start >= sc->ranges[j].bus && end < 364 >------->------->------- sc->ranges[j].bus + sc->ranges[j].size) { 365 >------->------->------->-------start -= sc->ranges[j].bus; 366 >------->------->------->-------start += sc->ranges[j].host; 367 >------->------->------->-------end -= sc->ranges[j].bus; 368 >------->------->------->-------end += sc->ranges[j].host; 370 371 >------->------->------->-------break; 372 >------->------->-------} 373 >------->-------} Here sc->ranges[j].bus is 0 and sc->ranges[j].host is 3 (basically the address of the parent and the child from the above DTS). It's not correct to sump up the host and start directly because 3 is an index (chipselect) from the parent (thus ending up with an alignment error). We must recursively go to the parent and obtain the address. Unfortunatelly I can't find a quick workaround for this. Thank you, Mihai