[ELDK] No uImage in build images directory
lothar at denx.de
lothar at denx.de
Mon Aug 19 14:21:39 CEST 2013
Hi Larry,
Am 2013-08-16 23:21, schrieb Larry Baker:
> Lothar,
> Can you attach your conf/local.conf and the exact command you used?
> Are you requesting MACHINE=generic-armv5te?
>
> I changed the two entries for number of threads from 4 to 2, and I
> enabled the line that said MACHINE ?= qemuarm. I assumed that would
> not override the MACHINE= on the command line. I was poking around and
> I saw that the default kernel image format is zImage. That is what was
> built. It is also possible that the zImage format replaced the uImage
> format because I first requested a QEMU test in conf/local.conf. That
> step failed. I removed it and re-ran the build, without doing any
> "clean". The rootfs was recreated, but the kernel build steps were not
> repeated. The build was very quick, of course, and was successful
> (except for warnings for many missing license files). Perhaps all I
> need to do is a "clean" and repeat the build with the QEMU test
> disabled.
>
> Overnight last night (I work on this at home) I ran the test build
> from the Yocto Project Quick Start guide (a SATO rootfs, which is too
> much for my needs) from my ELDK distribution build directory. It
> completed without errors. (Which was also true of my generic-armv5te
> build, I believe.) Tonight or over the weekend I will see if that will
> run on QEMU. I also downloaded the Yocto VMware interactive project
> builder overnight so I can try using Hob. (I cannot run Hob on my
> CentOS Linux box due to the Gtk and PyGtk versions required.)
>
> Thank you,
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker at usgs.gov
>
> On 15 Aug 2013, at 6:04 AM, <lothar at denx.de> <lothar at denx.de> wrote:
>
>> Hi Larry,
>>
>> Am 2013-08-14 08:04, schrieb Larry Baker:
>>
>>> I have built an ELDK rootfs and kernel from git sources using the
>>
>>> steps from the Wiki section 3:
>> MACHINE=generic-armv5te bitbake core-image-basic
>
>> In tmp/deploy/images there is a Linux kernel zImage, but not a
>> uImage.
>
>> I'm puzzled, because the ELDK git generic-armv5te.conf says
>
>>> KERNEL_IMAGETYPE = "uImage"
>
>> Is there a step I am missing? My first try, I had to install texinfo
>
>> and chrpath. No other prerequisites were missing. I also had to
>
>> remove the local.conf setting to test the install on QEMU because
>
>> there is no test script for core-image-basic. Everything seemed to
>
>> complete without errors. (There were warnings, like missing checksum
>
>> files.)
>
>> I don't really need this kernel at the moment. But, it is newer than
>
>> the one I built, and I would like to use the ELDK machinery to keep
>> my
>
>> entire system up-to-date.
>
>> Thank you,
>
>> Larry Baker
>
>> US Geological Survey
>
>> 650-329-5608
>
>> baker at usgs.gov
>
>> _______________________________________________
>
>> eldk mailing list
>
>> eldk at lists.denx.de
>
>> http://lists.denx.de/mailman/listinfo/eldk [1]
>
> Thank you for the feedback. I'm trying to reproduce this and have a
> look into the issues.
>
> As far as I see at the moment for core-image-minimal and
> core-image-basic in ELDK 5.4 I can get something by the name of
> uImage.
>
> Best,
> Lothar
>
> _______________________________________________
> eldk mailing list
> eldk at lists.denx.de
> http://lists.denx.de/mailman/listinfo/eldk
>
>
>
> Links:
> ------
> [1] http://lists.denx.de/mailman/listinfo/eldk
First of all, sorry, this month is holiday season so we there are
probably fewer people reading the mailing list and I was travelling last
week, too.
Ok, about the zImage: I tried to do the following and obtained an
uImage:
history:
(...)
4334 mkdir ./git
4335 cd ./git/
4336 git clone git://git.denx.de/eldk.git
4337 cd eldk
4338 git checkout eldk-5.4
4339 BUILD_NAME=$(git branch | sed -ne '/(no branch)/d' -e 's/$/-/' -e
's/^\* //p')$(git log --format="%ad-%h" --date=short HEAD^\!)
4340 echo $BUILD_NAME
4341 TEMPLATECONF=meta-eldk/conf source oe-init-build-env
/opt/eldk/build/${BUILD_NAME}-armv7a
< Here I needed to first create the folder >
4342 mkdir -p /opt/eldk/build
4343 TEMPLATECONF=meta-eldk/conf source oe-init-build-env
/opt/eldk/build/${BUILD_NAME}-armv7a
4344 vi /data/yocto/git/eldk/meta-eldk/tools/set-path
4345 source /data/yocto/git/eldk/meta-eldk/tools/set-path
4346 MACHINE=generic-armv5te bitbake -v core-image-base | tee
./out__generic-armv5te__core-image-base.log 2>&1
$ ll ./tmp/deploy/images/
total 12016
-rw-r--r-- 1 user user 5317017 Aug 19 12:27
core-image-base-generic-armv5te-20130819092507.rootfs.tar.gz
lrwxrwxrwx 1 user user 60 Aug 19 12:27
core-image-base-generic-armv5te.tar.gz ->
core-image-base-generic-armv5te-20130819092507.rootfs.tar.gz
-rw-r--r-- 1 user user 210891 Aug 19 12:23
modules--3.8+git0+88c40fc9401a458b7e08f510ff0b2e0a5b4b2d01-r1-generic-armv5te-20130819092507.tgz
-rw-r--r-- 1 user user 294 Aug 19 12:27
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
lrwxrwxrwx 1 user user 95 Aug 19 12:23 uImage ->
uImage--3.8+git0+88c40fc9401a458b7e08f510ff0b2e0a5b4b2d01-r1-generic-armv5te-20130819092507.bin
-rw-r--r-- 1 user user 6721632 Aug 19 12:23
uImage--3.8+git0+88c40fc9401a458b7e08f510ff0b2e0a5b4b2d01-r1-generic-armv5te-20130819092507.bin
lrwxrwxrwx 1 user user 95 Aug 19 12:23 uImage-generic-armv5te.bin
->
uImage--3.8+git0+88c40fc9401a458b7e08f510ff0b2e0a5b4b2d01-r1-generic-armv5te-20130819092507.bin
Remark:
I've build in /opt/eldk/build which links to /data/opt/eldk/build my
build folder's name is 2013-08-19-0250828-armv7a; I checked the eldk out
under /data/yocto/git/eldk (instead of ~/git). To have a better
understanding what is going on, I generated verbose output ( -v ), and
piped it into a log file ( out__generic-armv5te__core-image-base.log ).
To my understanding the uImage is a zImage containing an uboot
(bootloader) header. I don't know if it is related to the presence of,
in case, build artifacts, rather some recipe / config related artifacts
(?).
Of course you can try some MACHINE=... bitbake -c cleanall, which will
remove even all downloaded packages; or just a -c clean which cleans
some intermediate packages; you can try to increase PR in the related
linux-eldk...bb file, then the kernel has to be build again.
It might be easier to remove "just" the whole "tmp" folder in the build
folder, and rebuild cleanly.
Sorry again, not a clear answer, but I could not reproduce it either.
Anyway I figured out other issues (linux fetcher, and perf), and in case
will try to answer them separately.
Best,
Lothar Rubusch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: local.conf
Type: application/octet-stream
Size: 10773 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/eldk/attachments/20130819/c5d8e44e/attachment.obj>
More information about the eldk
mailing list