DEx(x) Mksocfpga 2019 sd-card images (final ?) Stretch quartus 15.1 release Needs urgent testers

[Michael Brown]

Dear All

I have just uploaded what I hope to be a final 100% bugfree Mksocfpga Debian stretch sd-card release

containing a one size fits all console and desktop version for the:

Terasic (Alters/Intel) Cyclone V based dev boards.

DE0_Nano_Soc and DE10_Nano

Features:

    An updated version of the release last year.

    Kernel update adds LTC spi functionality and framebuffer

    rootfs has a fix for dual ethernet address.

https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/2.1

As a companion I have this fresh getting-started documentation that can be improved by your review and feedback:

And then submitted as a PR to the Docs

https://github.com/the-snowwhite/machinekit-docs/blob/DEx_work/docs/getting-started/machinekit-images.asciidoc

https://github.com/the-snowwhite/machinekit-docs/blob/DEx_work/docs/getting-started/u-boot-mksocfpga-altera-initial.asciidoc

Next step is hopefully to get some more in depth Developer info into the mk docs :-)

DE10 Nano suggested development environment?

[Charles Steinkuehler]

On 5/11/2019 1:17 PM, Michael Brown wrote:
> Dear All
> I have just uploaded what I hope to be a final 100% bugfree Mksocfpga
> Debian stretch sd-card release
> containing a one size fits all console and desktop version for the:
> Terasic (Alters/Intel) Cyclone V based dev boards.
> DE0_Nano_Soc and DE10_Nano
>
> Features:
> An updated version of the release last year.
> Kernel update adds LTC spi functionality and framebuffer
> rootfs has a fix for dual ethernet address.
>
> https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/2.1
>
> As a companion I have this fresh getting-started documentation that can be
> improved by your review and feedback:
> And then submitted as a PR to the Docs
>
> https://github.com/the-snowwhite/machinekit-docs/blob/DEx_work/docs/getting-started/machinekit-images.asciidoc
> https://github.com/the-snowwhite/machinekit-docs/blob/DEx_work/docs/getting-started/u-boot-mksocfpga-altera-initial.asciidoc

Great work Michael!!!

How are you building U-Boot and the Kernel (or are you using
pre-compiled versions from somewhere)? I have found the Altera and
Rocket-boards build process to be very "fragile", requiring a lot of
manual intervention to get things to build.

> Next step is hopefully to get some more in depth Developer info into the mk
> docs :-)
> DE10 Nano suggested development environment?

> <https://groups.google.com/forum/#!topic/machinekit/eVhvTnuhblE>

I'm not sure what exactly you mean by "development environment", but I
typically develop directly on the system (eg: compile Machinekit & HAL
modules on the DE0/DE10), and use an x86 VM running Debian to build
the uSD images (kernel, boot loader, Debian rootfs).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Michael Brown]

On Saturday, 11 May 2019 22:38:47 UTC+2, Charles Steinkuehler wrote:

On 5/11/2019 1:17 PM, Michael Brown wrote:
> Dear All
> I have just uploaded what I hope to be a final 100% bugfree Mksocfpga
> Debian stretch sd-card release
> containing a one size fits all console and desktop version for the:
> Terasic (Alters/Intel) Cyclone V based dev boards.
> DE0_Nano_Soc and DE10_Nano
>
> Features:
>     An updated version of the release last year.
>     Kernel update adds LTC spi functionality and framebuffer
>     rootfs has a fix for dual ethernet address.
>
> https://github.com/the-snowwhite/soc-image-buildscripts/releases/tag/2.1
>
> As a companion I have this fresh getting-started documentation that can be
> improved by your review and feedback:
> And then submitted as a PR to the Docs
>
> https://github.com/the-snowwhite/machinekit-docs/blob/DEx_work/docs/getting-started/machinekit-images.asciidoc
> https://github.com/the-snowwhite/machinekit-docs/blob/DEx_work/docs/getting-started/u-boot-mksocfpga-altera-initial.asciidoc

Great work Michael!!!

How are you building U-Boot and the Kernel (or are you using
pre-compiled versions from somewhere)?  I have found the Altera and
Rocket-boards build process to be very "fragile", requiring a lot of
manual intervention to get things to build.

Thanks Charles

Back un the initial mksocfpga days I have created  a custom build-script I have been maintaining/updating ever since:

I have tried to keep it as simple as possible .... however it needs cleaning again .. :-)

Currently I run it on KDENeon 18.04 (Bionic)

It lives in this folder:

https://github.com/the-snowwhite/soc-image-buildscripts/tree/master/SD-Image-Gen

And I have just updated the README.MD

current patches for DExx u-boot are here:

https://github.com/the-snowwhite/soc-image-buildscripts/tree/master/SD-Image-Gen/patches/linux-xilinx-v2018.2/current

current patches for the Cyclone V armhf kernel are here:

https://github.com/the-snowwhite/soc-image-buildscripts/tree/master/SD-Image-Gen/patches/4.9.76-ltsi-rt/current

 

> Next step is hopefully to get some more in depth Developer info into the mk
> docs :-)
> DE10 Nano suggested development environment?
> <https://groups.google.com/forum/#!topic/machinekit/eVhvTnuhblE>

I'm not sure what exactly you mean by "development environment", but I
typically develop directly on the system (eg: compile Machinekit & HAL
modules on the DE0/DE10), and use an x86 VM running Debian to build
the uSD images (kernel, boot loader, Debian rootfs).

That thread was evolving into explaining how mksocfpga works...

For Machinekit and HAL related stuff on armhf I personally find it easier and faster to use the docker based .deb builders and then either use my local reprepro or 

just copy the .debs over and do sudo dpkg -i *.deb

 

--
Charles Steinkuehler
cha...@steinkuehler.net

[Michael Brown]

Charles ?

I just tested compiling mk-hal here:

https://github.com/machinekit/mksocfpga/issues/47#issuecomment-491866529

 

 

--
Charles Steinkuehler
cha...@steinkuehler.net

[b...@basdebruijn.com]

Thanks Michael,

I will definitely be trying this out.

Keep up the good work!

Bas

[Charles Steinkuehler]

There's nothing wrong with using the Docker VMs to build.

I typically self-compile because I don't have an "always-on" Docker
host machine added to my personal XenServer based stack yet, but I
typically always have at least one ARM board running when I'm
developing (the machine I'm testing). Often I've got a fast
multi-core ARM system with high-speed storage (eg: Zynq Ultrascale+,
BeagleBoard X15) on-line I can use as a build machine.

Just pick whatever works best for you.

--
Charles Steinkuehler
cha...@steinkuehler.net