[meta-xilinx] getting started for logicbricks ref designs

[Nathan Rossi]

On Fri, Jun 3, 2016 at 6:38 AM, Jean-Francois Dagenais
<jeff.dagenais at gmail.com> wrote:
> 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?

This is one of the main reason for the device trees being static
files. Xilinx mentioned that they have plans for integration with the
tools for device-tree generation among other things in the future, so
look out for that if you are interested.

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

No u-boot and the kernel use this property. But u-boot will fix up
some parts of the dt that are passed to the kernel, this includes the
cmdline/bootargs and I believe it will also fix up (aka overwrite with
its own values) memory nodes.

>
> 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.

For reference, you can use the reserved-memory dt node to handle the
carving of memory. This is a bit more consistent compared to just
changing the memory size.
https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

For an additional example that matches something like your platform,
the Parallella sets up a non-mapped memory region:
https://github.com/parallella/parallella-linux/blob/parallella-linux-2016.3/arch/arm/boot/dts/zynq-parallella1.dtsi#L37

>
> 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,

As for using the stock dts from Xylon with U-Boot, that is likely to
not work correctly. But might work with a small number of changes.

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

Having a bbappend and patches allows more customization of other pats
of the code. But if you only need to add your defconfig+dt then a
bbappend that works by adding the content via bb tasks/shell script
will work well too.

Regards,
Nathan

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