On Tue, May 31, 2016 at 3:52 AM, Jean-Francois Dagenais <[email protected]> wrote: > >> On May 30, 2016, at 09:07, Nathan Rossi <[email protected]> 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 -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
