Date: Tue, 19 Apr 2016 08:19:44 -0600 From: Ian Lepore <ian@freebsd.org> To: Milan Obuch <freebsd-arm@dino.sk>, freebsd-arm@freebsd.org Cc: Emmanuel Vadot <manu@bidouilliste.com>, Erich Dollansky <erich@alogt.com> Subject: Re: Orange Pi One Message-ID: <1461075584.1232.13.camel@freebsd.org> In-Reply-To: <20160419095358.351c74b3@zeta.dino.sk> References: <20160413232414.3a37907e@zeta.dino.sk> <20160414062820.7b907ba9@X220.alogt.com> <20160414064405.202e4eef@zeta.dino.sk> <CABx9NuQWatjAhA1oL8EtUbv5kSbG8qX-KB%2BGBr9PTqVs4fnMNg@mail.gmail.com> <20160418094916.10dc9ae8@zeta.dino.sk> <20160418174918.33d3d19e4105eb737d17b122@bidouilliste.com> <CABx9NuQaFEuZmDtJ=Rie5XC3iQDqTEBX6ZRiWxNfEa_BomTUcA@mail.gmail.com> <20160418210108.4047c526@zeta.dino.sk> <20160419092012.0ad4ad2d@zeta.dino.sk> <20160419093408.2f6d8d6472b09298f1e08ecb@bidouilliste.com> <20160419095358.351c74b3@zeta.dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2016-04-19 at 09:53 +0200, Milan Obuch wrote: > On Tue, 19 Apr 2016 09:34:08 +0200 > Emmanuel Vadot <manu@bidouilliste.com> wrote: > > > On Tue, 19 Apr 2016 09:20:12 +0200 > > Milan Obuch <freebsd-arm@dino.sk> wrote: > > > > > > > > One step further - compiled ubldr as part of buildworld, tried, > > > and > > > found I need ubldr.bin to start boot process, ubldr just keeps > > > crashing with following: > > > > > > Booting from: mmc 0 ubldr > > > reading ubldr > > > 235312 bytes read in 63 ms (3.6 MiB/s) > > > ## Starting application at 0x01000098 ... > > > undefined instruction > > > pc : [<01c0f00c>] lr : [<5ff77138>] > > > reloc pc : [<ebc9f00c>] lr : [<4a007138>] > > > sp : 5bf4ba70 ip : 00000030 fp : 5ff76ffc > > > r10: 00000001 r9 : 5bf4fee8 r8 : 00000000 > > > r7 : 00000001 r6 : 5bf513e0 r5 : 01000098 r4 : 00000000 > > > r3 : 00000001 r2 : 01c28000 r1 : 5bf513e4 r0 : 00000000 > > > Flags: nZCv IRQs off FIQs off Mode SVC_32 > > > Resetting CPU ... > > > > > > resetting ... > > > > > > but ubldr.bin works (command typed manually): > > > > > > => fatload mmc 0 0x42000000 ubldr.bin > > > reading ubldr.bin > > > 192096 bytes read in 58 ms (3.2 MiB/s) > > > => go 0x42000000 > > > ## Starting application at 0x42000000 ... > > > Consoles: U-Boot console > > > Compatible U-Boot API signature found @0x5bf504c8 > > > > > > FreeBSD/arm U-Boot loader, Revision 1.2 > > > (root@zeta.dino.sk, Tue Apr 19 06:33:11 CEST 2016) > > > > > > DRAM: 512MB > > > MMC Device 1 not found > > > Number of U-Boot devices: 1 > > > U-Boot env: loaderdev='mmc 0' > > > Found U-Boot device: disk > > > Checking unit=0 slice=<auto> partition=<auto>... good. > > > Booting from disk0s1: > > > - > > > can't load 'kernel' > > > > > > Type '?' for a list of commands, 'help' for more detailed help. > > > loader> > > > > > > Now I can type loader command, so I can try to load kernel if I > > > had > > > one (I tried to build it from stock FreeBSD sources, but > > > something > > > was wrong, I must figure why buildkernel did not produce > > > kernel... > > > just testing now, waiting where it breaks). > > > > > > Milan > > > > For ubldr to work you need to set UBLDR_LOADADDR variable to the > > correct address. > > > > Where is this defined? Or should be? Not top important issue now, as > I > can continue with ubldr.bin for some time, but I still would like to > check it. > Actually, ubldr (the elf version) shouldn't even exist anymore. Once I got the relocation worked out for ubldr.bin, the plan was always to eliminate the elf version and have just the .bin file. I left the elf file around to allow time for crochet and other scripts to adjust (which I think probably never happened). FreeBSD image building (for snapshots and releases) was supposed to transition to a new mechanism which built a single world for all supported systems, and a board-specific kernel for each supported board. The only way to build a single world for all images is to eliminate the elf ubldr which has to be compiled differently for each board. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1461075584.1232.13.camel>