DE10-DE0-Nano - Invitation to collaborate

[Michael Brown (via Google Drive)]

Michael Brown has invited you to contribute to the following shared folder:

DE10-DE0-Nano

DE10-SoC Machinekit demo image with framebuffer
This image also works with the Atlas (DE0-Nano-Soc) board(tested)

Open

Google Drive: Have all your files within reach from any device. Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

[Michael Brown]

DE10_Nano hdmi with 1024x768 works

This image also boot directly on the DE0_Nano_SoC without programming the fpga @boot (tested to work with mk) 

The hm2_soc_ol driver needs an update to be able to accept fpga configured from u-boot at boot.

Install notes:

https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md

:-)

Michael

[Charles Steinkuehler]

Nice!!!

To fix the hm2_soc_ol problem, just update the device tree file so it
doesn't try to program the FPGA. Replace (or comment) the
"firmware-name" line:

https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10

...with a tag indicating the FPGA is programmed already:

external-fpga-config = <1>;

This will keep the kernel from trying to (re)program the FPGA when you
load the overlay. Everything else (address ranges, IRQ numbers, etc)
should be OK and not need any changes.

On 8/29/2017 8:32 AM, Michael Brown wrote:
> DE10_Nano hdmi with 1024x768 works
> This image also boot directly on the DE0_Nano_SoC without programming the
> fpga @boot (tested to work with mk)
>
> The hm2_soc_ol driver needs an update to be able to accept fpga configured
> from u-boot at boot.
>
> Install notes:
> https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md
>
> :-)
> Michael
>
> On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote:
>>

>> Michael Brown <mib.hol...@gmail.com> has invited you to *contribute
>> to* the following shared folder:
>> DE10-DE0-Nano
>> <https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil&ts=59a5669b>

>> [image: Sender's profile photo]DE10-SoC Machinekit demo image with
>> framebuffer
>> This image also works with the Atlas (DE0-Nano-Soc) board(tested)
>> Open

>> <https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eip&ts=59a5669b>

>> Google Drive: Have all your files within reach from any device.
>> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA [image:

>> Logo for Google Drive] <https://drive.google.com>
>>
>


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

[mugginsac]

Michael,
Actually I have a couple questions for you.
First, is your image still using three partitions A2, Fat, and ext4?
Second, I cant find the source file "include/config_cmd_all.h". Is it part of u-boot??

I am trying to cut down to just two partitions. Initially A2 (for u-boot-with-spl.sfp) and ext4 (for rootfs).
I have had it boot but not consistently.

Thanks,
Alan

[Michael Brown]

OK nice

There were some issues with the original image I have worked them out and uploaded new tested images today.

I found a different workaround which I have created an Issue on:

https://github.com/machinekit/machinekit/issues/1261

Maybe someone can figure out how to mod the hm2_soc_ol driver so the machinekit mesa soc can run without forcing the load of the dtbo.. ?

I have commited my DE10_Nano quartus project here:

https://github.com/machinekit/mksocfpga/pull/88

Meanwhile:

https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10

How do I change the template so it only affects the DE10_Nano_FB_Cramps dtbo ?

[Michael Brown]

Well my Image is actually a 2 part Image with an added swap partition as partition2.

the ext4 rootfs partition was the moved to the last partition (3) so that is easily can be expanded by just resizing the last partition... :-) 

A2 (for u-boot-with-spl.sfp), swap and ext4 (for rootfs)

On Tuesday, 29 August 2017 19:01:01 UTC+2, mugginsac wrote:

Michael,
Actually I have a couple questions for you.
First, is your image still using three partitions A2, Fat, and ext4?
Second, I cant find the source file "include/config_cmd_all.h". Is it part of u-boot??

Yes:

file:///home/mib/Development/MK-Image-gen/uboot/include/config_cmd_all.h

[Michael Brown]

Personaly I think that this would be a more elegant solution, removing the requirement to Always load the device-tree-overlay at machinekit launch:

the-snowwhite/machinekit@bb33c62

[Michael Brown]

I setup a pull request on the remove dt-overlay on Machinekit launch requirement, issue as I may be away for some days.

https://github.com/machinekit/machinekit/pull/1263

On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote:

[Charles Steinkuehler]

I think that's the right direction, but I'm not sure just removing the
check for DTOV_STAT_APPLIED is safe in all instances. I'd have to
crawl through the hm2_soc code (not enough time right now), but from
memory, I think it would be better to pass two strings to the code.
One string (mandatory) would indicate the uio device name to use for
mapping the memory region and interrupt. The second (optional) string
would indicate a device-tree file to attempt to load/unload.

So without a device-tree overlay string, the driver will fail to load
if it doesn't find the proper uio device. When passed a device-tree
overlay string, the driver should behave as it does now (attempt to
load or unload/reload the overlay).

How does that sound?

On 8/30/2017 6:22 AM, Michael Brown wrote:
> Personaly I think that this would be a more elegant solution, removing the
> requirement to Always load the device-tree-overlay at machinekit launch:
>

> *the-snowwhite/machinekit@*bb33c62
> <https://github.com/the-snowwhite/machinekit/commit/bb33c62>

>
>
> On Wednesday, 30 August 2017 09:31:35 UTC+2, Michael Brown wrote:
>>
>> OK nice
>> There were some issues with the original image I have worked them out and
>> uploaded new tested images today.
>>
>> I found a different workaround which I have created an Issue on:
>> https://github.com/machinekit/machinekit/issues/1261
>>
>> Maybe someone can figure out how to mod the hm2_soc_ol driver so the
>> machinekit mesa soc can run without forcing the load of the dtbo.. ?
>>
>> I have commited my DE10_Nano quartus project here:
>> https://github.com/machinekit/mksocfpga/pull/88
>>
>> Meanwhile:
>>
>> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10

>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmksocfpga%2Fblob%2Fmaster%2FSW%2FMK%2Fdts-overlays%2Ftemplate.dts%23L10&sa=D&sntz=1&usg=AFQjCNE4OX4cvh7893gll32zCKNaXx0y5w>

>>
>> How do I change the template so it only affects the DE10_Nano_FB_Cramps
>> dtbo ?
>>
>>
>>
>> On Tuesday, 29 August 2017 16:10:01 UTC+2, Charles Steinkuehler wrote:
>>>
>>> Nice!!!
>>>
>>> To fix the hm2_soc_ol problem, just update the device tree file so it
>>> doesn't try to program the FPGA. Replace (or comment) the
>>> "firmware-name" line:
>>>
>>>
>>> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10

>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmksocfpga%2Fblob%2Fmaster%2FSW%2FMK%2Fdts-overlays%2Ftemplate.dts%23L10&sa=D&sntz=1&usg=AFQjCNE4OX4cvh7893gll32zCKNaXx0y5w>

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

[Charles Steinkuehler]

Upon further reflection, the "mandatory" uio device name should be
optional and have a sensible default if it's not passed on the command
line. The optional device tree overlay name should not (so the driver
doesn't do anything with loading/unloading device tree overlays if a
specific overlay name isn't passed in).

[Michael Brown]

Under all circumstances the driver will fail and unload the hal is any of the signatures are missing or incorrect
and will sometimes cause a kernel panic, this would IMHO be better to use time on solving.

Testing for device-tree overlay loaded or not is redundant overkill IMHO.

Testing for uio driver(s)/ports and signature(s)  is a necessaty.

[Michael Brown]

Yes seems like we agree :-)

[Charles Steinkuehler]

On 8/30/2017 5:14 PM, Michael Brown wrote:
> Under all circumstances the driver will fail and unload the hal is any of
> the signatures are missing or incorrect
> and will sometimes cause a kernel panic, this would IMHO be better to use
> time on solving.

Yeah, this is bad and should be fixed. Is there an issue for this in
the tracker?

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

[Michael Brown]

Not that I know of the pattern has been if the signature check failed the kernel would panic and talk a lot about about:

unable to handle kernel null pointer dereference

A google search revealed the it could be unloading some sort of variable that had not been initialized.

I have mostly ignored this issue until I had something more robust and the phenomena may have been due to the fpga not having enough time to

configure finish and startup before probing started (as the new designs are somewhat larger, or may take longer time to initialize)

[Michael Brown]

THat said .. if the signature or board name check fails this should not cause any kernel panics requiring a reboot. 

[Charles Steinkuehler]

On 8/31/2017 4:01 PM, Michael Brown wrote:
> THat said .. if the signature or board name check fails this should not
> cause any kernel panics requiring a reboot.

Agreed!

I haven't replicated your results here so I'm not 100% sure what's
happening, but from my experience the FPGA is programmed and running
by the time the UIO devices show up. One thing that could be causing
problems is if the FPGA is programmed by U-Boot and then reprogrammed
by the Linux kernel. If anything was talking to the FPGA fabric (like
the HDMI interface or any of the other "extra" logic in the example
designs and not just the HM2 logic) that could trigger BadThings up to
and including a kernel panic or system halt.

It's also possible there's a startup delay in the FPGA reset logic
that's causing the problem. The FPGA may be "running", but still
being held in an internal reset condition.

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

[mugginsac]

Michael,

How much swap did you add? I am trying to get my image to load but my SD writing programs don't like your image. I use  ApplePi Baker or Etcher. Etcher complains about no partition table. ApplePi Baker wrote an SD image but Linux thinks it is a CD.

How do you format the uSD card??

sudo sfdisk ${DISK} <<-__EOF__
1M,1M,0xA2,
---------------------------swap format goes here----------------------
2M,,,*
__EOF__
 

[Robert Nelson]

Or just use a swap file, then you don't have to worry about the
partition table..

Regards,


--
Robert Nelson
https://rcn-ee.com/

[Michael Brown]

? what os are you using.

Have you checked the md5sums of the files you have downloaded ?

On Debian I prefer using the bmap tool.

the swap file is 1G (see below)

You can use the following commands to copy to sd-card:

 mib@debian9-ws:~/Development/MK-Image-gen$ md5sum mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.bmap

a99856f140727124b09daa7fc910e3f4  mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.bmap

mib@debian9-ws:~/Development/MK-Image-gen$ md5sum mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.tar.bz2

5bd1d319bac2cb23e3db279970626b5d  mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.tar.bz2

sudo apt install bmap-tools

sudo apt install bzip2

mib@debian9-ws:~/Development/MK-Image-gen$ lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

loop0         7:0    0   5,7G  0 loop /tmp/qt_5.7.1-img

sdb           8:16   1   7,4G  0 disk 

├─sdb1        8:17   1     1M  0 part 

├─sdb2        8:18   1     1G  0 part 

└─sdb3        8:19   1   5,7G  0 part 

nvme1n1     259:0    0 953,9G  0 disk 

├─nvme1n1p4 259:1    0   512M  0 part 

├─nvme1n1p5 259:2    0 874,3G  0 part 

└─nvme1n1p6 259:3    0  15,3G  0 part 

nvme0n1     259:4    0   477G  0 disk 

├─nvme0n1p1 259:5    0   512M  0 part /boot/efi

├─nvme0n1p2 259:6    0  59,6G  0 part /

├─nvme0n1p3 259:7    0  16,2G  0 part [SWAP]

└─nvme0n1p4 259:8    0 400,6G  0 part /home

mib@debian9-ws:~/Development/MK-Image-gen$ sudo bmaptool copy mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.tar.bz2 /dev/sdb

[sudo] password for mib: 

bmaptool: info: discovered bmap file 'mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.bmap'

bmaptool: info: block map format version 2.0

bmaptool: info: 1740800 blocks of size 4096 (6.6 GiB), mapped 564041 blocks (2.2 GiB or 32.4%)

bmaptool: info: copying image 'mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.tar.bz2' to block device '/dev/sdb' using bmap file 'mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.bmap'

bmaptool: info: 100% copied

bmaptool: info: synchronizing '/dev/sdb'

bmaptool: info: copying time: 37.5s, copying speed 58.8 MiB/sec

mib@debian9-ws:~/Development/MK-Image-gen$ lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

loop0         7:0    0   5,7G  0 loop /tmp/qt_5.7.1-img

sdb           8:16   1   7,4G  0 disk 

├─sdb1        8:17   1     1M  0 part 

├─sdb2        8:18   1     1G  0 part 

└─sdb3        8:19   1   5,7G  0 part 

...

mib@debian9-ws:~/Development/MK-Image-gen$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 7,4 GiB, 7948206080 bytes, 15523840 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x55e7ded8

Device     Boot   Start      End  Sectors  Size Id Type

/dev/sdb1          2048     4095     2048    1M a2 unknown

/dev/sdb2          4096  2101247  2097152    1G 82 Linux swap / Solaris

/dev/sdb3       2101248 13926399 11825152  5,7G 83 Linux

[Michael Brown]

If you are running os x on a mac I found following commands in the Terminal to create a working sd-card.

First you have to extract the .bz2 image(in finder)

michaels-mbp:Delopement mib$ ls

mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.bmap

mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.tar.bz2

michaels-mbp:Delopement mib$ ls

mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.bmap

mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img.tar.bz2

diskutil list

michaels-mbp:Delopement mib$ sudo dd bs=1m if=mksocfpga_jessie_machinekit_4.1.22-2017-08-30-de10-nano_sd.img of=/dev/rdisk2 conv=sync

Password:

6800+0 records in

6800+0 records out

7130316800 bytes transferred in 86.625493 secs (82311991 bytes/sec)

michaels-mbp:Delopement mib$ diskutil list

/dev/disk0 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *500.3 GB   disk0

   1:                        EFI EFI                     209.7 MB   disk0s1

   2:          Apple_CoreStorage Macintosh HD            499.4 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                  Apple_HFS Macintosh HD           +499.0 GB   disk1

                                 Logical Volume on disk0s2

                                 412B5C72-F06E-4152-AE4B-5BE92D196E52

                                 Unencrypted

/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:     FDisk_partition_scheme                        *7.9 GB     disk2

   1:                       0xA2                         1.0 MB     disk2s1

   2:                 Linux_Swap                         1.1 GB     disk2s2

   3:                      Linux                         6.1 GB     disk2s3

Disk Utility  —> eject

REmember to Read/follow DE10_Nano_Commands.md (like setting a permanent mac address in u-boot )

:-)

On Friday, 1 September 2017 01:03:30 UTC+2, mugginsac wrote:

[Michael Brown]

BTW if os x prompts you about unrecognized disk click Ignore....

[Michael Brown]

Yes I agree that since increases the delay fixes this issue the problem is caused by:

"some sort of startup delay".

However you are pointing to a grander problem:

As the DE0_Nano_SoC is flaged EOL with the DE10_Nano (with hdmi) set as replacement

framebuffersupport would be something hard to keep out and.

by the time the UIO devices show up.  One thing that could be causing 
problems is if the FPGA is programmed by U-Boot and then reprogrammed 
by the Linux kernel.  If anything was talking to the FPGA fabric (like 
the HDMI interface or any of the other "extra" logic in the example 
designs and not just the HM2 logic) that could trigger BadThings up to 
and including a kernel panic or system halt. 

REmoving the devicetree requirement cleared being able to start machinekit without having to reconfigure the fpga on MK startup,,, fine.

But I have tested what happens when you have the display running (linux desktop) and then try to reconfigure the fpga with the same bitfile as loaded by uboot.

Result is a blank screen....

THis illustrates that loading/running a different bitfile / machinekit configuration will allways require a reboot when using the local soc display.

1 --> It may be possible to remedy this by reloading the alt_vip_fb driver (loaded as module), and resetting / restarting the x-server. ?

2 --> I have spent some time studying the partial-fpga-reconfiguration docs and it looks doable for me to create a partitioned design with.

the main partition containing the display and other qsys cores + - the uio. and a freezable bridge 

+ 1 new partition for each hm2 config.

[Charles Steinkuehler]

On 9/1/2017 8:47 AM, Michael Brown wrote:
>
> But I have tested what happens when you have the display running (linux
> desktop) and then try to reconfigure the fpga with the same bitfile as
> loaded by uboot.
>
> Result is a blank screen....

You're lucky.

You can easily wedge the entire system doing this.

> THis illustrates that loading/running a different bitfile / machinekit
> configuration will allways require a reboot when using the local soc
> display.

Yep.

> 1 --> It may be possible to remedy this by reloading the alt_vip_fb driver
> (loaded as module), and resetting / restarting the x-server. ?

Possible, but quite a hassle.

> 2 --> I have spent some time studying the partial-fpga-reconfiguration docs
> and it looks doable for me to create a partitioned design with.
> the main partition containing the display and other qsys cores + - the uio.
> and a freezable bridge
> + 1 new partition for each hm2 config.

This is *SERIOUSLY* challenging and very limiting for the logic going
into the FPGA (placement and routing for the display driver has to be
locked down and can't be moved to accommodate the hm2 recompiles, this
also prohibits logic optimization between the partitions).

IMHO, requiring a reboot to change the FPGA configuration when it's
loaded by U-Boot is a minor inconvenience. Considering the equivalent
with actual Mesa hardware is running the "mesaflash" utility (which
also requires a full power down, not just a reboot!) requiring a
reboot is fine.

...but since it's already working, I think programming the FPGA via
overlays should remain supported for folks who aren't trying to use
things like HDMI.

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

[schoo...@btinternet.com]

On 01/09/17 15:45, Charles Steinkuehler wrote:
> ...but since it's already working, I think programming the FPGA via
> overlays should remain supported for folks who aren't trying to use
> things like HDMI.

My thoughts for what they are worth.

I would have no intention of ever using HDMI from a board with 1GB SDRAM
and no GPU.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=1046&PartNo=2

I am not sure we should even encourage it by making it available!
Just asks for loads of "Axis locks up when I load my half billion line
printer file" threads.

It certainly needs to be able to be disabled or not used, with
preferably the inconvenience of reboot etc. being for those seeking to
use HDMI :-P

[Charles Steinkuehler]

On 9/1/2017 10:43 AM, schoo...@btinternet.com wrote:
>
> On 01/09/17 15:45, Charles Steinkuehler wrote:
>> ...but since it's already working, I think programming the FPGA via
>> overlays should remain supported for folks who aren't trying to use
>> things like HDMI.
>
> My thoughts for what they are worth.
>
> I would have no intention of ever using HDMI from a board with 1GB
> SDRAM and no GPU.
> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=1046&PartNo=2
>
> I am not sure we should even encourage it by making it available!
> Just asks for loads of "Axis locks up when I load my half billion line
> printer file" threads.

I would never recommend using the HDMI out for Axis, that's just
asking for problems. Some of the other light-weight UI's might be OK,
but I doubt it. People forget how slow CPU bit-banged displays can be
(and most of the young folk have never even used one).

> It certainly needs to be able to be disabled or not used, with
> preferably the inconvenience of reboot etc. being for those seeking to
> use HDMI :-P

I think HDMI should be disabled by default, or possibly in a text-only
console mode (I could actually see that being useful). I agree
enabling any sort of graphics output ought to require at least a
reboot, and possibly a compile (or installation) of a different FPGA
image.

I think there are some open-source text-mode displays that could be
compiled into the FPGA that have Linux drivers and could be tied to
the HDMI output...

...but again, I'm not particularly worried about getting HDMI output
working at all. I think effort is currently better spent on things
like fixing up the hm2_soc_ol driver and automating the uSD image
creation.

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

[Bas de Bruijn]

> On 1 Sep 2017, at 17:58, Charles Steinkuehler <cha...@steinkuehler.net> wrote:
>
> I think effort is currently better spent on things
> like fixing up the hm2_soc_ol driver and automating the uSD image
> creation.

Disclaimer: I claim ignorance on the technical side of this, and speak as a user.

Machinekit is mainly a motion stack, and one of the best benefits of machinetalk is to offload graphics/GUI.

Then if a machine runs, it hardly changes during its life imo. If it isn't broken, don't fix it. So I see no use case for non development setups where images/fpga firmware change frequently, thus a reboot is no hassle.

I agree with the above, up-to-date uSD images, like the fantastic BB images from RCN would be very valuable. Burn an image, easy install, get started quickly.

[mugginsac]

I disagree with Charles and Schooner. I used console access for years and I have had enough of it. I am tired of typing long lines of console entry to avoid the conveniences of a good gui interface. There are many features available in a good gui that help avoid carpal tunnel syndrome. I think the HDMI interface should be enabled by default. You can run MachineKit via ssh on another machine with decent 3D acceleration but having a gui interface on the DE10 still has value. If you want to talk about slow go back to a 2mHz Z-80.

You can avoid a half a billion lines of gcode by using a code generator that uses subroutines where possible instead of straight inline code.

Alan

[Charles Steinkuehler]

On 9/1/2017 1:11 PM, mugginsac wrote:
> I disagree with Charles and Schooner. I used console access for years and I
> have had enough of it. I am tired of typing long lines of console entry to
> avoid the conveniences of a good gui interface. There are many features
> available in a good gui that help avoid carpal tunnel syndrome. I think the
> HDMI interface should be enabled by default. You can run MachineKit via ssh
> on another machine with decent 3D acceleration but having a gui interface
> on the DE10 still has value. If you want to talk about slow go back to a
> 2mHz Z-80.

You are free to work on this if you'd like. IMHO, graphics
performance on the DE10 HDMI output is going to be dismal without
hardware acceleration, and building a GPU isn't generally a very
efficient way to use FPGA gates (although it is possible).

...and I've used many single MHz 8-bit systems, most of which would
probably have perceptively better performance than what you can get
from a DE10. But today you usually can't get by with 2 or 3
bit-planes of data with less than 100k pixels, or "cheats" like the
old character/tile based graphics displays. And even with a fast
32-bit ARM core, it takes a long time to do 3D manipulations on
graphics data with the CPU.

Using any sort of remote display with a built-in GPU (even my cheap
$20 Andriod cell phone) will give you *MUCH* better performance than
you could ever get natively on the DE10, even if you allocate all the
FPGA gates to graphics acceleration.

> You can avoid a half a billion lines of gcode by using a code generator
> that uses subroutines where possible instead of straight inline code.

For subtractive machining, yes. But the really big gcode files tend
to be generated by 3D printing, and there isn't really an effective
way to make them significantly smaller.

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

[Michael Brown]

Hmmm

Easy Easy folks

IMHO it is way to late to have another either or discussion when we actually have it ALL.

The demo Image I have donated is fully scriped and therefore fully reproducable and every step / command / customisation to every step

Is in the open.

AND only addition to the default generated sd-image are the DE10_Nano bitfiles which not yet are merged.

THis is not an effort to compete with  RHN's bbb originated build scripts, but thought as an complementary alternative

with additional other feel and options.

This scripted image supports DE10 / DE0 with and without framebuffer out-of-the box without major issues.

By editing 1 or 2 lines in the uEnv.txt file in the /boot folder the user can specify:

whether to run with or without HDMI
whether to turn the screen upside down (usefull for my13" lvds screen).

And / or if to configure the fpga via u-boot or not.

The only outstanding issue is that some of the packages / kernel options for enabling framebuffer support, seem to prevent

the kernel from loading.

I have this issue limited to the differences in generating a Jessie  sd-image without or with the -desktop option

in my buildscript repo ATM. 

---

I see no need for 3-D display or opengl etc. (I prefer the Machinekit-client --> Machineface, Cetus)

However

I see possibilities for having an local (touch based) 2-D display of which the Cyclone V socs do a decent job (even without DMA which is an upcoming option that may improve dragging windows a bit).

---

On another note practical tests have shown that it is possible to fully reload the fpga, without the system going haywire (except for the blank screen), which indicates that linux and the built in fpga(freeze) bridged + the altera socfpga 4.1.22-rt-ltsi kernel play well together in a default non optimized for this scenario setup.

You are very welcome to test the demo image with own hands to debunk or verify this bold claim.

Having to physically lock down the framebuffer cores, may be to challenging for the small (60-70% full) DE0, however

The DE10 project uses only (28%) in the HDMI PIN_3x24_cap config, so

I cannot refrain any longer from just talking about it and have to do some practical real world testing going down this occult like (partial reconfiguration) road, and report my findings.

Intel seems to have been busy focusing on the enterprise market for now leaving the Cyclone V SoC as the top low-cost bid.

(I know not much about what Xilinx are doing).

THis may change as Intel now has the potential to whip up something like a i5-fpga with a decent 3D graphics core, when

the time gets ripe, why wait for that ?

[pcwcol]

Actually you dont need to reboot or power cycle to reload the FPGA on most Mesa cards, you just use the mesaflash --reload option 

[mugginsac]

Michael,

It seemed to take forever to write, but eventually using dd the image wrote to the uSD and it boots.

I am in agreement with you that having the hdmi for local maintenance is a good idea. I have never tried to run 3D graphics on one of these small "card" computers. I think running linuxcnc or machinekit via ssh makes a lot of sense.

Thanks,
Alan

[Michael Brown]

Yes, I agree.

[Michael Brown]

As I did promise to return with my findings and report back when my Cyclone V partial reconfiguration quest had meet an conclusion I am not happy to verdict that is is true that it does work and that it is true that it does also not work "out of the box".

Until the license for incremental compilation and the pr core is open licensed, I will stick to consensus on the web of not placing any guide describing how to get it to work on Cyclone V with the linux dts overlay method.

I have instead chosen to share the steps needed in the shared folder available and let those that are benevolently curious,  investigative and open minded for open source hardware, fetch/grab the shared file and go look see what they would have to say if they deducted such easily fixable creative omissions themself. 

Leading to the "It dosn't work" statement above that fueled and kicked my relentless truth based intuitive guidance system into me having to provide verification of everything works if you know how to fix the omissions.

What remains is that:

Until such functionality is UNlicensed partial reconfiguration is unavailable for open hardware or source development contributors.

"It dosnt work" --> mythbusted :-)

Now whats that about an open sourced hardware society as the next evolutionary step ?

[Condit Alan]

Michael,

Is there an image for a uSD for the DE10 that will boot and run? I know you were working on an image that would boot both the DE0 and the DE10.

I have been away for awhile. I tried the 10/29/2017 http://deb.machinekit.io/uploads/de0-nano/debian-9.2-console-armhf-2017-10-29 upload but I couldn’t get it to boot the DE10.

Alan

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Michael Brown]

Hi Alan the link to that custom image file you will find in the first post in this thread. ( This is made from my own script  files and not Roberts online generated). 

To unsubscribe from this group and all its topics, send an email to machinekit+unsubscribe@googlegroups.com.

[Michael Brown]

Just a FYI that I have released 2 new stretch based images that are much more stable than the previous Jessie ones.

U-boot 2018.01,  4.9.76-ltsi-rt kernel

Also one is a desktop image running LXQT with kwin and even though there is some latency in loading, I find the windows to be much more responsive

with instantainios drag around etc.

And axis seems to run quite well with preview (see video demo).

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

On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote:

Michael Brown has invited you to contribute to the following shared folder:

DE10-DE0-Nano

DE10-SoC Machinekit demo image with framebuffer
This image also works with the Atlas (DE0-Nano-Soc) board(tested)

Open

[schoo...@btinternet.com]

Well done Michael,

Just tested it and works fine on a DE0-NANO too.

If you have no objections I will add them to the images at http://deb.machinekit.io/uploads/de0-nano/

Notes for anyone looking to test.

Instructions are in the file readme-console-image.md
DO use bmaptool to write to SD card.  dd does not seem to cope too well, but bmap works fine.

I used the console image and once the ethaddr etc was set etc. just needed to log in;
$ sudo apt update
$ sudo apt install machinekit-rt-preempt machinekit socfpga-rbf
and I was up and running the socfpga-stepper sim, easy as that!

--

website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---

You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.

[Michael Brown]

Yes you can boot the images without setting the ethernet and hostname variables(in u boot),

however things can get a bit messy on your network as the dhcp server will issue a new ip address for each reboot/boot.

---

Sure for the console image (this is tested to work on both de0-nano-soc and DE10 nano)

I just updated the readme for The Desktop image(readme_hdmi-desktop_image.md)

I'm wondering if there is a way to circumvent having to add bash -c to the linuxcnc.desktop file (does this work on a pc ?)

I am looking into adding the fpga-load u boot variables in an easier fashion, so that the desktop image is just as easy to startup as the console one. 

[Michael Brown]

@Schooner and others

OK I have now replaced the desktop image, with an enhanced version with less initial setup and updated the read me file accordingly.

This new image uses the fw_setenv / fw_printenv functionality so the u boot variables can be set from linux (also in chroot, with some fuss...)

Best wishes

Michael B.

On Monday, 9 April 2018 12:39:55 UTC+2, Schooner wrote:

[mugginsac]

Michael,

I just wrote a uSD of the desktop image with Etcher. I was able to login with the console in Putty, however, I didn't see anything with the monitor connected to the HDMI.
Am I missing something?

I am in the process of finishing the rewire of my CNC-Lathe controller using a 5i25/7i76 pair. What do I have to do to load the 5i25/7i76 bit file into the DE10-Nano?

Thanks,
Alan

[Michael Brown]

THe desktop image is mainly to demonstrate how responsive the kwin/lxqt desktop is,

and show off that Axis runs fine on the de10-Nano(with the de10_Nano_fb_Cramps bitfile), to put to a wider audience that local display

is a TRUE option ... :-)

This readme will get your display up and running if you follow the steps:

readme_hdmi-desktop_image.md
https://drive.google.com/open?id=1rLFGJgvm_q9CqeKDvfdKwD5T9ZRUgJaY

1.

The frame-buffer core needs to be programmed into the fpga before the kernel starts (from u boot).

2. 

You cannot reprogram the fpga while linux is running (the screen will go black). Hence the no_firmware load config example.

3.

... see below-->

On Sunday, 15 April 2018 00:10:22 UTC+2, mugginsac wrote:

Michael,

I just wrote a uSD of the desktop image with Etcher. I was able to login with the console in Putty, however, I didn't see anything with the monitor connected to the HDMI.
Am I missing something?

The readme file will guide you to a working display.

 

I am in the process of finishing the rewire of my CNC-Lathe controller using a 5i25/7i76 pair. What do I have to do to load the 5i25/7i76 bit file into the DE10-Nano?

Which bitfile config are you targeting for ?  (ie Quartus project)

The framebuffer core i initially only added to the Cramps flavor de10_nano quartus project this emulates a 5i25,

the GPIO_0 pinout is here:

Cramps2Nano.pdf

And here:

PIN_3x24.vhd

If you are using the db25 adaptor board:

With some persuasion it would be a reasonably small amount of work to add the de10 nano board with framebuffer 

somewhere around here:

DE0_Nano_SoC_DB25 

[mugginsac]

OK the firmware that I want to use is:
    /lib/firmware/socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo
    /lib/firmware/socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dts
    /lib/firmware/socfpga/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.rbf

So, are you saying that I have to modify the .vhd file in order to do so?

Thanks,
Alan

[mugginsac]

Michael,

I followed your instructions down to:

    setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap_spi.rbf
    setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb

It looks to me like I need something like:

    setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_DB25.rbf
    setenv fdtfile socfpga_cyclone5_de10_nano_fb.dtb

It looks like the socfpga_cyclone5_de10_nano_fb.dtb may already exist but that I need to create the DE10_Nano_FB_DB25.rbf.

Is that right?

[Michael Brown]

Short answer ... Yes

more verbose:

Each board needs its own Quartus project folder.

There are 2 options:

1.

To create that bitfile a new quartus project targeting the DE10 Nano Board with DB25 adaptor,

needs to be added here:

https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects

With a name like:

DE10_Nano_FB_DB25
Based on the existing _DB25 Quartus project by Charles
2.

As a last resort

I can add a 7I76_7I76_7I76_7I76 pin file to the existing DE10_Nano_FB_Cramps quartus project

and create it with a DE10_Nano_FB name and then add something to get the built in pin mux to configure for the DB25

Also needed would be to add the SSerial core.

(This will take some time as I'm caught up in updating and debugging my synthesizer project)

[Condit Alan]

Michael,

I have set up a quarts project DE10_Nano_FB_DB25 based on Charles DE0_Nano_DB25 project.

I copied the HDMI stuff from your DE10_Nano_FB_Cramps.qsf into DE0_Nano_DB25.qsf to create DE10_Nano_FB_DB25.qsf. There were pin conflicts between the HDMI stuff and the GPIO stuff. So I copied the GPIO stuff from your DE10_Nano_FB_Cramps.qsf as well, but then I got to wondering if that was the right thing to do? Should I have preserved the GPIO pins and changed the HDMI pins to resolve the conflicts?

Thanks,

Alan

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---

You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/BPRQpoyvFm8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

[Michael Brown]

Stop ... hold

On Tuesday, 17 April 2018 05:18:20 UTC+2, mugginsac wrote:

Michael,

I have set up a quarts project DE10_Nano_FB_DB25 based on Charles DE0_Nano_DB25 project.

This is a recipe for disaster.

---

The process is in crude steps:

You need to start with a DE10_Nano_Soc Board design (ie: the DE10_Nano_FB_Cramps)

Then the systemverilog .sv topfile  can be replaced with the vhdl .v one from the DE0_Nano_DB25.

The HDMI framebuffer core is in the Qsys design (in the DE10_Nano_FB_Cramps project), also the lcd clock is placed into the qsys partition.

 

I copied the HDMI stuff from your DE10_Nano_FB_Cramps.qsf into DE0_Nano_DB25.qsf to create DE10_Nano_FB_DB25.qsf. There were pin conflicts between the HDMI stuff and the GPIO stuff. So I copied the GPIO stuff from your DE10_Nano_FB_Cramps.qsf as well, but then I got to wondering if that was the right thing to do? Should I have preserved the GPIO pins and changed the HDMI pins to resolve the conflicts?

Do not edit any pins in the .qsf file these pins are set up for the physical boards and the DE0 nano is very different from the DE10 Nano, so you will only get no-go or smoke...!

You have to have some basic knowledge about fpga's verilog/vhdl and working with Quartus and qsys for this attempt to succeed, I would not recommend you to continue anything like you are describing ....  

 

---

[Michael Brown]

BTW

I'm sorry that there is not some nice documentation I can point at describing how to add a new project,

but here are some notes that have survived:

https://github.com/machinekit/mksocfpga/tree/master/docs

[Condit Alan]

Michael,

I have worked some with Verilog in the past but not much with VHDL. My question about the pins was because I recognized that there was a difference in devices but I have to admit I hadn’t thought it through well. I will go back to the beginning and go through the DE10 tutorial stuff.

Is there a particular reason that you guys are using Quartus version 15.1 instead of the current 17.1?

Thanks

[Charles Steinkuehler]

On 4/19/2018 10:21 PM, Condit Alan wrote:
>
> Is there a particular reason that you guys are using Quartus version 15.1 instead of the current 17.1?

That was the latest when I built the Docker images, and there's not a
huge incentive to upgrade. Newer versions of the tools will support
newer part families, but almost zero work goes into improving any
already-supported part families. So Cyclone-V support in Quartus 17.1
will be pretty much exactly the same as 15.1.

But if you'd like to upgrade, it's easy enough to install a newer
version of Quartus and build one-off cores, or you could create a Docker
image and push it to the Docker hub. Instructions are alongside the
docker files:

https://github.com/cdsteinkuehler/QuartusBuildVMs

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

[Condit Alan]

Charles,

Thank you for the clarification. I spent about a day trying to install Quartus 15.1 with no luck. I already have 17.1 installed and working so I think I will just go ahead and use it.

I was trying to run build.sh but it errors out on the “import google.protobuf.text_format”. I googled google.protobuf.text_format but it appears that there are several flavors c++, python, etc. What should I be looking for?

Thanks,
Alan

[Charles Steinkuehler]

On 4/20/2018 6:24 PM, Condit Alan wrote:
>
> I was trying to run build.sh but it errors out on the “import
> google.protobuf.text_format”. I googled google.protobuf.text_format
> but it appears that there are several flavors c++, python, etc. What
> should I be looking for?

You can do a one-off build without using a Docker image, but you still
probably want to review the build process used with Docker. The
top-level instructions are in the readme (see: Building a single
CycloneV bit file):

https://github.com/machinekit/mksocfpga/blob/master/README.MD

...the part you're missing is building the protobuf binding for the
firmware-id tag:

# From the Docker Quartus build image command line, run:
cd /work/HW/firmware-tag
make TOPDIR=/work py-proto

IIRC, you may run into problems building the protobuf bindings on a
stock Debian system. If so, make sure you've got all the required
packages installed. A good place to start is the package list used to
build the Docker image in the first place, in particular the stuff at
the bottom of the list:

https://github.com/cdsteinkuehler/QuartusBuildVMs/blob/master/Jessie-Quartus-Base/Dockerfile#L27-L32

Note that the last line "pip install intelhex" is actually a command and
not part of the package list.

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

[mugginsac]

OK, I have got "DE10_Nano_FB_DB25" building the dts, dtb and rbf with no errors. But before I try to use it on my DE10_Nano, it seems to me that Michael wrote something recently about setting some area of memory to load something. I have searched with no luck. So if you remember writing something Michael, could you point me to it again???

Charles took what I had done earlier and fixed it so that it would build on quartus 15.1. I had forgotten to add the hdmi stuff into DE10_Nano_FB_DB25.vhd. So I fixed that.

I have pushed my fixes using 17.1 back to github/muggins/mksocfpga branch muggins-master. 

Alan

[Michael Brown]

I found 1 quirk in the image:

If you do a ifconfig in the image you will probably see more than 1 ip address which gives strange

 login behavior. the solution to this is to remove the dhcpcd5 package. 

    sudo apt purge dhcpcd5

On Wednesday, 2 May 2018 06:04:11 UTC+2, mugginsac wrote:

OK, I have got "DE10_Nano_FB_DB25" building the dts, dtb and rbf with no errors. But before I try to use it on my DE10_Nano, it seems to me that Michael wrote something recently about setting some area of memory to load something. I have searched with no luck. So if you remember writing something Michael, could you point me to it again???

Charles took what I had done earlier and fixed it so that it would build on quartus 15.1. I had forgotten to add the hdmi stuff into DE10_Nano_FB_DB25.vhd. So I fixed that.

I have best experience with hand edited dtb files from the kernel source. using the .qsys project file from the provided DE10_Nano_FB_Cramps project

will enable yopu to be able to re-use the all-ready provided dtb( socfpga_cyclone5_de10_nano_fb.dtb).

Using the quartus generated dtb (soc_system.dtb) is not recomended from here, instead I look at the generated .dts file and hand edit the changes into the kernel ones.

 

I have pushed my fixes using 17.1 back to github/muggins/mksocfpga branch muggins-master. 

I will try to look into your new addition in near future .

[mugginsac]

Michael,

I tried your suggestion but apt reported dhcpcd5 not found. Did you take it out before you built the last uSD image?

Thanks,
Alan

[Michael Brown]

Ups forgot reply all:

Honestly I do not remember and I may have made a typo in the package name.

What matters first is:

When you run the ifconfig command how many up addresses do you see ? ..:-)

BTW.

You can also look in the leases list on the DHCP server on your local network.

[mugginsac]

I see two addresses. One for the ethernet 10.xx.xx.xx and 127.0.0.1 for local.

[Michael Brown]

Ok. The DHCP fix must be in the updated image.

If you are only able to ssh by using the ip address this can be due to DNS server setup on your local lan router.

[mugginsac]

I could say well it used to work, but the truth is that I forgot that I had added another router/switch into my network and I forgot to take that into account. Now it is working. Thanks for the help.

Alan

[Michael Brown]

Great

Thanks for the feedback.

[mugginsac]

I am trying to figure out exactly what I need to do to get the DE10_Nano_FB_DB25 to run with the HDMI console. The problem is that Charles' DE0_Nano_Soc_DB25 uses VHDL and Michael's DE10_Nano_FB_Cramps uses SYSTEM_VERILOG. And Charles' uses hostmot2_cfg.vhd while Michael is using hostmot3_cfg.vhd. So there are no files that I can compare directly and say "Oh, I just need to add 'X' to file 'y' inorder to fix the problem". I was able to get the DE10_Nano to boot using the Putty console under another version of Linux but not to bring up the HDMI console from the DE10-Nano.

So I see three options:
1. I use hostmot3_cfg.vhd and the SYSTEM_VERILOG stuff from DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv and create a PIN_ file for the 7I76 compatible with hostmote_cfg, or
2. I keep using hostmot2_cfg.vhd and translate/add the missing HDMI stuff from DE10_NANO_FB_CRAMPS.sv to the DE10_NANO_FB_DB25.vhd file, or
3. I keep using hostmot2_cfg.vhd and translate/add the missing PIN DESC stuff from DE10_NANO_FB_DB25.vhd to the SYSTEM_VERILOG file DE10_NANO_FB_CRAMPS.sv renamed to DE10_NANO_FB_DB25.sv (this seems easier to me).

Do any of these make any sense? What am I missing?

Thanks,
Alan

[Michael Brown]

It seems like you are trying to do too many things at once and then it gets too over complicated:

(the systemverilog Cramps version is core reduced only including the hm2cores needed for the cramps board)

(TODO: It is intended to later evolve with a systemverilog based config system, hence the hostmot3 name )

First step is to make a DE10 Nano version of the DE0_Nano_SoC_DB25:

Since explaining has fallen short of the mark I have initiated the port of the fullcore vhdl version in the link below:

Look carefully through the to 6 commits here:

https://github.com/the-snowwhite/mksocfpga/commits/DE10_Nano_SoC_FB_DB25 

I have cheated a little and kept the video cores in the qsys system, so the last commits do not compile fully,

until the video wiring is sorted out.

After that last step should be to add the hdmi config files to the top .vhd file.

The end result will use the same device tree (.dtb file), uboot ,rootfs and no_fw hm2 hal config setup as the DE10_Nano_FB_Cramps. ( only difference is the DE10_Nano_FB_DB25*.rbf bitfiles of course) :-)

I expect to have a commit ready within a few days unless someone else beats me to it.....

Question to ponder:

It is not yet possible (for me) to support more than 1 screen resolution pr bitfile , right now it is 1024x768x8bpp.

Do you prefer a different screen resolution (up to hd) ?

[Michael Brown]

OK

DE10_Nano_SoC_FB_DB25 project is now finished, compilable and ready for testing:

The default bitfile compiled is the PIN_7I76_7I76_7I76_7I76

https://github.com/the-snowwhite/mksocfpga/tree/DE10_Nano_SoC_FB_DB25

I will first be able to test the project this evening (in 4-6 hours).

You are very welcome to scrutinize and test in the meanwhile

[mugginsac]

Michael,

I found an error and I was trying to figure out what the problem was, but your latest fix, seems to have solved the problem.

I am rebuilding and I will know for sure in a bit.

Thanks,

Alan

[mugginsac]

Michael,

What is gained by renaming the "ip" directory to "cv_ip"?

What is lost is the ease in incorporating the changes back into "mksocfpga" master. Either every project that uses "ip" directory would have to be edited to use "cv_ip" or one would have to maintain both "ip" and "cv_ip" directories with mostly duplicate sources.

So do the benefits of the change outweigh the costs?

Alan

[mugginsac]

Never mind, I found the answer to my question, it is already cv_ip in mksocfpga.

[mugginsac]

I have gotten DE10_Nano_FB_25 with Michael's mods to build but I have yet to test it. After it built successfully, (since I was going to be gone all day anyway) I did "make scrub_clean" and tried running build again, however, this time it failed in Synthesis. I am running "./build.sh 7I76_7I76_7I76_7I76" again to see if it is just something about running build after "make scrub_clean" that has a problem. Anyway, I saved the folder after the successful build so that I can actually try testing the "DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf".

[mugginsac]

OK, the build was successful again this time. So it appears to me that something is being wiped out during “make scrub_clean” that causes the next build to fail testing. Because it completed the compile both times but didn’t complete the build script after the “make scrub_clean”. I hope this makes sense to somebody because I am confused at the moment.

Tomorrow I will try to test the generated .rbf file.

[Michael Brown]

Yes make scrub_clean will wipe out the firmware.mif file and also the .vhd config file. these files are easiest regenerated by running build.sh in the quartus docker image, this is why I copied these files over with an explicit note message in the commit list to make that clear.

After scrub clean you can "just" checkout the missing files from git.

The cv-ip folder name is due to mksocfpga contains multiple board configs for both Xilinx and Altera / intelfpga

[mugginsac]

I did built a new uSD and then did the following:

setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf

setenv fdtfile DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.dtb (renamed from soc_system.dtb)

and the result was that I couldn't boot at all.

So I reset the environment to default and started over.

I set the ethaddr, hostname, saveenv and tested the boot process and I could boot again.

Then I did

setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf

saveenv

and could still boot.

So the question is do I need to change the fdtfile and if so what with?

[Michael Brown]

On Friday, 25 May 2018 20:14:54 UTC+2, mugginsac wrote:

I did built a new uSD and then did the following:

setenv bitimage DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf

The bitimage variable needs to contain the full path to the *.rbf file you compiled and placed somewhere on the sd card ie: /boot/DE10_Nano_SoC_FB_DB25.rbf

(this assumes you copy the current test subject file you quartus compiled from the output_files folder to /boot folder on the sd card)

 

setenv fdtfile DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.dtb (renamed from soc_system.dtb)

No no no

where are you getting soc_system.dtb from ... not my instructions.

You need to use a sutable kernel compiled .dtb file from the /boot/dtb folder. (name something like: DE10_Nano_FB).

The exact same dtb file as named in the instructions for the demo image... OK ?

[Condit Alan]

Sorry Michael,

I copied the .rbf to lib/firmware/socfpga and I used the full path when I did the "setenv bitimage …".

I ran make dtb on the QuartusProject. It produced soc_system.dtb and soc_system.dts in the project directory. When I did "env default -f -a" it restored the fdtfile to socfpga_cyclone5_de10_nano_fb.dtb and when I tried booting it I was able to boot again. 

I wish I understood what the device tree blob is accomplishes, that would make it easier to avoid

these errors.

I am thinking about buying a small LCD monitor say (16” 1366x768). So that I can have a monitor on the putty console at the same time I am trying to see if the de10-nano is booting into the desktop. Right now I can’t easily switch between the x86 linux desktop and the de10-nano desktop to see if I am being successful or not. When I turn off my development box and try to boot the de10-nano desktop I am not seeing anything, the monitor just reports no signal. 

Thanks for your patience,

Alan

[Charles Steinkuehler]

On 5/25/2018 5:28 PM, Condit Alan wrote:
>
> I am thinking about buying a small LCD monitor say (16” 1366x768).
> So that I can have a monitor on the putty console at the same time
> I am trying to see if the de10-nano is booting into the desktop.
> Right now I can’t easily switch between the x86 linux desktop and
> the de10-nano desktop to see if I am being successful or not. When
> I turn off my development box and try to boot the de10-nano
> desktop I am not seeing anything, the monitor just reports no
> signal.

I recommend always having a UART serial terminal connected, you will
see a lot of errors you would otherwise miss. And most of the dev
boards (including the DE10) have a Linux console by default on the USB
UART interface.

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

[Condit Alan]

I am seeing three errors on the putty console when it starts to load the kernel
the first says [failed] Failed to start Load Kernel Modules
the second says [failed] Failed to start iSCSI initiator daemon(iscsid)
the third says [failed] Failed to start Login to default iSCSI targets

[Michael Brown]

On Saturday, 26 May 2018 06:36:46 UTC+2, mugginsac wrote:

I am seeing three errors on the putty console when it starts to load the kernel
the first says [failed] Failed to start Load Kernel Modules
the second says [failed] Failed to start iSCSI initiator daemon(iscsid)
the third says [failed] Failed to start Login to default iSCSI targets

Those errors are not important... however:

I think I know why you are booting to a blank screen:

In the (former released now online) sd image the framebuffer's address was 0x0005_0000, so that is the setting in that device tree.

I my recent work I have changed to using 0x0003_1000 for the framebuffer address.....

So I have attached my current version that will make the hdmi monitor work.

Copy this file to the /boot/dtb folder on you sd card overwriting the former version.

--- BTW

I am very close to having and updated image ready for release with:

-- A speedier framebuffer.

-- A much more simple u boot setup.

-- no missing -dev source files,(due to being built on stretch which has a newer qemu version than kde neon 16.04)

[Michael Brown]

While the former dtb file will enable the display, it will not let you run machinekit

as the name of the uio port is not correct for machinekit use.

this mishap is now corrected in this one.

---

I am now running the full quartus docker build, and then expect if all goes well

to upload the 2 fresh images, reduce the instructions and push my PR in a few hours....

:-)

[Michael Brown]

OK

New PR stuff is now in the pipeline,,, please enjoy ... :-)

images:

https://drive.google.com/open?id=1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ

HDMI readme:

https://drive.google.com/open?id=1rLFGJgvm_q9CqeKDvfdKwD5T9ZRUgJaY

No desktop (console version) readme:

https://drive.google.com/open?id=1goTy8C6fB2O5MGCEg_sDuG1fZVy63AsE

[Condit Alan]

Michael,

I built a uSD from the new image. I tried both my rbf “/lib/firmware/socfpga/DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf” and the one you listed in the instructions “/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_Cap.rbf” I still am not getting a display from the HDMI port of the DE10_Nano. I realized that I had missed a crucial instruction earlier, I was not setting FPGA_LOAD_ON_BOOT to 1. The console looks like it is initializing the desktop according to the messages but I don’t see anything on the monitor when I turn off my development system to try and allow the DE10_Nano to control the monitor. I think Monday I will try to get an extra monitor so that each system can have its own.

Alan

[Michael Brown]

Yes a separate monitor for each system would definitely be to recommend.

But with one monitor I recommend you stay in the usb kermit/putty console until it successfully gets down to saying:

(It is not necessary to see the 2 penguins...)

[  OK  ] Started User Manager for UID 111.

Debian GNU/Linux 9 mksocfpga-nano-soc ttyS0

mksocfpga-nano-soc login: 

Then shift to the de10 board hdmi output.

it takes around another 10 secs (after the login message) until the DE10 Nano HDMI display shows the login screen gui (on first boot it may take up to a minute).

---

Since the frame buffer address has been altered:

With the new images you need to wait for the PR to get merged, and the hopefully build the new socfpga-rbf debs without problems:

https://github.com/machinekit/mksocfpga/pull/95

Or

pull the latest updates on the pushed (De10 nano soc fb db25) branch and then manually re-compile in quartus.

On Sunday, 27 May 2018 06:24:38 UTC+2, mugginsac wrote:

Michael,

I built a uSD from the new image. I tried both my rbf “/lib/firmware/socfpga/DE10_Nano_FB_DB25.7I76_7I76_7I76_7I76.rbf” and the one you listed in the instructions “/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_Cap.rbf” I still

I dont know if you are aware that capitalization matters the correct filenames are:

/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf

/lib/firmware/socfpga/DE10_Nano_SoC_FB_DB25.7I76_7I76_7I76_7I76.rbf

 

But these will first be in the socfpga-rbf.deb package a few hours after Charles (or someone else) gets around to merging.....

:-) 

[Condit Alan]

Michael,

I am attaching the files printenv.txt and the puttyBootLog.txt. I noticed that the printenv no longer shows things like fpgaintf and fpgaintf_handoff. Is that OK?

Also, the console log goes from:

[  OK  ] Started Update UTMP about System Runlevel Changes.

to:

Debian GNU/Linux 9 mksocfpga-nano-soc ttyS0

mksocfpga-nano-soc login:  

I never see [  OK  ] Started User Manager for UID 111.

Alan

[schoo...@btinternet.com]

On 27/05/18 11:26, Michael Brown wrote:

I dont know if you are aware that capitalization matters the correct filenames are:

/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf

/lib/firmware/socfpga/DE10_Nano_SoC_FB_DB25.7I76_7I76_7I76_7I76.rbf

 

But these will first be in the socfpga-rbf.deb package a few hours after Charles (or someone else) gets around to merging.....

:-) 

You requested review by @cdsteinkuehler, but I have no idea as to his availability at present.

I am happy to merge if you require the files available and we can revert if there transpires to be a problem.

[Charles Steinkuehler]

Looks OK, merged.

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

[Michael Brown]

On Sunday, 27 May 2018 16:14:10 UTC+2, mugginsac wrote:

Michael,

I am attaching the files printenv.txt and the puttyBootLog.txt. I noticed that the printenv no longer shows things like fpgaintf and fpgaintf_handoff. Is that OK?

--> bitimage=/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf

You seem to be using the old (former rev) bitfile as the newer versions to go into socfpga-rbf are still compiling @ this moment.

Yes All the manually added bridge handoff stuff is replaced by the builtin uboot command --> bridge enable.

Also, the console log goes from:

[  OK  ] Started Update UTMP about System Runlevel Changes.

to:

Debian GNU/Linux 9 mksocfpga-nano-soc ttyS0

mksocfpga-nano-soc login:  

I never see [  OK  ] Started User Manager for UID 111.

I have no clue what that is related to....

 

Alan

 Online Quartus build is almost finished right now and if that finishes with success packaging will run afterwards. look at bottom here to see the current status yourself:

https://github.com/machinekit/mksocfpga

[Michael Brown]

Thanks for the offer meanwhile Charles found a way to push the merge button after a look-over ,,,,

I am looking forward to the feedback on this release... especially on the performance of the new framebuffer wire-ring... :-)

[Michael Brown]

Hmm quartus build went fine however package building failed with:

Failed to pull Docker image mhaberler/ubker

FATAL: Failed to pull Docker image mhaberler/ubker

Sounds oddly familiar ..... 

[Michael Brown]

I created an issue as placeholder

https://github.com/machinekit/mksocfpga/issues/96

[Michael Brown]

Alan

Keep you uboot variables as they are they are fine to run the hm2socfpga--> nofw load demo without errors.

While the packaging thingie (hopefully) gets sorted with success, I attach the new version of the bitfile to this post, so you don't have to

kee staring at a blang screen each time you boot the soc ... :-). 

On Sunday, 27 May 2018 16:14:10 UTC+2, mugginsac wrote:

[Michael Brown]

Hi Charles

Thanks for the latest merge.

I would like to address this elder post and update it with the current state of my explorations, and encourage a test of axis,

with the latest rev 2.1 soc image.

On Friday, 1 September 2017 17:58:59 UTC+2, Charles Steinkuehler wrote:

On 9/1/2017 10:43 AM, schoo...@btinternet.com wrote:
>
> On 01/09/17 15:45, Charles Steinkuehler wrote:
>> ...but since it's already working, I think programming the FPGA via
>> overlays should remain supported for folks who aren't trying to use
>> things like HDMI.
>
> My thoughts for what they are worth.
>
> I would have no intention of ever using HDMI from a board with 1GB
> SDRAM and no GPU.
> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=1046&PartNo=2

Yes no gpu however the older vip framereader core is able to act as bus master and utilize the fpga to hps sdram bus,

which is a great advancement over the old style bit-banged framebuffers you are refering to.

even in the rev 2.0 image without this enhancement axis worked adequately. 

 

>
> I am not sure we should even encourage it by making it available!
> Just asks for loads of "Axis locks up when I load my half billion line
> printer file" threads.

This needs to be tested (again) on he new image.

 

I would never recommend using the HDMI out for Axis, that's just
asking for problems.  Some of the other light-weight UI's might be OK,
but I doubt it.  People forget how slow CPU bit-banged displays can be
(and most of the young folk have never even used one).

There has been some advancement with sddm - kwin and lxqt

 

> It certainly needs to be able to be disabled or not used, with
> preferably the inconvenience of reboot etc. being for those seeking to
> use HDMI :-P

I think HDMI should be disabled by default, or possibly in a text-only
console mode (I could actually see that being useful).  I agree
enabling any sort of graphics output ought to require at least a
reboot, and possibly a compile (or installation) of a different FPGA
image.

This has been solved via different device trees for the de10 nano:

only those containing _fb_ activate the framebuffer

_fb_hd is for 192x1080 resolution, _fb_ has 1024x760 resolution matching the bitfiles in the #95 pr commit.

If you prefer also not to have the detktop gui related files and run console only, you should be able to use the deo_nano sd image with a non _hd_ devicetree.

(look at the devicetree utilized upon first-boot in the de10_hdmi instructions, works fine without loading the fpga upon boot).

((I have not tested a machinekit fpga load run in this setup, it is Supposed to work  ))

I think there are some open-source text-mode displays that could be
compiled into the FPGA that have Linux drivers and could be tied to
the HDMI output...

...but again, I'm not particularly worried about getting HDMI output
working at all.  I think effort is currently better spent on things
like fixing up the hm2_soc_ol driver and automating the uSD image
creation.

Yes agree it seem like the deb package building is failing ... atm.
:-)

 

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

[Michael Brown]

--> If you prefer also not to have the detktop gui related files and run console only, you should be able to use the deo_nano sd image with a non _hd_ devicetree.

ups I meant

non _fb_ devicetree

[Condit Alan]

Michael,

Why did you choose to call your DB25 setup for the DE10_Nano DE10_Nano_SoC_FB_DB25? There is a board that is the DE0_Nano_SoC and there is the  DE10_Nano but no DE10_Nano_SoC. You called the cramps setup DE10_Nano_FB_Cramps consistency would seem to have dictated that the DB25 for the DE10_Nano would be DE10_Nano_FB_DB25.

Alan

[Michael Brown]

Since the new addition relies on the config files for the DE0_Nano_SoC_DB25 and new configs added there are also compiled in the new config.

I thought i best to reflect that in the naming, hence the DE10_Nano_SoC_FB_DB25.

Btw have you had any luck with the bitfile I attached to my post yesterday ? 

[Condit Alan]

Michael,

Still no luck in Muddville. I copied the new “socfpga_cyclone5_de10_nano_fb.dtb” to /boot/dtb/ and I copied the new "DE10_Nano_FB_Cramps.3x24_cap.rbf” to /lib/firmware/socfpga-rbf/. 

I am attaching the cKermit boot log (I switched to cKermit because cutting and pasting is easier). It shows a printenv followed by a record of the boot. No success in seeing the HDMI output.

Alan

[Michael Brown]

Well ... When you are dealing with setting up a so complex system as this where a single wrong character can give problems,

attention to detail is a must.

I have noticed an odd tendency which make you stray from given instructions thus leading to postponing your eventual success...

--> /lib/firmware/socfpga-rbf/. 

this is a new folder name you have invented, in linux copying a file directly to a folder that does not exist will instead lead to a file with that name,

So here I suspect this would have lead to the fpga not getting programmed, unless you manually created that folder first. (Inventing a new unspecified variant)

the agreed upon folder name is /lib/firmware/socfpga

--> socfpga_cyclone5_de10_nano_fb.dtb

This is not the name specified in the instructions i carefully edited when I uploaded the rev 2.1 images. (I have just checked if I made a typo....)

Until you have your first successful test run it is best not to experiment with modifications.. please.

[Condit Alan]

Michael,

I was confused by something you wrote yesterday. You wrote

--> bitimage=/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf

You seem to be using the old (former rev) bitfile as the newer versions to go into socfpga-rbf are still compiling @ this moment.

I created the directory before I copied the file into it. I didn’t understand why you were changing the naming convention for the directory but I was trying to follow your directions.

Since it is now clear that I misunderstood what you were saying, I have copied the file to /lib/firmware/socfpga. Then I went back into uboot and did

setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf

   followed by

saveenv

Then I again tried booting and again got the same result. See attached cKermitLog2.txt (with printenv and boot log). Can you connect ckermit to the DE10-Nano and do printenv and boot and send me the log so that I can see if I can identify any critical differences between what I am seeing and what you are getting. 

By the way I got a separate monitor for the HDMI output.

Thanks,

Alan

[Michael Brown]

ok

I don't know if you have noticed the command: sudo apt install socfpga-rbf , which then installs all the machinekit compiled *.rbf files in the folder

/lib/firmware/socfpga ... plus some more.

(The online packaging system is still having a problem, so this does not contain the newest update yet)

I can attach my boot printout but first: 

Can you please paste the full name of the sd image file you are using ?

Also please give the full name of that default supplied sd-image you were able to boot with the hdmi output working. (plus where you found it).

[Michael Brown]

Alan

I'm not sure what the culprit is, and now my own setup is having some monitor screen issues.

I'm currently downloading the rev 2.1 desktop image to try to debug where this issue stems from, give me some time...

[Condit Alan]

Michael,

I downloaded your "mksocfpga_stretch_machinekit_4.9.76-2018-05-26-de10_nano_desktop_sd.img.tar.bz2”. I extracted "mksocfpga_stretch_machinekit_4.9.76-2018-05-26-de10_nano_desktop_sd.img” from it and wrote the uSD using etcher.

I was booting the original uSD that came with the board to see the HDMI. I don’t know the name of that image. 

I just wrote a uSD from DE10_Nano_LXDE.zip that I downloaded some time ago. I can boot it into the HDMI monitor and for what it worth, on the console I am seeing something very similar to what I am seeing with your image. It is located at "http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=1046&PartNo=4”. You may have to create an account to download it.

Alan

[Michael Brown]

Ok

I think that image is based upon the DE10_Nano_FB demonstration project from terasic, which are the display timings and resolutions I have replicated.

And yes you are using the correct image.

I have just had a bad few hours of doubt because my own monitor suddenly kept showing no image and a blank screen no matter what I did.

But it turned out the solution was to unplug the HDMI cable and then replug... :-)

Now I need to revert back to the downloaded image once again for a last checkup... after a break.

[Michael Brown]

Heads up:

The updated socfpga-rbf stretch .deb package is now online in the repo:

The *_Cramps.rbf work, the updated desktop readme instructions work:

my hdmi display shows following information:

    H.Frequency:    55.7 Khz

    V.Frequency:    69.1 Hz
    Resolution:       1024x768

    Pixel Clock:      73.9 Mhz

@Alan  I'm not sure if these are standard xvga timings, and this may need to be changed to be

more all round compatible(including your monitor(s))

 

The new DE10_*_DE25.rbf's have devicetree related errors upon booting so:

https://github.com/machinekit/mksocfpga/issues/97

[Michael Brown]

Hi Alan

Please be so kind as to try out the new attached files.
Please inform If they work correctly:

I am now ready for a bugfix PR.

I have changed the hdmi core clock frequency from 75Mhz to 65MHz, and aligned all the qsys ip core and device-tree addresses(In qsys and the *.dtb's):

hdmi display now shows following information:

    H.Frequency:    48.2 Khz

    V.Frequency:    59.8 Hz
    Resolution:       1024x768

    Pixel Clock:      64.7 Mhz

[Condit Alan]

Hi Michael,

Still no go. I still get to the login prompt on the cKermit console but see nothing on the HDMI monitor.

I copied the socfpga_cyclone5_de10_nano_uio_fb_hd.dtb into /boot/dtb/ and did "setenv fdtfile socfpga_cyclone5_de10_nano_uio_fb_hd.dtb". I copied DE10_Nano_FB_Cramps.3x24_cap.rbf into /lib/firmware/socfpga/ and doing "setenv bitimage /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf”. Then I did saveenv before booting. Then I powered it down and rebooted in case I should have done reset before booting.

Have you “flashed anything to the fpga”? How are your switches set?

Can you boot in to the cKermit console, do printenv and boot, then copy the output of that to a text file and send it to me?

Alan