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?
Thanks for replying so quickly, I really do appreciate it.
Dieter:
Yes, I can pull directly as you indicated to try, thanks.
Robert:
It would appear that Buildroot can just pull from ‘head’ or whatever GIT calls the current copy. If I clear out the tag entry in Buildroot, I get the following:
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: 76% (2620199/3445333), 381.07 MiB | 1.07 MiB/s
This is still in progress as I type this, but it looks promising since the number of objects matches what it indicated when it was attempting to pull the tagged version. I’ll post up if this works after the download completes.
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] […]
or: git archive --list
or: git archive --remote [–exec ] [options] […]
or: git archive --remote [–exec ] --list
–format archive format
–prefix prepend prefix to each pathname in the archive
-o, --output 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 retrieve the archive from remote repository
–exec 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?
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?
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?
It is possible to use a head tag, but I just pushed that particular
commit back in on a new branch and tagged it. That should mean it is
there if you try again.
I can now successfully build a bootable version of the sources and access to the MMC/SD seems to work (all I needed was the SD for persisting configuration data).
I have tried to save my information with this procedure, but when the BBB start (Power led ON), with the S2 pushed, The USR leds are not Blinked (OFF), I pushed for several seconds and minutes, but they do not turn ON, after 15 or 20 min. nothing happen inseide the uSD, no data are save?
Could someone help me?, can’t have my data save in order to reflashed the BBB
I have tried to save my information with this procedure, but when the BBB start (Power led ON), with the S2 pushed, The USR leds are not Blinked (OFF), I pushed for several seconds and minutes, but they do not turn ON, after 15 or 20 min. nothing happen inseide the uSD, no data are save?
Could someone help me?, can’t have my data save in order to reflashed the BBB
First of all, thank you for this post, it works great on my latest BBBs (REV C). However, I cannot get it to work with my older BBBs (REV A6). We have quite a few of the older versions laying around and would like to use those for some KIOSKs we are setting up in house. Unfortunately, the script does not want to work on these boards. The script is booting to the SD card but it does not appear to recognize (or mount) the eMMC. I added ls /dev > /mnt/dev.txt to the bash script so I could see the device list, and there is only mmcblk0, there is not a mmcblk1. I am powering the device with a 5V, 2A power supply and have disconnected all other cables (as suggested in other posts) and still no luck. The device goes straight to a solid LED and writes the dev.txt and a 1KB img.gz file. I have tried running it on multiple boards and am unsure what to try next. Any thoughts as to why the eMMC is not being loaded/mounted?