@Charles
I didn't have much luck with your image working with the Ultra96 2018.3 
Petalinux bsp (the BOOT.BIN), as this has a watchdog timeout
that needs to be triggered by some udev stuff I found in the petalinus 
rootfs. I could only get it to work in my own build scripot generated 
rootfs.
(otherwise it times out and triggers a reset in 60 sec from boot).

Also porting from the existing zturn (ztio_10) configs has only led to the 
uio port writing zeros (no data).

Looking into:
If the (latest and newest) vivado/petalinux 2019.1 had some interresting 
new stuff I noticed:

Partial Reconfiguration Licenses for Partial Reconfiguration are no longer 
required for any Vivado Edition 
<https://www.xilinx.com/products/design-tools/vivado/vivado-whats-new.html>

Hmmm.....

AFAIK the ultra96 needs to be fpga configured on boot to be able to start 
linux (at least with a gui and power manangement),
this (new stuff) opens the door for being able to swap in (and out) the hm2 
mesa pin configs from the Machinekit SW.
(with a boot configured fpga)

Also a new configure/compile system based on the partial re-confuguration 
scheme, has to/can be conceptualized/realized ...?  


On Tuesday, 27 August 2019 21:06:17 UTC+2, Charles Steinkuehler wrote:
>
> On 8/27/2019 12:16 PM, Michael Brown wrote: 
> > @Charles: 
> > 
> > NOTE: I have a uSD image that's "Plain ole Debian" if you want 
> >> something more generic to work with than the Xilinx AI SDK.  It's for 
> >> the ZCU104 but you should be able to use it as-is with the Ultra96 if 
> >> you swap out the boot files (kernel, device-tree, & U-Boot).  Let me 
> >> know if you're interested. 
> > 
> > Swapping out the BOOT.BIN and adding image.ub from the U96 petalinux bsp 
> to 
> > the AI image 
> > gives about 1 min of gui access before rebooting, re-placing the rootfs 
> > with the petalinux one fixes the reboots, however ...too minimal 
>
> Make sure the device tree is copied over as well.  Depending on the 
> setup the device tree can be in the BOOT.BIN file, in image.ub, a 
> separate file, stored in raw sectors on the boot media, etc. 
>
> > I think its time to make that call, for your "Plain ole Debian" rootfs. 
> > Is it Stretch ? 
>
> Yes, it's stretch but it probably wouldn't take much to migrate to Buster. 
>
> I'll PM you a link to the uSD images.  If you (or anyone else) is 
> interested in the source (I've got scripts for building full working 
> uSD images for the Zybo-Z7-20 and ZCU104 from scratch), follow along 
> below: 
>
> Hit the following link, scroll to the bottom, and click the download 
> link for the Embedded SDK: 
>
> https://www.newtek.com/ndi/sdk/ 
>
> After installing the SDK, the uSD README file has the links to the 
> images.  The scripts for building the uSD Image are in the 
> fpga_reference_design/os_uSD/ directory. 
>
> The root filesystem is virtually identical for both images, one's just 
> armhf and the other is aarch64.  They are almost bone-stock Debian 
> installs, with a few minor tweaks here and there (mostly customizing 
> the login prompt & such) as well as a couple "magic" bits you'll 
> likely want to keep (like generating ssh keys and resizing the uSD 
> partition on first boot). 
>
> Depending on how the 96 boards image is setup, it may be easier to 
> copy the boot loader & such onto my uSD images, or it may work better 
> to copy (rsync) the contents of the rootfs onto their image.  My 
> Debian rootfs system is agnostic with regards to where it lives, as 
> long as you pass an appropriate root= command to the kernel.  :) 
>
> -- 
> Charles Steinkuehler 
> [email protected] <javascript:> 
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/551fb2d8-3a63-4f95-8ada-2df62518bd4c%40googlegroups.com.

Reply via email to