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
[email protected]

On 15 Aug 2013, at 6:04 AM, <[email protected]> <[email protected]> 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

[email protected]

_______________________________________________

eldk mailing list

[email protected]

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
[email protected]
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








Attachment: local.conf
Description: Binary data

_______________________________________________
eldk mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/eldk

Reply via email to