Hi Nathan, (I am making progress, thank you for tagging along! ;)
> On May 31, 2016, at 11:42, Nathan Rossi <[email protected]> wrote: > > 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. I went this path now. It looks like a better fit. I am however wondering what is the best way to deal with the device tree. The handoff (HDF) file, as I understand it so far, contains the required information to generate the DTS file. This is not reflected in the zybo linux-bd's yocto implementation, where the DTS is actually a regular file in meta-xilinx. Is it like this so that meta-xilinx doesn't depend on the zynq SDK tools? For my DTS, since I had to change the kernel tree (I am based on linux-xlnx/master), I chose to put my adapted version of logiref's DTS into the kernel tree (next to the zedboard's). I copied zynq-zed.dts and added the logiref's specific stuff. I eventually got a graphic terminal (using their fb driver mind you, not the drm in linux-xlnx.) So it's a start, but think I got lucky, and this is not viable. Let me explain... Logiref's dts memory node says that there is only 256MB at 0x0, while zynq-zed.dts says 512MB. The logicvc layers config in their DTS have pixel buffers located between 256MB and 512MB addresses. Even if I change the memory node to conform to logiref's dts, declaring only 256MB, once booted, there is still 512MB in the system. Here's what's weirder (to me): root@localhost:/sys/firmware/devicetree/base/memory# hexdump -C reg 00000000 00 00 00 00 20 00 00 00 |.... ...| 00000008 This does not match my dts file: $ dtc -I dtb -O dts /media/me/ZBOOT/uImage-zynq-zed-logiref.dtb |grep --context=2 "\"memory\"" memory { device_type = "memory"; reg = <0x0 0x10000000>; }; I also see that U-Boot (2nd stage) reports 512MB: U-Boot 2016.01 (Jun 01 2016 - 16:11:08 -0400) Model: Zynq Zed Development Board Board: Xilinx Zynq DRAM: ECC disabled 512 MiB (FYI, this is my first arm work since 2003! I have lots to catch up!) I gather that there's a DTS file used by u-boot as well, and that even if my logiref-zgpu-zed.bb recipe installed ps7_init_gpl files in "custom_hw_platform_init" of u-boot-xlnx's workspace, it seems u-boot-xlnx's recipe has used the "stock" arch/arm/dts/zynq-zed.dts, which says 512MB. Is it just that u-boot uses low-level stuff from the dts, and these configuration nodes in the dtb become irrelevant/useless when the linux kernel comes along and parses it? Right now when the logicvc initializes memory regions between 256 and 512MB, I get: /* * Don't allow RAM to be mapped - this causes problems with ARMv6+ */ if (WARN_ON(pfn_valid(pfn))) return NULL; in __arm_ioremap_pfn_caller from (linux tree)/arch/arm/mm/ioremap.c Before I understood the 256vs512MB correctly I had changed the layers config to point to >512MB addresses. It "worked". I suspect the IP cores mask the MSBs and the real addresses used wrapped back to between 0 and 256MB...? So I tried changing zynq-zed.dts in u-boot-lnx's workdir and indeed I got the kernel to say there was 256MB. However I can only get something on screen if I use Xylon's original ref-design DTS. I think I will revert to using Xylon's stock DTS from recipe space. Do you think I could apply it to both my boot image AND the u-boot-xlnx build process? If so, what would be the preferred pattern to customize u-boot-xlnx_%.bb's defconfig and DTS? Perhaps it should be along the same lines the way zybo-linux-bd overrides the ps7_init files? Or u-boot-xlnx bbappend to patches source directly? > 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). Thanks for pointing that out, I didn't know. But these are Xylon maintained drivers... I'll have to take them as is, unless the XylonQPA driver/library stack can easily operate on top of the DRM version of the driver found in linux-xlnx?
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
