Date: Tue, 04 Aug 2015 07:56:05 -0600 From: Ian Lepore <ian@freebsd.org> To: Svatopluk Kraus <onwahe@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: kernel entry point address [was: Hummingboard u-boot not loading?] Message-ID: <1438696565.70393.72.camel@freebsd.org> In-Reply-To: <CAFHCsPXo2BLkrmfsB7UbwZZtsLkB=iAU9wK67O6Y6FJBDgSBnA@mail.gmail.com> References: <CABx9NuTk2xwncnOMb73ujtOLmA4LvN7V=CHfiL5CC9bFwZ%2BX_Q@mail.gmail.com> <20150728173831.229400355e485fa511ca388b@ulrich-grey.de> <CABx9NuQ3vPbJv%2B0cxt1QijnqYad1nKrQyifbNPBgicyr%2Bv5Mow@mail.gmail.com> <CABx9NuTNbh3Ckbx1L7wLWmP%2Bq4kJXQMd-huem7PcfehzQk18_g@mail.gmail.com> <CABx9NuTgD3US6AW9fpo0OmKSKEuJHqPPMD-pM28fTHMf92q7tw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-08-04 at 11:52 +0200, Svatopluk Kraus wrote: > 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 There has been some mention lately on irc of the entry point address jumping around from one kernel compile to the next (not just on arm). It may be alignment-related in the sense that a tiny change to the source requires it to split the text and data into different sections so that the data section is aligned properly. That results in an extra program header for the next section, and that makes the headers big enough to push the start of the text segment to its next alignment boundary (256 bytes iirc). It's not clear when/why this started happening, but there have been changes to the elf toolchain stuff lately. Maybe the old tools inserted some padding bytes but left text+data as one section, and now the new tool splits it into two sections (perhaps because of differences in the RWE bits that are now being honored correctly). U-boot launches ubldr using the 'bootelf' command which reads the elf headers, so it should work fine (unless maybe it fails to deal with multiple sections with the LOAD flag on). ubldr uses the elf headers in the kernel (but again I'm not sure about handling of multiple LOAD flags). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1438696565.70393.72.camel>