Add resin io support for am571x-evm

[agherzan]

No description provided.

[jturnsek]

How to force AM57xx EVM to boot from eMMC after resin-image-flasher from SD card is finished? I can see that mmcblk1 device is populated, but the board is always booted form mmcblk0. Removing the SD card does not help.

[floion]

Removing the SD card from the board would force your board to boot from the other available media, which should be the eMMC.
If you remove the SD card and press SW3 do you get something on the debug console?

[jturnsek]

No, the console is empty. The only way I can boot device is via SD card without pressing the button. After a few minutes, the systemctl-shutdown is called. Is that normal?

[floion]

So you get no output on the console but only after a few minutes when you see systemctl-shutdown being called? You should see some boot logs too. But about the systemctl shutdown problem, I am aware of that and looking into it just now as a matter of fact.
This being said, this is still somewhat WIP.

[floion]

Let me rephrase that. When you boot off the SD card, at some point systemctl shutdown is being called?
And after that, you remove the SD card and try to boot off the eMMC and nothing happens?

[jturnsek]

I can see console only if SD card with resin-image-flasher is inserted and the device is booted. I do note need to press SW3 when powering on in order to boot from SD card. This was usually the case with beaglebone. When mounting mmcblk1 device I can see all partitions already be made, but when removing the SD card, EVM is not booted (not even U-Boot). Maybe auto shutdown is a problem here?

In order to build the images I changed the Dockerfile in docker-disk (added tmp path before entry.sh), otherwise image build failed. Also host-update-resin.bbclass needs to be changed to find proper images for tar. I have used IMGDEPLOYDIR instead of DEPLOY_DIR_IMAGE. Are you aware of this problems?

[jturnsek]

Exactly @last message

[floion]

Yes, these should be fixed now. When did you fetch the repository? Might try to pull it again. And sorry, as it is still WIP, I have rewritten the history to keep just the initial commit until I feel it is stable. Once we release the board in resin.io, then I will consider it stable and git history shall be also stable.

So when you boot off the SD card, that particular image is a flasher image (an installer) which writes the resin OS image to the eMMC and then shutsdown. After that, removing the SD card and pressing SW3 should boot off the eMMC.
In order to avoid the reboot, you could boot off the SD card again, mount the rootfs as read-write# mount -o remount,rw / , edit /usr/bin/resin-init-flasher and comment out the shutdown part at the end of this script and then restart the resin-init-flasher.service again. When it finishes you can inspect the eMMC and check if it has been partitioned etc.
And by the way, hat hardware revision are you using?

[jturnsek]

I have fetched the repository a few hours ago. My board version is A3. Would be possible to include the history in your commits in order to see what is changed. This way is easier for us to analyze the fixes.
What would be the best way to clean the images I have built but not to go through the whole building procedure again, because it takes too much time?

[floion]

Right now I am working in meta-resin and adding changes there so we have this board using poky morty revision. So this means I had to do quite a few commits in meta-resin and then that would have meant a lot of meaningless meta-resin submodule updates in resin-am57xx-evm. Once it is stable, as I said, the git history would not be changed anymore.

A3? That is a bit strange. Are you sure you are using the AM571x Industrial EVM board? My board says Revision 1.3A on the PCB and it is not that old. Your A3 seems a bit strange to me.

Well, if you have pulled the repository successfully, you should be able to just run barys once more and the build process would re-build only the packages which have the yocto metadata changed

[jturnsek]

I am using http://www.ti.com/tool/TMDSEVM572X

[floion]

Hm, this may be a problem.
Have you ever booted the board with something else other than resin? Do you know where the bootloader needs to be written when booting off the eMMC? I suspect that this is the difference between your board and the one that I am using. See this file about more details on this: https://github.com/resin-os/resin-am57xx-evm/blob/master/layers/meta-resin-am57xx-evm/recipes-support/resin-init/resin-init-flasher.bbappend

[jturnsek]

I have used the board with Ubuntu image succesfully. I think the processor is similar enough, but will check.
Thanks for support.

[jturnsek]

Manually copied MLO an uboot to mmcblk1p1 and the board boots from eMMC.

Still having problems with docker-disk Dockerfile and entry.sh. Also resinhup tar is not finding images from DEPLOY_DIR_IMAGE. Wonder why others don't see these problems?

[floion]

What is the command you use to build? Can you paste it here please?

[jturnsek]

Hi, command I am using is: jernej@server:~/resinos/resin-am571x$ ./resin-yocto-scripts/build/barys Regards, Jernej

…

On Thu, Jan 26, 2017 at 10:57 AM, Florin Sarbu ***@***.***> wrote: What is the command you use to build? Can you paste it here please? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACts42Dhuu0YgvwhJtP0SjyAP1Tbno1qks5rWG4BgaJpZM4Ln698> .

[floion]

Can you also post the git sha of your working tree please?
Be aware that now we specifically moved the repository to https://github.com/resin-os/resin-am571x-evm so that it's clear for which board it's supposed to work

[jturnsek]

For the meta-resin:

commit 5fee04b864ec31b8f70ec8c13def58c5357eedab
Merge: 00eb85c cb5f4d3
commit 5fee04b864ec31b8f70ec8c13def58c5357eedab
Merge: 00eb85c cb5f4d3
Author: Florin Sarbu florin@resin.io
Date: Tue Jan 24 12:46:27 2017 +0200

Merge pull request #552 from resin-os/fix_unclosed_socket_warnings

docker-utils.inc: Fix unclosed socket warnings for the master branch

[floion]

K, and what about the git sha of https://github.com/resin-os/resin-am571x-evm ? This repository should be stable from now on in terms of history

[jturnsek]

commit 53412a83050d4ccb929ba6d55a0b2eea0c6a60c7
Merge: d25c5c7 d15a670
Author: Florin Sarbu florin@resin.io
Date: Fri Jan 27 09:11:09 2017 +0200

Merge pull request #4 from resin-os/move_from_am57xx_to_am571x_naming

As we renamed the repository resin-am571x-evm from

[floion]

That is strange.
Can you try a "./resin-yocto-scripts/build/barys -d" and let me know if it works for you?

[jturnsek]

Nope, ot doesn't work. I am building on Ubuntu Server 16.04.

[floion]

You get the same error as before?

[jturnsek]

ERROR: docker-resin-supervisor-disk-0.0.0-r0 do_compile: Function failed: do_compile (log file is located at /home/jernej/resinos/resin-am571x-evm/build/tmp/work/am57xx_evm-poky-linux-gnueabi/docker-resin-supervisor-disk/0.0.0-r0/temp/log.do_compile.12101)
ERROR: Logfile of failure stored in: /home/jernej/resinos/resin-am571x-evm/build/tmp/work/am57xx_evm-poky-linux-gnueabi/docker-resin-supervisor-disk/0.0.0-r0/temp/log.do_compile.12101
Log data follows:
| DEBUG: Executing shell function do_compile
| Sending build context to Docker daemon 146.4 kB
|
| Step 1 : FROM docker:1.10.3-dind
| ---> 305c151749f4
| Step 2 : RUN apk add --update bash util-linux && rm -rf /var/cache/apk/*
| ---> Using cache
| ---> 178fc6d303e4
| Step 3 : ADD entry.sh /entry.sh
| stat /var/lib/docker/aufs/mnt/c381cb93e6bd245b90d0a92f1006c82e4002757eaad8fdd27de4c34859e63d33/entry.sh: no such file or directory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/jernej/resinos/resin-am571x-evm/build/tmp/work/am57xx_evm-poky-linux-gnueabi/docker-resin-supervisor-disk/0.0.0-r0/temp/log.do_compile.12101)
ERROR: Task (/home/jernej/resinos/resin-am571x-evm/build/../layers/meta-resin/meta-resin-common/recipes-containers/docker-disk/docker-resin-supervisor-disk.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3201 tasks of which 2919 didn't need to be rerun and 1 failed.

[floion]

What is the docker version on your build machine?

[jturnsek]

Docker version 1.12.1, build 23cf638

[floion]

What storage driver is docker using on your build machine?

[jturnsek]

Containers: 10
Running: 0
Paused: 0
Stopped: 10
Images: 14
Server Version: 1.12.1
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 37
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: null host overlay bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 4.4.0-47-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.859 GiB
Name: firmwaresvr3
ID: 4BI2:QLHB:S2AX:LD5L:PLSC:FYT6:UHEK:LEIO:NUWJ:ZSVV:K5H3:TTGS
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
127.0.0.0/8

[floion]

Okay, so that is a new error, right? I don't recall you saying that you had this issue before.
Wonder what has changed that made this new error pop out

[jturnsek]

No, it is not a new error. It always pop up when building from scratch. I have fixed it with adding tmp path in front every entry.sh in Dockerfile.
Other error has something to do with resinhup build race condition, which is now a separate issue. I have fixed with replacing DEPLOY_IMAGE_DIR with IMGDEPLOYDIR.

[floion]

Yeah, apparently I need to do something similar like I did in balena-os/meta-balena@ab0949e when also using resinHUP. I did not build with resinHUP support when I switched to morty

[floion]

Hi @jturnsek, if you update manually meta-resin now you should not have the second error anymore.
This update will get merged in soon so you don't have to update meta-resin manually.

As for the first error, I haven't encountered that on my side so not sure what to make of it

[jturnsek]

Hi. Probably it is a problem with dash vs bash. On similar project we had problems with building Yocto when using default dash shell. Switched to bash and problems disappeared.

[agherzan]

Hi @jturnsek . This was not the case now. It was actually a bug in our core OS layer which was fixed in the meanwhile.

[floion]

@agherzan , @jturnsek had 2 issues as he described above. One has been fixed by us, I've told him that the issue on our side has been fixed, and the other is apparently due to dash vs bash on Ubuntu

[agherzan]

Were we able to reproduce, @floion ? Sounds like something we would like to fix.

[floion]

No. I don't have an Ubuntu available to change from bash to dash and try to reproduce this

[jturnsek]

@floion the problem is still there. I was mistaken when changing dash to bash worked for me, because I still had tmp path inside Dockerfile. It must be something with the Ubuntu distribution or docker version related. Try adding tmp path before each entry.sh. This should fix the problem for all distros.

[floion]

@jturnsek can you paste the diff here?

[jturnsek]

diff --git a/meta-resin-common/recipes-containers/docker-disk/files/Dockerfile b/meta-resin-common/recipes-containers/docker-disk/files/Dockerfile
index b446dc7..bd47d13 100644
--- a/meta-resin-common/recipes-containers/docker-disk/files/Dockerfile
+++ b/meta-resin-common/recipes-containers/docker-disk/files/Dockerfile
@@ -2,8 +2,8 @@ FROM docker:1.10.3-dind

RUN apk add --update bash util-linux && rm -rf /var/cache/apk/*

-ADD entry.sh /entry.sh
+ADD entry.sh /tmp/entry.sh

-RUN chmod a+x /entry.sh
+RUN chmod a+x /tmp/entry.sh

-CMD /entry.sh
+CMD /tmp/entry.sh

[agherzan]

Hi @jturnsek . Did you manage to figure out the issue? I know @floion tried to replicate and he could not.

[jturnsek]

No, I haven't had time to find it. I am on other projects now. My fix with the tmp dir is working and is good enough for me. Probably it is related with my build machine somehow.

[agherzan]

Ok @jturnsek . I will close this issue for now but feel free to come back if you have any additional information that would help us to investigate further.