Parallella Ubuntu ESDK 2016.3 released

Forum about Parallella boot process, linux kernel, distros, SD-cards, etc.

Re: Parallella Ubuntu ESDK 2016.3 released

Postby derekmulcahy » Thu Apr 28, 2016 2:50 am

It looks like the /dev/xdevcfg device hasn't been configured into the new kernel.

Looking at the kernel configs, 2015.1 has

Code: Select all
CONFIG_XILINX_DEVCFG=y


I think the new 2016.3 kernel should have something like

Code: Select all
CONFIG_FPGA=y
CONFIG_FPGA_MGR_ZYNQ_FPGA=y


but my kernel config knowledge is more than a little bit rusty.
derekmulcahy
 
Posts: 2
Joined: Tue Dec 29, 2015 2:18 am

Re: Parallella Ubuntu ESDK 2016.3 released

Postby hndrcksn » Fri Apr 29, 2016 1:53 pm

Unfortunately doing an apt-get update generates errors.

Code: Select all
parallella@parallella0:~$ sudo apt-get update
Hit http://archive.ubuntu.com vivid InRelease
Hit http://ports.ubuntu.com vivid InRelease
Hit http://ppa.launchpad.net vivid InRelease
Ign http://packages.erlang-solutions.com vivid InRelease
Hit http://ports.ubuntu.com vivid-security InRelease
Ign http://ppa.launchpad.net vivid InRelease
Get:1 http://packages.erlang-solutions.com vivid Release.gpg [836 B]
Hit http://ports.ubuntu.com vivid InRelease
Ign http://ppa.launchpad.net vivid Release.gpg
Hit http://ports.ubuntu.com vivid-updates InRelease
Hit http://packages.erlang-solutions.com vivid Release
Ign http://ppa.launchpad.net vivid Release
Hit http://ports.ubuntu.com vivid-backports InRelease
Hit http://ports.ubuntu.com vivid-updates InRelease
Hit http://archive.ubuntu.com vivid/main Sources
Hit http://archive.ubuntu.com vivid/restricted Sources
Hit http://archive.ubuntu.com vivid/universe Sources
Ign http://packages.erlang-solutions.com vivid Release
Hit http://archive.ubuntu.com vivid/multiverse Sources
Hit http://ports.ubuntu.com vivid/main Sources
Hit http://ppa.launchpad.net vivid/main Sources
Hit http://ppa.launchpad.net vivid/main armhf Packages
Hit http://ppa.launchpad.net vivid/main Translation-en
Hit http://ports.ubuntu.com vivid/universe Sources
Hit http://ports.ubuntu.com vivid/main armhf Packages
Err http://packages.erlang-solutions.com vivid/contrib armhf Packages
  404  Not Found
Ign http://packages.erlang-solutions.com vivid/contrib Translation-en
Err http://ppa.launchpad.net vivid/main Sources
  404  Not Found
Err http://ppa.launchpad.net vivid/main armhf Packages
  404  Not Found
Ign http://ppa.launchpad.net vivid/main Translation-en
Hit http://ports.ubuntu.com vivid/universe armhf Packages
Hit http://ports.ubuntu.com vivid/main Translation-en
Hit http://ports.ubuntu.com vivid-backports/restricted Sources
Hit http://ports.ubuntu.com vivid-backports/multiverse Sources
Hit http://ports.ubuntu.com vivid-backports/restricted armhf Packages
Hit http://ports.ubuntu.com vivid-backports/multiverse armhf Packages
Hit http://ports.ubuntu.com vivid-backports/multiverse Translation-en
Hit http://ports.ubuntu.com vivid-backports/restricted Translation-en
Hit http://ports.ubuntu.com vivid/universe Translation-en
Hit http://ports.ubuntu.com vivid-security/main armhf Packages
Hit http://ports.ubuntu.com vivid-security/universe armhf Packages
Hit http://ports.ubuntu.com vivid-security/main Translation-en
Hit http://ports.ubuntu.com vivid-security/universe Translation-en
Hit http://ports.ubuntu.com vivid/main Sources
Hit http://ports.ubuntu.com vivid/restricted Sources
Hit http://ports.ubuntu.com vivid/universe Sources
Hit http://ports.ubuntu.com vivid/multiverse Sources
Hit http://ports.ubuntu.com vivid/main armhf Packages
Hit http://ports.ubuntu.com vivid/restricted armhf Packages
Hit http://ports.ubuntu.com vivid/universe armhf Packages
Hit http://ports.ubuntu.com vivid/multiverse armhf Packages
Hit http://ports.ubuntu.com vivid/main Translation-en
Hit http://ports.ubuntu.com vivid/multiverse Translation-en
Hit http://ports.ubuntu.com vivid/restricted Translation-en
Hit http://ports.ubuntu.com vivid/universe Translation-en
Hit http://ports.ubuntu.com vivid-updates/main Sources
Hit http://ports.ubuntu.com vivid-updates/restricted Sources
Hit http://ports.ubuntu.com vivid-updates/universe Sources
Hit http://ports.ubuntu.com vivid-updates/multiverse Sources
Hit http://ports.ubuntu.com vivid-updates/main armhf Packages
Hit http://ports.ubuntu.com vivid-updates/restricted armhf Packages
Hit http://ports.ubuntu.com vivid-updates/universe armhf Packages
Hit http://ports.ubuntu.com vivid-updates/multiverse armhf Packages
Hit http://ports.ubuntu.com vivid-updates/main Translation-en
Hit http://ports.ubuntu.com vivid-updates/multiverse Translation-en
Hit http://ports.ubuntu.com vivid-updates/restricted Translation-en
Hit http://ports.ubuntu.com vivid-updates/universe Translation-en
Hit http://ports.ubuntu.com vivid-backports/main Sources
Hit http://ports.ubuntu.com vivid-backports/universe Sources
Hit http://ports.ubuntu.com vivid-backports/main armhf Packages
Hit http://ports.ubuntu.com vivid-backports/universe armhf Packages
Hit http://ports.ubuntu.com vivid-backports/main Translation-en
Hit http://ports.ubuntu.com vivid-backports/universe Translation-en
Hit http://ports.ubuntu.com vivid-updates/main Sources
Hit http://ports.ubuntu.com vivid-updates/universe Sources
Hit http://ports.ubuntu.com vivid-updates/main armhf Packages
Hit http://ports.ubuntu.com vivid-updates/universe armhf Packages
Hit http://ports.ubuntu.com vivid-updates/main Translation-en
Hit http://ports.ubuntu.com vivid-updates/universe Translation-en
Fetched 836 B in 1min 12s (11 B/s)
W: GPG error: http://packages.erlang-solutions.com vivid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D208507CA14F4FCA
W: Failed to fetch http://ppa.launchpad.net/parallella/snapshots/ubuntu/dists/vivid/main/source/Sources  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/parallella/snapshots/ubuntu/dists/vivid/main/binary-armhf/Packages  404  Not Found

W: Failed to fetch http://packages.erlang-solutions.com/ubuntu/dists/vivid/contrib/binary-armhf/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.


I checked the repositories listed in /etc/apt/sources.list.d and found that packages.erlang-solutions.com and ppa.launchpad.net have binary-armhf packages under the trusty release path, but none under the vivid release path as yet. Should we comment out these repos or are vivid armhf binaries forthcoming?
hndrcksn
 
Posts: 1
Joined: Mon Dec 17, 2012 3:27 am

Re: Parallella Ubuntu ESDK 2016.3 released

Postby sebraa » Fri Apr 29, 2016 7:03 pm

I found some time to update to the new image and found a few things which make me sad.

  • Loading of SREC files has been removed from the eSDK.
    While the error message shown is misleading ("deprecated" does not mean "removed"),
    an additional (correct) message is shown on higher verbosity.
    The current documentation (5.13.09.10) still states that e_load() only supports SREC files.
    (Since this definitely breaks older code, I think this should have been mentioned on the forum announcement. Oh, well.)

  • In the linker scripts, the symbol names have been changed (_NUM_ROWS_IN_CHIP_ became __NUM_ROWS_IN_CHIP_).
    I expect that the next eSDK will add another underscore at the end just to show that we shouldn't rely on anything.
    I love code breakage for no obvious reason. Time to roll our own linker scripts, I guess...

  • The ELF loader has been changed incompatibly, I now receive this error:
    ep_main: ERROR: Can't load executable file "bin/program.elf" (no other relevant message).
    It seems that running "e-objcopy -R .shared_dram program.elf program.elf" now invalidates the ELF file.
    More code breakage, no workaround for this yet.

Again, more work due to undocumented changes in the eSDK. Sigh.
sebraa
 
Posts: 495
Joined: Mon Jul 21, 2014 7:54 pm

Re: Parallella Ubuntu ESDK 2016.3 released

Postby aolofsson » Sat Apr 30, 2016 1:13 pm

sebraa,

You bring up some good points. The srec loader was a huge hack that we are trying to get away from, but I suppose just removing support was too draconic and we will have to live with this mistake a while longer...

Regarding the other two, I will let Ola respond so that we can see if this is a misunderstanding or what we can do about this. Did you read the release notes?

Anreas
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Re: Parallella Ubuntu ESDK 2016.3 released

Postby sebraa » Mon May 02, 2016 3:01 pm

I did not fully read the release notes until noticing that my code stopped working, so this is my own fault. I did read it before posting, though.

On the other hand, I did upgrade to ELF in my own infrastructure, so removing SREC support only affects programs based on older infrastructures. However, some of our projects date back to eSDK 4.x when ELF was not an option yet. I did like using SREC files though, since they are an extremely simple solution to the problem, and are useful as fallback solutions in special cases (e.g. the ELF loader rejecting my post-processed files). In fact, in my first tests I did post-processing on the SREC files manually (later using sed) before turning to binutils.

In any case, my main complaint about this is that the documentation was not updated accordingly and now simply states wrong facts. I tend to read documentation once completely through (taking notes) and then start coding based on what I read. I also prefer referring to documentation instead of code, so I rely on the documentation to be both truthful and the most important source of authority. If I can't trust the documentation, I can't trust the project.
sebraa
 
Posts: 495
Joined: Mon Jul 21, 2014 7:54 pm

Re: Parallella Ubuntu ESDK 2016.3 released

Postby olajep » Mon May 02, 2016 8:25 pm

sebraa wrote:I found some time to update to the new image and found a few things which make me sad.

  • Loading of SREC files has been removed from the eSDK.
    While the error message shown is misleading ("deprecated" does not mean "removed"),
    an additional (correct) message is shown on higher verbosity.
    The current documentation (5.13.09.10) still states that e_load() only supports SREC files.
    (Since this definitely breaks older code, I think this should have been mentioned on the forum announcement. Oh, well.)

Yes, it was a mistake to remove SREC support now, we should have waited one release. Good thing it's easy to fix; you already have an elf file from compilation so it should more or less just be a matter of changing ".srec" to ".elf" in all calls to e_load()/e_load_group(). This should be backwards compatible with all previous releases back to esdk.5.13.09.10.
sebraa wrote:
  • In the linker scripts, the symbol names have been changed (_NUM_ROWS_IN_CHIP_ became __NUM_ROWS_IN_CHIP_).
    I expect that the next eSDK will add another underscore at the end just to show that we shouldn't rely on anything.
    I love code breakage for no obvious reason. Time to roll our own linker scripts, I guess...

  • We did not change symbol names in the linker scripts (and never will without any good reason). But we did change USER_LABEL_PREFIX in GCC from "_" to "" as part of the ABI change (almost all modern GCC targets have it and we don't want to be special). This affects generated assembler code, and how external symbols are referenced.
    Unfortunately I did not provide both "__" and "_" (AFAICT undocumented) versions for those symbols you mentioned. Fixed in git, and I've also added a test case to epiphany-examples.

    For assembler source you need to drop the "_" prefix for functions / objects you need to reference from C.
    If you have assembler code that need to be backwards compatible you can use the SYM macro here:
    https://github.com/adapteva/epiphany-ne ... .h#L27-L34
    https://github.com/adapteva/epiphany-ne ... ny/_exit.S
    and change the file extension to ".S" (capital S) so that the source is preprocessed.

    sebraa wrote:
  • The ELF loader has been changed incompatibly, I now receive this error:
    ep_main: ERROR: Can't load executable file "bin/program.elf" (no other relevant message).
    It seems that running "e-objcopy -R .shared_dram program.elf program.elf" now invalidates the ELF file.
    More code breakage, no workaround for this yet.

  • It does not invalidate the elf file but it can result in a empty loadable program segment (you should see a warning). Whether that is legal ELF or not there is a range check bug in the loader that makes it fail on empty segments. Fixed in git.
    The workaround is to not place any objects in .shared_dram, then the linker will discard that section.


    // Ola
    _start = 266470723;
    olajep
     
    Posts: 121
    Joined: Mon Dec 17, 2012 3:24 am
    Location: Sweden

    Re: Parallella Ubuntu ESDK 2016.3 released

    Postby sebraa » Tue May 03, 2016 8:44 am

    olajep wrote:This affects generated assembler code, and how external symbols are referenced. Unfortunately I did not provide both "__" and "_" (AFAICT undocumented) versions for those symbols you mentioned. Fixed in git, and I've also added a test case to epiphany-examples.
    Thank you. I used the _NUM_ROWS_IN_CHIP_ symbol to linearize the row/col parameters into a single integer, which simplifies data structures and initialization code. My apologies.

    olajep wrote:
    sebraa wrote:It seems that running "e-objcopy -R .shared_dram program.elf program.elf" now invalidates the ELF file.
    It does not invalidate the elf file but it can result in a empty loadable program segment (you should see a warning). Whether that is legal ELF or not there is a range check bug in the loader that makes it fail on empty segments. Fixed in git.
    Thank you. Unfortunately, I have not found a way to make objcopy remove the segment completely. I hope I can workaround this problem with a custom linker script; otherwise, this is a game breaker for us.

    olajep wrote:The workaround is to not place any objects in .shared_dram, then the linker will discard that section.
    Sadly, this is not possible in my case. I use a single, overlaid data structure in .shared_dram, which is used (among others) for handshaking at e_load() time. This means that loading a core must not touch this area of memory. (This is one of those cases where SREC files would have been a workaround.)
    sebraa
     
    Posts: 495
    Joined: Mon Jul 21, 2014 7:54 pm

    Previous

    Return to Linux/U-Boot

    Who is online

    Users browsing this forum: No registered users and 1 guest