[meta-xilinx] getting started for logicbricks ref designs

[Jean-Francois Dagenais]

Hi Nathan,

(I am making progress, thank you for tagging along! ;)

> On May 31, 2016, at 11:42, Nathan Rossi <nathan at nathanrossi.com> wrote:
> 
> 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.

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 at 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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20160602/0737078e/attachment.pgp>