Installation from scratch after build / fix postbuild #6
Comments
|
@farfromrefug Did you check the wiki for this repo? The postbuild script is not yet working, so the files copied to the flash directory are not complete. Instead you can find u-boot, initramfs image and ext4 image in the deploy directory. Instruction for installing are also in the wiki. I dogfood the instructions myself so they should be good, otherwise let me know. The idea is to install the rootfs on an sd card, so leaving your initial images untouched and bootable. But to boot the sd card the kernel needs the modules. The sd card modules can not be built-in (or not all), so I created a kernel with initramsfs, with the essential modules inside. This should boot (if you have the correct u-boot), at least into a busybox shell, but if all is well will switchroot to the sd card. |
|
Self assigned as a reminder to fix postbuild script and env to enable flashing with make flash |
|
@htot yes i read the wiki but i must have missed that! Sorry and thank you |
|
Is this issue resolved for you? Have you been able to build and flash? |
htot
changed the title
|
@htot sorry for my late answer. |
|
Hmm. I haven't used flash-tool-lite. Can you tell it to skip updating u-boot? Once you've updated that manually it doesn't need updating any more. |
|
@htot actually i really need this. We have around 100 Edisons. I need it to be able to clone my working system. |
|
Right now you need to:
That's quite a development setup and doesn't lend itself to updating many edisons at once. It surely can be enhanced to be so, but right now this whole activity is focusing on getting the basics ironed out and stable, first. |
|
Actually in step 2 you can scp it, not need to dfu-util. If you follow the wiki, you can update u-boot manually, scp new kernel manually, update the env manually. With a slightly modified kernel command line you should be able to boot your existing jubilinux (with a newer kernel). Except for kernel modules may have added. If you follow the instructions carefully your existing ubilinux should remain working but at least you can test it with a newer kernel. Then later we can try to help you figure out a way to automate the process. |
|
@alext-mkrs @htot First thanks a lot for helping me! Now about the kernel. I yet have to compile on and try to install manually to see if it works with my jubilinux. Using a newest kernel will also be a requirement very soon for us as we have to disable the SDcard module to make some GPIOs available: Now about the flash process, i think i can at least manage to make it flash a custom u-boot. #!/bin/bash
BACKUP_IFS=$IFS
IFS=$(echo -en "\n\b")
GETOPTS="$(which getopt)"
if [[ "$OSTYPE" == "darwin"* ]] ; then READLINK=greadlink; GETOPTS="$(brew list gnu-getopt | grep bin/getopt)"; else READLINK=readlink;fi;
if [[ "$OSTYPE" == "cygwin" ]] ;
then
TEMP_DIR="$(dirname $($READLINK -f $0))"
ESC_BASE_DIR="$(cygpath -m ${TEMP_DIR})"
BASE_DIR="$(cygpath -m ${TEMP_DIR})"
else
BASE_DIR="$(dirname $($READLINK -f $0))"
ESC_BASE_DIR=${BASE_DIR//' '/'\ '}
fi;
USB_VID=8087
USB_PID=0a99
TIMEOUT_SEC=60
DO_RECOVERY=0
# Handle Ifwi file for DFU update
IFWI_DFU_FILE=${ESC_BASE_DIR}/edison_ifwi-dbg
VAR_DIR="${BASE_DIR}/u-boot-envs"
if [[ "$OSTYPE" == "cygwin" ]] ; then
VARIANT_NAME="edison-blankrndis"
else
VARIANT_NAME="edison-blankcdc"
fi
LOG_FILENAME="flash.log"
OUTPUT_LOG_CMD="2>&1 | tee -a ${LOG_FILENAME} | ( sed -n '19 q'; head -n 1; cat >/dev/null )"
function print-usage {
cat << EOF
Usage: ${0##*/} [-h][--help][--recovery]
Update all software and restore board to its initial state.
-h,--help display this help and exit.
-v verbose output
--recovery recover the board to DFU mode using a dedicated tool,
available only on linux and window hosts.
EOF
exit -5
}
function flash-command-try {
eval dfu-util -v -d ${USB_VID}:${USB_PID} $@ $OUTPUT_LOG_CMD
}
function flash-dfu-ifwi {
ifwi_hwid_found=`dfu-util -l -d ${USB_VID}:${USB_PID} | grep -c $1`
if [ $ifwi_hwid_found -ne 0 ];
then
flash-command ${@:2}
fi
}
function flash-command {
flash-command-try $@
if [ $? -ne 0 ] ;
then
echo "Flash failed on $@"
exit -1
fi
}
function flash-debug {
echo "DEBUG: lsusb"
lsusb
echo "DEBUG: dfu-util -l"
dfu-util -l
}
function flash-ifwi {
if [ -x "$(which xfstk-dldr-solo)" ]; then
flash-ifwi-xfstk
else
echo "!!! You should install xfstk tools, please visit http://xfstk.sourceforge.net/"
exit -1
fi
}
function flash-ifwi-xfstk {
XFSTK_PARAMS=" --gpflags 0x80000007 --osimage ${ESC_BASE_DIR}/u-boot-edison.img"
XFSTK_PARAMS="${XFSTK_PARAMS} --fwdnx ${ESC_BASE_DIR}/edison_dnx_fwr.bin"
XFSTK_PARAMS="${XFSTK_PARAMS} --fwimage ${ESC_BASE_DIR}/edison_ifwi-dbg-00.bin"
XFSTK_PARAMS="${XFSTK_PARAMS} --osdnx ${ESC_BASE_DIR}/edison_dnx_osr.bin"
eval xfstk-dldr-solo ${XFSTK_PARAMS}
if [ $? -ne 0 ];
then
echo "Xfstk tool error"
flash-debug
exit -1
fi
}
function dfu-wait {
echo "Now waiting for dfu device ${USB_VID}:${USB_PID}"
if [ -z "$@" ]; then
echo "Please plug and reboot the board"
fi
while [ `dfu-util -l -d ${USB_VID}:${USB_PID} | grep Found | grep -c ${USB_VID}` -eq 0 ] \
&& [ $TIMEOUT_SEC -gt 0 ] && [ $(( TIMEOUT_SEC-- )) ];
do
sleep 1
done
if [ $TIMEOUT_SEC -eq 0 ];
then
echo "Timed out while waiting for dfu device ${USB_VID}:${USB_PID}"
flash-debug
if [ -z "$@" ]; then
echo "Did you plug and reboot your board?"
echo "If yes, please try a recovery by calling this script with the --recovery option"
fi
exit -2
fi
}
# Execute old getopt to have long options support
ARGS=$($GETOPTS -o hv -l "recovery,help" -n "${0##*/}" -- "$@");
#Bad arguments
if [ $? -ne 0 ]; then print-usage ; fi;
eval set -- "$ARGS";
while true; do
case "$1" in
-h|--help) shift; print-usage;;
-v) shift; OUTPUT_LOG_CMD=" 2>&1 | tee -a ${LOG_FILENAME}";;
--recovery) shift; DO_RECOVERY=1;;
--) shift; break;;
esac
done
echo "** Flashing Edison Board $(date) **" >> ${LOG_FILENAME}
if [ ${DO_RECOVERY} -eq 1 ];
then
if [[ "$OSTYPE" == "darwin"* ]] ; then
echo "Recovery mode is only available on windows and linux";
exit -3
fi
echo "Starting Recovery mode"
echo "Please plug and reboot the board"
echo "Flashing IFWI"
flash-ifwi
echo "Recovery Success..."
echo "You can now try a regular flash"
else
echo "Using U-Boot target: ${VARIANT_NAME}"
VARIANT_FILE="${VAR_DIR}/${VARIANT_NAME}.bin"
if [ ! -f "${VARIANT_FILE}" ]; then
echo "U-boot target ${VARIANT_NAME}: ${VARIANT_FILE} not found aborting"
exit -5
fi
VARIANT_FILE=${VARIANT_FILE/' '/'\ '}
dfu-wait
echo "Flashing IFWI"
flash-dfu-ifwi ifwi00 --alt ifwi00 -D "${IFWI_DFU_FILE}-00-dfu.bin"
flash-dfu-ifwi ifwib00 --alt ifwib00 -D "${IFWI_DFU_FILE}-00-dfu.bin"
flash-dfu-ifwi ifwi01 --alt ifwi01 -D "${IFWI_DFU_FILE}-01-dfu.bin"
flash-dfu-ifwi ifwib01 --alt ifwib01 -D "${IFWI_DFU_FILE}-01-dfu.bin"
flash-dfu-ifwi ifwi02 --alt ifwi02 -D "${IFWI_DFU_FILE}-02-dfu.bin"
flash-dfu-ifwi ifwib02 --alt ifwib02 -D "${IFWI_DFU_FILE}-02-dfu.bin"
flash-dfu-ifwi ifwi03 --alt ifwi03 -D "${IFWI_DFU_FILE}-03-dfu.bin"
flash-dfu-ifwi ifwib03 --alt ifwib03 -D "${IFWI_DFU_FILE}-03-dfu.bin"
flash-dfu-ifwi ifwi04 --alt ifwi04 -D "${IFWI_DFU_FILE}-04-dfu.bin"
flash-dfu-ifwi ifwib04 --alt ifwib04 -D "${IFWI_DFU_FILE}-04-dfu.bin"
flash-dfu-ifwi ifwi05 --alt ifwi05 -D "${IFWI_DFU_FILE}-05-dfu.bin"
flash-dfu-ifwi ifwib05 --alt ifwib05 -D "${IFWI_DFU_FILE}-05-dfu.bin"
flash-dfu-ifwi ifwi06 --alt ifwi06 -D "${IFWI_DFU_FILE}-06-dfu.bin"
flash-dfu-ifwi ifwib06 --alt ifwib06 -D "${IFWI_DFU_FILE}-06-dfu.bin"
echo "Flashing U-Boot"
flash-command --alt u-boot0 -D "${ESC_BASE_DIR}/u-boot-edison.bin"
echo "Flashing U-Boot Environment"
flash-command --alt u-boot-env0 -D "${VARIANT_FILE}"
echo "Flashing U-Boot Environment Backup"
flash-command --alt u-boot-env1 -D "${VARIANT_FILE}" -R
echo "Rebooting to apply partition changes"
dfu-wait no-prompt
echo "Flashing boot partition (kernel)"
flash-command --alt boot -D "${ESC_BASE_DIR}/edison-image-edison.hddimg"
echo "Flashing rootfs, (it can take up to 5 minutes... Please be patient)"
flash-command --alt rootfs -D "${ESC_BASE_DIR}/edison-image-edison.ext4" -R
echo "Rebooting"
echo "U-boot & Kernel System Flash Success..."
echo "Your board needs to reboot to complete the flashing procedure, please do not unplug it for 2 minutes."
fi
IFS=${BACKUP_IFS}I will try building a kernel and manually install it. Then i'll report here. |
|
@htot, indeed, forgot about that one and I actually used it, not dfu :-) @farfromrefug, that script looks very similar to Edison's official flashall.sh, is that the one or a fork? |
|
I just diffed, they are identical |
|
@alext-mkrs @htot yes it might, this is the one from jubilinux i think. Well what i am sure is that it is the one i use. |
|
So where above you say you have a working u-boot, not built with Yocto and you copy it to the deploy dir, I think you name it u-boot-edison.bin and overwrite the existing one? What kind of output do you get when the flashall.sh fails? |
|
@htot sorry i am not clear. This scripts works for me with the flash image (directory) from jubilinux. |
|
No that was clear. So you replace u-boot-edison.bin by the newly generated u-boot.bin? That should probably have worked. That's why I asked for the output of flashall when it fails. |
|
Or maybe that's the truncation thing? If you have old u-boot there, you need to run the truncate command on the binary before flashing. And yes, the output from the script would be quite helpful for troubleshooting. |
|
@alext-mkrs I did the truncate thing for sure. about the flash error log i will have to get it. |
|
When you update u-boot, it's permanent replacement. It's the boot kernel selection that is not and for which you need to do something during boot. By default, wiki instructions get you essentially a dual-image environment, where both kernel and rootfs from the official installation are preserved and boot by default. New kernel and rootfs are installed in parallel and namely to boot those you need to have those "edsboot" u-boot variables and have to interrupt the boot sequence, to explicitly boot them. The idea is that when new kernel and rootfs are proven to be stable enough, we'll have standard flashall script (or maybe its replacement, we'll see) do a full in-place update of the official image. |
|
@alext-mkrs thanks i get it now. For us it will be direct switch :D We actually can't wait... |
|
Updating u-boot by executing a command from within u-boot has worked more reliably for me then running the flashall script, which sometimes fails (or failed). The update itself is permanent, although we provide a binary image for recovery to an original edison image as well as xfstk deb (needed by the flashall script when you use --recovery). |
|
@htot my process would be this:
So i still need the flash script to install the latest u-boot for my "clones" |
|
With commit c159f4c we now generate all files needed to flash with |
|
@htot This is a great news. I will to test it this week and report here. Though we are on CES deadline so might be the week after. Thanks for your great job |
|
Credits go to @alext-mkrs mostly, thanks! |
|
@farfromrefug did you find time to test this? |
|
Hi there,
The following hack prevents the mkimage directory from being picked up and postBuild completes without errors.
After that, I try to use flashall but it fails:
On the console, I see:
And the normal kernel boots instead of the flashing process to start. I have been seeing that MMC error since I updated u-boot to the one built w/ Yocto. Is that a byproduct of me trying to use a mini-breakout board (without an SD card) or another issue? Thanks! |
|
Thanks, I just found the same error a few days ago and fixed it. I will compare yours with mine and commit. I have successfully flashed all using Flashtool Lite. But haven't tried on the breakout board, also haven't tried the flashall acript yet. Did you update the environment variables as here: https://github.com/htot/meta-intel-edison/wiki/6.3-Fixing-up-the-u-boot-environment BTW master now contains the latest (reviewed) code. I will be developing in rocko64 and sending PR's to self. |
|
Thanks for the quick reply. I had not updated the u-boot env, which might explain the issue. I'll see to 'make update' to get to the latest commits (my branch is about 1m old) |
|
Maybe you want to try out PR https://github.com/htot/meta-intel-edison/pull/18? |
|
Thanks, I'll give that a try after the environment update. |
|
@htot sorry it took me so long to answer! I did not have time to look at this. Should i use another branch? I tested this one cause it was the one with the most recent commits. Thanks |
|
Rocko is where I push my tested commits. After review (thanks @alext-mkrs ) I merge them into master. |
|
@htot seems like the setup.sh tries to setup a mingw env even if i am on linux or macos. |
|
@farfromrefug I see the exact same. What I did in setup: remove the lines that apply the mingw patch (but leave other setup of mingw as is). This caused If this works (i.e. builds image) I'll commit the patch. This means building sdk for windows is not tested, but actually this was never tested, maybe never worked. |
|
@htot yes that's it. I got it to start building on linux (failed on macos though). |
|
Hmm. I used |
|
That's interesting, my last checkout build (clean) of your PR was ok - I also had that mingw failure, but the fix was trivial (new patch - mingw file changed a bit) and then it was ok. Never got to send that patch update. |
|
I'm surprised too. That patch is still needed? If so, please send. |
|
@alext-mkrs Any ideas on how to make core-image-minimal-initramfs.bbappend depend on the kernel modules being available? |
|
I confirm I have the same issue on the pyro64-acpi branch which I tried tonight from a fresh clone. The following patch allows to work around the problem on pyro64-acpi at least (github is unable to attach the file if it has the .patch extension, I have renamed it). |
|
@vrubiolo thanks, that's about the same I have, although I left cloning mingw intact and just skipped the patch. But I believe @alext-mkrs has a fixed patch for mingw. So we can 2 ways: remove building sdk for windows or fix it. I am not particularly attached to building a sdk for windows. But if it is easy to fix, why not. let me know what you think. BTW the easiest way to send a patch is to push to a new branch in your repo, then send me a pull request. |
|
@alext-mkrs is right, it was a trivial fix. I just push that to rocko64-acpi for you to test. If you undo your changes to setup.sh, pull from me and run 'make update' all should be well again. |
|
@htot it build fine on linux so thats great. thanks for the fix on Now 2 questions remain.
thanks EDIT: BTW i think this issue is fixed as we can now flash it. Let me know if i can close it. EDIT2: also i started trying to configure the linux on the newly flashed edison. So i ran |
|
@farfromrefug Thanks for testing!
Maybe @alext-mkrs or @andy-shev have better advise for you in this area, if they can find a little time. For now, yes go ahead and close this issue. |
Not otmh. Generally bitbake doesn't know which ones are enabled, so it may not be possible at all. I'm currently travelling with no access to my dev machine and flaky internet, so can't advise more at the moment, sorry. |
|
@htot thanks for the explanation. I am looking at it right now.
Now i was thinking about changing the acpi tables in u-boot as you said. I think i have the acpi enabled u-boot kernel as it says so when i boot ;)
Thanks and sorry for all the questions :s |
|
In my latest (rocko) I moved the acpi tables to initramfs and the 'acpi-tables-load' script is called from init. So the arduino asl is loaded early. It could be loaded earlier if you load the cpio from U-Boot. Still you need to toggle TRI_STATE_ALL before external mux's work (as per hw ug). And that doesn't seem to be working completely yet, looks like I am to early. Maybe I need to build i2c modules into kernel in acpi case. Working on that. Note that MRAA won't toggle TRI_STATE_ALL for you in the acpi case as pin numbering changed. It does work nicely when you use gpiofind/gpioset. The above only applies if you build with acpi support. For no-acpi you don't load the tables. Maybe that is better for you? Also I applied the patch that should get i2c-6 working (should work, but I did not test yet). This required loading i2c modules from initramfs. init-live.sh is symlinked from /sbin/init iirc, so it is process 1. It needs to be 1 to execute this line 'exec switch_root -c /dev/console /realroot /sbin/init $CMDLINE'. So what happens is: If you want to go into busybox in the initramfs to see what is there I think you could add 'debugshell=1' to the kernel command line (or if you are trying to boot rootfs on sd or usb, just pull it out). 1 sec will be too short so you will be dropped to a shell (will be process 2, so you can't manually call switch_root here). You can add that using setenv from U-Boot (temporarily), or fw_setenv from linux (permanent). Default env is here: https://github.com/htot/meta-intel-edison/blob/master/meta-intel-edison-bsp/recipes-bsp/u-boot/files/edison.env |
I built the the Pyro64 following the wiki.
After the successfull build i ended up with the ext4 image, the u-boot-envs folder and the u-boot files.
Now i was thinking about flashing it from scratch on an edison.
To do so
But i get stuck at starting Kernel
Obvioulsy i forgot to compile and upgrade the kernel. I see how to build it from the wiki, then i end up with a
bzImage-initramfs-edison.binfile. But i dont see where to put that file.This is the list of files i have in my "flashing" directory that i use with "Flash Tool Lite"
Can someone help?
Thanks
The text was updated successfully, but these errors were encountered: