18.04 official release

[nickl-]

The PRs from @xuminready has been merged which updates the source but no new releases were published.

There is a forum thread announcing the new development but it is unclear if all outstanding issues were resolved before the PRs were merged.

We have an unofficial release made available by @xuminready but these raise additional questions.

• There is no one-to-one mapping between the official 16.11 release (6 image files) and the unofficial 18.04 release (only 4 image files).
• There is a new naming convention, with xpiose added, which remains unexplained.
• With the 16.11 release there is a visible size difference of 191MB between the hdmi and the headless images whereas the 18.04 images appear to all be the same size.

We should have an official release of 18.04 which also resolves these ambiguities and concerns.

[xuminready]

@nickl- parallella is fading away. I doubt there's any more official release.

headless-noelink is not include in my release. It's the version without Epiphany Support.

I guess gpiose is from its FPGA bit file
https://github.com/parallella/parabuntu/blob/master/bootfs-and-kernel.sh

My release doesn't have desktop environment for hdmi version. The differences between 4 images are FPGA bit file and devicetree.

[nickl-]

parallella is fading away. I doubt there's any more official release.

I am hoping we can change that and save it before it fades to black. Trying to get in touch with Andreas.

Saw your comment about the gcc in the forum, but I am still waiting for account activation. I also made a comment on the gcc project about the gcc version.

If we look at build-essential package, which indicates the minimum gcc version needed to build ubuntu this is what you find:

xenial 16.04 LTS - gcc (>= 4:5.2)
bionic 18.04 LTS - gcc (>= 4:7.2)
cosmic 18.10 - gcc (>= 4:7.3)
disco 19.04 - gcc (>= 4:8.3)

So gcc 5 is still in good position for now however I did notice that our epiphany version of gcc 5 is a couple of commits behind the official since it was forked and changes made. So I do suggest we rebase it first and rebuild for a new gcc 5 release.

I think the issue with gcc 6+ is that there is still very much active development going on in those versions so perhaps it is better to wait for now.

As for parabuntu we should probably get OpenSHMEM in here now and there is the ePython project too. What are we doing about including documentation and examples? Shouldn't this be all inclusive?

You also mentioned something about pthreads?

[nickl-]

@xuminready I found a branch epiphany-gcc-8 and with a bit of tweaking I was able to build a gcc 8.3 version of the eSDK.

Now if only we could get the changes merged development can continue.

[tony-travis]

@nickl- I too don't want to see parallella fade away: I've cross-compiled an ARM kernel and created a bootable parabuntu 18.04 image from the sources here, but I've not yet been able to get a working eSDK. The esdk.2016.11.tar.gz release does not, of course, work under parabuntu 18.04.

[nickl-]

@tony-travis Only received my board last month, I chose parallella above the nvidia because it was obvious that I could make more of a difference here. Call it a weakness for trying to rescue abandoned projects but I did hope to at least still get a response from Adapteva. Gave up trying to get a response from @aolofsson, I am convinced he must be aware of me but I don't want to be a nuisance so I quit. Now trying to ping @olajep as a last resort but can't find any other information aside from his GitHub user so options are limited.

Ideally they will open these projects and allow us to maintain them in their absence and this way retain the community under the original banners. Forking the projects should be a last resort as it splits the community. On the other hand it may be beneficial to break away towards a more general purpose vision and start porting these efforts to similar platforms like celerity et al. Either way I am invested now and it still seems people are keen so lets do it.

I've not yet been able to get a working eSDK. The esdk.2016.11.tar.gz release does not, of course, work under parabuntu 18.04.

Yes indeed, I also figured we need to start with the eSDK so that is what I've been focusing on. I've managed to cross compile epiphany-gcc-5 with a few tweaks to epiphany-sdk and also epiphany-gcc-8 with a bit more elbow grease, using Ubuntu 18.04 as the build system. This is all based on the sources currently made available merging with new releases are going to be challenging as it is unclear what exactly has been changed. I would love to release the work so that we can start to test but it is pending this PR to see what we will have to do.

I can make the tar balls of the compiled eSDKs available, they are still called 2016.11 for now, if you want to give them a try? Give it a week and you can also build your own.

Once we have the eSDK we can update (I think there is a version 1.6.3) and compile coprthr and the OpenSHMEM released by the US Army Research Lab, along with a complete parabuntu 18.04 release.

[tony-travis]

@nickl- Yes, I'd be very interested in giving your version a try - Where can I download it from?
I encountered problems when trying to compile the eSDK from source under my own parabuntu 18.04 because of legacy "usleep()", even though nanosleep() is actually present in the sources.

[nickl-]

Reference: adapteva/epiphany-binutils-gdb#11.

[nickl-]

@tony-travis you can find the tar balls at adapteva/epiphany-sdk#75

[xuminready]

@nickl- I think parallella board has a lot of potential. Zynq(ARM + FPGA) is powerful, plus Epiphany. I don't know much about eSDK. But I can build kernel, modify root filesystem.
other things need to upgrade:

• rebuild FPGA with latest Xilinx Vivado
  parallella-fpga
• Upgrade kernel and Epiphany driver
  parallella-linux

[tony-travis]

@xuminready: I believe one reason that Parallella has failed to become an equivalent to the Raspberry-Pi for parallel computing is that its USB PHY does not initialise reliably despite many people, including Adapteva, trying to find out the reason why. I would prioritise re-writing the USB PHY initialisation when you rebuild the FPGA code to make sure that the USB PHY is set up correctly. Adapteva have denied there is a USB issue and recommend the use of specific USB cables and powered hubs to initialise the USB PHY properly. However, in my tests and those of other people using exactly the PSU, powered hub and OTG cable the USB seldom initialises. This makes it very difficult to use the Parallella as a 'desktop' computer with a USB keyboard+mouse. I know it can be used with a serial connection to the UART or SSH if networked, but the USB is there for a reason, as it is on the raspberry Pi: To use the SBC with a USB keyboard+mouse.

[nickl-]

@xuminready and @tony-travis I am still holding out hope that we will hear from @olajep or @aolofsson not to do any of the work but there are so many unclarified and just having someone around to answer a question or nod in agreement would go a long way.

USB issue

I am also having the issues with the USB but it seems once the board is powered up and you managed to get the mouse and keyboard working, it will keep working through restarts.

Read through the threads on the forum about it and while it is obvious Adapteva is pleading the 5th I didn't actually see anyone denying it exists. Unless there are more representatives in official capacities which I don't know about. Olaf seemed eager as always and did make the firmware available.

It is all fine and well to want a fix for this but do we even know what the problem is exactly? Unless I missed something, there appears to be some far fetched work arounds and elaborate theories but neither seems to be coherent. We first need to identify the problem then we can cook up a cure. As long as we can still get it functioning for the majority of the time I think there are higher priorities.

FPGA rebuild

I am not a complete stranger to hardware and building devices but I was resolved with the theory that all chips and electronic components work on smoke... once the smoke escapes it needs to be replaced.

Jokes I'm not that lost everyone know it works with transistor and logic gates. Never could quite fathom how mixing a bunch of them together creates instruction sets but I can follow a diagram. I've been quite content with writing software and getting the hardware to comply but completely missed this HDL development. Looking at Verilog it does not appear all that strange but after finish reading the code I cannot imagine how that is supposed to produce HDMI, USB or what ever other hardware it claims to define.

If I understand you correctly @xuminready you are saving that xilinx updated their software and we can expect to magically see improvements by simply rebuilding the existing definitions. My trained expectations are usually to look for updated software with problems fixed which were not previously addressed. Is not the case with this bitstreams anymore? The hardware definitions are rock solid and only requires a rebuild to get updated with the enhancements and bug fixes. Obviously I still have a lot to learn...

There seems to be issues with the HDMI which causes these flashes on the screen usually at higher loads which makes me imagine it could be the firmware. Although I can't say I have completely ruled out cabling problems...

Upgrade kernel

@tony-travis said something about rolling a fresh kernel unless I misunderstood. One thing is certain parallella-linux is a whopping 121958 commits behind upstream at Analog Devices Inc so here we might expect to see some improvements or we could also find something that doesn't work at all. Not knowing exactly what has been modified on our end and why remains the largest obstacles.

What seemed promising to me was the fact that a lot of improvement have gone into the HDMI driver side which gives some hope. We will only know for sure when we try.

Epiphany hardware monitor

If I can place an item on the wishlist it would be for a hardware information an monitoring. You can give me volumes of documentation, clever software and extensive libraries with benchmarks claiming the sun moon and stars but you will not convince me unless you can show me.

For starters show me the information, model numbers and names read from the hardware with 16 cores each with memory, DMA and processor. Show me that there's a mesh and comms from 4 directions available for read and write. Then stand back while we fire up one of those black box examples and show me how these things light up as we can detect message traffic, storage consumption and processor loads.

This is the first thing I am looking for and this must make me weird or something strange as it doesn't seem to be something anyone has even considered or talked about. Is this not the first thing you want to have? I would settle for a HAT with 16 flashing LEDs if that's what it takes but frankly, I have not seen an ounce of proof that it is what it says it is.

If you have also seen the youtube video, Parallel Programming Made Simple you may be inclined to disagree with me because there it is you can see exactly what you need. You may argue on the lines of what more proof to you need and you would have a valid point. The ERM app would've been a good start and an even greater launching point for feature enhancements, or so you would think.

At closer inspection you will find the JAVA gui application does not monitor the cores but instead parses text output files produced by the accompanying resource manager for its data. This tight coupling renders the monitor for exclusive use only and leaves a lot wanting. If you know about any other monitoring solutions please let me know...

[tony-travis]

USB
The USB issue is that the low-level USB PHY in the Zynq fails to be initialised properly and, as a consequence, the Linux kernel can't access the physical device. To me, resolving this is a priority in order to use Parallella as a 'Desktop' SBC equivalent to the Raspberry Pi, but with Epiphany.

Kernel
I cross-recompiled the kernel and created an up-to-date Ubuntu 18.04 SD image under Ubuntu-MATE 18.04 LTS, with one change to the code in this repo:

diff --git a/bootfs-and-kernel.sh b/bootfs-and-kernel.sh
index bd8f293..6bb31ce 100755
--- a/bootfs-and-kernel.sh
+++ b/bootfs-and-kernel.sh
@@ -120,6 +120,7 @@ build_kernel () {
             echo kernel: make $@
             make -j $j \
                 O=$KERNEL_BUILD_DIR \
+               CFLAGS_MODULE=-fno-pic \
                 ARCH=arm \
                 CROSS_COMPILE=$CROSS_COMPILE \
                 LOADADDR=0x8000 \

However, I have not been able to rebuild the eSDK (going to try the version created by @nicki-).

[olajep]

Hi all, As you might have seen from commits here and there in various repos I have been working on a new release based on Ubuntu 2018.04/ ADI HDL/kernel 2018.2 during this spring. Most of the work is done (upgraded toolchain, linux, FPGA bitstreams) but there are still some issues that I didn't have time to address yet: - see the TODO:s in the parabuntu README) - and I haven't tested the HDMI version at all - and there are other things (e.g. missing ping command in default install) Unfortunately I probably won't have any time to work on it until September. :( // Ola

…

On Mon, Aug 12, 2019 at 5:58 PM Nick Lombard ***@***.***> wrote: @xuminready <https://github.com/xuminready> and @tony-travis <https://github.com/tony-travis> I am still holding out hope that we will hear from @olajep <https://github.com/olajep> or @aolofsson <https://github.com/aolofsson> not to do any of the work but there are so many unclarified and just having someone around to answer a question or nod in agreement would go a long way. USB issue I am also having the issues with the USB but it seems once the board is powered up and you managed to get the mouse and keyboard working, it will keep working through restarts. Read through the threads on the forum about it and while it is obvious Adapteva is pleading the 5th I didn't actually see anyone denying it exists. Unless there are more representatives in official capacities which I don't know about. Olaf seemed eager as always and did make the firmware available. It is all fine and well to want a fix for this but do we even know what the problem is exactly? Unless I missed something, there appears to be some far fetched work arounds and elaborate theories but neither seems to be coherent. We first need to identify the problem then we can cook up a cure. As long as we can still get it functioning for the majority of the time I think there are higher priorities. FPGA rebuild I am not a complete stranger to hardware and building devices but I was resolved with the theory that all chips and electronic components work on smoke... once the smoke escapes it needs to be replaced. Jokes I'm not that lost everyone know it works with transistor and logic gates. Never could quite fathom how mixing a bunch of them together creates instruction sets but I can follow a diagram. I've been quite content with writing software and getting the hardware to comply but completely missed this HDL development. Looking at Verilog it does not appear all that strange but after finish reading the code I cannot imagine how that is supposed to produce HDMI, USB or what ever other hardware it claims to define. If I understand you correctly @xuminready <https://github.com/xuminready> you are saving that xilinx updated their software and we can expect to magically see improvements by simply rebuilding the existing definitions. My trained expectations are usually to look for updated software with problems fixed which were not previously addressed. Is not the case with this bitstreams anymore? The hardware definitions are rock solid and only requires a rebuild to get updated with the enhancements and bug fixes. Obviously I still have a lot to learn... There seems to be issues with the HDMI which causes these flashes on the screen usually at higher loads which makes me imagine it could be the firmware. Although I can't say I have completely ruled out cabling problems... Upgrade kernel @tony-travis <https://github.com/tony-travis> said something about rolling a fresh kernel unless I misunderstood. One thing is certain parallella-linux is a whopping 121958 commits behind upstream at Analog Devices Inc so here we might expect to see some improvements or we could also find something that doesn't work at all. Not knowing exactly what has been modified on our end and why remains the largest obstacles. What seemed promising to me was the fact that a lot of improvement have gone into the HDMI driver side which gives some hope. We will only know for sure when we try. Epiphany hardware monitor If I can place an item on the wishlist it would be for a hardware information an monitoring. You can give me volumes of documentation, clever software and extensive libraries with benchmarks claiming the sun moon and stars but you will not convince me unless you can show me. For starters show me the information, model numbers and names read from the hardware with 16 cores each with memory, DMA and processor. Show me that there's a mesh and comms from 4 directions available for read and write. Then stand back while we fire up one of those black box examples and show me how these things light up as we can detect message traffic, storage consumption and processor loads. This is the first thing I am looking for and this must make me weird or something strange as it doesn't seem to be something anyone has even considered or talked about. Is this not the first thing you want to have? I would settle for a HAT with 16 flashing LEDs if that's what it takes but frankly, I have not seen an ounce of proof that it is what it says it is. If you have also seen the youtube video, Parallel Programming Made Simple <https://youtu.be/OU9TGVAbSo0> you may be inclined to disagree with me because there it is you can see exactly what you need. You may argue on the lines of what more proof to you need and you would have a valid point. The ERM app would've been a good start and an even greater launching point for feature enhancements, or so you would think. At closer inspection you will find the JAVA gui application does not monitor the cores but instead parses text output files produced by the accompanying resource manager for its data. This tight coupling renders the monitor for exclusive use only and leaves a lot wanting. If you know about any other monitoring solutions please let me know... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19?email_source=notifications&email_token=AAGB3WDAOJBAZEOJCLYDW3DQEHMIXA5CNFSM4ID54N6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4D6J3Y#issuecomment-520611055>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGB3WAYQP22U62HYUNXYIDQEHMIXANCNFSM4ID54N6A> .

[xuminready]

@nickl- USB controller is on Zynq. And it works sometimes. I guess the USB controller is not initialized correctly. If the problem is caused by software, I think it might on Uboot (stored on board 32Mb QSPI Flash Memory) or FPGA bit file.

FPGA is the glue between ARM and Epiphany, HDMI. There are several IPs upgraded for Zynq. I tried to rebuild it with Vivado 2017 last year. I made some progress, but there's some Verilog error I don't know how to fix. And some scripts are generated by Vivado, it's not easy to make it work with Vivado 2017. If someone knows Verilog and Vivado, it mgith be helpful.

For the kernel, I actually built analogdevicesinc/linux and 5.0 mainline kernel for the Zynq on parallella board. I need to modified Device Tree a little bit to make it work. But the Epiphany driver doesn't work for me.
https://github.com/parallella/parallella-linux/blob/parallella-linux-2016.11/drivers/misc/epiphany.c

[xuminready]

@olajep is there anything I can help.