Date: Fri, 25 Jan 2019 21:36:44 -0700 From: Warner Losh <imp@bsdimp.com> To: ticso@cicely.de Cc: freebsd-arm@freebsd.org, Bernd Walter <ticso@cicely7.cicely.de> Subject: Re: 12-RELEASE loader fails on Orange Pi R1 (maybe 256MB related) Message-ID: <CANCZdfpmkMQtmSL_3add=6Z9ybSE-nmHC8_4%2BxKtofVTTuze_w@mail.gmail.com> In-Reply-To: <20190126030330.GI74542@cicely7.cicely.de> References: <20190126030330.GI74542@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 25, 2019, 9:08 PM Bernd Walter <ticso@cicely7.cicely.de wrote: > All boards install as u-boot-orangepi-*. > The R1 is an exception and installs as u-boot-orangepi_r1 > I noticed because I did cd ../u-boot-orangepi- <tab> and got no R1, > which I was sure to be installed. > > But just as a side note. > The board won't even run our loader: > > U-Boot SPL 2018.11 (Jan 20 2019 - 22:14:40 +0100) > DRAM: 256 MiB > Trying to boot from MMC1 > > > U-Boot 2018.11 (Jan 20 2019 - 22:14:40 +0100) Allwinner Technology > > CPU: Allwinner H3 (SUN8I 1680) > Model: Xunlong Orange Pi R1 > DRAM: 256 MiB > MMC: SUNXI SD/MMC: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > USB2: USB EHCI 1.00 > scanning bus 0 for devices... 1 USB Device(s) found > scanning bus 2 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > 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 > 587736 bytes read in 29 ms (19.3 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... > > Device 0: device type unknown > ... is now current device > ethernet@1c30000 Waiting for PHY auto negotiation to complete. done > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > DHCP client bound to address 10.1.1.155 (1006 ms) > Using ethernet@1c30000 device > TFTP from server 10.1.1.16; our IP address is 10.1.1.155 > Filename 'pxeboot'. > Load address: 0x42000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > missing environment variable: pxeuuid > Retrieving file: pxelinux.cfg/01-02-42-ea-47-d9-eb > Using ethernet@1c30000 device > ... > It is now doing several other U-Boot network fallbacks. > > I'm a bit confused about EFI on an ARMv7 board. > There is a Zero plus, which is 64 bit (H5 AFAIK), but the R1 is an > H2+ board, similar to the normal zero, just with an additional USB ethernet > instead of the onboard USB header. > Do we use EFI on 32bit ARM as well? > I just noticed now because unfortunately the loader resets the screen, so > it is quicly gone. > > But I get the same error on an R1 with the bootcode for the zero, which > boots fine on a real zero board and mentions EFI as well: > 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 > 587736 bytes read in 29 ms (19.3 MiB/s) > ## Starting EFI application at 42000000 ... > Consoles: EFI console > FreeBSD/arm EFI loader, Revision 1.1 > > Command line arguments: l > EFI version: 2.70 > EFI Firmware: Das U-Boot (rev 8216.4352) > Console: efi (0) > Load Path: /\efi\boot\bootarm.efi > Load Device: > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x81f,0x18fa8) > Trying ESP: > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x81f,0x18fa8) > Setting currdev to disk0p1: > > It might be because my R1 is a 256MB, while the tested zero is 512MB. > I can test a 256MB zero in a few days, but don't have a 256MB zero at home. > Maybe it is the block cache code? It hovers up a ton of memory.... it was fixed on i386, though, I thought... Warner -- > B.Walter <bernd@bwct.de> http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpmkMQtmSL_3add=6Z9ybSE-nmHC8_4%2BxKtofVTTuze_w>