From owner-freebsd-arm@freebsd.org Tue Sep 4 17:11:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E136FF5AB1 for ; Tue, 4 Sep 2018 17:11:04 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2806C77CF1 for ; Tue, 4 Sep 2018 17:11:04 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: by mailman.ysv.freebsd.org (Postfix) id E0897FF5AAF; Tue, 4 Sep 2018 17:11:03 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A62B9FF5AAE for ; Tue, 4 Sep 2018 17:11:03 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DA6977CE9 for ; Tue, 4 Sep 2018 17:11:03 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxEqs-000IQP-Kf; Tue, 04 Sep 2018 19:10:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cQJpvya5usjDPJKDFOthAr7LEiz/I7QlE0AAaL/h9mE=; b=YXx6l9CdYK/mUK28v9eDf7FDZJ 9iWAJeclikRAJJOxuRfzGa8fJznHoKe5qNLYWuvcD9zHTGgC/949Kblvcmj1O+vmopaxpIqEb/Hg9 004aFtJ2+FZvwoISSEzA9VxxtECmQP2x6u1zgo6XKLSG81PLKJAULa3lNS8FeuXiJQ7ewv1XYxEYG FPl083Pb5UBWrkiGw94lVOHsA3M2qmh/+fEkIXBgflglED81W+Hbi5jQgy06gvIGxn1KVSqPqOWSd yz6pxrcrwCv8/UIuU3LGY2rEzIUEgWwBCWOs2TnWgxQbuHJeD69VqyoBkj6CjvUJ3ipP/gNz1U0Zz +5Oi47CA==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxEqs-000PIW-3v; Tue, 04 Sep 2018 19:10:54 +0200 Subject: Re: allwinner/nanopi neo boot issues To: Emmanuel Vadot , Daniel Braniss Cc: "freebsd-arm@freebsd.org" References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> From: Jakob Alvermark Message-ID: <79e69d73-b4f0-177a-15da-786c4101697a@alvermark.net> Date: Tue, 4 Sep 2018 19:10:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 17:11:04 -0000 On 9/4/18 6:16 PM, Emmanuel Vadot wrote: > On Mon, 3 Sep 2018 11:21:09 +0300 > Daniel Braniss wrote: > >> >>> On 3 Sep 2018, at 11:05, Jakob Alvermark wrote: >>> >>> >>> On 9/3/18 9:01 AM, Daniel Braniss wrote: >>>> >>>>> On 2 Sep 2018, at 19:33, Jakob Alvermark > wrote: >>>>> >>>>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: >>>>>> On Sun, 2 Sep 2018 17:14:10 +0200 >>>>>> Jakob Alvermark > wrote: >>>>>> >>>>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: >>>>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 >>>>>>>> Jakob Alvermark > wrote: >>>>>>>> >>>>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>>>>>>>>> >> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> hi, >>>>>>>>>>>>> with the latest current r338243 no longer boots via ubldr, efi does >>>>>>>>>>>>> but with overlays I have to manually enter the root partition. >>>>>>>>>>>>> >>>>>>>>>>>>> this is where it hangs via ubldr: >>>>>>>>>>>>> >>>>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop >>>>>>>>>>>>> >>>>>>>>>>>>> Loading kernel... >>>>>>>>>>>>> /boot/kernel/kernel text=0x8a0950 data=0xae160+0x184520 >>>>>>>>>>>>> syms=[0x4+0xa6d70+0x4+0x109f17] >>>>>>>>>>>>> Loading configured modules... >>>>>>>>>>>>> /boot/entropy size=0x1000 >>>>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x601b >>>>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>>>> Kernel args: (null) >>>>>>>>>>>>> >>>>>>>>>>>>> older - r337232 - boots fine, >>>>>>>>>>>>> >>>>>>>>>>>>> any ideas where to look? >>>>>>>>>>>> should have done an update before writing! >>>>>>>>>>>> >>>>>>>>>>>> with the latest (and greatest) all is back to normal! >>>>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi >>>>>>>>>>>> neo a64 >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> danny >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>>>>>>>> >>>>>>>>>>> Loading kernel... >>>>>>>>>>> /boot/kernel/kernel text=0x89ee40 data=0xae620+0x1f5ba0 >>>>>>>>>>> syms=[0x4+0xa6d20+0x4+0x109e51] >>>>>>>>>>> Loading configured modules... >>>>>>>>>>> Could not load one or more modules! >>>>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>> Kernel args: (null) >>>>>>>>>>> >>>>>>>>>>> This is at r338369. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> try booting via efi; >>>>>>>>>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/bootaa64.efi >>>>>>>>>> remove /boot/msdos/boot.scr >>>>>>>>>> good luck, >>>>>>>>>> danny >>>>>>>>> I tried the ALPHA4 snapshot, this happens: >>>>>>>>> >>>>>>>>> Hit any key to stop autoboot: 0 >>>>>>>>> switch to partitions #0, OK >>>>>>>>> mmc0 is current device >>>>>>>>> Scanning mmc 0:1... >>>>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) >>>>>>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>>>>>> Scanning disks on usb... >>>>>>>>> Disk usb0 not ready >>>>>>>>> Disk usb1 not ready >>>>>>>>> Disk usb2 not ready >>>>>>>>> Disk usb3 not ready >>>>>>>>> Scanning disks on mmc... >>>>>>>>> MMC Device 1 not found >>>>>>>>> MMC Device 2 not found >>>>>>>>> MMC Device 3 not found >>>>>>>>> Found 3 disks >>>>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) >>>>>>>>> ## Starting EFI application at 42000000 ... >>>>>>>>> Consoles: EFI console >>>>>>>>> failed to allocate staging area: 14 >>>>>>>>> failed to allocate staging area >>>>>>>>> ## Application terminated, r = 5 > So this is weird, it mean that loader.efi couldn't allocate some pages. > > I've just tried ALPHA4 on my orangepi-zero (closer board that I have), > I've just overwritten u-boot using the port we have for it and the > board boots just fine. > How did you generate the image for this one ? > Could you test with my method ? Thanks. Which image should I use? For ALPHA3 there is a GENERICSD image, but not for ALPHA4. I just tried with FreeBSD-12.0-ALPHA4-arm-armv7-CUBIEBOARD2-20180831-r338410.img dd the u-boot from the port (latest one, u-boot-orangepi_r1-2018.07_3) Put the SD card in and this happened: Hit any key to stop autoboot:  0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... 25395 bytes read in 3 ms (8.1 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi Scanning disks on usb... Disk usb0 not ready Disk usb1 not ready Disk usb2 not ready Disk usb3 not ready Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 3 disks 508704 bytes read in 25 ms (19.4 MiB/s) ## Starting EFI application at 42000000 ... Consoles: EFI console failed to allocate staging area: 14 failed to allocate staging area ## Application terminated, r = 5 EFI LOAD FAILED: continuing... >>>>>>>>> EFI LOAD FAILED: continuing... >>>>>>>>> >>>>>>>>> >>>>>>>>> Tried manually loading ubldr.bin: >>>>>>>>> >>>>>>>>> => fatload mmc 0 0x42000000 ubldr.bin >>>>>>>>> 306972 bytes read in 15 ms (19.5 MiB/s) >>>>>>>>> => go 0x42000000 >>>>>>>>> Loading kernel... >>>>>>>>> /boot/kernel/kernel text=0x85d7f0 data=0xaf620+0x24e1e0 >>>>>>>>> syms=[0x4+0xa87d0+0x4+0x10c603] >>>>>>>>> Loading configured modules... >>>>>>>>> /boot/kernel/umodem.ko text=0x1bf4 text=0x1320 data=0x1080+0xf88 >>>>>>>>> syms=[0x4+0x1070+0x4+0xbcd] >>>>>>>>> loading required module 'ucom' >>>>>>>>> /boot/kernel/ucom.ko text=0x1f8c text=0x2e90 data=0x1080+0x17bc >>>>>>>>> syms=[0x4+0x14f0+0x4+0xc5d] >>>>>>>>> Could not load one or more modules! >>>>>>>>> >>>>>>>>> Hit [Enter] to boot immediately, or any other key for command prompt. >>>>>>>>> Booting [/boot/kernel/kernel]... >>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>> Kernel args: (null) >>>>>>>>> >>>>>>>>> And then it reboots... >>>>>>>> I've just re-introduce the cache patches for u-boot as it appears that >>>>>>>> some boards needs them (I've probably tested the wrong unpatched u-boot >>>>>>>> when I removed them ...) so booting with ubldr.bin should work now. >>>>>>>> For the EFI issue I don't really know what is happening. >>>>>>> Thanks! With the updated U-boot it now boots with ubldr.bin. >>>>>>> >>>>>>> How can I make it do this automatically? >>>>>> If you copy the boot.scr file from the port/package to the root of the >>>>>> fat partition this will load ubldr.bin directly. >>>>> Thanks again! It works! >>>>> >>>>> >>>>>> I'm more interested to debug the efi problem, I'll try on a H2 board. >>>>> If there is anything I can do to help let me know. >>>>> >>>>> I tried with boot1.efi as /efi/boot/bootarm.efi: >>>>> >>>>> ## Starting EFI application at 42000000 ... >>>>>>> FreeBSD EFI boot block >>>>> Loader path: /boot/loader.efi >>>>> >>>>> Initializing modules: UFS >>>>> Load Path: /\efi\boot\bootarm.efi >>>>> Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x800,0x2000) >>>>> Probing 3 block devices.....* done >>>>> UFS found 1 partition >>>>> Consoles: EFI console >>>>> failed to allocate staging area: 14 >>>>> failed to allocate staging area >>>>> Failed to start image provided by UFS (5) >>>>> panic: No bootable partitions found! >>>>> ## Application terminated, r = 1 >>>>> EFI LOAD FAILED: continuing? >>>> shot in the dark: >>>> I found out that if the root partition is not freebsd-ufs the efi boot failed. >>>> do a gpart show, >>>> >>>> mine looks like this: >>>> neo-001> gpart show >>>> => 63 15523777 mmcsd0 MBR (7.4G) >>>> 63 1985 - free - (993K) >>>> 2048 102400 1 fat32lba [active] (50M) >>>> 104448 6187008 2 freebsd (3.0G) >>>> 6291456 9232384 - free - (4.4G) >>>> >>>> => 0 6187008 mmcsd0s2 BSD (3.0G) >>>> 0 6187008 1 freebsd-ufs (3.0G) >>> Nope, mine looks almost the same: >>> >>> => 63 31116225 mmcsd0 MBR (15G) >>> 63 1985 - free - (993K) >>> 2048 8192 1 fat16 (4.0M) >>> 10240 6144 - free - (3.0M) >>> 16384 4177920 2 freebsd (2.0G) >>> 4194304 26921984 - free - (13G) >>> >>> => 0 4177920 mmcsd0s2 BSD (2.0G) >>> 0 4177920 1 freebsd-ufs (2.0G) >>> >>> Interestingly, loading bootarm.efi(boot1.efi) manually gets me to the loader: >>> >>> >> bootarm.efi should be a copy of loader.efi not boot1.efi as far as I know. > Both should work. > >>> => fatload mmc 0 0x42000000 efi/boot/bootarm.efi >>> 39500 bytes read in 4 ms (9.4 MiB/s) >>> => bootefi 0x42000000 >>> But it does not boot: >>> >>> Type '?' for a list of commands, 'help' for more detailed help. >>> OK load boot/kernel/kernel >>> boot/kernel/kernel text=0x89ef08 data=0xae620+0x1f5aa0 syms=[0x4+0xa6d30+0x4+0x109e65] >>> OK load -t dtb boot/dtb/sun8i-h2-plus-orangepi-r1.dtb >>> boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>> OK boot >>> Using DTB from loaded file 'boot/dtb/sun8i-h2-plus-orangepi-r1.dtb'. >>> EHCI failed to shut down host controller. >>> Kernel entry at 0x43000180... >>> Kernel args: (null) >>> modulep: 0xc0d03000 >>> relocation_offset 0 >>> --Hangs here-- >