Installation from scratch after build / fix postbuild

[farfromrefug]

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

• i took official release zip,
• copied the built files inside it, replacing old ones
• tried to flash.

But i get stuck at starting Kernel

U-Boot 2017.09 (Nov 17 2017 - 15:07:34 +0000)

CPU: x86_64, vendor Intel, device 406a8h
DRAM:  980.6 MiB
MMC:   mmc@ff3fc000: 0, mmc@ff3fa000: 1
In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0
Target:blank
Partitioning already done...
Flashing already done...
reading vmlinuz
6989120 bytes read in 315 ms (21.2 MiB/s)
Valid Boot Flag
Setup Size = 0x00003e00
Magic signature found
Using boot protocol version 2.0d
Linux kernel version 4.8.0-rc4 (root@ubuntu) #3 SMP Mon Sep 5 07:49:17 EDT 2016
Building boot_params at 0x00090000
Loading bzImage at address 100000 (6973248 bytes)
Magic signature found
Kernel command line: "rootwait root=PARTUUID=012b3303-34ac-284d-99b4-34e03a2335f4 rootfstype=ext4 console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config=cdc systemd.unit=multi-user.target hardware_id=00 g_multi.iSerialNumber=701aeb7dcdbca11ae870b32fd711de3b g_multi.dev_addr=02:00:86:11:de:3b platform_mrfld_audio.audio_codec=dummy"

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.bin file. 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

[htot]

@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.

[htot]

Self assigned as a reminder to fix postbuild script and env to enable flashing with make flash

[farfromrefug]

@htot yes i read the wiki but i must have missed that! Sorry and thank you

[htot]

Is this issue resolved for you? Have you been able to build and flash?

[farfromrefug]

@htot sorry for my late answer. So no i have not been able to build and flash. As mentioned before my issue is with u-boot. I built the u-boot using andy-shev/u-boot branch. That u-boot works perfectly and i can install it manually using dfu-util. However if i copy that file to my "flash" directory (based on jubilinux), the flash process wont work. I guess this is because i am missing files. I want to help but i don't even know where to start right now :s I will keep on looking

[htot]

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.

[farfromrefug]

@htot actually i really need this. We have around 100 Edisons. I need it to be able to clone my working system. How do you flash your edison? you use a sh script?

[alext-mkrs]

Right now you need to:

1. update u-boot (done once per Edison, uses dfu-util) and its environment (manually)
2. flash kernel to the ex-OTA partition (using dfu-util)
3. dump the ext4 file (rootfs) onto sd card, the kernel will boot from there by default.

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.

[htot]

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.

[farfromrefug]

@alext-mkrs @htot First thanks a lot for helping me! @htot yes i already have the u-boot working with my jubilinux using the manual install. Works great. That s actually a necessary first step because someone in our team is about to start working on GPIO in the u-boot (will create a PR obviously).

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: https://github.com/andy-shev/linux/issues/19

Now about the flash process, i think i can at least manage to make it flash a custom u-boot. To flash jubilinux we use a .sh file like this: I need to get deeply into it

#!/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. Thanks!

[alext-mkrs]

@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?

[htot]

I just diffed, they are identical

[farfromrefug]

@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.

[htot]

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?

[farfromrefug]

@htot sorry i am not clear. This scripts works for me with the flash image (directory) from jubilinux. Now if i change only the u-boot-edison.bin it fails! What i am saying we might be able to modify the script to update the u-boot only using the bin file. I have to look deeper into it EDIT: i am sorry for not being clear, we are in a rush before the CES ...

[htot]

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. Of course you would still need to fix the u-boot environment by pressing ESC during boot. You can use this https://github.com/htot/meta-intel-edison/wiki/6.3-Fixing-up-the-u-boot-environment as inspiration.

[alext-mkrs]

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.

[farfromrefug]

@alext-mkrs I did the truncate thing for sure. about the flash error log i will have to get it. @htot i am a little worried about the u-boot replacement, the wiki mentions that i have to do it in the boot sequence. Can't i make it permanent? Obviously as this will be part of our product, i can't have such a procedure on startup.

[alext-mkrs]

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.

[farfromrefug]

@alext-mkrs thanks i get it now. For us it will be direct switch :D We actually can't wait...

[htot]

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).

[farfromrefug]

@htot my process would be this:

• update the u-boot manually on my "dev" edison
• test
• backup my edison into an ext4 file
• flash duplicates edisons (about 100)

So i still need the flash script to install the latest u-boot for my "clones"

[htot]

With commit c159f4cf29e65861b5651d3572580bb9c3d60592 we now generate all files needed to flash with flashall.sh and Flash Tool Lite. Probable the make file is not yet fully working because we have a step to bitbake edison-image and one to bitbake lib32-u-boot. After these are done go to the directory above meta-intel-edison and do ./meta-intel-edison/utils/flash/postBuild.sh ./out/current/build This will generate the out/linux64/build/toFlash/ directory. Go there and source flashall.sh should work. Myself, I just tested this using Flash Tool Lite.

[farfromrefug]

@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

[htot]

Credits go to @alext-mkrs mostly, thanks!

[htot]

@farfromrefug did you find time to test this?

[vrubiolo]

Hi there, I managed to build pyro64-acpi so I gave postBuild/flashAll a try. There was an issue when calling postBuild.sh in that it picks up the wrong mkimage, preventing that step from working:

4194304 bytes (4.2 MB) copied, 0.0126044 s, 333 MB/s ./meta-intel-edison/utils/flash/postBuild.sh: line 100: ./out/current/build/tmp/work/edison-poky-linux/u-boot/1_2018.01-r0/build/include/config/mkimage: Is a directory * Done Files ready to flash in ./out/current/build/toFlash/ Run the flashall script there to start flashing.

---

The following hack prevents the mkimage directory from being picked up and postBuild completes without errors.

diff --git a/utils/flash/postBuild.sh b/utils/flash/postBuild.sh index 0ba82aee0b4f..b6b9c1fa9ba5 100755 --- a/utils/flash/postBuild.sh +++ b/utils/flash/postBuild.sh @@ -78,7 +78,7 @@ if [ -a $ubootdir ]; then mkimage_tool_path=$(find $top_repo_dir/u-boot -name mkimage) fi if [ -z $mkimage_tool_path ]; then - mkimage_tool_path=$(find $build_dir/tmp/work/edison-poky-linux/u-boot -name mkimage) + mkimage_tool_path=$(find $build_dir/tmp/work/edison-poky-linux/u-boot -name mkimage | grep tools) if [ -z "$mkimage_tool_path" ]; then echo "Error : ota_update.scr creation failed, mkimage tool not found" exit 0

After that, I try to use flashall but it fails:

$ sudo ./flashall.sh Using U-Boot target: edison-blankcdc Now waiting for dfu device 8087:0a99 Please plug and reboot the board Timed out while waiting for dfu device 8087:0a99

On the console, I see:

U-Boot 2018.01 (Mar 03 2018 - 09:29:07 +0000) CPU: x86_64, vendor Intel, device 406a8h DRAM: 980.6 MiB MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1 In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Target:blank Partitioning already done... Flashing already done... Memory layout (mmc) not supported! DFU entities configuration failed! dfu - Device Firmware Upgrade Usage: dfu [list|timeout] - device firmware upgrade via on device , attached to interface

[list] - list available alt settings [timeout] - specify inactivity timeout in sec, doesn't work with list reading vmlinuz

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!

[htot]

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.

[vrubiolo]

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)

[htot]

Maybe you want to try out PR https://github.com/htot/meta-intel-edison/pull/18?

[vrubiolo]

Thanks, I'll give that a try after the environment update.

[farfromrefug]

@htot sorry it took me so long to answer! I did not have time to look at this. I am back on it. Now i am wondering which branch i should work with? i tried rocko64-acpi but i get errors on setup :

Setup buildenv for SDK host linux64
./meta-intel-edison/setup.sh  --dl_dir=/home/mguillon/dev/edison/bbcache/downloads --sstate_dir=/home/mguillon/dev/edison/bbcache/sstate-cache --build_dir=/home/mguillon/dev/edison/out/linux64 --build_name=custom_build_mguillon@20180423183914 --sdk_host=linux64
Fetching origin
remote: Counting objects: 11830, done.
remote: Compressing objects: 100% (3165/3165), done.
remote: Total 11830 (delta 9033), reused 11260 (delta 8514)
Receiving objects: 100% (11830/11830), 6.55 MiB | 1.43 MiB/s, done.
Resolving deltas: 100% (9033/9033), completed with 1203 local objects.
From git://git.yoctoproject.org/poky
   fb8bf6a..58863ad  dizzy      -> dizzy
   c53ddb2..8763191  fido       -> fido
   ac4d3fc..3312754  jethro     -> jethro
   bddb60b..444dc2e  krogoth    -> krogoth
   205cfd7..c4338a9  master     -> master
 + fa2225d...bc76f69 master-next -> master-next  (forced update)
   e6aadcc2..0e73077 morty      -> morty
 + 1472eab...3ffb69b morty-next -> morty-next  (forced update)
   333b79a..f3e674c  pyro       -> pyro
 + 75874c8...0dd299e pyro-next  -> pyro-next  (forced update)
   759b36a..fdeecc9  rocko      -> rocko
 + e62d98a...a75be50 rocko-next -> rocko-next  (forced update)
 * [new branch]      sumo       -> sumo
 * [new branch]      sumo-next  -> sumo-next
 * [new tag]         2.5_M1     -> 2.5_M1
 * [new tag]         2.5_M2     -> 2.5_M2
 * [new tag]         2.5_M3     -> 2.5_M3
 * [new tag]         morty-16.0.3 -> morty-16.0.3
 * [new tag]         pyro-17.0.3 -> pyro-17.0.3
 * [new tag]         rocko-18.0.1 -> rocko-18.0.1
 * [new tag]         rocko-18.0.2 -> rocko-18.0.2
 * [new tag]         uninative-1.8 -> uninative-1.8
 * [new tag]         uninative-1.9 -> uninative-1.9
 * [new tag]         yocto-2.2.3 -> yocto-2.2.3
 * [new tag]         yocto-2.3.3 -> yocto-2.3.3
 * [new tag]         yocto-2.4.1 -> yocto-2.4.1
 * [new tag]         yocto-2.4.2 -> yocto-2.4.2
Fetching origin
remote: Counting objects: 6270, done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 6270 (delta 1428), reused 1423 (delta 1423), pack-reused 4824
Receiving objects: 100% (6270/6270), 1.24 MiB | 552.00 KiB/s, done.
Resolving deltas: 100% (4008/4008), completed with 618 local objects.
From https://github.com/openembedded/meta-openembedded
   e632093..f0a664f  master     -> master
 + ea50f55...bb952c2 master-next -> master-next  (forced update)
   6e3fc5b..dacfa2b  rocko      -> rocko
   d8f82c4..b5674b7  rocko-next -> rocko-next
 + 48e668d...f0dcba4 refs/pull/56/merge -> refs/pull/56/merge  (forced update)
 * [new ref]         refs/pull/61/head -> refs/pull/61/head
 * [new ref]         refs/pull/61/merge -> refs/pull/61/merge
 * [new ref]         refs/pull/62/head -> refs/pull/62/head
 * [new ref]         refs/pull/63/head -> refs/pull/63/head
 * [new ref]         refs/pull/63/merge -> refs/pull/63/merge
 * [new ref]         refs/pull/64/head -> refs/pull/64/head
 * [new ref]         refs/pull/64/merge -> refs/pull/64/merge
 * [new ref]         refs/pull/65/head -> refs/pull/65/head
 * [new ref]         refs/pull/65/merge -> refs/pull/65/merge
 * [new ref]         refs/pull/66/head -> refs/pull/66/head
 * [new ref]         refs/pull/66/merge -> refs/pull/66/merge
 * [new ref]         refs/pull/67/head -> refs/pull/67/head
 * [new ref]         refs/pull/67/merge -> refs/pull/67/merge
 * [new ref]         refs/pull/72/head -> refs/pull/72/head
 * [new ref]         refs/pull/72/merge -> refs/pull/72/merge
 * [new ref]         refs/pull/73/head -> refs/pull/73/head
 * [new ref]         refs/pull/73/merge -> refs/pull/73/merge
 * [new ref]         refs/pull/74/head -> refs/pull/74/head
 * [new ref]         refs/pull/74/merge -> refs/pull/74/merge
Fetching origin
remote: Counting objects: 54, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 54 (delta 19), reused 24 (delta 19), pack-reused 29
Unpacking objects: 100% (54/54), done.
From https://github.com/imyller/meta-nodejs
   9a9385d..afd41c1  refs/pull/86/head -> refs/pull/86/head
 + 1d2e75d...cd67d95 refs/pull/86/merge -> refs/pull/86/merge  (forced update)
 * [new ref]         refs/pull/91/head -> refs/pull/91/head
 * [new ref]         refs/pull/91/merge -> refs/pull/91/merge
Cloning into bare repository 'meta-intel-mirror.git'...
remote: Counting objects: 15804, done.
remote: Compressing objects: 100% (4892/4892), done.
remote: Total 15804 (delta 9277), reused 15775 (delta 9248)
Receiving objects: 100% (15804/15804), 4.54 MiB | 948.00 KiB/s, done.
Resolving deltas: 100% (9277/9277), done.
Checking connectivity... done.
Fetching origin
remote: Counting objects: 90, done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 90 (delta 42), reused 64 (delta 16)
Unpacking objects: 100% (90/90), done.
From git://git.yoctoproject.org/meta-mingw
   a2c5fb8..6106b73  master     -> master
   58dda84..f5f676d  morty      -> morty
   4bdb996..c6db193  pyro       -> pyro
   a2c5fb8..1cc620b  rocko      -> rocko
 * [new branch]      sumo       -> sumo
 * [new tag]         2.5_M3     -> 2.5_M3
Fetching origin
Cloning into bare repository 'meta-acpi-mirror.git'...
remote: Counting objects: 469, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 469 (delta 0), reused 4 (delta 0), pack-reused 463
Receiving objects: 100% (469/469), 102.99 KiB | 0 bytes/s, done.
Resolving deltas: 100% (211/211), done.
Checking connectivity... done.
Cloning Poky in the /home/mguillon/dev/edison/out/linux64/poky directory
Cloning into 'poky'...
done.
Already on 'rocko'
Your branch is up-to-date with 'origin/rocko'.
Cloning Mingw layer to /home/mguillon/dev/edison/out/linux64/poky/meta-mingw directory from local cache
Cloning into 'meta-mingw'...
done.
Cloning Darwin layer to /home/mguillon/dev/edison/out/linux64/poky/meta-darwin directory from local cache
Cloning into 'meta-darwin'...
done.
Note: checking out '29b5ff31cee24e796f2eb2d2fd1269e3e92c831c'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 29b5ff3... gcc-runtime: Don't pollute global export namespace
Cloning Openembedded layer to /home/mguillon/dev/edison/out/linux64/poky/meta-openembedded directory from local cache
Cloning into 'meta-openembedded'...
done.
Branch rocko set up to track remote branch rocko from origin.
Switched to a new branch 'rocko'
Cloning Nodejs layer to /home/mguillon/dev/edison/out/linux64/poky/meta-nodejs directory from local cache
Cloning into 'meta-nodejs'...
done.
Already on 'master'
Your branch is up-to-date with 'origin/master'.
Cloning meta-intel layer to /home/mguillon/dev/edison/out/linux64/poky/meta-intel directory from local cache
Cloning into 'meta-intel'...
done.
Branch rocko set up to track remote branch rocko from origin.
Switched to a new branch 'rocko'
Cloning meta-acpi layer to /home/mguillon/dev/edison directory from local cache
Cloning into 'meta-acpi'...
done.
Branch eds set up to track remote branch eds from origin.
Switched to a new branch 'eds'
Cloning meta-arduino layer to /home/mguillon/dev/edison directory from GitHub.com/01org/meta-arduino
Cloning into 'meta-arduino'...
remote: Counting objects: 72, done.
remote: Compressing objects: 100% (42/42), done.
remote: Total 72 (delta 22), reused 72 (delta 22), pack-reused 0
Unpacking objects: 100% (72/72), done.
Checking connectivity... done.
Already on '1.6.x'
Your branch is up-to-date with 'origin/1.6.x'.
Applying patch on poky
error: patch failed: conf/machine-sdk/i686-mingw32.conf:16
error: conf/machine-sdk/i686-mingw32.conf: patch does not apply
error: patch failed: conf/machine-sdk/x86_64-mingw32.conf:16
error: conf/machine-sdk/x86_64-mingw32.conf: patch does not apply
Makefile:25: recipe for target 'setup' failed
make: *** [setup] Error 1

Should i use another branch? I tested this one cause it was the one with the most recent commits.

Thanks

[htot]

Rocko is where I push my tested commits. After review (thanks @alext-mkrs ) I merge them into master. I looks like you are experiencing a new problem, possibly caused by some upstream update. I don't think we are using that mingw stuff, maybe we should just remove it. I'll update my local branches and have a look.

[farfromrefug]

@htot seems like the setup.sh tries to setup a mingw env even if i am on linux or macos. I have moved things around to get it to work. Now i am stuck on oe-init-build-env which fails. Working on it right now

[htot]

@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 oe-init-build-env to fail. The reason was I accidentally removed the line cd $poky_dir (should be right after git checkout 1.6.x now). Building fresh now.

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.

[farfromrefug]

@htot yes that's it. I got it to start building on linux (failed on macos though). I am now building, taking it's time ... Will report. Thanks

[htot]

Hmm. I used make image to start the build and it fails on a initramfs recipe. Started again (without any cleaning) and it continues until complete. Looks like we are missing a dependency. Probably harmless but irritating.

[alext-mkrs]

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.

[htot]

I'm surprised too. That patch is still needed? If so, please send.

[htot]

@alext-mkrs Any ideas on how to make core-image-minimal-initramfs.bbappend depend on the kernel modules being available?

[vrubiolo]

I confirm I have the same issue on the pyro64-acpi branch which I tried tonight from a fresh clone. Error log is error_mingw_pyro64-acpi.txt

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). 0001-WIP-on-getting-around-mingw-pb.txt

[htot]

@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.

[htot]

@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.

[farfromrefug]

@htot it build fine on linux so thats great. thanks for the fix on rocko64-acpi I also managed to flash it correctly using Flash Tool Lite, amazing! Thank you so much for your work.

Now 2 questions remain.

• This one might be dump but i can't really get my head around it. Can i use my jubilinux ext4 image with the build that i made here? I mean the thing i want is actually my jubilinux (if possible!) with the new kernel / u-boot. Would that work? If not i will have to recreate my env from the vanilla linux. Doable but long.
• i am also kind of lost on the state of the u-boot / kernel and GPIO state. AS a reminder the only thing i want is to force the gpio states right on boot. Especially we have a power gpio that needs to be set right away so that the user can release the power button. Can i already set the GPIO state? even if it is hardcoded somewhere in meta-intel-edison and i have to recompile, i am ok with this.

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 configure_edison --setup to setup the wifi and i end up with an error Failed to connect to non-global ctrl_ifname: (nil) error: No such file or directory After looking around it seems i dont have bcm4334x module. Is that normal?

[htot]

@farfromrefug Thanks for testing!

• I think booting jubilinux should be possible. The initramfs contains the modules needed for boot. But of course the remaining modules need to be installed on your rootfs. These are generated as deb's so could be installed using dpkg, or you could just copy them from /lib/modules to your rootfs (but needs to be depmod -a?).
• I think the earliest opportunity to set gpio's is in u-boot. So you could hack that. I would try to change the acpi tables in u-boot, but those probably take effect when the kernel is loaded. Maybe to late for you. If not, you can set them in the init script here https://github.com/htot/meta-intel-edison/blob/rocko64-acpi/meta-intel-edison-distro/recipes-core/initrdscripts/files/init-live.sh instead of through acpi. Note there is already a call to acpi-load which runs /usr/bin/acpi-tables-load. Currently this loads the edison-arduino specific acpi tables through configfs (but this only works with the acpi enabled u-boot and kernel).

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.

[alext-mkrs]

@alext-mkrs Any ideas on how to make core-image-minimal-initramfs.bbappend depend on the kernel modules being available?

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.

[farfromrefug]

@htot thanks for the explanation. I am looking at it right now.

• if i am correct acpi-tables-load is started through a service? which is pretty late. Right now we are already using a service to set the GPIO. Takes around 13sec...
• when is the init-live.sh script run compare to acpi-tables-load?

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 ;) I am sorry but i am going to ask a few questions :s now.

• when you say it loads edison arduino acpi table, you say it's loading recipes-bsp/acpi-tables/samples/edison/arduino.asl?
• is that setup from meta-intel-edison-bsp/conf/machine/edison.conf?
• is there a documentation for the gpio mapping in asli file? If i take the example of i2c6 i can't understand the mapping

Thanks and sorry for all the questions :s

[htot]

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: 1 kernel boots (in acpi case when tables in cpio, tables are already loaded) 2 kernel loads modules 3 init script starts (and in acpi case loads tables) and waits 4 partitions on sd card, usb appear 5 init script remounts partitions as needed and calls switch_root 6 /sbin/init on rootfs starts (systemd)

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