Date: Wed, 05 Aug 2015 11:02:23 -0600 From: Ian Lepore <ian@freebsd.org> To: Russell Haley <russ.haley@gmail.com> Cc: Svatopluk Kraus <onwahe@gmail.com>, Oleksandr Tymoshenko <gonzo@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Hummingboard u-boot not loading? Message-ID: <1438794143.70393.174.camel@freebsd.org> In-Reply-To: <CABx9NuQnDmJ0ToPQ4LgsDq3XSTYhgqMw60uk%2BPaqbw1-ESHp-Q@mail.gmail.com> References: <CABx9NuTk2xwncnOMb73ujtOLmA4LvN7V=CHfiL5CC9bFwZ%2BX_Q@mail.gmail.com> <CAJwjRmSx3JJLTROzTPfDpAptJoiOSsOS6V2ZrWSDYE-8DaGm5g@mail.gmail.com> <20150801182519.4886608.58781.1809@gmail.com> <CABx9NuQi2=8L_1hdpkTPLi864X9y5RigU2Vg7FyAhCOc_v8MNQ@mail.gmail.com> <CAJwjRmQegAs5WcudU0baUqM%2BBxBW=MNpwsBx7ep7QUjAxS%2BtPw@mail.gmail.com> <CABx9NuTeExjRFa7YrpDFa3nJwDx9gg%2B0_wCqAhRF1ezFga6pNA@mail.gmail.com> <CABx9NuT-bcoz_wyz9s5rAuy7jEPwzJ0PehLsXQSh2EOiT3GEFA@mail.gmail.com> <CABx9NuTJ-9NeEQpMZk3nRZVCcYZOspfeX7K1=zGxhjYTMb1_1A@mail.gmail.com> <CABx9NuSm5rwVJYRxPAXoRnx7qyq%2BgBC48BufHPkS4M09V155iw@mail.gmail.com> <CAFHCsPXo2BLkrmfsB7UbwZZtsLkB=iAU9wK67O6Y6FJBDgSBnA@mail.gmail.com> <20150804220401.4886608.77426.1917@gmail.com> <CABx9NuQnDmJ0ToPQ4LgsDq3XSTYhgqMw60uk%2BPaqbw1-ESHp-Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
If you've got enough control to type at u-boot prompts, maybe we can
wish away any ubldr-doesn't-match-uboot address problems by using the
new relocatable ubldr, like so...
fatload mmc 0 ${loadaddr} ubldr.bin
go ${loadaddr}
Depending on how you build your images, you may need to do something
extra to copy ubldr.bin to the fat partition.
Next issue is "setenv fdt_file hummingboard-dual.dtb" -- where is that
name coming from? The right filename for a dual-core hummingboard would
be imx6dl-hummingboard.dtb, and that file should exist in
your /boot/dtb directory on the freebsd filesystem.
Svata's comments about the load address changing are for the kernel
address, and only apply if you're launching the kernel directly from
u-boot (which nobody should be doing unless they're somehow forced to
use a vendor-supplied u-boot instead of building one with API support
for ubldr). Once ubldr is running it will read the kernel headers and
load the kernel correctly even if the entry point has moved around.
BTW... you can do "printenv varname" to see just one var, and
tab-completion should work if you don't know the exact spelling of the
var.
-- Ian
On Wed, 2015-08-05 at 00:41 -0700, Russell Haley wrote:
> Hello,
>
> From what I can see, the loadaddr from printenv is 0x10800000 which is
> consistent with the solid-run wiki. I can't tell what the boot command used
> is. <red herring>Nothing has been easy with this project. I was trying to
> go back and see what the u-boot environment variables told me but the text
> rolls off the top of the screen. I can't pipe the printenv into less/more
> because the keyboard I am using just won't give me a pipe character. So
> there is something weird about the character codes it's sending (I get ~ or
> # instead of the characters I'm supposed to get for that key).</red
> herring> No big deal, I will replace this keyboard at my soonest
> convenience.
>
> So for kicks and giggles I ran this command at the u-boot prompt:
>
> *setenv fdt_file hummingboard-dual.dtb; fatload mmc 0 10800000 ubldr;
> bootelf 10800000;*
>
> and I get the same output:
>
> *260674 bytes read in 26 ms (9.6MiB/s)*
>
>
> I further boiled it down and ran
>
> *fatload 10800000 ubldr;*
>
> and then
>
> *bootelf 10800000;*
>
> With the same result. This combined with the lack of boot logs in the
> /mnt/var/log/messages folder seems to indicate bootelf hangs?
>
> Anyway, the suggestion about just loading the kernel and booting it a good
> one - I did that with an older CCWMX53 board. However, that is a very last
> ditch temporary solution. I want this to boot properly using ubldr, so it
> is worth the extra to get this working correctly.
>
> So here are some of the questions I am asking myself:
> - I have done alot of "thrashing around". Perhaps I should go back and get
> u-boot to build properly? But that doesn't seem to matter: if I get the
> u-boot prompt, doesn't that mean it's working?
> - Do I need to further investigate the fdt files?
> - Do I need to look into the ubldr build and code? What is the possibility
> of ubldr being broken? Is Svata correct that the start address changed and
> I need to do something different?
>
> Thanks,
>
> Russ
>
> On Tue, Aug 4, 2015 at 3:04 PM, Russell Haley <russ.haley@gmail.com> wrote:
>
> > I'll check my load and starting addresses when I get home. I have seen two
> > different numbers around.
> >
> > Russ
> >
> > Sent from my BlackBerry 10 smartphone on the Koodo network.
> > Original Message
> > From: Svatopluk Kraus
> > Sent: Tuesday, August 4, 2015 2:52 AM
> > To: Russell Haley
> > Cc: Mikaël Urankar; Oleksandr Tymoshenko; Ian Lepore; freebsd-arm
> > Subject: Re: Hummingboard u-boot not loading?
> >
> > On Tue, Aug 4, 2015 at 6:57 AM, Russell Haley <russ.haley@gmail.com>
> > wrote:
> > > Hello,
> > >
> > > Recap: I'm trying to get a Hummingboard with dual core pro SOM to boot
> > > using only HDMI output (I don't have a FTDI cable yet) . I am running a
> > > binary u-boot from Oleksandr. Successfullly built head yesterday.
> > >
> > > My SD Card looks like this:
> > >
> > > - 1Mb free space with uboot at 1k
> > > - 50Mb Fat32 partition with ubldr
> > > - 3.6Gb ufs partition
> > >
> > > I applied the patch for HDMI output:
> > > https://lists.freebsd.org/pipermail/freebsd-arm/2015-July/011912.html
> > > (Oleksandr via Mikael). I then ran buildkernel with the -DNOCLEAN option
> > > (thanks Ian!). I then mistakenly did a installkernel which takes hours on
> > > an SD card and overwrote everything so I couldn't tell if the files I
> > > wanted were actually installed (i.e. imx6_hdmi.o). I can't find any of
> > the
> > > files I think I should have been added, but that could be my feeble
> > > understanding of file searching.
> > >
> > > Anyway, I ran it and nothing changed. I get a u-boot auto config counting
> > > down, I get the message *20647 bytes read in 26 ms (9.6MiB/s) *which is
> > the
> > > size of ubldr, but nothing fires after that. It could the output is
> > > happening on a serial out, or it could be nothing is happening??? I have
> > > toyed with the idea of adding something to loarder.conf, but the defaults
> > > all seem sufficient, again, unless someone can suggest something?
> > >
> >
> >
> > Well, this just reminds me of something I dealt with recently. I'm
> > running FreeBSD kernel without ubldr, so u-boot loads kernel and then
> > jumps to kernel starting address. It turns out that kernel starting
> > address, which was always stable, was changed suddently and the result
> > was same like in your case. Thus, maybe it's worth a try to find out
> > how ubldr is run from u-boot and which is its starting address.
> >
> > Svata
> >
> >
> > > I have no further actions I can think of until I get an FDTI cable. All
> > > suggestions welcome.
> > >
> > > Russ
> > >
> > > On Mon, Aug 3, 2015 at 12:11 AM, Russell Haley <russ.haley@gmail.com>
> > wrote:
> > >
> > >> Just an FYI,
> > >>
> > >> I'm rebuilding the kernel after applying the IMX6 HDMI patch provided
> > >> by Mikaël (but incidentally written by Oleksandr!). Will know more in
> > >> the morning
> > >>
> > >> Russ
> > >>
> > >> On Sun, Aug 2, 2015 at 9:53 PM, Russell Haley <russ.haley@gmail.com>
> > >> wrote:
> > >> > Well I have seen what I think is ubldr get loaded by u-boot. I see the
> > >> > following message:
> > >> >
> > >> > 20647 bytes read in 26 ms (9.6MiB/s)
> > >> >
> > >> > And then nothing. I am hoping this mean ubldr successfully loaded. The
> > >> > lack of the rest of the output seems to make me think, well, I don't
> > >> > know what to think. Is the output going to the serial console I don't
> > >> > currently have? Just because it read the file doesn't mean that
> > >> > bootelf worked? I don't have anything in a loader.conf file yet so
> > >> > that may also be the problem.
> > >> >
> > >> > Ian, thanks for chiming in. I want to keep going with the binary that
> > >> > Gonzo gave me but I will look back at the pkgng image once I get a
> > >> > full boot happening.
> > >> >
> > >> > As usual, all suggestions welcome.
> > >> >
> > >> > Thanks,
> > >> > Russ
> > >> >
> > >> > On Sun, Aug 2, 2015 at 10:26 AM, Russell Haley <russ.haley@gmail.com>
> > >> wrote:
> > >> >> Hi guys,
> > >> >>
> > >> >> No, I don't have a serial cable yet. I have ordered an FDTI cable and
> > >> >> should have it this week. Oleksandr gave me a binary that is working
> > >> >> right now, I will try out the new patch as soon as I have the FDTI
> > >> >> cable and can get debug output.
> > >> >>
> > >> >> okay, on to the next problem...
> > >> >>
> > >> >> Russ
> > >> >>
> > >> >> On Sun, Aug 2, 2015 at 9:02 AM, Mikaël Urankar <
> > >> mikael.urankar@gmail.com> wrote:
> > >> >>> 2015-08-02 5:57 GMT+02:00 Russell Haley <russ.haley@gmail.com>:
> > >> >>>> Thanks Mikael,
> > >> >>>>
> > >> >>>> I was able to build using the patches you provided and the binary
> > >> >>>> u-boot.imx is the exact same size as the one from pkgng. However,
> > >> >>>> nothing happens when I boot it:
> > >> >>>
> > >> >>> I've updated my patch, it works on my cubox.
> > >> >>>
> > >>
> > http://mikael.urankar.free.fr/FreeBSD/arm/patches/sysutils_u-boot-cubox-hummingboard_gcc-5.2.patch
> > >> >>>
> > >> >>> The patches come from here:
> > >> >>>
> > >>
> > https://github.com/OpenELEC/OpenELEC.tv/tree/master/packages/tools/u-boot/patches
> > >> >>>
> > >>
> > http://u-boot.denx.narkive.com/XoUw8ZsY/patch-arm-switch-to-mno-unaligned-access-when-supported-by-the-compiler
> > >>
> > > _______________________________________________
> > > freebsd-arm@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
> >
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> http://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?1438794143.70393.174.camel>