offer: custom firmware builds

[mhaberler]

in case someone wants to experiment with custom FPGA firmware builds - that is super easy to do on jenkins.machinekit.io

happy to host valiant experimenters ;)

outline:

• fork machinekit/mksocfpga and create your config
• under Settings, Collaborators and Teams, Add collaborator machinekit-ci (the jenkins bot github user)
• generate a Personal Access Token which has the repo and admin:repo_hook scopes set, name it like 'mksocfpga- jenkins'
• drop me a mail and add the token - I need to add it in jenkins so the machinekit-ci user can set the Commit Status on a run
• generate a new project -> copy from 'mksocfpga-mah'
• Under "General/Github project": change to point to your repo, not mine
• under "Source Code Management", Repositories - do the same
• under "Source Code Management", "Branches to build" - set your preferred branch
• under Build: if you delete the argument to ./build.sh, all configs will be built - else pass the basename of the config to build
• under "Post-build Actions - SSH publishers: change "Remote directory" to "user//rbf"
• under "E-Mail Notification" enter your email address
• hit "Save"

your build artefacts are downloadable from http://deb.mah.priv.at/uploads/user/ post-success

the hm2 startup log contains references to the git SHA and the jenkins job:

Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: board_name = 'Terasic DE0-Nano'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: build_sha = '5efcc6a'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: fpga_part_number = 'altera socfpga'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: num_leds = 4
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: comment = https://jenkins.machinekit.io/job/mksocfpga-mah/60/
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 0 name = 'GPIO0.P2'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 0 pins = 17
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 1 name = 'GPIO0.P3'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 1 pins = 17
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 2 name = 'GPIO1.P2'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 2 pins = 17
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 3 name = 'GPIO1.P3'
Jul 26 09:44:08 mksocfpga msgd:0: hal_lib:2277:rt hm2/hm2_de0n.0: connector 3 pins = 17

[the-snowwhite]

Wow

This concept is impressively mind blowing, if I am getting it right... ?

If this makes it possible to be able to do fpga programming / bugfixing etc,from lets say my cell phone on a mountain top,,, it opens up a wide range of options like:

Doing local or remote firmware updates from anywhere you can hook up to the internet.
Also great for field testing purposes also, when something unexpected that needs a quick fix happens and your workstation is miles away.....

I need to try this out asap...

[mhaberler]

here it is: https://jenkins.machinekit.io/view/userjobs/job/mksocfpga-the-snowwhite/

[mhaberler]

you can follow my cargo-culting attempts at https://github.com/mhaberler/mksocfpga/commits/mah and https://jenkins.machinekit.io/view/userjobs/job/mksocfpga-mah

build works, it's just that the nano is 200km away :-/

[mhaberler]

actually we might make this a travis job so everybody can do this, even without my jenkins

we might have to brush up @cdsteinkuehler 's QuartusBuildVM Docker repo to build on dockerhub so everybody can pull, not sure this is automated

[cdsteinkuehler]

Updating the QuartusBuildVM docker images is NOT automated. You can easily generate a new image using the Dockerfile, but it will be HUGE and unsuitable for sharing. Directions for shrinking the image to a manageable size are in the dockerfile:

https://github.com/cdsteinkuehler/QuartusBuildVMs/blob/master/Jessie-Quartus-15.1.2/Dockerfile#L53-L82

Questions:
Do I need to generate a new docker image (very painful for me, uploading that much data reliably kills my local internet connection), or should we have official Machinekit (vs. cdsteinkuehler) images on Dockerhub?

If we want to stick with my cdsteinkuehler images, maybe I can use MAH's server to create and upload? I think that would work much better than my local ISP for pushing GBs of data upstream!

[mhaberler]

I think we should move to a machinekit dockerhub user
definitely use my server, wont get stuck

if you build them as-is on dockerhub - does it work? or does it exceed some limit?

[cdsteinkuehler]

On 8/6/2016 4:38 PM, Michael Haberler wrote:

if you build them as-is on dockerhub - does it work? or does it exceed some limit?

Unknown...I wouldn't be able to upload one even if I wanted to.

I have enough trouble getting the ~5G images uploaded[1], I'd never be
able to complete an ~30G upload.

[1] I have to monitor my uplink status and when it dies I need to
power-cycle my cable-modem quickly enough that the TCP connection
doesn't time-out. My uplink dies typically 3-5 times when uploading a
5G image, which takes many hours. :(

Charles Steinkuehler
charles@steinkuehler.net

[luminize]

On 06 Aug 2016, at 23:48, cdsteinkuehler notifications@github.com wrote:

On 8/6/2016 4:38 PM, Michael Haberler wrote:

if you build them as-is on dockerhub - does it work? or does it exceed some limit?

Unknown...I wouldn't be able to upload one even if I wanted to.

I have enough trouble getting the ~5G images uploaded[1], I'd never be
able to complete an ~30G upload.

[1] I have to monitor my uplink status and when it dies I need to
power-cycle my cable-modem quickly enough that the TCP connection
doesn't time-out. My uplink dies typically 3-5 times when uploading a
5G image, which takes many hours. :(

maybe silly remark, but couldn’t we share these huge files (docker images, normal images) with some sort of torrent?