[meta-xilinx] getting started for logicbricks ref designs

[Nathan Rossi]

On Tue, May 31, 2016 at 3:52 AM, Jean-Francois Dagenais
<jeff.dagenais at gmail.com> wrote:
>
>> On May 30, 2016, at 09:07, Nathan Rossi <nathan at nathanrossi.com> wrote:
>>
>> But the meta-xilinx
>> layer does have the 'zybo-linux-bd-zynq7' machine which is a good
>> example to work from.
>
> Thanks, I had spotted it as a good example. Although I was a bit thrown off by
> the "linux-bd" stuff in "recipes-bsp/reference-design/zybo-linux-bd.bb".

Depending on what your hardware development process/workflow is, you
can use that recipe as a reference for where to place files. If you
are getting a HDF file, that zybo-linux-bd.bb recipe shows one way of
unpacking it and pulling the bitstream and ps7_init files into the
right places.

>
>>
>> That is how it is implemented in meta-xilinx, although using
>> EXTRA_IMAGEDEPENDS as that ensures the bitstream is output but not
>> added to the root filesystem (although that depends on how/when you
>> want to load your bitstream).
>
> I guess I need the bitstream file to be loaded ASAP so I can get something on
> the screen (splash). Perhaps by the first stage loader (as fpga.bin)? I think
> the FSL is a "hacked" version of u-boot, is this still true?

So you will want to load it before the kernel is booted.

U-Boot is capable of loading bitstreams, have a look at U-Boot's "fpga
..." commands, you can setup auto booting via the environment. You can
also setup U-Boot SPL to load the bitstream. By default meta-xilinx
produces boot.bin files with U-Boot SPL, which can load linux/etc
directly or load U-Boot for more features. You will want to
investigate this deeper if you have special requirements (e.g. image
signing, multiple bitstreams, etc).

>
>>
>> I am not sure of the specifics on the Xylon drivers, you might need to
>> check against resources provided by Xylon regarding what drivers are
>> needed. Some of the documentation might be old and rely on older
>> kernels (e.g. the current linux-xlnx master has xylon drm drivers
>> instead of fbdev).
>>
>> There is some in-kernel docs (linux-xlnx) on the logicvc and the xylon
>> drm driver:
>> ./Documentation/devicetree/bindings/drm/xylon/logicvc.txt
>> ./Documentation/devicetree/bindings/drm/xylon/xylon_drm.txt
>>
>> A bbappend is the right way, you can have .cfg/.scc fragment pairs
>> added to the SRC_URI.
>
> Xylon support team cues me I should remove the DRM driver in favour of their fb
> driver found at:
> https://github.com/logicbricks/driver_fb_logicvc/tree/master/kernel_src . I
> guess I will just comply with this to start.

Just for reference, fbdev is considered a deprecated framework. This
article is worth looking at if you intend to use a non-mainline fbdev
driver (https://www.phoronix.com/scan.php?page=news_item&px=Linux-FBDEV-Stop-Making-Drivers).

>
>>
>> The linux-yocto bbappends in meta-xilinx are used to add kernel
>> configuration to the linux-yocto kernels in order to use the
>> linux-yocto kernels on Zynq/ZynqMP/MicroBlaze targets.
>>
>> There are advantages and disadvantages to both kernels. Generally
>> speaking, linux-yocto provides a better generic base kernel for most
>> users as it provides support for Zynq hardware (due to mainline
>> support for Zynq/ZynqMP/MicroBlaze), the linux-yocto kernel is also
>> supported with continual updates, backports and mainline minor
>> releases making it very useful for long term projects. But the driver
>> support provided by linux-xlnx is required in a number of cases.
>
> Yeah I'd like to benefit from that. But I assume I need all the configuration
> stuff I get from linux-xlnx.inc. Would you say it's a bad idea to "git merge"
> linux-yocto-4.4/standard/base into linux-xlnx/master but still use
> linux-xlnx_4.4.bb? Both are 4.4. I guess I would not get all the kmeta and other
> configuration fragments from linux-yocto though, am I correct?

Merging the linux-yocto tree and linux-xlnx tree might work, but you
would need to continuously do it for each update of the linux-yocto
tree. If you are interested in using linux-yocto consider taking
specific drivers as patches across to the linux-yocto tree, this is
easier to maintain compared to merging the trees. You can add them
using kmeta or just append to the SRC_URI from within your layer.

Regarding the kmeta configs, those from the yocto-kernel-cache really
only apply to the linux-yocto kernel. The linux-xlnx recipe does
actually use the kmeta config framework, but not the
yocto-kernel-cache.

>
> Oh, sorry to all about my first post not respecting the usual 80 cols
> netiquette! ;)

Don't worry about it, people on this list are not too picky about
email formatting :).

Regards,
Nathan