OK, more digging. Putting 'HEAD' in for BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION forces a complete pull of the latest code (there isn't a tag called 'HEAD', so GIT punts and creates a local repository called 'linux-HEAD' with all of the latest commits).
But of course, there is always something... there appears to be a problem with the power management stuff, resulting in a build failure: LD sound/soundcore.o LD sound/built-in.o make[2]: *** No rule to make target `firmware/am335x-pm-firmware.bin', needed by `firmware/am335x-pm-firmware.bin.gen.o'. Stop. make[1]: *** [firmware] Error 2 make[1]: *** Waiting for unfinished jobs.... CC drivers/net/mii.o CC drivers/mtd/ubi/upd.o There is a 'am335x-pm-firmware.bin.gen.S' file in the firmware directory, but this is not present in other versions of the kernel that I have been working with from the TI GIT repository. When booting those variants (which don't have working MMC/SD support), they all seem to load up an 'am335x-pm-firmware.bin' file, which they are getting from who knows where; perhaps the 'am33x-cm3-AM335xPSP_04.06.00.10-rc1' project in output/build? Argh. Sorry to vent, Jim On Monday, January 6, 2014 3:58:26 PM UTC-5, [email protected] wrote: > > Oh well, that didn't work. Same MO, fails with a 20-byte tarball image > named 'linux-'. > > It would seem that there needs to be something useful in the field for > Buildroot (and maybe GIT) to work: > > BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION: > > │ > > │ > > │ > │ Git revision to use in the format used by git > rev-parse, > │ > │ E.G. a sha id, a tag, branch, .. > > The build results indicate that there might be a problem with 'linux-' as > well: > > >>> linux Downloading > Doing shallow clone > Cloning into 'linux-'... > warning: Could not find remote branch --bare to clone. > fatal: Remote branch --bare not found in upstream origin > Doing full clone > Cloning into bare repository 'linux-'... > remote: Counting objects: 3445333, done. > remote: Compressing objects: 100% (526886/526886), done. > Receiving objects: 100% (3445333/3445333), 697.64 MiB | 1.20 MiB/s, done. > remote: Total 3445333 (delta 2898718), reused 3435074 (delta 2888463) > Resolving deltas: 100% (2898718/2898718), done. > usage: git archive [options] <tree-ish> [<path>...] > or: git archive --list > or: git archive --remote <repo> [--exec <cmd>] [options] <tree-ish> > [<path>...] > or: git archive --remote <repo> [--exec <cmd>] --list > > --format <fmt> archive format > --prefix <prefix> prepend prefix to each pathname in the archive > -o, --output <file> write the archive to this file > --worktree-attributes > read .gitattributes in working directory > -v, --verbose report archived files on stderr > -0 store only > -1 compress faster > -9 compress better > > -l, --list list supported archive formats > > --remote <repo> retrieve the archive from remote repository > <repo> > --exec <command> path to the remote git-upload-archive command > > >>> linux Extracting > gzip -d -c > /home/build/mi/beaglebone/buildroot-save-emmc-0.0.1/dl/linux-.tar.gz | tar > --strip-components=1 -C > /home/build/mi/beaglebone/buildroot-save-emmc-0.0.1/output/build/linux- > -xf - > tar: This does not look like a tar archive > tar: Exiting with failure status due to previous errors > > Ugh. Is there a new(er) tag that I can use, one some sort of 'head' tag > or something? > > Thanks, > Jim > On Monday, January 6, 2014 2:52:00 PM UTC-5, RobertCNelson wrote: >> >> On Mon, Jan 6, 2014 at 1:02 PM, <[email protected]> wrote: >> > Hello, >> > >> > I realize that this is an old thread, but was hoping that one of y'all >> might >> > see this and shed some light on what I'm doing wrong... >> > >> > I pulled the buildroot project from >> > "https://github.com/jadonk/buildroot/releases/tag/save-emmc-0.0.1"; >> since >> > it's exactly what I need (an initramfs with working support for the SD >> card; >> > I can't get MMC/SD to work with the mainline kernel and Buildroot >> 2013.11). >> > >> > Problem is, when I follow the build instructions, it goes off to do a >> GIT >> > clone on from GitHub of tag "ddd36e546e53d3c493075bbebd6188ee843208f9" >> to >> > get Linux kernel patches. It appears to contact the GIT server, >> processes >> > some 697MB with of data, builds a tarball on the remote end, and then >> > downloads a "linux-ddd36e546e53d3c493075bbebd6188ee843208f9.tar.gz" >> tarball >> > file with 20 bytes in it. >> >> Yeah... I think i see an issue with github.com/beagleboard/linux the >> current practice has always been to push over the old branch, so when >> i pushed to fixes to the 3.8 branch last week that rewrote the history >> and now ddd36e546e53d3c493075bbebd6188ee843208f9 is probally a single >> file no longer connected to anything... >> >> Can buildroot just use the "3.8" branch instead of a specific commit? >> >> > >> > At this point, the Buildroot compile dies, since the tarball is >> > truncated/corrupted/something. >> > >> > I'm not very well versed in GIT internals; can anyone shed some light >> on >> > what might be wrong so I can get this compiled? I will happily provide >> any >> > logs or other information, but am too new at using GIT to know what to >> post >> > up. >> >> -- >> Robert Nelson >> http://www.rcn-ee.com/ >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
