Date: Mon, 12 Dec 2016 11:26:10 +0800 From: Ganbold Tsagaankhuu <ganbold@gmail.com> To: Daniel Braniss <danny@cs.huji.ac.il> Cc: arm@freebsd.org Subject: Re: ubldr, was Re: dtb printout Message-ID: <CAGtf9xNb2_NWNb7pArT0qXZ9j__s4UmaM9B3F6qLFt9PVCcQfg@mail.gmail.com> In-Reply-To: <2660E67D-10E4-4680-B824-EBF138FBC3FF@cs.huji.ac.il> References: <7FD12DD6-B390-4EF3-811B-391798410BC0@cs.huji.ac.il> <1480950103.1889.251.camel@freebsd.org> <93729768-D887-4568-8686-FE691A881BC6@cs.huji.ac.il> <CAGtf9xPfLAgUaUZ4ivJxesXvJ_NQ0Y1usuqBQ_=%2BQjk8YEDw5w@mail.gmail.com> <2660E67D-10E4-4680-B824-EBF138FBC3FF@cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 12, 2016 at 1:29 AM, Daniel Braniss <danny@cs.huji.ac.il> wrote= : > > On 11 Dec 2016, at 6:09 PM, Ganbold Tsagaankhuu <ganbold@gmail.com> wrote= : > > > > On Tue, Dec 6, 2016 at 5:17 PM, Daniel Braniss <danny@cs.huji.ac.il> > wrote: > >> >> > On 5 Dec 2016, at 17:01, Ian Lepore <ian@freebsd.org> wrote: >> > >> > On Mon, 2016-12-05 at 15:48 +0200, Daniel Braniss wrote: >> >> Hi, >> >> the short version: >> >> is there a way to obtain the dtb from the kernel? >> >> >> >> the longer version: >> >> I am developing on several different arm boards, rpi, rpi2, orangepi- >> >> one, orange-pc, to mention >> >> a few, and each one has a different u-boot, ubldr, dtb, and I keep >> >> loosing track :-( >> >> I find myself too often wondering which ddb file got loaded. >> >> >> >> cheers, >> >> danny >> > >> > First: each one does NOT have a different ubldr. All ubldr.bin files >> > are the same, they're not board-specific anymore. (The elf versions, >> > ubldr without the .bin, may have a different load address in the elf >> > header, but other than that, they're identical too and can actually be >> > loaded at any address.) >> > >> > To see the contents of the dtb, use ofwdump. The output is not >> > especially pretty. There is a manpage for it. >> > >> > To just get a quick reminder of which file was loaded, create a >> > /boot/loader.rc.local (<-- .rc not .conf) that contains >> > >> > ubenv import fdtfile fdt_file >> > >> > Then in the running system you can use kenv and you'll see >> > >> > uboot.fdtfile=3D"bcm2835-rpi-b-rev2.dtb" >> > >> > Unfortunately, some u-boots use fdtfile, some use fdt_file. Grrr. >> > >> > You can, of course, use that ubenv import thing to pull any variable >> > from the uboot environment into the kernel environment. If you just >> > say ubenv import without naming a variable, you get all the vars >> > (including vars that contain scripts, which is kind of messy). >> > >> > =E2=80=94 Ian >> > >> >> as usual, I get more than I bargained for :-) >> on rpi adding ubenv import worked, but on orange/allwinner I got a >> =E2=80=98syntax error=E2=80=99, >> I tried to upgrade the ubldr, but so far i get: >> >> U-Boot SPL 2016.09 (Dec 05 2016 - 15:02:38) >> DRAM: 1024 MiB >> Trying to boot from MMC1 >> >> >> U-Boot 2016.09 (Dec 05 2016 - 15:02:38 +0200) Allwinner Technology >> >> CPU: Allwinner H3 (SUN8I 1680) >> Model: Xunlong Orange Pi PC >> I2C: ready >> DRAM: 1 GiB >> WARNING: Caches not enabled >> MMC: SUNXI SD/MMC: 0 >> reading u-boot.env >> >> ** Unable to read "u-boot.env" from mmc0:1 ** >> 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 >> USB3: USB OHCI 1.0 >> USB4: USB EHCI 1.00 >> USB5: USB OHCI 1.0 >> scanning bus 0 for devices... 1 USB Device(s) found >> scanning bus 2 for devices... 1 USB Device(s) found >> scanning bus 4 for devices... 1 USB Device(s) found >> Hit any key to stop autoboot: 0 >> Booting from: mmc 0 ubldr.bin >> reading ubldr.bin >> 223912 bytes read in 53 ms (4 MiB/s) >> ## No elf image at address 0x42000000 >> ## Starting application at 0x42000000 ... >> > > Did ubldr work for you? > I feel like I have same problem: > > Booting from: mmc 0 ubldr.bin > reading ubldr.bin > 228276 bytes read in 67 ms (3.2 MiB/s) > ## No elf image at address 0x42000000 > ## Starting application at 0x42000000 ... > > Ganbold > > > > > > the latest one hangs, just like with you. > I=E2=80=99m using an older ubldr > Just curious, how old is your working ubldr? thanks, Ganbold > > > >> _______________________________________________ >> 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?CAGtf9xNb2_NWNb7pArT0qXZ9j__s4UmaM9B3F6qLFt9PVCcQfg>