Darren Hart wrote on 2012-01-17: > On 01/17/2012 01:35 AM, Cui, Dexuan wrote: >> Darren Hart wrote on 2012-01-13: >> So, I think here we should change the = to ?= like the below -APPEND >> = "root=/dev/sda2" >> +APPEND ?= "root=/dev/sda2" >> And in meta/conf/machine/include/qemu.inc, I can add a line APPEND = >> "root=/dev/hda2". >> >> Does this sound ok? > > That seems appropriate to me. I decide not to change the line in boot-directdisk.bbclass and I think adding a line APPEND_${MACHINE} = "root=/dev/hda2" in qemu.inc should be ok. This is because ?= can have some side effort, i.e., in the case of atom, in atom-pc.conf, APPEND is already assigned a value that isn't suitable for syslinux.
>> >>> >>>> TIMEOUT = "10" >>>> SYSLINUXCFG = "${HDDDIR}/syslinux.cfg" >>>> SYSLINUXMENU = "${HDDDIR}/menu" >>>> @@ -50,6 +51,7 @@ build_boot_dd() { >>>> >>>> install -d ${HDDDIR} >>>> install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage >>> ${HDDDIR}/vmlinuz >>>> + install -m 0644 ${S}/syslinux.cfg ${HDDDIR}/syslinux.cfg >>> >>> Hrm... syslinux.cfg wasn't installed before at all? >> I'm not very clear about the history, but according to >> syslinux.bbclass, iso and hddimg do invoke syslinux_populate, but >> hdddirect doesn't -- I suppose hdddirect doesn't need all the >> functionality of build_syslinux_menu, so it tries to install the >> files itself, and unluckily it misses syslinux.cfg. Now there is no >> user of .hdddirect in poky, and I don't know there is any actual >> external user. This may explain why nobody complains. :-) > > This sounds like an opportunity to modularize and reuse to me. Agree. We should try to improve the code here in future. >> >>> >>>> install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys >>>> ${HDDDIR}/ldlinux.sys >>>> >>>> BLOCKS=`du -bks ${HDDDIR} | cut -f 1` @@ -83,6 +85,12 @@ >>>> build_boot_dd() { cd ${DEPLOY_DIR_IMAGE} rm -f >>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect ln -s >>>> ${IMAGE_NAME}.hdddirect >>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect >>>> + >>>> + if [ "${NOVMDK}" != "1" ] ; then >>>> + ${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk \ >>> >>> You've added a dependency on qemu-img, please add the appropriate >>> DEPENDS above. >> I have added the line in my patch: >> do_bootdirectdisk[depends] += "qemu-native:do_populate_sysroot" >> >> I think this is enough? >> Need I add "DEPENDS += "qemu-native", too? > > No, I don't think so. Is do_populate_sysroot the right task? That > would be my guess as well, but we should be confident. I think it should be ok: do_populate_sysroot installs the utility qemu-img into the sysroot and this is all we need. >> >>> >>>> + ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \ >>>> + ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk + fi >>>> } >>>> >>>> python do_bootdirectdisk() { >> >>> Darren Hart wrote on 2012-01-13: >>> On 01/10/2012 10:53 AM, Dexuan Cui wrote: >>> >>> A couple additional thoughts about the boot-directdisk class in general: >>> >>> So build_boot_dd needs a careful audit to ensure the various dd >>> commands do not stomp on eachother iirc, the dd of syslinux/mbr.bin >>> was stomping on the partition table or some such. >> Hi Darren, The dd-ing of mbr.bin actually writes only the first 440 >> bytes of $IMAGE -- please note the size of mbr.bin(generated by the >> recipe syslinux, I think) is 440 bytes rather than 512 bytes. :-) I >> think 440 is safe enough because it's even smaller than 512-16*4=448 >> bytes. >> >>> Also note that it uses "mkdosfs -d" which we have purged (and it >>> aint coming back if my NACK is worth anything ;-). Sounds like we >>> need to abstract building msdos images into an msdosfs.bbclass. No >>> reason to >> Would you volunteer to make a msdosfs.bbclass? :-) > > Not in the near future unfortunately, I'm heavily overloaded as it is. > That said, please open a bug and we can find an appropriate owner. Ok, I opened a bug http://bugzilla.pokylinux.org/show_bug.cgi?id=1913. >>> duplicate all the fatfs overhead calculations I did yesterday (See >>> the patch I sent yesterday to bootimg.bbclass). >> I agree. >> I see your patch has been in poky master now. >> If you could help to make msdosfs.bbclass, I would appreciate that a lot. >> Now I'm stick in something else and I'm afraid I can't start to work >> on this immediately. :-( >> > > Understood. Open the bug and explain what's needed and we'll > prioritize and assign it. There may also be others who would like this > feature that would be willing to pick up the task. Hi Darren, Thanks for all the comments! I'll send out the v2 patch and Cc you. Thanks, -- Dexuan _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core