From owner-freebsd-arm@freebsd.org Tue Sep 4 16:16:13 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 27784FF3BD9 for ; Tue, 4 Sep 2018 16:16:13 +0000 (UTC) (envelope-from manu@bidouilliste.com) 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 96407756F4 for ; Tue, 4 Sep 2018 16:16:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 56CFCFF3BD8; Tue, 4 Sep 2018 16:16:12 +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 34C1CFF3BD6 for ; Tue, 4 Sep 2018 16:16:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A626D756F2 for ; Tue, 4 Sep 2018 16:16:11 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id b1d6c73b; Tue, 4 Sep 2018 18:16:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=gj3BRK0Z3R4XyYEFCQwY/jFeJ5U=; b=M4JwAgSOpxwTSL5utU2xvK0JCvKC EgmwDkyQP62e24iim4MY5n2YwcZC8w9t/0l8/+yqXRegrC0K2Ocvo4oJhtCaipf6 IW4o+7aBAeo80UqJQ0wuvBfmtL9pCs9RKNFSMFIqpkSq7IBjHG3geSc5qjgMh1o7 HPNT4DUevbqHN+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=fgM3EwLIch5cPg8dndpryrTIx242HSMZcX38VDw4zrFCLYJ/g4lfaKMa fuXnlIRud8k4b1CWY+PoeITu3ChsYRpBPt9HlpQcI9jK/v0dzE8Iiv4lOqoPY0Cg H56FFJC32gZma573K3N8Kiou5ANrTQ9LKAMM1zF2SI67Dz8zr9g= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 29d465d0 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 4 Sep 2018 18:16:03 +0200 (CEST) Date: Tue, 4 Sep 2018 18:16:03 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: Jakob Alvermark , "freebsd-arm@freebsd.org" Subject: Re: allwinner/nanopi neo boot issues Message-Id: <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> In-Reply-To: <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> 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> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 16:16:13 -0000 On Mon, 3 Sep 2018 11:21:09 +0300 Daniel Braniss wrote: >=20 >=20 > > On 3 Sep 2018, at 11:05, Jakob Alvermark wrote: > >=20 > >=20 > > On 9/3/18 9:01 AM, Daniel Braniss wrote: > >>=20 > >>=20 > >>> On 2 Sep 2018, at 19:33, Jakob Alvermark > wrote: > >>>=20 > >>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: > >>>> On Sun, 2 Sep 2018 17:14:10 +0200 > >>>> Jakob Alvermark > w= rote: > >>>>=20 > >>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: > >>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 > >>>>>> Jakob Alvermark >= wrote: > >>>>>>=20 > >>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: > >>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark > >>>>>>>>> >> wrot= e: > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: > >>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss > >>>>>>>>>>> >> wr= ote: > >>>>>>>>>>>=20 > >>>>>>>>>>> hi, > >>>>>>>>>>> with the latest current r338243 no longer boots via ubldr, ef= i does > >>>>>>>>>>> but with overlays I have to manually enter the root partition. > >>>>>>>>>>>=20 > >>>>>>>>>>> this is where it hangs via ubldr: > >>>>>>>>>>>=20 > >>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key t= o stop > >>>>>>>>>>>=20 > >>>>>>>>>>> Loading kernel... > >>>>>>>>>>> /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520 > >>>>>>>>>>> syms=3D[0x4+0xa6d70+0x4+0x109f17] > >>>>>>>>>>> Loading configured modules... > >>>>>>>>>>> /boot/entropy size=3D0x1000 > >>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b > >>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > >>>>>>>>>>> Kernel entry at 0x42400180... > >>>>>>>>>>> Kernel args: (null) > >>>>>>>>>>>=20 > >>>>>>>>>>> older - r337232 - boots fine, > >>>>>>>>>>>=20 > >>>>>>>>>>> any ideas where to look? > >>>>>>>>>> should have done an update before writing! > >>>>>>>>>>=20 > >>>>>>>>>> with the latest (and greatest) all is back to normal! > >>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nan= opi > >>>>>>>>>> neo a64 > >>>>>>>>>>=20 > >>>>>>>>>> thanks, > >>>>>>>>>> danny > >>>>>>>>> Hi, > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. > >>>>>>>>>=20 > >>>>>>>>> Loading kernel... > >>>>>>>>> /boot/kernel/kernel text=3D0x89ee40 data=3D0xae620+0x1f5ba0 > >>>>>>>>> syms=3D[0x4+0xa6d20+0x4+0x109e51] > >>>>>>>>> Loading configured modules... > >>>>>>>>> Could not load one or more modules! > >>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > >>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. > >>>>>>>>> Kernel entry at 0x42400180... > >>>>>>>>> Kernel args: (null) > >>>>>>>>>=20 > >>>>>>>>> This is at r338369. > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>> try booting via efi; > >>>>>>>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/boota= a64.efi > >>>>>>>> remove /boot/msdos/boot.scr > >>>>>>>> good luck, > >>>>>>>> danny > >>>>>>> I tried the ALPHA4 snapshot, this happens: > >>>>>>>=20 > >>>>>>> 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 =3D 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. > >>>>>>> EFI LOAD FAILED: continuing... > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> Tried manually loading ubldr.bin: > >>>>>>>=20 > >>>>>>> =3D> fatload mmc 0 0x42000000 ubldr.bin > >>>>>>> 306972 bytes read in 15 ms (19.5 MiB/s) > >>>>>>> =3D> go 0x42000000 > >>>>>>> Loading kernel... > >>>>>>> /boot/kernel/kernel text=3D0x85d7f0 data=3D0xaf620+0x24e1e0 > >>>>>>> syms=3D[0x4+0xa87d0+0x4+0x10c603] > >>>>>>> Loading configured modules... > >>>>>>> /boot/kernel/umodem.ko text=3D0x1bf4 text=3D0x1320 data=3D0x1080+= 0xf88 > >>>>>>> syms=3D[0x4+0x1070+0x4+0xbcd] > >>>>>>> loading required module 'ucom' > >>>>>>> /boot/kernel/ucom.ko text=3D0x1f8c text=3D0x2e90 data=3D0x1080+0x= 17bc > >>>>>>> syms=3D[0x4+0x14f0+0x4+0xc5d] > >>>>>>> Could not load one or more modules! > >>>>>>>=20 > >>>>>>> Hit [Enter] to boot immediately, or any other key for command pro= mpt. > >>>>>>> Booting [/boot/kernel/kernel]... > >>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > >>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. > >>>>>>> Kernel entry at 0x42400180... > >>>>>>> Kernel args: (null) > >>>>>>>=20 > >>>>>>> And then it reboots... > >>>>>> I've just re-introduce the cache patches for u-boot as it appear= s 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. > >>>>>=20 > >>>>> Thanks! With the updated U-boot it now boots with ubldr.bin. > >>>>>=20 > >>>>> 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. > >>>=20 > >>> Thanks again! It works! > >>>=20 > >>>=20 > >>>> I'm more interested to debug the efi problem, I'll try on a H2 boar= d. > >>>=20 > >>> If there is anything I can do to help let me know. > >>>=20 > >>> I tried with boot1.efi as /efi/boot/bootarm.efi: > >>>=20 > >>> ## Starting EFI application at 42000000 ... > >>> >> FreeBSD EFI boot block > >>> Loader path: /boot/loader.efi > >>>=20 > >>> 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 =3D 1 > >>> EFI LOAD FAILED: continuing? > >>=20 > >> shot in the dark: > >> I found out that if the root partition is not freebsd-ufs the efi boo= t failed. > >> do a gpart show, > >>=20 > >> mine looks like this: > >> neo-001> gpart show > >> =3D> 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) > >>=20 > >> =3D> 0 6187008 mmcsd0s2 BSD (3.0G) > >> 0 6187008 1 freebsd-ufs (3.0G) > >=20 > > Nope, mine looks almost the same: > >=20 > > =3D> 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) > >=20 > > =3D> 0 4177920 mmcsd0s2 BSD (2.0G) > > 0 4177920 1 freebsd-ufs (2.0G) > >=20 > > Interestingly, loading bootarm.efi(boot1.efi) manually gets me to the l= oader: > >=20 > >=20 >=20 > bootarm.efi should be a copy of loader.efi not boot1.efi as far as I know. Both should work. > > =3D> fatload mmc 0 0x42000000 efi/boot/bootarm.efi > > 39500 bytes read in 4 ms (9.4 MiB/s) > > =3D> bootefi 0x42000000 > > But it does not boot: > >=20 > > Type '?' for a list of commands, 'help' for more detailed help. > > OK load boot/kernel/kernel > > boot/kernel/kernel text=3D0x89ef08 data=3D0xae620+0x1f5aa0 syms=3D[0x4+= 0xa6d30+0x4+0x109e65] > > OK load -t dtb boot/dtb/sun8i-h2-plus-orangepi-r1.dtb =20 > > boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > > 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-- >=20 --=20 Emmanuel Vadot