[ELDK] No uImage in build images directory
Larry Baker
baker at usgs.gov
Sun Aug 18 19:45:24 CEST 2013
On Aug 16, 2013, at 2:21 PM, Larry Baker wrote:
> 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
>>
>>
>> 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.
>>
The Yocto Project SATO build completed without any errors, but when I went to run qemuarm, I got nothing. I think maybe the kernel arguments (console=) were not compatible with QEMU, but I did not want to spend any time on that problem.
I started over and wiped everything out. I downloaded the ELDK git again. The fresh build from ELDK git sources worked this time.
I have not tested the results on my hardware yet. This time I did not edit any of the MACHINE settings in conf/local.conf and I did not ask for QEMU testing. I think when I first asked for QEMU testing, that changed the kernel image setting from uImage to zImage. Even after I removed that, bitbake -c clean did not clean up the choices, which seemed to be fixed in the build tree. For example, when I tried to rerun MACHINE=... bitbake, bitbake ignored the MACHINE on the command line and always used the MACHINE from conf/local.conf.
I think the instructions in the ELDK-5 EldkBuilding web page where it says you can edit conf/local.conf should add a cautionary note about what can happen. It does not seem necessary.
Also, it would be nice to know how to wipe out the build tree but preserve the sources that have already been downloaded. It took hours to download all the source files again because I do not know how to separate the local download cache from the build tree.
I think I am making progress now.
Thank you.
>> Best,
>> Lothar
>>
>> _______________________________________________
>> eldk mailing list
>> eldk at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/eldk
>
More information about the eldk
mailing list