parallella / parallella-linux Goto Github PK

@olajep: More a comment than an issue that I have observed.. but I would appreciate your comment on this..

I noticed in epiphany.c the while loop that waits for an interrupt:

while (!atomic_read(&elink->mailbox_maybe_not_empty) || elink_mailbox_empty_p(elink)) { atomic_set(&elink->mailbox_maybe_not_empty, 0); ... elink_mailbox_irq_enable(elink); ... }
Once the while loop has started if no mailbox message arrives then the loop will never terminate and can not be cancelled. The mailbox irq will remain enabled because every 100 msec it will be re-enabled.

In my prototype driver I used epoll and I suspect if you did the same then it would be possible to allow the mailbox read to be stopped gracefully as well as avoid a while loop.

If the cores are separately reset before the mailbox message is received then the epoll wait could be cancelled.

Peter.

Hello everyone!
Is it possible to upgrade to v4.1.x linux kernel?
So one could use it with docker and overlay?
I'm probably going to use Arch Linux ARM, but the first step is the kernel compilation

See my project

@olajep I have proven the hdmi drivers now. The set of new drivers is contained in these patches https://github.com/peteasa/meta-parallella/tree/a6e8e77582c3000d07331ac950ea6ace2e02565b/recipes-kernel/linux/linux-parallella/4.4

(with the exception of 0011-Cache-elink-rxcfg-reg.patch.. this is not to do with hdmi)

I can provide these as a pull request to parallella-linux plus the associated device tree changes.

Let me know if this works for you.

This is a useful facility (sort of mandated by the homenet working group) for doing source specific routing sanely. It lets you have routes that are "default from" and eliminate the bcp38 problem from ipv6. (all x86, and the pi2, pi3, and odroid c2) have this kernel feature enabled...

(the fallback for the same functionality in the routing protocol I'm using is "ip rules", which is disabled entirely in this build. I don't know who needs vpn functionality here, but that's that common use case)

Ironically, I fired up the 4.6 kernel this afternoon to think about applying bellman-ford search to the adapteva co-processor.

default from 2600:3c01:elided:9300::/56 via fe80::20d:b9ff:fe41:6c2d dev eno1 proto babel metric 1024  pref medium
default from 2601:646:elided:a740::/60 via fe80::32b5:c2ff:fe75:7faa dev eno1 proto babel metric 1024  pref medium
2406:da00:ff00::/48 from 2600:3c01:elided:9300::/56 via fe80::20d:b9ff:fe41:6c2d dev eno1 proto babel metric 1024  pref medium

I've created a 'devicetree.dtb' as described in 'parallella/parallella.bin' README with

'scripts/dtc/dtc -I dts -O dtb -o arch/arm/boot/zynq-parallella.dtb arch/arm/boot/dts/zynq-parallella.dts'

Booting the board shown only two Tux-logos and nothing more.
Compared with the 'devicetree.dtb' file the created file is slightly bigger.

The platform hdf indicates that ERAM is at a different address.

https://github.com/adapteva/epiphany-libs/blob/a5df5bb/bsps/parallella64/platform.hdf#L13

In epiphany_vm_fault():
https://github.com/parallella/parallella-linux/blob/4ee628ea226a/drivers/misc/epiphany.c#L1224

We should speculatively pre-fault a couple of pages after the faulting page to reduce the number of times the fault handler needs to be called to amortize the fault-handler overhead.