Re: [meta-xilinx] devtmpfs: error mounting -2

[Giordon Stark]

ng a wic image made with
> the
> > "sdimage-bootpart.wks" from yocto. This method has worked fine before
> now.
> >
> > Are there obvious things I should check to make sure devtmpfs can be
> mounted
> > properly? I have not messed with bootargs or anything since the working
> > version of the OS, so I'm not sure why I am suddenly seeing this error.
> >
> > A comparison output from the working OS and the bad OS can be seen
> below. Any
> > ideas are greatly appreciated!
> >
> > Thanks,
> > Emily
> >
> > *Bad OS: *
> > [4.125754] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to
> feature
> > incompatibilities
> > [4.163579] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data
> mode.
> > Opts: (null)
> > [4.171613] VFS: Mounted root (ext4 filesystem) on device 179:2.
> > [4.178864] devtmpfs: error mounting -2
> > [4.182766] Freeing unused kernel memory: 640K (ffc000d2 -
> > ffc000dc)
> > /bin/sh: can't access tty; job control turned off
> > / #
> >
> > *Working OS: *
> > [4.089697] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to
> feature
> > incompatibilities
> > [5.324662] EXT4-fs (mmcblk0p2): recovery complete
> > [5.404047] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data
> mode.
> > Opts: (null)
> > [5.412083] VFS: Mounted root (ext4 filesystem) on device 179:2.
> > [5.418084] devtmpfs: mounted
> > [5.421106] Freeing unused kernel memory: 512K (ffc000c1 -
> > ffc000c9)
> >
> > ... (boot continues)
> >
>
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] PMUFW debugging with debug flags

[Giordon Stark]

So is the m-x-t layer using a recipe described by this page (
http://www.wiki.xilinx.com/PMU+Firmware) and not the m-x-bsp layer?

That's unfortunate if so. I'd rather not pull in m-x-t right now.

Giordon

On Thu, Jul 19, 2018 at 9:00 AM Peter Smith  wrote:

> The two recipes are different for sure, I noticed this only yesterday and
> yes you need xsct for m-x-t
>
> On Thu, 19 Jul 2018, 14:58 Giordon Stark,  wrote:
>
>> Hi JF,
>>
>> No, but I am on rocko so it's got the two different layers under
>> meta-xilinx and I'm using the meta-xilinx-bsp version. Is meta-xilinx-tools
>> completely different? The main reason I'm not using meta-xilinx-tools right
>> now is that my understanding is I need the SDK installed on the machine and
>> point m-x-t at it, and I'm just trying to get things in a way that doesn't
>> depend on something external to yocto...
>>
>> Giordon
>>
>> On Thu, Jul 19, 2018 at 8:55 AM Jean-Francois Dagenais <
>> jeff.dagen...@gmail.com> wrote:
>>
>>> Hi Giordon,
>>>
>>> > On Jul 19, 2018, at 8:58 AM, Giordon Stark  wrote:
>>> >
>>> > However, when recompiling and re-running -- I do not see extra debug
>>> information from the PMUFW -- so I'm patching the kernel
>>> drivers/clk/zynqmp/pll.c to get more information about the PLL hang itself
>>> in the meantime.
>>> >
>>> > Any ideas? Did I do something wrong in enabling the debug flags?
>>>
>>> Are you using the meta-xilinx-tools pmu_firmware recipe?
>>>
>>> I ask because, coincidently, I am discussing a patch in
>>> xsctbase:do_configure about cleaning the xsct workspace on do_configure
>>> start to avoid these kinds of behaviour. See
>>> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-June/003916.html
>>> and
>>> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-July/003986.html
>>>
>>> Turns out I had the manual "rm" in my local repo only, but the point
>>> remains.
>>>
>>> Hope this helps!
>>
>> --
>> Giordon Stark
>>
> --
>> ___
>> meta-xilinx mailing list
>> meta-xilinx@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>
> --
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card

[Giordon Stark]

Hi all,

A brief update on the progress. After going back and forth with Xilinx a
lot -- we finally found a series of patches to apply on top of rocko that
resolve the PLL hang we've been observing for a long time (~since a week
after my last response in this email thread).

I'd like to double-back over to the erase block size. Unfortunately, I'm
very confused about why Linux and U-boot are reporting different sizes (or
maybe I'm confused).

Referring to this kernel log for a qspi boot that failed:
https://gist.github.com/kratsg/b93fb762d956c148dd0d26f9028419a3

I see these two blocks:

*u-boot*
ZynqMP> sf probe
zynqmp_qspi_ofdata_to_platdata: CLK 12499
SF: Detected mt25qu02g with page size 512 Bytes, erase size 128 KiB, total
512 MiB
*linux*
[2.738079] mtdoops: mtd device (mtddev=name/number) must be supplied
[2.745816] m25p80 spi0.0: found mt25qu02g, expected n25q512a
[2.751774] m25p80 spi0.0: mt25qu02g (524288 Kbytes)
[2.756677] 3 ofpart partitions found on MTD device spi0.0
[2.762131] Creating 3 MTD partitions on "spi0.0":
[2.766907] 0x0200-0x0300 : "kernel"
[2.772323] 0x0300-0x0400 : "device-tree"
[2.778083] 0x0400-0x0800 : "rootfs"

U-boot tells me the erase block size is 128 KiB (0x2_) but this seems
to be incorrect as I see lines like these later on

[4.438252] jffs2: Node at 0x1bfc with length 0x0435 would run
over the end of the erase block
[4.447494] jffs2: Perhaps the file system was created with the wrong
erase size?
[4.454974] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c00: 0x0435 instead
[4.464418] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c04: 0x9438 instead
[4.473878] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c08: 0x0013 instead
[4.483348] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c0c: 0x0006 instead
[4.492803] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c10: 0x81ed instead
[4.502267] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c18: 0x4398 instead
[4.511722] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c28: 0x5000 instead
[4.521184] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c2c: 0x03f1 instead
[4.530645] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c30: 0x1000 instead
[4.540107] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not
found at 0x1c34: 0x0006 instead
[4.549567] jffs2: Further such events for this erase block will not be
printed

However, in the above guide, it was set to 0x2000 (8 KiB?) so I tried that,
and get similar "magic bitmask not found" errors. I'm at a loss at how to
figure out the correct eraseblock size here.

I am using rocko branches, 2017.3 for what concerns the kernel/sdk.

Giordon

On Fri, Nov 17, 2017 at 8:10 AM Giordon Stark  wrote:

> Hi Mike,
>
> Thanks -- I was wondering about this, since it's been a struggle to find
> information about this. We do have two gotchas that might affect whether we
> can use SPL or not.
>
> 1) we have a custom FSBL we need to use for the board [custom power-on
> sequence, clocks, etc...] that the engineers wrote
> 2) we do not have a working SD card on the board, a problem with the
> placement process
>
> So this gives me a question or two:
>
> - how do I partition the QSPI without being able to initially boot linux
> on the board using SD Card boot?
> - do I edit my device tree to define the partitions for the kernel to be
> aware of -- and how do I make sure I partition exactly like defined?
>
> I will take a look at meta-topic.
>
> Giordon
>
>
> On Fri, Nov 17, 2017 at 2:01 AM Mike Looijmans 
> wrote:
>
>> Much of the zynq booting information on the Xilinx website focuses on
>> petalinux and the Xilinx SDK and doesn't apply to the Openembedded/Yocto
>> toolflow at all.
>>
>> The boot flow can be mostly the same as any ARM based board, but Xilinx
>> doesn't provide that information anywhere. You can find an example in our
>> repo
>> though, https://github.com/topic-embedded-products/meta-topic which
>> applies to
>> the Topic boards, but this should work with the Xilinx boards as well if
>> you
>> use the appropriate configs and devicetrees.
>>
>> The QSPI boot procedure for the ZynqMP using Yocto/OE should be:
>>
>> Partition the QSPI:
>> - boot.bin (192k)
>> - ATF (128k or whatever your sector size is)
>> - u-boot.bin (768k)
>> - "rootfs"
>>
>> Building u-boot SPL using OE should deliver boot.bi

Re: [meta-xilinx] PMUFW debugging with debug flags

[Giordon Stark]

Hi JF,

No, but I am on rocko so it's got the two different layers under
meta-xilinx and I'm using the meta-xilinx-bsp version. Is meta-xilinx-tools
completely different? The main reason I'm not using meta-xilinx-tools right
now is that my understanding is I need the SDK installed on the machine and
point m-x-t at it, and I'm just trying to get things in a way that doesn't
depend on something external to yocto...

Giordon

On Thu, Jul 19, 2018 at 8:55 AM Jean-Francois Dagenais <
jeff.dagen...@gmail.com> wrote:

> Hi Giordon,
>
> > On Jul 19, 2018, at 8:58 AM, Giordon Stark  wrote:
> >
> > However, when recompiling and re-running -- I do not see extra debug
> information from the PMUFW -- so I'm patching the kernel
> drivers/clk/zynqmp/pll.c to get more information about the PLL hang itself
> in the meantime.
> >
> > Any ideas? Did I do something wrong in enabling the debug flags?
>
> Are you using the meta-xilinx-tools pmu_firmware recipe?
>
> I ask because, coincidently, I am discussing a patch in
> xsctbase:do_configure about cleaning the xsct workspace on do_configure
> start to avoid these kinds of behaviour. See
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-June/003916.html
> and
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-July/003986.html
>
> Turns out I had the manual "rm" in my local repo only, but the point
> remains.
>
> Hope this helps!

-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] PMUFW debugging with debug flags

[Giordon Stark]

Hi all,

I'm trying to debug a PLL hang on a custom board (ultrascale+ chip) that
Xilinx believes is related to the PMUFW. To aid in debugging the issue,
they asked for two flags to be turned on:

https://github.com/kratsg/meta-l1calo/commit/ca4ce190f69f89bc3da4d39bcf32d00329264351#diff-0740188d1d09f1293bb14f19f19be79a



*file: recipes-bsp/pmu-firmware/pmu-firmware_2017.3.bbappend*
# Please enable debug logs in pmufw by defining XPFW_DEBUG_DETAILED and
DEBUG_MODE macros in pmufw source code.
# See http://www.wiki.xilinx.com/PMU+Firmware for more flags.

EXTRA_COMPILER_FLAGS_append = " -DXPFW_DEBUG_DETAILED -DDEBUG_MODE"

However, when recompiling and re-running -- I do not see extra debug
information from the PMUFW -- so I'm patching the kernel
drivers/clk/zynqmp/pll.c to get more information about the PLL hang itself
in the meantime.

Any ideas? Did I do something wrong in enabling the debug flags?

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Patching the zc702-zynq device tree

[Giordon Stark]

Hi,

The device tree for the zc702-zynq is in both the linux-xlnx repository as
well as the u-boot repository. If I want to modify it, e.g. to add a
hard-coded mac-address, or to add additional changes, which one am I
patching?

Giordon


-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] External XADC sources for zc702-zynq7 via device-tree

[Giordon Stark]

Hi all,

Following one of the xilinx forum posts here --
https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-zc706-XADC-Reading-External-Voltages/td-p/593620
--
I wanted to plug in external sources for the xadc to monitor, so I made a
patch like so:

https://github.com/kratsg/meta-l1calo/blob/patch/externalXADC/recipes-bsp/u-boot/files/0001-add-external-xadc-to-device-tree.patch


diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
index 57a7474..8d136af 100644
--- a/arch/arm/dts/zynq-7000.dtsi
+++ b/arch/arm/dts/zynq-7000.dtsi
@@ -76,6 +76,23 @@
  interrupts = <0 7 4>;
  interrupt-parent = <&intc>;
  clocks = <&clkc 12>;
+
+ xlnx,channels {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0{
+ reg = <0>;
+ };
+ channel@1{
+ reg = <1>;
+ };
+ channel@2{
+ reg = <2>;
+ };
+ channel@8{
+ reg = <8>;
+ };
+ };
  };

  can0: can@e0008000 {


which is patched via u-boot-xlnx recipe

SRC_URI_append_zc702-zynq7 +=
"file://0001-add-external-xadc-to-device-tree.patch"

Part of me is a little suspicious that I patch it through u-boot-xlnx
instead of device-tree, but I guess part of that is because the dtsi files
are actually part of upstream u-boot by now...

In any case, a core-image builds just fine, however the kernel doesn't seem
to indicate that it's changed:

root@zc702-zynq7:~# ls /proc/device-tree/amba/adc@f8007100/
clockscompatibleinterrupt-parent  interrupts
name  reg
root@zc702-zynq7:~# ls /sys/devices/soc0/amba/f8007100.adc/iio\:device0/
devin_temp0_raw
 in_voltage0_vccint_scale   in_voltage2_vccbram_raw
in_voltage3_vccpint_scale  in_voltage5_vccoddr_raw
in_voltage6_vrefp_scalename   sampling_frequency
events in_temp0_scale
 in_voltage1_vccaux_raw in_voltage2_vccbram_scale
in_voltage4_vccpaux_rawin_voltage5_vccoddr_scale
in_voltage7_vrefn_raw  of_nodesubsystem
in_temp0_offsetin_voltage0_vccint_raw
 in_voltage1_vccaux_scale   in_voltage3_vccpint_raw
in_voltage4_vccpaux_scale  in_voltage6_vrefp_raw
in_voltage7_vrefn_scalepower  uevent

where I expect to be able to see something like in_voltage8 or something
new -- but I don't. Have I messed up the counting somehow?

Thanks,

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] gator.ko for Mali 4xx -- using a gator_git.bb recipe

[Giordon Stark]

Hi all,

This is documented here (
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0482r/ric1362294970611.html).
I'm curious about what the additional steps are to get a gator.ko
available. From what I understand, it's just a matter of an extra
oe_runmake command inside the '${S}/driver' directory and then installing
the gator.ko file?

Has someone had experience with this? This is for a Mali 400 GPU on the
ZCU102-ZynqMP from Xilinx. The current recipe is here:
https://github.com/kratsg/meta-l1calo/blob/add/glewAndGator/recipes-kernel/gator/gator_git.bb
(I
got this from meta-linaro, but I have issues just including that layer, so
I just copied the short recipe over).

Giordon

-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Yocto fo Pynq Z1?

[Giordon Stark]

I think, off-hand, the PYNQ project provides the bitstream + HDF -- so you
can generate your device tree from that and build a "custom" machine that
matches the PYNQ Z1 board -- but it would be an unofficial one.

I'm still kinda surprised by the entire development of PYNQ without any
seeming reference to using Yocto to rebuild pieces of it. It seems like a
natural fit, but that's my 2 cents.

G

On Tue, Jun 5, 2018 at 4:41 PM Matthew Clark 
wrote:

> Hi, Giordon,
>
> Well, my main thing was to make sure the right kernel config and device
> tree was being pulled into any recipe, so I wanted to start there.  Since
> there there are numerous "zynq" machines in the folder already, I wasn't
> sure if any one would be the best to leverage.
>
> I know I could use the kernel config and device-tree from the Ubuntu build
> provided by Xilinx, but wanted to know if there was more to it than that.
>
> Matt
>
>
>
> On Tue, Jun 5, 2018 at 3:45 PM, Giordon Stark  wrote:
>
>> Hi,
>>
>> My understanding is that having a Python recipe for the PYNQ framework
>> ontop of Vanilla yocto is all that's necessary as it uses the kernel
>> drivers to interface plus numpy for buffering.
>>
>> Is there something special about PYNQ that is needed that can't be done
>> in Yocto?
>>
>> Giordon
>>
>> On Fri, Jun 1, 2018 at 22:10 Manjukumar Harthikote Matha <
>> manju...@xilinx.com> wrote:
>>
>>> Hi Matt,
>>>
>>> > -Original Message-
>>> > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>>> > boun...@yoctoproject.org] On Behalf Of Matthew Clark
>>> > Sent: Friday, June 01, 2018 12:59 PM
>>> > To: meta-xilinx@yoctoproject.org
>>> > Subject: [meta-xilinx] Yocto fo Pynq Z1?
>>> >
>>> > I've got a Pynq Z1 and I'd like to build Yocto on it instead of the
>>> Ubuntu distro.  Is
>>> > there a recipe for that board?  I know it's zynq, but I don't know
>>> which particular
>>> > flavor to use or if I need to custom make a recipe.
>>> >
>>>
>>> You need to make a custom recipe. There is no Yocto support for PYNQ yet
>>>
>>> Thanks,
>>> Manju
>>> --
>>> ___
>>> meta-xilinx mailing list
>>> meta-xilinx@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>>
>> --
>> Giordon Stark
>>
>
> --
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Yocto fo Pynq Z1?

[Giordon Stark]

Hi,

My understanding is that having a Python recipe for the PYNQ framework
ontop of Vanilla yocto is all that's necessary as it uses the kernel
drivers to interface plus numpy for buffering.

Is there something special about PYNQ that is needed that can't be done in
Yocto?

Giordon

On Fri, Jun 1, 2018 at 22:10 Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

> Hi Matt,
>
> > -Original Message-
> > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> > boun...@yoctoproject.org] On Behalf Of Matthew Clark
> > Sent: Friday, June 01, 2018 12:59 PM
> > To: meta-xilinx@yoctoproject.org
> > Subject: [meta-xilinx] Yocto fo Pynq Z1?
> >
> > I've got a Pynq Z1 and I'd like to build Yocto on it instead of the
> Ubuntu distro.  Is
> > there a recipe for that board?  I know it's zynq, but I don't know which
> particular
> > flavor to use or if I need to custom make a recipe.
> >
>
> You need to make a custom recipe. There is no Yocto support for PYNQ yet
>
> Thanks,
> Manju
> --
> ___________
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?

[Giordon Stark]

(resending from right email)

Hi,

I've also seen a ton of issues myself with just getting QSPI working on the
ultrascale Zynq. We've been going back and forth with Xilinx support since
early December trying to get the QSPI on our board working (an example of
some of the changes is here
https://github.com/kratsg/meta-l1calo/pull/15/files ) but there seems to be
some compounding set of issues that more or less makes us unable to
actually get the board to use the QSPi correctly [still working on it...]

Giordon


On Mon, Apr 30, 2018 at 8:28 AM Martin Lund  wrote:

> Yeah, I see a lot of good stuff coming from you and Holden Sandlar trying
> to fix/patch the qspi-nor driver but as you state Xilinx seems to pay
> little attention to this driver. I've also applied your patches.
>
>
> Surprisingly, we have just discovered that if we lower the
> spi-max-frequency from 108 MHz (default in .dts) to e.g. 50 MHz our
> read/write problem goes away?
>
>
> It seems the prebuilt xilinx petalinux images run successfully at 108 MHz
> so it makes me wonder exactly what they are doing differently.
>
>
> Also, running up UBI/UBIFS on the qspi-nor flash with the "has-io-mode"
> flag and at 50 MHz it seems to work fine except when we run ubi-tests
> ("runubitests.sh /dev/ubi0") from mtd-utils we see it crashing when running
> the *_paral tests which are sort of stress tests.
>
>
>
>
>
> --
> *From:* meta-xilinx-boun...@yoctoproject.org <
> meta-xilinx-boun...@yoctoproject.org> on behalf of Mike Looijmans <
> mike.looijm...@topic.nl>
> *Sent:* Sunday, April 29, 2018 5:31:38 PM
> *To:* meta-xilinx@yoctoproject.org
> *Subject:* Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx
> layer for zcu102-zynqmp?
>
> There were quite a few bugs in the QSPI support last year, I've sent
> patches to fix the ones I found on the 'regular' Zynq to Xilinx. Since
> the ZynqMP has a different controller than the Zynq, there may some
> similar leftover bugs in there as well.
>
> The QSPI driver still has not been submitted into Linux mainline, which
> indicates the poor attention the driver has been receiving.
>
> Side note: There's no point running both flash_erase and flashcp. The
> flashcp command will also erase before writing (otherwise, you wouln't
> need the command...). Either use flashcp, or use flash_erase followed by
> dd.
>
> On 25-04-18 09:04, Martin Lund wrote:
> > Hi,
> >
> > Is the qspi-nor flash feature broken in the meta-xilinx layer for
> zcu102-zynqmp ?
> >
> > We've been trying to test and verify the qspi-nor flash feature on a
> ZynqMP zcu102 rev 1.0 development board only to find out that basic
> reading/writing to the qspi-nor flash is failing.
> >
> > We are building and testing with core-image-minimal on latest rocko
> branch (commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the
> following patch/fix added to avoid the zynqmp_clk_get_periphial_rate error
> which prevents the u-boot SPL from booting:
> >
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html
> >
> > This is how we test and see the qspi-flash fail:
> >
> > root@zcu102-zynqmp:~# cat /proc/mtd
> > dev:size   erasesize  name
> > mtd0: 0010 2000 "qspi-fsbl-uboot"
> > mtd1: 0050 2000 "qspi-linux"
> > mtd2: 0002 2000 "qspi-device-tree"
> > mtd3: 005e 2000 "qspi-rootfs"
> >
> > root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0
> > Erasing 8 Kibyte @ 2000 --  0 % complete [  103.966880] random: crng
> init done
> > Erasing 8 Kibyte @ 5de000 -- 100 % complete
> >
> > root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024
> count=4096
> > 4096+0 records in
> > 4096+0 records out
> >
> > root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3
> > Erasing blocks: 512/512 (100%)
> > Writing data: 4096k/4096k (100%)
> > Verifying data: 10k/4096k (0%)File does not seem to match flash data.
> First mismatch at 0x-0x2800
> >
> > Any ideas what might be wrong in the meta-xilinx layer that would make
> the qpsi-nor flash fail like that?
> >
> > Thanks.
> >
> > /Martin
> >
>
>
> --
> Mike Looijmans
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Supported SD cards for Zynq Ultrascale+ chips?

[Giordon Stark]

Update,

We've ordered some other SD cards and see a different error:

mmc0: error -84

Any ideas? We're using rocko.

Giordon

On Mon, Mar 19, 2018 at 9:35 AM Giordon Stark  wrote:

> Hi,
>
> In migrating from pyro to rocko -- the SD card we've been using to boot
> the board is now making the kernel unhappy:
>
> [4.110470] Waiting for root device /dev/mmcblk0p2...
> [4.243284] sdhci-arasan ff17.sdhci: : Timeout for Buffer Read
> Ready inte  rrupt, back to fixed
> sampling clock
> [4.253391] mmc0: tuning execution failed: -5
> [4.257723] mmc0: error -5 whilst initialising SD card
> [4.435286] sdhci-arasan ff17.sdhci: : Timeout for Buffer Read
> Ready inte  rrupt, back to fixed
> sampling clock
> [4.445395] mmc0: tuning execution failed: -5
> [4.449724] mmc0: error -5 whilst initialising SD card
> [4.651284] sdhci-arasan ff17.sdhci: : Timeout for Buffer Read
> Ready inte  rrupt, back to fixed
> sampling clock
> [4.661389] mmc0: tuning execution failed: -5
> [4.665721] mmc0: error -5 whilst initialising SD card
>
> This is an SD card we've flashed before with wic previously and had no
> issues booting. It is an ADATA SDXC, 64gb, speed class 10. Does anyone have
> suggestions on a good card (high speed, 64gb+) that works?
>
> Giordon
>
> --
> Giordon Stark
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Supported SD cards for Zynq Ultrascale+ chips?

[Giordon Stark]

Hi,

In migrating from pyro to rocko -- the SD card we've been using to boot the
board is now making the kernel unhappy:

[4.110470] Waiting for root device /dev/mmcblk0p2...
[4.243284] sdhci-arasan ff17.sdhci: : Timeout for Buffer Read Ready
inte  rrupt, back to fixed sampling
clock
[4.253391] mmc0: tuning execution failed: -5
[4.257723] mmc0: error -5 whilst initialising SD card
[4.435286] sdhci-arasan ff17.sdhci: : Timeout for Buffer Read Ready
inte  rrupt, back to fixed sampling
clock
[4.445395] mmc0: tuning execution failed: -5
[4.449724] mmc0: error -5 whilst initialising SD card
[4.651284] sdhci-arasan ff17.sdhci: : Timeout for Buffer Read Ready
inte  rrupt, back to fixed sampling
clock
[4.661389] mmc0: tuning execution failed: -5
[4.665721] mmc0: error -5 whilst initialising SD card

This is an SD card we've flashed before with wic previously and had no
issues booting. It is an ADATA SDXC, 64gb, speed class 10. Does anyone have
suggestions on a good card (high speed, 64gb+) that works?

Giordon

-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?

[Giordon Stark]

Comments inline.

On Mon, Mar 19, 2018 at 4:18 AM Nathan Rossi  wrote:

> On 19 March 2018 at 01:42, Giordon Stark  wrote:
> > Hi Nathan,
> >
> > On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi 
> wrote:
> >>
> >> On 18 March 2018 at 04:57, Giordon Stark  wrote:
> >> > Hi,
> >> >
> >> > Based on Jorge's suggestion (cc'd), I uncommented my lines in
> >> > device-tree.bbappend to set compatible machine = ".*" for my
> particular
> >> > boards as it is being done upstream... and bitbake seems to be happier
> >> > with
> >> > that, but then I run into this error
> >>
> >> Yes that change was done for rocko. It was done to prevent
> >> expectations around device-tree supporting machines where the user has
> >> not provided the device tree files to build, in order to make it clear
> >> what pieces are needed to build for custom machines.
> >
> >
> > Can you point to the specific change made? It's not clear to me that
> adding
> >
> > COMPATIBLE_MACHINE_my-machine = ".*"
> >
> > actually makes this situation clearer, rather than say
> >
> > COMPATIBLE_MACHINE_my-machine = "my_machine"
>
> The change that made requirement of COMPATIBLE_MACHINE to be set is:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/commit/?id=eb0abe0230
>
>
I see. How is this change affecting the zynqmp boards? I don't see a
bbappends adding COMPATIBLE_MACHINE for them?


> There is not a lot of difference between the two ways of setting
> COMPATIBLE_MACHINE as you have described above.
>
> Just be careful not to use "_" in machine names, or you will hit issues.
>
> >
> > So I went ahead and set SPL_BINARY = "" to clear it out, and updated
> > platform-init but then I got a boot-bin recipe related error as well as
> the
> > fact that platform-init can't find the ps*init files. I guess a lot of
> this
> > is now requiring tighter integration with the SDK which is slightly
> breaking
> > my use case..
>
> I don't think there is any integration between the SDK tooling and the
> platform-init recipe or for that matter the
> virtual/xilinx-platform-init provider. But u-boot-xlnx will _not_
> provide virtual/boot-bin if it does not have the platform-init files,
> though that is intended in your case. You might need to select a
> different provider for virtual/boot-bin if you are using the SDK
> tooling layer and depending on that virtual target.
>
> >
> > I'm currently using the FSBL method at the moment, so I'm doing this via
> > CROPS (virtual machine + automating the build in continuous integration)
> and
> > then taking the bitbake outputs and loading them up into my SDK on a
> > different machine to make the BOOT.bin. Is this not possible anymore with
> > all of these changes and requiring the zcu102-zynqmp.conf? Should I just
> go
> > one step higher and set all of these things myself manually and drop
> > platform-init/boot-bin/spl?
>
> If you are not building your machine exactly like the
> zcu102-zynqmp.conf then you are likely better off copying it and
> modifying it the way you want instead of including it. But looking at
> your layers master branch it appears you have already made that
> change. So I am not sure of the exact question you are asking here?
>

Yes, very observant :) I've been switching things over because I'm now
realizing my (lazy!) days of copying the zcu102-zynqmp.conf is probably
coming to an end... I suspect my problem is that I had to add the
"zcu102-zynqmp" to the machine overrides for when I initially copied things
over, and that caused issues down the line with things like platform-init
and so on -- with all the changes to COMPATIBLE_MACHINE.

G


>
> Regards,
> Nathan
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] wic creation manifest warnings with zynqmp-pmu recipe in rocko?

[Giordon Stark]

Here are two machines I've tried this one where I receive the above
warnings:

https://github.com/kratsg/meta-l1calo/blob/bumpToRocko/conf/machine/gfex-prototype3a.conf

https://github.com/kratsg/meta-l1calo/blob/bumpToRocko/conf/machine/gfex-prototype4.conf


Both of these include my tune-gfex-zynqmp.inc (inspired by how meta-xilinx
does it) here:

https://github.com/kratsg/meta-l1calo/blob/bumpToRocko/conf/machine/include/tune-gfex-zynqmp.inc


This zynqmp tune includes the one from meta-xilinx (tune-zynqmp.inc).

The example image I'm building is here:
https://github.com/kratsg/meta-l1calo/blob/bumpToRocko/recipes-core/images/zynq-base.bb


Giordon

On Sun, Mar 18, 2018 at 12:27 PM Giordon Stark  wrote:

> Hi Manju,
>
> Just running something like bitbake zynq-base which is just an image
> inheriting from core-image plus 2 other python packages I've written (added
> as an install).
>
> I'm still running into lots of issues with my images with the change to
> rocko, so I'm not sure where I'm going wrong...
>
> G
>
> On Sun, Mar 18, 2018 at 12:24 PM Manjukumar Harthikote Matha <
> manju...@xilinx.com> wrote:
>
>>
>>
>> > -Original Message-
>> > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>> > boun...@yoctoproject.org] On Behalf Of Giordon Stark
>> > Sent: Sunday, March 18, 2018 10:20 AM
>> > To: meta-xilinx@yoctoproject.org
>> > Subject: [meta-xilinx] wic creation manifest warnings with zynqmp-pmu
>> recipe in
>> > rocko?
>> >
>> > Hi,
>> >
>> > I'm switching over to rocko, trying to get my images to compile again,
>> and I see
>> > these warnings?
>> >
>> >
>> > WARNING: zynq-base-1.0-r0 do_image_wic: Manifest
>> > /local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-
>> > zynqmp-pmu-gcc-cross-microblazeel.populate_sysroot not found?
>> > WARNING: zynq-base-1.0-r0 do_image_wic: Manifest
>> > /local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-
>> > zynqmp-pmu-binutils-cross-microblazeel.populate_sysroot not found?
>> > WARNING: zynq-base-1.0-r0 do_image_complete: Manifest
>> > /local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-
>> > zynqmp-pmu-gcc-cross-microblazeel.populate_sysroot not found?
>> > WARNING: zynq-base-1.0-r0 do_image_complete: Manifest
>> > /local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-
>> > zynqmp-pmu-binutils-cross-microblazeel.populate_sysroot not found?
>> >
>> > Is this expected? I'm not sure I can safely ignore these, but I'm also
>> not sure these
>> > come from something I did.
>> >
>>
>>
>> Building e-SDK? Or just images?
>>
>> Thanks,
>> Manju
>>
> --
> Giordon Stark
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] wic creation manifest warnings with zynqmp-pmu recipe in rocko?

[Giordon Stark]

Hi Manju,

Just running something like bitbake zynq-base which is just an image
inheriting from core-image plus 2 other python packages I've written (added
as an install).

I'm still running into lots of issues with my images with the change to
rocko, so I'm not sure where I'm going wrong...

G

On Sun, Mar 18, 2018 at 12:24 PM Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

>
>
> > -Original Message-
> > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> > boun...@yoctoproject.org] On Behalf Of Giordon Stark
> > Sent: Sunday, March 18, 2018 10:20 AM
> > To: meta-xilinx@yoctoproject.org
> > Subject: [meta-xilinx] wic creation manifest warnings with zynqmp-pmu
> recipe in
> > rocko?
> >
> > Hi,
> >
> > I'm switching over to rocko, trying to get my images to compile again,
> and I see
> > these warnings?
> >
> >
> > WARNING: zynq-base-1.0-r0 do_image_wic: Manifest
> > /local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-
> > zynqmp-pmu-gcc-cross-microblazeel.populate_sysroot not found?
> > WARNING: zynq-base-1.0-r0 do_image_wic: Manifest
> > /local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-
> > zynqmp-pmu-binutils-cross-microblazeel.populate_sysroot not found?
> > WARNING: zynq-base-1.0-r0 do_image_complete: Manifest
> > /local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-
> > zynqmp-pmu-gcc-cross-microblazeel.populate_sysroot not found?
> > WARNING: zynq-base-1.0-r0 do_image_complete: Manifest
> > /local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-
> > zynqmp-pmu-binutils-cross-microblazeel.populate_sysroot not found?
> >
> > Is this expected? I'm not sure I can safely ignore these, but I'm also
> not sure these
> > come from something I did.
> >
>
>
> Building e-SDK? Or just images?
>
> Thanks,
> Manju
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] wic creation manifest warnings with zynqmp-pmu recipe in rocko?

[Giordon Stark]

Hi,

I'm switching over to rocko, trying to get my images to compile again, and
I see these warnings?

WARNING: zynq-base-1.0-r0 do_image_wic: Manifest
/local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-zynqmp-pmu-gcc-cross-microblazeel.populate_sysroot
not found?
WARNING: zynq-base-1.0-r0 do_image_wic: Manifest
/local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-zynqmp-pmu-binutils-cross-microblazeel.populate_sysroot
not found?
WARNING: zynq-base-1.0-r0 do_image_complete: Manifest
/local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-zynqmp-pmu-gcc-cross-microblazeel.populate_sysroot
not found?
WARNING: zynq-base-1.0-r0 do_image_complete: Manifest
/local/d4/gstark/poky/build/tmp/sstate-control/manifest-x86_64_aarch64-zynqmp-pmu-binutils-cross-microblazeel.populate_sysroot
not found?

Is this expected? I'm not sure I can safely ignore these, but I'm also not
sure these come from something I did.

Thanks,

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?

[Giordon Stark]

Hi Nathan,

On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi  wrote:

> On 18 March 2018 at 04:57, Giordon Stark  wrote:
> > Hi,
> >
> > Based on Jorge's suggestion (cc'd), I uncommented my lines in
> > device-tree.bbappend to set compatible machine = ".*" for my particular
> > boards as it is being done upstream... and bitbake seems to be happier
> with
> > that, but then I run into this error
>
> Yes that change was done for rocko. It was done to prevent
> expectations around device-tree supporting machines where the user has
> not provided the device tree files to build, in order to make it clear
> what pieces are needed to build for custom machines.
>

Can you point to the specific change made? It's not clear to me that adding

COMPATIBLE_MACHINE_my-machine = ".*"

actually makes this situation clearer, rather than say

COMPATIBLE_MACHINE_my-machine = "my_machine"

So I went ahead and set SPL_BINARY = "" to clear it out, and updated
platform-init but then I got a boot-bin recipe related error as well as the
fact that platform-init can't find the ps*init files. I guess a lot of this
is now requiring tighter integration with the SDK which is slightly
breaking my use case..

I'm currently using the FSBL method at the moment, so I'm doing this via
CROPS (virtual machine + automating the build in continuous integration)
and then taking the bitbake outputs and loading them up into my SDK on a
different machine to make the BOOT.bin. Is this not possible anymore with
all of these changes and requiring the zcu102-zynqmp.conf? Should I just go
one step higher and set all of these things myself manually and drop
platform-init/boot-bin/spl?

G


>
> >
> > ERROR: Nothing PROVIDES 'virtual/xilinx-platform-init' (but
> > /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/
> u-boot-xlnx_2017.3.bb
> > DEPENDS on or otherwise requires it)
> > platform-init PROVIDES virtual/xilinx-platform-init but was skipped:
> > incompatible with machine gfex-prototype3a (not in COMPATIBLE_MACHINE)
> > ERROR: Required build target 'zynq-base' has no buildable providers.
> > Missing or unbuildable dependency chain was: ['zynq-base',
> > 'virtual/bootloader', 'virtual/xilinx-platform-init']
> >
> > So I suppose I need to add a platform-init/platform-init.bbappend file
> that
> > overrides the compatible machine again as well...
> >
> > This seems slightly hacky, and maybe indicative that I've done something
> > wrong in defining a machine on top of zcu102-zynqmp somehow... but this
> > worked in pyro, so there must be a change between pyro and rocko... any
> > ideas?
>
> There were some changes to the u-boot spl platform detection logic,
> this may have changed your use case. But if you don't want u-boot SPL
> for zynqmp, don't set SPL_BINARY to boot.bin.
>
> If you do want SPL make sure you are doing one of the following:
>
> * using a defconfig that provides platform init files (e.g.
> xilinx_zynqmp_zcu102_rev1_0_defconfig), u-boot-xlnx had some churn to
> which configs provided platform-init files, check you are using the
> desired one
> * appending to platform-init to include the files in your layer, and
> that platform-init has COMPATIBLE_MACHINE set to match your machine
> * patching u-boot to include the platform init files, and that you are
> adding the defconfig that provides them to the HAS_PLATFORM_INIT
> variable.
>
> Regards,
> Nathan
>
> >
> > Giordon
> >
> >
> >
> > On Sat, Mar 17, 2018 at 1:10 PM Giordon Stark  wrote:
> >>
> >> Hi,
> >>
> >> I've been trying to understand/figure out what changed to break
> something
> >> that was definitely working on pyro -- but it's been hard to trace
> changes
> >> because of the move/restructuring...
> >>
> >> When I re-run bitbake for an image that I've built in pyro just fine
> using
> >> all the same code, I see this error about "Nothing PROVIDES
> 'device-tree' as
> >> seen below.
> >>
> >> This seems to stem from how I tell u-boot about the dtb files that have
> >> been made:
> >>
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc
> >> (DEPENDS_append_... = " device-tree"). Is there a new way of doing it?
> >>
> >> ERROR: Nothing PROVIDES 'device-tree' (but
> >> /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/
> u-boot-xlnx_2017.3.bb
> >> DEPENDS on or otherwise requires it)
> >> 

Re: [meta-xilinx] meta-xilinx layer on Layer Index?

[Giordon Stark]

I see, so does meta-xilinx-contrib get added to this layer indexing too,
since it is a layer? I don't see it, hence my confusion.

G

On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi  wrote:

> On 18 March 2018 at 03:40, Giordon Stark  wrote:
> > Hi,
> >
> > Since the meta-xilinx "layer" is really meta-xilinx-bsp and
>
> The root of the meta-xilinx git repository is not actually a layer. So
> it doesn't have an entry in the layer index.
>
> > meta-xilinx-contrib -- shouldn't this page
> > (
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-xilinx/
> )
> > get updated to represent the change/renaming? It seems a bit confusing
> > otherwise.
>
> I did update it, you will note it has the subdirectory set to
> meta-xilinx-bsp. It however is still labeled as 'meta-xilinx' for a
> couple reasons.
>
> * People wanting 'meta-xilinx' actually want the layer in the
> directory labeled meta-xilinx-bsp
> * meta-xilinx-bsp, whilst a sub-directory still has the layer
> BBFILES_COLLECTIONS named "xilinx"
>
> Regards,
> Nathan
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?

[Giordon Stark]

Hi,

Based on Jorge's suggestion (cc'd), I uncommented my lines in
device-tree.bbappend to set compatible machine = ".*" for my particular
boards as it is being done upstream... and bitbake seems to be happier with
that, but then I run into this error

ERROR: Nothing PROVIDES 'virtual/xilinx-platform-init' (but
/local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/
u-boot-xlnx_2017.3.bb DEPENDS on or otherwise requires it)
platform-init PROVIDES virtual/xilinx-platform-init but was skipped:
incompatible with machine gfex-prototype3a (not in COMPATIBLE_MACHINE)
ERROR: Required build target 'zynq-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['zynq-base',
'virtual/bootloader', 'virtual/xilinx-platform-init']

So I suppose I need to add a platform-init/platform-init.bbappend file that
overrides the compatible machine again as well...

This seems slightly hacky, and maybe indicative that I've done something
wrong in defining a machine on top of zcu102-zynqmp somehow... but this
worked in pyro, so there must be a change between pyro and rocko... any
ideas?

Giordon



On Sat, Mar 17, 2018 at 1:10 PM Giordon Stark  wrote:

> Hi,
>
> I've been trying to understand/figure out what changed to break something
> that was definitely working on pyro -- but it's been hard to trace changes
> because of the move/restructuring...
>
> When I re-run bitbake for an image that I've built in pyro just fine using
> all the same code, I see this error about "Nothing PROVIDES 'device-tree'
> as seen below.
>
> This seems to stem from how I tell u-boot about the dtb files that have
> been made:
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc
>  (DEPENDS_append_...
> = " device-tree"). Is there a new way of doing it?
>
> ERROR: Nothing PROVIDES 'device-tree' (but
> /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/
> u-boot-xlnx_2017.3.bb DEPENDS on or otherwise requires it)
> device-tree was skipped: incompatible with machine gfex-prototype3a (not
> in COMPATIBLE_MACHINE)
> ERROR: Required build target 'zynq-base' has no buildable providers.
> Missing or unbuildable dependency chain was: ['zynq-base',
> 'virtual/bootloader', 'device-tree']
>
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>
> Giordon
> --
> Giordon Stark
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?

[Giordon Stark]

Hi,

I've been trying to understand/figure out what changed to break something
that was definitely working on pyro -- but it's been hard to trace changes
because of the move/restructuring...

When I re-run bitbake for an image that I've built in pyro just fine using
all the same code, I see this error about "Nothing PROVIDES 'device-tree'
as seen below.

This seems to stem from how I tell u-boot about the dtb files that have
been made:
https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc
(DEPENDS_append_...
= " device-tree"). Is there a new way of doing it?

ERROR: Nothing PROVIDES 'device-tree' (but
/local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/
u-boot-xlnx_2017.3.bb DEPENDS on or otherwise requires it)
device-tree was skipped: incompatible with machine gfex-prototype3a (not in
COMPATIBLE_MACHINE)
ERROR: Required build target 'zynq-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['zynq-base',
'virtual/bootloader', 'device-tree']

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] meta-xilinx layer on Layer Index?

[Giordon Stark]

Hi,

Since the meta-xilinx "layer" is really meta-xilinx-bsp and
meta-xilinx-contrib -- shouldn't this page (
http://layers.openembedded.org/layerindex/branch/master/layer/meta-xilinx/)
get updated to represent the change/renaming? It seems a bit confusing
otherwise.

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] OpenSSH problems : sshd will not start up because of keys with invalid format

[Giordon Stark]

Hi Adrian

Indeed, they were empty, so removing them and restarting the ssh daemon
does fix it. It does worry me a little bit that this happened... so I'll
just watch and see if it happens again. Glad I wasn't the only one that hit
this problem..

Giordon

On Mon, Mar 5, 2018 at 10:26 AM  wrote:

> Hi Giordon,
>
> I've seen this before and I'm not sure what causes it - probably a reboot
> during the first sshd attempt to generate the host keys?
>
> As a result you end up with public/private keys of size 0.
> The ssh-keygen -A command will only generate a key pair for missing keys
> (zero sized keys are OK!).
>
> The solution is to delete all keys (*key*), then either restart sshd or
> run ssh-keygen -A.
>
> Regards,
> Adrian
>
>
>
> -meta-xilinx-boun...@yoctoproject.org wrote: -
> To: "meta-xilinx@yoctoproject.org" 
> From: "Giordon Stark"
> Sent by: meta-xilinx-boun...@yoctoproject.org
> Date: 03/05/2018 03:39PM
> Subject: [meta-xilinx] OpenSSH problems : sshd will not start up because
> of keys with invalid format
>
>
> Hi all,
>
> I'm seeing the following:
>
> root@gfex-prototype4:~# /etc/init.d/sshd restart
> key_load_public: invalid format
> Could not load host key: /etc/ssh/ssh_host_rsa_key
> key_load_public: invalid format
> Could not load host key: /etc/ssh/ssh_host_dsa_key
> key_load_public: invalid format
> Could not load host key: /etc/ssh/ssh_host_ecdsa_key
> key_load_public: invalid format
> Could not load host key: /etc/ssh/ssh_host_ed25519_key
> sshd: no hostkeys available -- exiting.
>
> I'm not entirely sure what happened here. I'm using pyro. Is this a known
> issue? I tried regenerating using ssh-keygen and this still doesn't seem to
> work:
>
> root@gfex-prototype4:~# /usr/bin/ssh-keygen -A
> root@gfex-prototype4:~# ls -lavh /etc/ssh/
> drwxr-xr-x2 root root1.0K Feb 27 17:37 .
> drwxr-xr-x   28 root root3.0K Jan  1  1970 ..
> -rw-r--r--1 root root  540.2K Feb 27 17:17 moduli
> -rw-r--r--1 root root1.5K Feb 27 17:17 ssh_config
> -rw---1 root root   0 Feb 27 17:37 ssh_host_dsa_key
> -rw-r--r--1 root root   0 Feb 27 17:37 ssh_host_dsa_key.pub
> -rw---1 root root   0 Feb 27 17:37 ssh_host_ecdsa_key
> -rw-r--r--1 root root   0 Feb 27 17:37
> ssh_host_ecdsa_key.pub
> -rw---1 root root   0 Feb 27 17:37 ssh_host_ed25519_key
> -rw-r--r--1 root root   0 Feb 27 17:37
> ssh_host_ed25519_key.pub
> -rw---1 root root   0 Feb 27 17:37 ssh_host_rsa_key
> -rw-r--r--1 root root   0 Feb 27 17:37 ssh_host_rsa_key.pub
> -rw-r--r--1 root root3.5K Feb 27 17:37 sshd_config
> -rw-r--r--1 root root3.5K Feb 27 17:37 sshd_config_readonly
> root@gfex-prototype4:~# /etc/init.d/sshd restart
> key_load_public: invalid format
> Could not load host key: /etc/ssh/ssh_host_rsa_key
> key_load_public: invalid format
> Could not load host key: /etc/ssh/ssh_host_dsa_key
> key_load_public: invalid format
> Could not load host key: /etc/ssh/ssh_host_ecdsa_key
> key_load_public: invalid format
> Could not load host key: /etc/ssh/ssh_host_ed25519_key
> sshd: no hostkeys available -- exiting.
>
> Thanks,
>
> Giordon
> --
> Giordon Stark
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] OpenSSH problems : sshd will not start up because of keys with invalid format

[Giordon Stark]

Hi all,

I'm seeing the following:

root@gfex-prototype4:~# /etc/init.d/sshd restart
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_rsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_dsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_ed25519_key
sshd: no hostkeys available -- exiting.

I'm not entirely sure what happened here. I'm using pyro. Is this a known
issue? I tried regenerating using ssh-keygen and this still doesn't seem to
work:

root@gfex-prototype4:~# /usr/bin/ssh-keygen -A
root@gfex-prototype4:~# ls -lavh /etc/ssh/
drwxr-xr-x2 root root1.0K Feb 27 17:37 .
drwxr-xr-x   28 root root3.0K Jan  1  1970 ..
-rw-r--r--1 root root  540.2K Feb 27 17:17 moduli
-rw-r--r--1 root root1.5K Feb 27 17:17 ssh_config
-rw---1 root root   0 Feb 27 17:37 ssh_host_dsa_key
-rw-r--r--1 root root   0 Feb 27 17:37 ssh_host_dsa_key.pub
-rw---1 root root   0 Feb 27 17:37 ssh_host_ecdsa_key
-rw-r--r--1 root root   0 Feb 27 17:37
ssh_host_ecdsa_key.pub
-rw---1 root root   0 Feb 27 17:37 ssh_host_ed25519_key
-rw-r--r--1 root root   0 Feb 27 17:37
ssh_host_ed25519_key.pub
-rw---1 root root   0 Feb 27 17:37 ssh_host_rsa_key
-rw-r--r--1 root root   0 Feb 27 17:37 ssh_host_rsa_key.pub
-rw-r--r--1 root root3.5K Feb 27 17:37 sshd_config
-rw-r--r--1 root root3.5K Feb 27 17:37 sshd_config_readonly
root@gfex-prototype4:~# /etc/init.d/sshd restart
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_rsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_dsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
key_load_public: invalid format
Could not load host key: /etc/ssh/ssh_host_ed25519_key
sshd: no hostkeys available -- exiting.

Thanks,

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] wget not working?

[Giordon Stark]

Hi all,

I think there's some SSL issues with wget. Has anyone seen this?

root@gfex-prototype4:~# wget
https://raw.githubusercontent.com/kratsg/gfex_v4a_i2c_scripts/master/configurations.py
Connecting to raw.githubusercontent.com (151.101.200.133:443)
wget: error getting response
root@gfex-prototype4:~# wget google.com
Connecting to google.com (172.217.8.14:80)
Connecting to www.google.com (173.194.205.99:80)
index.html   100%
||
12164   0:00:00 ETA

Unfortunately, since it's a busybox installation, I'm having a hard time
debugging w/ a lack of verbosity options?

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ZynqMP - Multiple ETH - Not detected PHY?

[Giordon Stark]

Hi Sandeep,

We have a new board and we got the OS booted up on it, however, we're
unable to get the second PHY working in the OS (we're not talking about
u-boot anymore). We have both PHY enabled in the design:
https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/device-tree/files/gfex-prototype4/gfex-prototype4.dts#L26-L46


We can see both GEMs working with the LWIP application project that comes
with SDK, but Linux is unable to get `ifup eth1` working (eth0 works very
nicely though).

Are there some extra checks we can do?

Thanks!

Giordon

On Thu, Jan 11, 2018 at 12:39 PM Sandeep Gundlupet Raju 
wrote:

> Hi Giordon,
>
>
>
> Yes you need local mac and phy device-tree property for each GEM.
>
>
>
> We haven’t supported multiple GEM in U-boot. Right now this is planned for
> 2018.1/3.
>
>
>
> If you want to use multiple GEM in linux refer XAPP1305
> http://www.wiki.xilinx.com/PS+and+PL+based+Ethernet+in+Zynq+MPSoC
>
>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* meta-xilinx-boun...@yoctoproject.org [mailto:
> meta-xilinx-boun...@yoctoproject.org] *On Behalf Of *Giordon Stark
> *Sent:* Wednesday, January 10, 2018 1:35 AM
> *To:* Oleg K Dzhimiev 
> *Cc:* meta-xilinx@yoctoproject.org
> *Subject:* Re: [meta-xilinx] ZynqMP - Multiple ETH - Not detected PHY?
>
>
>
> Hi all,
>
>
>
> So I definitely got somewhere, but I think there might be issues with
> u-boot. A patch like this
>
>
>
> +&gem3 {^M
>
> +local-mac-address = [00 0a 35 00 00 01];
>
> +phy-handle = <&phy1>;
>
> +phy1: phy@7 {
>
> +reg = <0x7>;
>
> +ti,rx-internal-delay = <0x8>;
>
> +ti,tx-internal-delay = <0xa>;
>
> +ti,fifo-depth = <0x1>;
>
>  };
>
>  };
>
>
>
> works perfectly to get GEM3 working. This also works if I do it for gem2
> (similar, but with the phy address at 0x4). If I use one or the other,
> u-boot doesn't seem to have a problem picking things up and running with
> it... but if I *enable both* GEM2 and GEM3 in my project (since we will
> require two ETH later), I get errors like
>
>
>
> Xilinx Zynq MP First Stage Boot Loader
>
> Release 2017.2   Dec  5 2017  -  15:52:54
>
> NOTICE:  ATF running on XCZU19EG/silicon v3/RTL5.1 at 0xfffea000, with PMU
> firmware
>
> NOTICE:  BL31: Secure code at 0x0
>
> NOTICE:  BL31: Non secure code at 0x800
>
> NOTICE:  BL31: v1.3(release):7d1a673
>
> NOTICE:  BL31: Built : 14:42:17, Jan  3 2018
>
> PMUFW:  v0.3
>
>
>
>
>
> U-Boot 2017.01 (Jan 09 2018 - 13:37:43 -0600) gFEX Prototype v3 (ZynqMP
> SoC)
>
>
>
> I2C:   ready
>
> DRAM:  16 GiB
>
> EL Level:   EL2
>
> Chip ID:xczu19eg
>
> Using default environment
>
>
>
> In:serial@ff00
>
> Out:   serial@ff00
>
> Err:   serial@ff00
>
> Bootmode: QSPI_MODE
>
> Net:   ZYNQ GEM: ff0d, phyaddr 4, interface rgmii-id
>
> i2c_mux_set: could not set mux: id: 5 chip: 74 channel: 0
>
> I2C EEPROM MAC address read failed
>
>
>
> *Warning: ethernet@ff0d (eth0) using random MAC address -
> 12:92:73:12:c0:41*
>
> *eth0: ethernet@ff0dZYNQ GEM: ff0e, phyaddr 7, interface rgmii-id*
>
> *PHY is not detected*
>
> *GEM PHY init failed*
>
>
>
> Hit any key to stop autoboot:  0
>
> Invalid bus 0 (err=-19)
>
> Failed to initialize SPI flash at 0:0 (error -19)
>
> *ZynqMP> mdio list*
>
> *eth0:*
>
> *4 - Marvell 88E1118R <--> ethernet@ff0d*
>
> *eth1:*
>
> ZynqMP>
>
>
>
> What's strange about this error is that if I enable GEM2 or I enable GEM3
> separately in my project, and change my device tree according, bitbake, and
> then program the flash -- I'm seeing zero problems with the PHY detection.
> It is only when I have *both* PHY enabled that I see a problem. Is this
> an issue with u-boot? The `dhcp` command does work fine in the sense that I
> have a working PHY to send TFTP communications over -- and I haven't booted
> linux yet [and this may not be a problem inside linux, but only inside
> u-boot].
>
>
>
> Thanks,
>
>
>
> Giordon
>
>
>
> eth1:
>
> ZynqMP> dhcp
>
> BOOTP broadcast 1
>
> BOOTP broadcast 2
>
> DHCP client bound to address 192.168.1.123 (279 ms)
>
> *** Warning: no boot file name; using 'C0A8017B.img'
>
> Using ethernet@ff0d device
>
> TFTP from server 0.0.0.0; our IP address is 192.168.1.123; sending through
> gateway 192.168.1.1
>
>
>
>
>
> On Wed, Jan 3, 2018 at 9:29 PM Ol

Re: [meta-xilinx] Cannot load VFS from SDCard partitioned using wic

[Giordon Stark]

Hi all,

Thanks for all the answers.

@Nathan

> Its mounted read only. Check the card, and the preceding log (there
might be information regarding why it was mounted read only).

Which preceding log? I double-checked this on the Linux VM using fdisk and
nothing seemed off. I followed your suggestion to add the 'ro' flag instead
(sdroot0 from zcu102-zynqmp recipe uses rw). We would like to use 'rw' in
the future, but switch to 'ro' makes this work nicely now. This is
obviously a workaround, but not a permanent solution.

@Richard,

If the wic image isn't a problem, it sounds like it's related to the issue
you posted where we need to add a flag to the device tree to disable this
check -- even though we're not using the WP pin in our design? I will check
this.

@Jean-Francois

We've seen this finnickiness with the Zynq-700 series - so I'm glad I'm not
the only one!

> As for manually copying files on the wic generated sdcard image, you
shouldn't have to do this.

We do this right now for two somewhat convoluted(?) reasons.
- we are using the FSBL method, which, unless I'm using meta-xilinx-tools
(part of meta-xilinx now), I need to use the Vivado SDK to generate the
FSBL. In any case, we have a custom power sequence interfacing with an ATCA
shelf manager that requires extra logic in the FSBL right now [injected by
engineers at CERN] so I'm not ready to try and get this portion automated
-- I need to copy the BOOT.bin and system.dtb into the SD card -- but this
isn't too hard since the files exist and the BOOT partition is the active
one as FAT 32, so I can just copy it
- we do not have a Linux machine available capable of running bitbake
(mostly because Xilinx does not work on CC7/SLC6 which are the only ones we
have available) and just a windows.

Your recipe looks great and I'll need to look at this more to understand it
better... Still learning bitbake!

Giordon

On Mon, Feb 26, 2018 at 7:26 AM Jean-Francois Dagenais <
jeff.dagen...@gmail.com> wrote:

>
>
> > On Feb 25, 2018, at 15:34, Giordon Stark  wrote:
> >
> > I used the wic file created to flash an SD card using dd. I also copied
> system.dtb and created a BOOT.bin to copy into the first (boot) partition.
> However, the SD card seems readable, and shows the right partitions.. but I
> still cannot get the kernel to load the FS from it?
> >
>
> Hi Giordon,
>
> In my experience on our board, the SD is quite finicky. For me it boiled
> down to certain SD cards that will work and others that don't. Of course
> there may be underlying issue, but we have not pinpointed them just yet. As
> a workaround, we simply avoid the "bad" SD cards. Maybe try lower speed
> cards.
>
> As for manually copying files on the wic generated sdcard image, you
> shouldn't have to do this.
>
> Here's a wic file I created for this purpose (there's another pretty
> similar in poky, we use this because we need extra space in the first
> partition) :
>
> $ cat ./scripts/lib/wic/canned-wks/zynq-wic-sdcard.wks
> # short-description: Create SD card image with a boot partition
> # long-description: Creates a partitioned SD card image. Boot files
> # are located in the first vfat partition.
>
> # !! the partition alignment must match that found in test files
> # we add 6MB to the boot partition to allow devs to copy a fpga.bin for
> example
> part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat
> --label ZBOOT --active --align 4096 --extra-space 6
> part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs
> --align 4096 --extra-space
>
>
> Of course, I use my patch for boot.bin as a normal recipe:
> https://www.mail-archive.com/meta-xilinx@yoctoproject.org/msg02179.html
>
> Here's my slightly different version of the file:
> SUMMARY = "Generates boot.bin using bootgen tool"
> DESCRIPTION = "Manages task dependencies and creation of boot.bin. Use the
> \
> BIF_PARTITION_xyz global variables and flags to determine what makes it
> into \
> the image."
>
> LICENSE = "BSD"
>
> include machine-xilinx-${SOC_FAMILY}.inc
>
> inherit xsct-tc deploy
>
> PROVIDES = "virtual/boot-bin"
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> BIF_FILE_PATH ?= "${B}/bootgen.bif"
> BIF_FILE_PATH = "${WORKDIR}/bootgen.bif"
>
> # this recipe is almost like an image recipe, taken from image.bbclass:
> inherit nopackages
> deltask do_fetch
> deltask do_unpack
> deltask do_patch
> do_install[noexec] = "1"
>
> def create_bif(config, attrflags, attrimage, common_attr, biffd, d):
> import re, os
> for cfg in config:
> if cfg not in attrflags and 

[meta-xilinx] Cannot load VFS from SDCard partitioned using wic

[Giordon Stark]

Hi all, I'm using a zynqmp 102 chip:

I used the wic file created to flash an SD card using dd. I also copied
system.dtb and created a BOOT.bin to copy into the first (boot) partition.
However, the SD card seems readable, and shows the right partitions.. but I
still cannot get the kernel to load the FS from it?

Any ideas?

[6.983061] Waiting for root device /dev/mmcblk0p2...
[7.244076] mmc0: new high speed SDXC card at address 59b4
[7.249846] mmcblk0: mmc0:59b4 SD58.9 GiB (ro)
[7.255864]  mmcblk0: p1 p2
[7.341815] VFS: Cannot open root device "mmcblk0p2" or
unknown-block(179,2): error -30
[7.349751] Please append a correct "root=" boot option; here are the
available partitions:
[7.358115] 0100   65536 ram0 [7.361627]  (driver?)
[7.363996] 0101   65536 ram1 [7.367529]  (driver?)
[7.369880] 0102   65536 ram2 [7.373446]  (driver?)
[7.375782] 0103   65536 ram3 [7.379334]  (driver?)
[7.381697] 0104   65536 ram4 [7.385236]  (driver?)
[7.387587] 0105   65536 ram5 [7.391139]  (driver?)
[7.393503] 0106   65536 ram6 [7.397041]  (driver?)
[7.399392] 0107   65536 ram7 [7.402956]  (driver?)
[7.405295] 0108   65536 ram8 [7.408846]  (driver?)
[7.411196] 0109   65536 ram9 [7.414762]  (driver?)
[7.417100] 010a   65536 ram10 [7.420738]  (driver?)
[7.423100] 010b   65536 ram11 [7.426727]  (driver?)
[7.429078] 010c   65536 ram12 [7.432727]  (driver?)
[7.435067] 010d   65536 ram13 [7.438706]  (driver?)
[7.441056] 010e   65536 ram14 [7.444706]  (driver?)
[7.447046] 010f   65536 ram15 [7.450684]  (driver?)
[7.453051] b30061766656 mmcblk0 [7.456848]  driver: mmcblk
[7.459632]   b301   31159 mmcblk0p1 22568d5b-01[7.464767]
[7.466227]   b302  161078 mmcblk0p2 22568d5b-02[7.471344]
[7.472837] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(179,2)
[7.481257] CPU: 3 PID: 1 Comm: swapper/0 Not tainted
4.9.0-xilinx-v2017.1 #1
[7.488364] Hardware name: xlnx,zynqmp (DT)
[7.492528] Call trace:
[7.494965] [] dump_backtrace+0x0/0x198
[7.500345] [] show_stack+0x14/0x20
[7.505379] [] dump_stack+0x90/0xb0
[7.510414] [] panic+0x110/0x258
[7.515188] [] mount_block_root+0x198/0x270
[7.520916] [] mount_root+0x11c/0x134
[7.526123] [] prepare_namespace+0x170/0x1b8
[7.531939] [] kernel_init_freeable+0x1c0/0x1e0
[7.538016] [] kernel_init+0x10/0x100
[7.543223] [] ret_from_fork+0x10/0x50
[7.548516] SMP: stopping secondary CPUs
[7.585970] Kernel Offset: disabled
[7.589380] Memory Limit: none
[7.592425] ---[ end Kernel panic - not syncing: VFS: Unable to mount
root fs on unknown-block(179,2)

-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Yocto inside docker

[Giordon Stark]

Thanks Tim, Peter -- this looks great.

@Peter, I didn't see anything about docker in the yocto manual - can you
link me where it was mentioned?

Giordon

On Tue, Feb 20, 2018 at 12:28 PM Tim Orling  wrote:

> Documentation on how to use the CROPS docker containers on Linux, Mac and
> Windows can be found here:
> https://github.com/crops/docker-win-mac-docs/wiki
>
> On Tue, Feb 20, 2018 at 8:50 AM, Peter Smith  wrote:
>
>> Hi, I have used the "official" Yocto project crops containers without
>> issue. You can find them here : https://github.com/crops/. There is some
>> material about using them in the Yocto rocko manual.
>>
>> Best Regards
>> Peter
>>
>> On 20 February 2018 at 16:12, Giordon Stark  wrote:
>>
>>> Hi all,
>>>
>>> I found a docker image which looks to work for yocto builds here (
>>> https://hub.docker.com/r/gmacario/build-yocto/) like so:
>>>
>>> docker run -ti --rm gmacario/build-yocto
>>>
>>> and then cloning poky and the other layers and running bitbake. However,
>>> what works on my ubuntu machine seems to be failing in this docker image on
>>> the unpack step for a recipe (see below).
>>>
>>> Has anyone seen this or has an idea why it's failing? I ran it by hand
>>> manually, and I don't have issues.
>>>
>>> Giordon
>>>
>>> ERROR: linux-libc-headers-4.10-r0 do_unpack: Unpack failure for URL: '
>>> http://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.10.tar.xz'. Unpack
>>> command
>>> PATH="/home/build/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/build/openembedded-core/scripts:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot/usr/bin/crossscripts:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/usr/sbin:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/usr/bin:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/sbin:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/bin:/home/build/poky/bitbake/bin:/home/build/poky/build/tmp/hosttools"
>>> xz -dc /home/build/poky/build/downloads/linux-4.10.tar.xz | tar x
>>> --no-same-owner -f - failed with return value 2
>>> ERROR: linux-libc-headers-4.10-r0 do_unpack: Function failed:
>>> base_do_unpack
>>> ERROR: Logfile of failure stored in:
>>> /home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/temp/log.do_unpack.4320
>>> ERROR: Task
>>> (/home/build/openembedded-core/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb:do_unpack)
>>> failed with exit code '1'
>>> NOTE: Tasks Summary: Attempted 278 tasks of which 256 didn't need to be
>>> rerun and 1 failed.
>>>
>>> Summary: 1 task failed:
>>>
>>> /home/build/openembedded-core/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb:
>>> do_unpack
>>> Summary: There was 1 WARNING message shown.
>>> Summary: There were 2 ERROR messages shown, returning a non-zero exit
>>> code.
>>>
>>> --
>>> Giordon Stark
>>>
>>> --
>>> ___
>>> meta-xilinx mailing list
>>> meta-xilinx@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>>
>>>
>>
>> --
>> ___
>> meta-xilinx mailing list
>> meta-xilinx@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>
>>
> --
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Using wic to generate sd-image and writing it correctly

[Giordon Stark]

Hi Jean-François,

The script looks formatted weird in my email, but how is this script run or
where? Is it part of bitbake, or separately? Do you use the wic output
file, etc...?

Giordon

On Tue, Feb 20, 2018 at 3:25 PM Jean-François Dagenais <
jeff.dagen...@gmail.com> wrote:

>
> On Feb 19, 2018, at 10:21, Giordon Stark  wrote:
>
> Mac), I see the two partitions (great!) but the Linux partition only takes
> up 150MB instead of the expected rest of the SD card. Is there a way to
> resize that partition? Is this just not possible, or should I be writing a
> custom wks that defines the size of the second partition? Where should I
> start?
>
>
> Hi Giordon
>
> We use a helper script to perform the raw write, then partition expansion.
> Her’s an extract:
>
>
>
> if $IS_SD_CARD; then
> printWarning "adjusting sdcard's partitions"
> set +e
> command="sudo partprobe /dev/$DEVICE"
> echo "$command"; $command
> sudo udevadm settle
> command="sudo e2fsck -f /dev/${DEVICE}2"
> echo "$command"; $command
> command="sudo parted /dev/${DEVICE} resizepart 2 '100%'"
> echo "$command"; $command
> sudo udevadm settle
> command="sudo resize2fs /dev/${DEVICE}2"
> echo "$command"; $command
> set -e
>
> sync
> fi
>
> Hope it helps.
>
> --
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Yocto inside docker

[Giordon Stark]

Hi all,

I found a docker image which looks to work for yocto builds here (
https://hub.docker.com/r/gmacario/build-yocto/) like so:

docker run -ti --rm gmacario/build-yocto

and then cloning poky and the other layers and running bitbake. However,
what works on my ubuntu machine seems to be failing in this docker image on
the unpack step for a recipe (see below).

Has anyone seen this or has an idea why it's failing? I ran it by hand
manually, and I don't have issues.

Giordon

ERROR: linux-libc-headers-4.10-r0 do_unpack: Unpack failure for URL: '
http://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.10.tar.xz'. Unpack
command
PATH="/home/build/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/build/openembedded-core/scripts:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot/usr/bin/crossscripts:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/usr/sbin:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/usr/bin:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/sbin:/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/recipe-sysroot-native/bin:/home/build/poky/bitbake/bin:/home/build/poky/build/tmp/hosttools"
xz -dc /home/build/poky/build/downloads/linux-4.10.tar.xz | tar x
--no-same-owner -f - failed with return value 2
ERROR: linux-libc-headers-4.10-r0 do_unpack: Function failed: base_do_unpack
ERROR: Logfile of failure stored in:
/home/build/poky/build/tmp/work/aarch64-poky-linux/linux-libc-headers/4.10-r0/temp/log.do_unpack.4320
ERROR: Task
(/home/build/openembedded-core/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb:do_unpack)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 278 tasks of which 256 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:

/home/build/openembedded-core/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb:
do_unpack
Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Using wic to generate sd-image and writing it correctly

[Giordon Stark]

Hi all,

Do you know how to get the filesystem partition to auto-expand to the rest
of the disk space? I followed some of the instructions here:
https://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#creating-wic-images-oe


using `dd` to flash the SD card that I have. Looking at it from Disk
Utility (on Mac), I see the two partitions (great!) but the Linux partition
only takes up 150MB instead of the expected rest of the SD card. Is there a
way to resize that partition? Is this just not possible, or should I be
writing a custom wks that defines the size of the second partition? Where
should I start?

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Patching u-boot by adding custom defconfig files

[Giordon Stark]

Update, it seems a

bitbake -c cleanall u-boot-xlnx
bitbake zynq-base # my image

worked just fine here. Thanks for the suggestion @Oleg!

G

On Fri, Feb 16, 2018 at 5:06 PM Giordon Stark  wrote:

> Hi all,
>
> I managed to get somewhere, but u-boot is now broken (but not clear how).
> Log file: https://gist.github.com/aebae13e9054472e6c584cef6eb80912
>
> I refactored my bbappend to look like this:
> https://github.com/kratsg/meta-l1calo/blob/appendFiles/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bbappend
>  .
> Specifically, to add these lines instead:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI_append += "file://machine.h"
> SRC_URI_append += "file://defconfig"
>
> do_copy_configs () {
> cp ${WORKDIR}/defconfig ${S}/configs/${MACHINE}_defconfig
> cp ${WORKDIR}/machine.h ${S}/include/configs/${MACHINE}.h
> }
>
> do_patch_append() {
> bb.build.exec_func('do_copy_configs', d)
> }
>
> the SRC_URI_append was to get the files/${MACHINE}/machine.h and
> files/${MACHINE}/defconfig copied over correctly. This could probably be
> renamed to include the machine in the name of the file itself to handle
> conflicts later.. unless there's a better option?
>
> Any ideas? Note that at this point, it seems like the files are getting
> copied over correctly, so not sure why u-boot is complaining...
>
> G
>
> On Fri, Feb 16, 2018 at 4:05 PM Giordon Stark  wrote:
>
>> Hi Oleg,
>>
>> How can I do this with overrides correctly? I have 3 different machines
>> and each have their own config, etc... are you just suggesting I copy *all*
>> the appends/defconfigs and not do any overrides?
>>
>> G
>>
>> On Fri, Feb 16, 2018 at 2:37 PM Oleg K Dzhimiev  wrote:
>>
>>> Hi,
>>>
>>> You could replace patches with the files then (to
>>> u-boot-xlnx_2017.1.bbappend) add do_patch_append(){...} in which you do
>>> the copying, something like this:
>>>
>>>> do_patch_append(){
>>>>   cp ${WORKDIR}/file1 ${S}/configs/
>>>>
>>>   cp ${WORKDIR}/file2 ${S}/includes/
>>>
>>> }
>>>
>>>
>>> Regards,
>>> Oleg
>>>
>> --
>> Giordon Stark
>>
> --
> Giordon Stark
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Patching u-boot by adding custom defconfig files

[Giordon Stark]

Hi all,

I managed to get somewhere, but u-boot is now broken (but not clear how).
Log file: https://gist.github.com/aebae13e9054472e6c584cef6eb80912

I refactored my bbappend to look like this:
https://github.com/kratsg/meta-l1calo/blob/appendFiles/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bbappend
.
Specifically, to add these lines instead:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append += "file://machine.h"
SRC_URI_append += "file://defconfig"

do_copy_configs () {
cp ${WORKDIR}/defconfig ${S}/configs/${MACHINE}_defconfig
cp ${WORKDIR}/machine.h ${S}/include/configs/${MACHINE}.h
}

do_patch_append() {
bb.build.exec_func('do_copy_configs', d)
}

the SRC_URI_append was to get the files/${MACHINE}/machine.h and
files/${MACHINE}/defconfig copied over correctly. This could probably be
renamed to include the machine in the name of the file itself to handle
conflicts later.. unless there's a better option?

Any ideas? Note that at this point, it seems like the files are getting
copied over correctly, so not sure why u-boot is complaining...

G

On Fri, Feb 16, 2018 at 4:05 PM Giordon Stark  wrote:

> Hi Oleg,
>
> How can I do this with overrides correctly? I have 3 different machines
> and each have their own config, etc... are you just suggesting I copy *all*
> the appends/defconfigs and not do any overrides?
>
> G
>
> On Fri, Feb 16, 2018 at 2:37 PM Oleg K Dzhimiev  wrote:
>
>> Hi,
>>
>> You could replace patches with the files then (to
>> u-boot-xlnx_2017.1.bbappend) add do_patch_append(){...} in which you do
>> the copying, something like this:
>>
>>> do_patch_append(){
>>>   cp ${WORKDIR}/file1 ${S}/configs/
>>>
>>   cp ${WORKDIR}/file2 ${S}/includes/
>>
>> }
>>
>>
>> Regards,
>> Oleg
>>
> --
> Giordon Stark
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Patching u-boot by adding custom defconfig files

[Giordon Stark]

Hi Oleg,

How can I do this with overrides correctly? I have 3 different machines and
each have their own config, etc... are you just suggesting I copy *all* the
appends/defconfigs and not do any overrides?

G

On Fri, Feb 16, 2018 at 2:37 PM Oleg K Dzhimiev  wrote:

> Hi,
>
> You could replace patches with the files then (to
> u-boot-xlnx_2017.1.bbappend) add do_patch_append(){...} in which you do
> the copying, something like this:
>
>> do_patch_append(){
>>   cp ${WORKDIR}/file1 ${S}/configs/
>>
>   cp ${WORKDIR}/file2 ${S}/includes/
>
> }
>
>
> Regards,
> Oleg
>
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Patching u-boot by adding custom defconfig files

[Giordon Stark]

Hi guys,

Thanks a lot for previous help. I'm wondering how you're supposed to go
about adding the header file and defconfig for u-boot to compile from for a
custom board. Specifically, I do this right now by adding patch files

https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bbappend


but this is somewhat a pain to manage since if I want to edit or change
things, I have to re-update the patch. It would make a lot more sense to
just append these files in SRC_URI correctly, and have u-boot pick them up.
Is there an example, or how should I do this?

Thanks,

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] QSPI Flash partitioning example on custom board?

[Giordon Stark]

Hi,

I have a custom device tree (and defconfig) where I've defined the
partitioning in my device tree, but I'm unable to get the kernel to
recognize the flash (but u-boot finds it just find with `sf probe 1:0`)

Is there a working example I can follow or suggestions on what to try?
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ramdisk format for booti command in u-boot

[Giordon Stark]

Hi Sandeep,

So I don't have `mmc` in u-boot at all. Here's my attempt at trying to do
it by setting root=/dev/mtd3 where that was supposedly pointing to the QSPI
flash partition I made with the rootfs in it:
https://gist.github.com/kratsg/33dd03d49d6c8580587410160f79243a

&qspi {
flash0: flash@0 {
compatible = "micron,mt25qu02g";
reg = <0x0>;
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <5000>;
partition@qspi-fsbl-uboot {
  label = "qspi-fsbl-uboot";
  reg = <0x0 0x200>;
};
partition@qspi-linux {
  label = "qspi-linux";
  reg = <0x200 0x200>;
};
partition@qspi-device-tree {
  label = "qspi-device-tree";
  reg = <0x400 0x200>;
};
partition@qspi-rootfs {
  label = "qspi-rootfs";
  reg = <0x600 0x200>;
};
partition@qspi-bitstream {
  label = "qspi-bitstream";
  reg = <0x800 0x200>;
};
};
};

I'm not sure why I'm struggling so much with this part and I can't find
anything I'm doing wrong based on the various guides and posts, but it
seems like the partitions in the QSPI aren't being created as I expected.
Posts/guides like:

-
https://forums.xilinx.com/t5/Embedded-Linux/QSPI-FLASH-file-system-mount-error/td-p/759963

-
https://forums.xilinx.com/t5/Embedded-Linux/Booting-Linux-PL-bitstream-from-Zynq-QSPI/td-p/521617

- http://www.wiki.xilinx.com/Zynq+QSPI+Driver
- http://www.wiki.xilinx.com/Zynq+UltraScale+MPSoC+Non+Secure+Boot

Thanks,

Giordon

On Sat, Jan 13, 2018 at 12:09 AM Sandeep Gundlupet Raju 
wrote:

> Hi Giordon,
>
>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* meta-xilinx-boun...@yoctoproject.org [mailto:
> meta-xilinx-boun...@yoctoproject.org] *On Behalf Of *Giordon Stark
> *Sent:* Wednesday, January 10, 2018 9:48 AM
> *To:* meta-xilinx@yoctoproject.org
> *Subject:* [meta-xilinx] ramdisk format for booti command in u-boot
>
>
>
> Hi all,
>
>
>
> Initially, I tried the bootm command, and found the Image format to be
> incorrect.. so then I switched to the booti command, and I get this:
>
>
> > booti 0x20 0x700 0x100
>
> Bad Linux ARM64 Image magic!
>
>
>
>
> I do something like the following to set things up:
>
>
>
> > setenv ip no
>
> > setenv autoload no
>
> > setenv serverip 192.168.1.100
>
> > dhcp
>
> > tftpboot 0x20 Image
>
> > tftpboot 0x700 zynq-base-gfex-prototype3.tar.gz
>
> > tftpboot 0x100 gfex-prototype3.dtb
>
>
>
> Three questions:
>
>
>
> 1) Is there a different image format I should be using? If so, what is it?
>
> 2) are the addresses here arbitrary?
>
> 3) if I run without the initrd (passing '-' as the second parameter
> instead), it gets to a point where it cannot open a root device (we have no
> working SD card):
> https://gist.github.com/kratsg/b5630a23aa3b71161da833fcad07eaaf - how to
> fix this? Having `bootargs=boot=ram0` or something similar did not work.
>
>
>
> Try similar to this command.
>
> # mmc dev 0 && mmcinfo && load mmc 0:1 0x8 Image.bin && load mmc 0:1
> 0x400 system.dtb && load mmc 0:1 0x600 rootfs.cpio.gz && booti
> 0x8 - 0x400
>
>
>
> Thanks,
>
>
>
> Giordon
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ramdisk format for booti command in u-boot

[Giordon Stark]

Hi Sandeep,

So for my board - we have no SD card (hence the mmc won't work). My way of
getting files is to do the following:

- Vivado to program the flash with boot.bin that contains u-boot
- u-boot to communicate and transfer files using TFTP

I have tried both mtd3 and mtdblock3 to no avail. It doesn't seem like my
QSPI is getting partitioned at all - how do you get that partitioning set
up?

ZynqMP> printenv partition
## Error: "partition" not defined
ZynqMP> printenv mtdids
## Error: "mtdids" not defined
ZynqMP> printenv mtdparts
## Error: "mtdparts" not defined
ZynqMP> mtdparts
mtdids not defined, no default present
ZynqMP>


On Sat, Jan 13, 2018 at 12:39 AM Sandeep Gundlupet Raju 
wrote:

> Hi Giordon,
>
>
>
> I have some steps tested in 2017.1 with JFFS2 you can use this as
> reference. I used SD card to load the images to RAM and then program it.
>
>
>
> -
>
> BOOT.bin:
>
> -
>
> ZynqMP> fatload mmc 0 0x1000 qspi_BOOT.bin
>
> ZynqMP> sf probe 0 0 0
>
> ZynqMP> sf erase 0x0 0x1E0
>
> ZynqMP> sf write 0x1000 0x0 ${filesize}
>
>
>
> --
>
> For Image:
>
> --
>
> ZynqMP> fatload mmc 0 0x1000 Image.bin
>
> ZynqMP> sf erase 0x1E4 0xF0
>
> ZynqMP> sf write 0x1000 0x1E4 ${filesize}
>
>
>
> 
>
> For DTB:
>
> 
>
> ZynqMP> fatload mmc 0 0x1000 system.dtb
>
> ZynqMP> sf erase 0x2d4 0x2
>
> ZynqMP> sf write 0x1000 0x2d4 ${filesize}
>
>
>
> ---
>
> For RootFS:
>
> ---
>
> ZynqMP> fatload mmc 0 0x1000 rootfs.jffs2
>
> ZynqMP> sf erase 0x2d6 0x6F0000
>
> ZynqMP> sf write 0x1000 0x2d6 ${filesize}
>
>
>
> ZynqMP> setenv qspiboot "setenv bootargs earlycon clk_ignore_unused
> root=/dev/mtdblock3 rw rootwait rootfstype=jffs2"
>
> ZynqMP> saveenv
>
> ZynqMP> run qspiboot
>
>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* Giordon Stark [mailto:gst...@cern.ch]
> *Sent:* Friday, January 12, 2018 4:20 PM
> *To:* Sandeep Gundlupet Raju 
> *Cc:* meta-xilinx@yoctoproject.org
> *Subject:* Re: [meta-xilinx] ramdisk format for booti command in u-boot
>
>
>
> Hi Sandeep,
>
>
>
> So I don't have `mmc` in u-boot at all. Here's my attempt at trying to do
> it by setting root=/dev/mtd3 where that was supposedly pointing to the QSPI
> flash partition I made with the rootfs in it:
> https://gist.github.com/kratsg/33dd03d49d6c8580587410160f79243a
>
>
>
> &qspi {
>
> flash0: flash@0 {
>
> compatible = "micron,mt25qu02g";
>
> reg = <0x0>;
>
> #address-cells = <1>;
>
> #size-cells = <1>;
>
> spi-max-frequency = <5000>;
>
> partition@qspi-fsbl-uboot {
>
>   label = "qspi-fsbl-uboot";
>
>   reg = <0x0 0x200>;
>
> };
>
> partition@qspi-linux {
>
>   label = "qspi-linux";
>
>   reg = <0x200 0x200>;
>
> };
>
> partition@qspi-device-tree {
>
>   label = "qspi-device-tree";
>
>   reg = <0x400 0x200>;
>
> };
>
> partition@qspi-rootfs {
>
>   label = "qspi-rootfs";
>
>   reg = <0x600 0x200>;
>
> };
>
> partition@qspi-bitstream {
>
>   label = "qspi-bitstream";
>
>   reg = <0x800 0x200>;
>
> };
>
> };
>
> };
>
>
>
> I'm not sure why I'm struggling so much with this part and I can't find
> anything I'm doing wrong based on the various guides and posts, but it
> seems like the partitions in the QSPI aren't being created as I expected.
> Posts/guides like:
>
>
>
> -
> https://forums.xilinx.com/t5/Embedded-Linux/QSPI-FLASH-file-system-mount-error/td-p/759963
>
>
> -
> https://forums.xilinx.com/t5/Embedded-Linux/Booting-Linux-PL-bitstream-from-Zynq-QSPI/td-p/521617
>
>
> - http://www.wiki.xilinx.com/Zynq+QSPI+Driver
>
> - http://www.wiki.xilinx.com/Zynq+UltraScale+MPSoC+Non+Secure+Boot
>
>
>
> Thanks,
>
>
>
> Giordon
>
>
>
> On Sat, Jan 13, 2018 at 12:09 AM Sandeep Gundlupet Raju <
> sande...@xilinx.com> wrote:
>
> Hi Giordon,
>
>
>
> *Thanks,*
>
> 

Re: [meta-xilinx] ramdisk format for booti command in u-boot

[Giordon Stark]

Hi,

Just a quick update since I think I can answer part of my question.

1) the image format is indeed correct.

Lord Stark:~/gfex-prototype3$ hexdump -n64 -C Image
  4d 5a 00 91 ff 7f 2e 14  00 00 08 00 00 00 00 00
|MZ..|
0010  00 70 d3 00 00 00 00 00  0a 00 00 00 00 00 00 00
|.p..|
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
||
0030  00 00 00 00 00 00 00 00  41 52 4d 64 40 00 00 00  |ARMd@
...|
0040

I compared this with
http://elixir.free-electrons.com/linux/latest/source/Documentation/arm64/booting.txt
and
this looks correctly built.

2) I'm not sure, but I think the addresses are slightly arbitrary with some
caveats that there's enough space such that booting the kernel doesn't
override the location of these things in memory - at least until such a
time I persist it by writing to the SPI or something more permanent

3) I'm not sure what's going on here. I suspect it's related to SPI flash
issues that I need to work out. I'm not clear on how to get the kernel to
boot from a filesystem that is in my SPI flash. Any pointers on this would
be nice.

Giordon

On Wed, Jan 10, 2018 at 6:22 PM Giordon Stark  wrote:

> Hi all,
>
> Initially, I tried the bootm command, and found the Image format to be
> incorrect.. so then I switched to the booti command, and I get this:
>
> > booti 0x20 0x700 0x100
> Bad Linux ARM64 Image magic!
>
>
> I do something like the following to set things up:
>
> > setenv ip no
> > setenv autoload no
> > setenv serverip 192.168.1.100
> > dhcp
> > tftpboot 0x20 Image
> > tftpboot 0x700 zynq-base-gfex-prototype3.tar.gz
> > tftpboot 0x100 gfex-prototype3.dtb
>
> Three questions:
>
> 1) Is there a different image format I should be using? If so, what is it?
> 2) are the addresses here arbitrary?
> 3) if I run without the initrd (passing '-' as the second parameter
> instead), it gets to a point where it cannot open a root device (we have no
> working SD card):
> https://gist.github.com/kratsg/b5630a23aa3b71161da833fcad07eaaf - how to
> fix this? Having `bootargs=boot=ram0` or something similar did not work.
>
> Thanks,
>
> Giordon
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ZynqMP - Multiple ETH - Not detected PHY?

[Giordon Stark]

Hi Sandeep,

Thanks for the reply. I suspected this might be the case, but I really
couldn't find anything on Xilinx forums / googling. It's good to hear that
this is planned for 2018.1/3 - do you have a ticket I can subscribe to for
updates or how will this be announced? I assume this requires modifications
to u-boot-xlnx.

Giordon

On Thu, Jan 11, 2018 at 7:39 PM Sandeep Gundlupet Raju 
wrote:

> Hi Giordon,
>
>
>
> Yes you need local mac and phy device-tree property for each GEM.
>
>
>
> We haven’t supported multiple GEM in U-boot. Right now this is planned for
> 2018.1/3.
>
>
>
> If you want to use multiple GEM in linux refer XAPP1305
> http://www.wiki.xilinx.com/PS+and+PL+based+Ethernet+in+Zynq+MPSoC
>
>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* meta-xilinx-boun...@yoctoproject.org [mailto:
> meta-xilinx-boun...@yoctoproject.org] *On Behalf Of *Giordon Stark
> *Sent:* Wednesday, January 10, 2018 1:35 AM
> *To:* Oleg K Dzhimiev 
> *Cc:* meta-xilinx@yoctoproject.org
> *Subject:* Re: [meta-xilinx] ZynqMP - Multiple ETH - Not detected PHY?
>
>
>
> Hi all,
>
>
>
> So I definitely got somewhere, but I think there might be issues with
> u-boot. A patch like this
>
>
>
> +&gem3 {^M
>
> +local-mac-address = [00 0a 35 00 00 01];
>
> +phy-handle = <&phy1>;
>
> +phy1: phy@7 {
>
> +reg = <0x7>;
>
> +ti,rx-internal-delay = <0x8>;
>
> +ti,tx-internal-delay = <0xa>;
>
> +ti,fifo-depth = <0x1>;
>
>  };
>
>  };
>
>
>
> works perfectly to get GEM3 working. This also works if I do it for gem2
> (similar, but with the phy address at 0x4). If I use one or the other,
> u-boot doesn't seem to have a problem picking things up and running with
> it... but if I *enable both* GEM2 and GEM3 in my project (since we will
> require two ETH later), I get errors like
>
>
>
> Xilinx Zynq MP First Stage Boot Loader
>
> Release 2017.2   Dec  5 2017  -  15:52:54
>
> NOTICE:  ATF running on XCZU19EG/silicon v3/RTL5.1 at 0xfffea000, with PMU
> firmware
>
> NOTICE:  BL31: Secure code at 0x0
>
> NOTICE:  BL31: Non secure code at 0x800
>
> NOTICE:  BL31: v1.3(release):7d1a673
>
> NOTICE:  BL31: Built : 14:42:17, Jan  3 2018
>
> PMUFW:  v0.3
>
>
>
>
>
> U-Boot 2017.01 (Jan 09 2018 - 13:37:43 -0600) gFEX Prototype v3 (ZynqMP
> SoC)
>
>
>
> I2C:   ready
>
> DRAM:  16 GiB
>
> EL Level:   EL2
>
> Chip ID:xczu19eg
>
> Using default environment
>
>
>
> In:serial@ff00
>
> Out:   serial@ff00
>
> Err:   serial@ff00
>
> Bootmode: QSPI_MODE
>
> Net:   ZYNQ GEM: ff0d, phyaddr 4, interface rgmii-id
>
> i2c_mux_set: could not set mux: id: 5 chip: 74 channel: 0
>
> I2C EEPROM MAC address read failed
>
>
>
> *Warning: ethernet@ff0d (eth0) using random MAC address -
> 12:92:73:12:c0:41*
>
> *eth0: ethernet@ff0dZYNQ GEM: ff0e, phyaddr 7, interface rgmii-id*
>
> *PHY is not detected*
>
> *GEM PHY init failed*
>
>
>
> Hit any key to stop autoboot:  0
>
> Invalid bus 0 (err=-19)
>
> Failed to initialize SPI flash at 0:0 (error -19)
>
> *ZynqMP> mdio list*
>
> *eth0:*
>
> *4 - Marvell 88E1118R <--> ethernet@ff0d*
>
> *eth1:*
>
> ZynqMP>
>
>
>
> What's strange about this error is that if I enable GEM2 or I enable GEM3
> separately in my project, and change my device tree according, bitbake, and
> then program the flash -- I'm seeing zero problems with the PHY detection.
> It is only when I have *both* PHY enabled that I see a problem. Is this
> an issue with u-boot? The `dhcp` command does work fine in the sense that I
> have a working PHY to send TFTP communications over -- and I haven't booted
> linux yet [and this may not be a problem inside linux, but only inside
> u-boot].
>
>
>
> Thanks,
>
>
>
> Giordon
>
>
>
> eth1:
>
> ZynqMP> dhcp
>
> BOOTP broadcast 1
>
> BOOTP broadcast 2
>
> DHCP client bound to address 192.168.1.123 (279 ms)
>
> *** Warning: no boot file name; using 'C0A8017B.img'
>
> Using ethernet@ff0d device
>
> TFTP from server 0.0.0.0; our IP address is 192.168.1.123; sending through
> gateway 192.168.1.1
>
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] ramdisk format for booti command in u-boot

[Giordon Stark]

Hi all,

Initially, I tried the bootm command, and found the Image format to be
incorrect.. so then I switched to the booti command, and I get this:

> booti 0x20 0x700 0x100
Bad Linux ARM64 Image magic!


I do something like the following to set things up:

> setenv ip no
> setenv autoload no
> setenv serverip 192.168.1.100
> dhcp
> tftpboot 0x20 Image
> tftpboot 0x700 zynq-base-gfex-prototype3.tar.gz
> tftpboot 0x100 gfex-prototype3.dtb

Three questions:

1) Is there a different image format I should be using? If so, what is it?
2) are the addresses here arbitrary?
3) if I run without the initrd (passing '-' as the second parameter
instead), it gets to a point where it cannot open a root device (we have no
working SD card):
https://gist.github.com/kratsg/b5630a23aa3b71161da833fcad07eaaf - how to
fix this? Having `bootargs=boot=ram0` or something similar did not work.

Thanks,

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] ramdisk format for booti command in u-boot

[Giordon Stark]

Hi all,

Initially, I tried the bootm command, and found the Image format to be
incorrect.. so then I switched to the booti command, and I get this:

> booti 0x20 0x700 0x100
Bad Linux ARM64 Image magic!


I do something like the following to set things up:

> setenv ip no
> setenv autoload no
> setenv serverip 192.168.1.100
> dhcp
> tftpboot 0x20 Image
> tftpboot 0x700 zynq-base-gfex-prototype3.tar.gz
> tftpboot 0x100 gfex-prototype3.dtb

Three questions:

1) Is there a different image format I should be using? If so, what is it?
2) are the addresses here arbitrary?
3) if I run without the initrd (passing '-' as the second parameter
instead), it gets to a point where it cannot open a root device (we have no
working SD card):
https://gist.github.com/kratsg/b5630a23aa3b71161da833fcad07eaaf - how to
fix this? Having `bootargs=boot=ram0` or something similar did not work.

Thanks,

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ZynqMP - Multiple ETH - Not detected PHY?

[Giordon Stark]

Hi all,

So I definitely got somewhere, but I think there might be issues with
u-boot. A patch like this

+&gem3 {^M
+local-mac-address = [00 0a 35 00 00 01];
+phy-handle = <&phy1>;
+phy1: phy@7 {
+reg = <0x7>;
+ti,rx-internal-delay = <0x8>;
+ti,tx-internal-delay = <0xa>;
+ti,fifo-depth = <0x1>;
 };
 };

works perfectly to get GEM3 working. This also works if I do it for gem2
(similar, but with the phy address at 0x4). If I use one or the other,
u-boot doesn't seem to have a problem picking things up and running with
it... but if I *enable both* GEM2 and GEM3 in my project (since we will
require two ETH later), I get errors like

Xilinx Zynq MP First Stage Boot Loader
Release 2017.2   Dec  5 2017  -  15:52:54
NOTICE:  ATF running on XCZU19EG/silicon v3/RTL5.1 at 0xfffea000, with PMU
firmware
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x800
NOTICE:  BL31: v1.3(release):7d1a673
NOTICE:  BL31: Built : 14:42:17, Jan  3 2018
PMUFW:  v0.3


U-Boot 2017.01 (Jan 09 2018 - 13:37:43 -0600) gFEX Prototype v3 (ZynqMP SoC)

I2C:   ready
DRAM:  16 GiB
EL Level:   EL2
Chip ID:xczu19eg
Using default environment

In:serial@ff00
Out:   serial@ff00
Err:   serial@ff00
Bootmode: QSPI_MODE
Net:   ZYNQ GEM: ff0d, phyaddr 4, interface rgmii-id
i2c_mux_set: could not set mux: id: 5 chip: 74 channel: 0
I2C EEPROM MAC address read failed

*Warning: ethernet@ff0d (eth0) using random MAC address -
12:92:73:12:c0:41*
*eth0: ethernet@ff0dZYNQ GEM: ff0e, phyaddr 7, interface rgmii-id*
*PHY is not detected*
*GEM PHY init failed*

Hit any key to stop autoboot:  0
Invalid bus 0 (err=-19)
Failed to initialize SPI flash at 0:0 (error -19)
*ZynqMP> mdio list*
*eth0:*
*4 - Marvell 88E1118R <--> ethernet@ff0d*
*eth1:*
ZynqMP>

What's strange about this error is that if I enable GEM2 or I enable GEM3
separately in my project, and change my device tree according, bitbake, and
then program the flash -- I'm seeing zero problems with the PHY detection.
It is only when I have *both* PHY enabled that I see a problem. Is this an
issue with u-boot? The `dhcp` command does work fine in the sense that I
have a working PHY to send TFTP communications over -- and I haven't booted
linux yet [and this may not be a problem inside linux, but only inside
u-boot].

Thanks,

Giordon

eth1:
ZynqMP> dhcp
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.123 (279 ms)
*** Warning: no boot file name; using 'C0A8017B.img'
Using ethernet@ff0d device
TFTP from server 0.0.0.0; our IP address is 192.168.1.123; sending through
gateway 192.168.1.1


On Wed, Jan 3, 2018 at 9:29 PM Oleg K Dzhimiev  wrote:

> Hi,
>
> I had this problem with the older Zynq7 series board
>> https://github.com/kratsg/meta-l1calo/commit/940fa27aa6c9a456ccca7ec60351c26287f9f671
>>  and
>> this was the patch to get the PHY working.
>
> If that patch does not work. Try changing:
>
>> compatible = "marvell,88e1116r";
>
> to
>
>> compatible = "ethernet-phy-ieee802.3-c22";
>
>
> Also, see Documentation/devicetree/bindings/net/phy.txt
> 
> Example: zynq-parallella.dts
> 
>
> Regards,
> Oleg
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] ZynqMP - Multiple ETH - Not detected PHY?

[Giordon Stark]

Hi,

Still making progress on this chip here -- I managed to get uboot working
(with some probably unrelated errors to fix):
https://gist.github.com/kratsg/432a0c7ff4b348ea24f6960c2b140055

I'm currently trying to get the TFTP sever working, but we have:

gem2: ethernet@ff0d
gem3: ethernet@ff0e

For us, gem2 is currently disconnected from MDIO (open) and gem3 is
currently connected... however, eth0 -> gem2 and seems to be discoverable
(PHY?) but eth1 -> gem3 is not.

I suspect this is a problem where the device tree doesn't specify the mdio (
https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/device-tree/files/gfex-prototype3/gfex-prototype3.dts).
I had this problem with the older Zynq7 series board
https://github.com/kratsg/meta-l1calo/commit/940fa27aa6c9a456ccca7ec60351c26287f9f671
and
this was the patch to get the PHY working. Is the auto-generated device
tree still doesn't seem to work out of the box for ethernet if that's the
case?

Thanks,

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

After realizing even the core-image-minimal wouldn't build either - I just
went ahead and recloned my repositories and things worked! Here's the image
deploy listing:
https://gist.github.com/kratsg/e1a30a1cf2c32fffb75925cd4468050f

Should I be worried that the zynqmp-zcu102.dtb file is still being made? I
suppose that's probably for the qemu and my image inherits from
zynqmp-zcu102 (lazily) and I should fix that? How would I confirm that
u-boot was built with the right device tree?

Giordon

On Wed, Jan 3, 2018 at 8:19 AM Giordon Stark  wrote:

> Hi Nathan,
>
> Thanks! This seems to have let u-boot work successfully. I am indeed using
> pyro (I guess rocko is just a bit newer and I will update when I get this
> working). I think I'm almost there, but now i'm getting an error that
> doesn't make sense to me:
> https://gist.github.com/kratsg/3ce79f7d4bd0b786db203c0e54b5202f
>
> ERROR: zynq-base-1.0-r0 do_rootfs: Could not invoke dnf.
>
> These are my current layers:
>
> layer path  priority
> ==
> meta  /local/d4/gstark/poky/meta5
> meta-poky /local/d4/gstark/poky/meta-poky   5
> meta-yocto-bsp/local/d4/gstark/poky/meta-yocto-bsp  5
> meta-xilinx   /local/d4/gstark/meta-xilinx  5
> meta-oe   /local/d4/gstark/meta-openembedded/meta-oe  6
> meta-python   /local/d4/gstark/meta-openembedded/meta-python  7
> meta-l1calo   /local/d4/gstark/meta-l1calo  7
>
> I'm somewhat confused since it's complaining about packages I can bitbake
> normally and I also see recipes for them:
>
> $ bitbake -s | grep python-ironman
> python-ironman :0.2.13-r0
>
> $ bitbake -s | grep devmem2
> devmem2   :1.0-r7
>
> $ bitbake -s | grep packagegroup-core-ssh-openssh
> packagegroup-core-ssh-openssh :1.0-r1
>
> However, I'm definitely unable to find these:
>
> No package locale-base-en-us available.
> No package locale-base-en-gb available.
> No package run-postinsts available.
>
> So I wonder what happened. Here is the image I'm trying to build:
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/images/zynq-base.bb
>
>
> Giordon
>
> On Wed, Jan 3, 2018 at 12:41 AM Nathan Rossi 
> wrote:
>
>> On 3 January 2018 at 12:34, Giordon Stark  wrote:
>> > Thanks! This makes a lot more sense now. I'm definitely getting close.
>> Here
>> > is the log file:
>> > https://gist.github.com/kratsg/7b2e9059d675c96081e461640f4006d3
>> >
>> > Using Nathan's suggestions + Manju's suggestions, I see that the *.dtb
>> is
>> > built and referenced correctly:
>> >
>> > | NOTE: make -j 24 CROSS_COMPILE=aarch64-poky-linux-
>> > CC=aarch64-poky-linux-gcc
>> >
>> --sysroot=/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot
>> > V=1 HOSTCC=gcc
>> >
>> -isystem/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/usr/include
>> > -O2 -pipe
>> >
>> -L/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/usr/lib
>> >
>> -L/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/lib
>> >
>> -Wl,-rpath-link,/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/usr/lib
>> >
>> -Wl,-rpath-link,/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/lib
>> >
>> -Wl,-rpath,/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/usr/lib
>> >
>> -Wl,-rpath,/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/lib
>> > -Wl,-O1
>> >
>> EXT_DTB=/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot/boot/devicetree/gfex-prototype3.

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Nathan,

Thanks! This seems to have let u-boot work successfully. I am indeed using
pyro (I guess rocko is just a bit newer and I will update when I get this
working). I think I'm almost there, but now i'm getting an error that
doesn't make sense to me:
https://gist.github.com/kratsg/3ce79f7d4bd0b786db203c0e54b5202f

ERROR: zynq-base-1.0-r0 do_rootfs: Could not invoke dnf.

These are my current layers:

layer path  priority
==
meta  /local/d4/gstark/poky/meta5
meta-poky /local/d4/gstark/poky/meta-poky   5
meta-yocto-bsp/local/d4/gstark/poky/meta-yocto-bsp  5
meta-xilinx   /local/d4/gstark/meta-xilinx  5
meta-oe   /local/d4/gstark/meta-openembedded/meta-oe  6
meta-python   /local/d4/gstark/meta-openembedded/meta-python  7
meta-l1calo   /local/d4/gstark/meta-l1calo  7

I'm somewhat confused since it's complaining about packages I can bitbake
normally and I also see recipes for them:

$ bitbake -s | grep python-ironman
python-ironman :0.2.13-r0

$ bitbake -s | grep devmem2
devmem2   :1.0-r7

$ bitbake -s | grep packagegroup-core-ssh-openssh
packagegroup-core-ssh-openssh :1.0-r1

However, I'm definitely unable to find these:

No package locale-base-en-us available.
No package locale-base-en-gb available.
No package run-postinsts available.

So I wonder what happened. Here is the image I'm trying to build:
https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/images/zynq-base.bb


Giordon

On Wed, Jan 3, 2018 at 12:41 AM Nathan Rossi  wrote:

> On 3 January 2018 at 12:34, Giordon Stark  wrote:
> > Thanks! This makes a lot more sense now. I'm definitely getting close.
> Here
> > is the log file:
> > https://gist.github.com/kratsg/7b2e9059d675c96081e461640f4006d3
> >
> > Using Nathan's suggestions + Manju's suggestions, I see that the *.dtb is
> > built and referenced correctly:
> >
> > | NOTE: make -j 24 CROSS_COMPILE=aarch64-poky-linux-
> > CC=aarch64-poky-linux-gcc
> >
> --sysroot=/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot
> > V=1 HOSTCC=gcc
> >
> -isystem/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/usr/include
> > -O2 -pipe
> >
> -L/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/usr/lib
> >
> -L/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/lib
> >
> -Wl,-rpath-link,/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/usr/lib
> >
> -Wl,-rpath-link,/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/lib
> >
> -Wl,-rpath,/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/usr/lib
> >
> -Wl,-rpath,/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot-native/lib
> > -Wl,-O1
> >
> EXT_DTB=/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot/boot/devicetree/gfex-prototype3.dtb
> > dtb_depends= -C
> >
> /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/git
> >
> O=/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/build
> > gfex-prototype3_defconfig
> >
> > However, it seems like the *.dtb cannot be found:
> >
> > | Device Tree Source is not correctly specified.
> > | Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> > | or build with 'DEVICE_TREE=' argument
> >
> > when I `ls` the above directory:
> >
> > kratsg@dc:/local/d4/gstark/meta-l1calo/recipes-bsp/device-tree$ ls
> >
> /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/u-boot-xlnx/v2017.01-xilinx-v2017.1+gitAUTOINC+92e3dd638b-r0/recipe-sysroot
> > total 20K
> > drwxr

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

r--  1 kratsg atlas  866 Jan  2 16:43 system-top.dts.pp

and installed here

kratsg@dc:/local/d4/gstark/poky/build$ ls
/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-tree/1.0-r0/image/boot/devicetree/
total 48K
drwxr-xr-x 2 kratsg atlas 4.0K Jan  2 16:43 .
drwxr-xr-x 3 kratsg atlas 4.0K Jan  2 16:43 ..
-rw-r--r-- 1 kratsg atlas  39K Jan  2 16:43 system-top.dtb

I just don't see it being installed to the right location that is expected
from
https://github.com/nathanrossi/meta-xilinx/blob/60193934fc1c7717a71f272370aaad1bfeb118b4/recipes-bsp/u-boot/u-boot_2017.09.bbappend


*EXT_DTB=${RECIPE_SYSROOT}/boot/devicetree/${MACHINE}.dtb*

So how do I install the dtb correctly from device-tree to get picked up by
u-boot-xlnx?

Giordon

On Tue, Jan 2, 2018 at 8:40 PM Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

>
>
> > -Original Message-
> > From: Giordon Stark [mailto:kra...@gmail.com]
> > Sent: Tuesday, January 02, 2018 2:36 PM
> > To: Manjukumar Harthikote Matha 
> > Cc: Nathan Rossi ; Tang, Shaochun  >;
> > meta-xilinx@yoctoproject.org
> > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL +
> u-boot?
> >
> > Hi Manju,
> >
> >
> > On Tue, Jan 2, 2018 at 5:30 PM Manjukumar Harthikote Matha
> > mailto:manju...@xilinx.com> > wrote:
> >
> >
> >   Hi,
> >
> >   > -Original Message-
> >   > From: Giordon Stark [mailto:kra...@gmail.com
> > <mailto:kra...@gmail.com> ]
> >   > Sent: Tuesday, January 02, 2018 2:15 PM
> >   > To: Nathan Rossi  > <mailto:nat...@nathanrossi.com> >
> >   > Cc: Manjukumar Harthikote Matha  > <mailto:manju...@xilinx.com> >; Tang, Shaochun
> >   > mailto:st...@bnl.gov> >; meta-
> > xil...@yoctoproject.org <mailto:meta-xilinx@yoctoproject.org>
> >   > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using
> FSBL +
> > u-boot?
> >   >
> >   > Hi,
> >   >
> >   > I've followed along with everything so far. I'm finding that
> device-tree.bb
> > <http://device-tree.bb>
> >   > <http://device-tree.bb>  is not very happy with my initial
> structure of
> > device-tree
> >   > files. Here (
> https://github.com/kratsg/meta-l1calo/tree/master/recipes-
> > bsp/device-
> >   > tree) you can see my device-tree.bbappend and the associated
> files.
> >   >
> >   > I was hoping to structure my device tree sources this way,
> because I will
> > eventually
> >   > want
> >   >
> >   > boards/gfex
> >   > boards/jfex
> >   > boards/...
> >   >
> >   > in the future, and each group has their own set of versioned
> codes. What
> > I'm seeing
> >   > now, when I run `bitbake device-tree` is this:
> >   >
> >   > ERROR: device-tree-1.0-r0 do_compile: Function failed:
> do_compile (log
> > file is
> >   > located at
> /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-
> >   > linux/device-tree/1.0-r0/temp/log.do_compile.29239)
> >   > ERROR: Logfile of failure stored in:
> >   > /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-
> > linux/device-
> >   > tree/1.0-r0/temp/log.do_compile.29239
> >   > Log data follows:
> >   > | DEBUG: Executing shell function do_compile
> >   > | gcc: error:
> >   > | /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-
> > linux/device
> >   > | -tree/1.0-r0/*.dts: No such file or directory
> >   > | gcc: warning: ‘-x assembler-with-cpp’ after last input file
> has no
> >   > | effect
> >   > | gcc: fatal error: no input files
> >   > | compilation terminated.
> >   > | WARNING: /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-
> > poky-
> >   > linux/device-tree/1.0-r0/temp/run.do_compile.29239:1 exit 1 from
> 'gcc -
> > E -
> >   > nostdinc -Ulinux -x assembler-with-cpp -
> >   > I/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-
> > linux/device-
> >   > tree/1.0-r0 -I/local/d4/gstark/poky/build/tmp/work-shared/gfex-
> >   > prototype3/kernel-source/arch/arm64/boot/dts -
> >   >
> I/local/d4/gstark/poky/build/tmp/work-shared/gfex-prototype3/kernel-
> >   > source/arch/arm64/boot/dts/include -
> > I/local/d4/gstark/poky/

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Manju,


On Tue, Jan 2, 2018 at 5:30 PM Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

> Hi,
>
> > -Original Message-
> > From: Giordon Stark [mailto:kra...@gmail.com]
> > Sent: Tuesday, January 02, 2018 2:15 PM
> > To: Nathan Rossi 
> > Cc: Manjukumar Harthikote Matha ; Tang, Shaochun
> > ; meta-xilinx@yoctoproject.org
> > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL +
> u-boot?
> >
> > Hi,
> >
> > I've followed along with everything so far. I'm finding that
> device-tree.bb
> > <http://device-tree.bb>  is not very happy with my initial structure of
> device-tree
> > files. Here (
> https://github.com/kratsg/meta-l1calo/tree/master/recipes-bsp/device-
> > tree) you can see my device-tree.bbappend and the associated files.
> >
> > I was hoping to structure my device tree sources this way, because I
> will eventually
> > want
> >
> > boards/gfex
> > boards/jfex
> > boards/...
> >
> > in the future, and each group has their own set of versioned codes. What
> I'm seeing
> > now, when I run `bitbake device-tree` is this:
> >
> > ERROR: device-tree-1.0-r0 do_compile: Function failed: do_compile (log
> file is
> > located at /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-
> > linux/device-tree/1.0-r0/temp/log.do_compile.29239)
> > ERROR: Logfile of failure stored in:
> > /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-
> > tree/1.0-r0/temp/log.do_compile.29239
> > Log data follows:
> > | DEBUG: Executing shell function do_compile
> > | gcc: error:
> > | /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device
> > | -tree/1.0-r0/*.dts: No such file or directory
> > | gcc: warning: ‘-x assembler-with-cpp’ after last input file has no
> > | effect
> > | gcc: fatal error: no input files
> > | compilation terminated.
> > | WARNING: /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-
> > linux/device-tree/1.0-r0/temp/run.do_compile.29239:1 exit 1 from 'gcc -E
> -
> > nostdinc -Ulinux -x assembler-with-cpp -
> > I/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-
> > tree/1.0-r0 -I/local/d4/gstark/poky/build/tmp/work-shared/gfex-
> > prototype3/kernel-source/arch/arm64/boot/dts -
> > I/local/d4/gstark/poky/build/tmp/work-shared/gfex-prototype3/kernel-
> > source/arch/arm64/boot/dts/include
> -I/local/d4/gstark/poky/build/tmp/work-
> > shared/gfex-prototype3/kernel-source/arch/arm64/boot/dts/xilinx -o
> `basename
> > ${DTS_FILE}`.pp ${DTS_FILE}'
> > | ERROR: Function failed: do_compile (log file is located at
> > | /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device
> > | -tree/1.0-r0/temp/log.do_compile.29239)
> > ERROR: Task (/local/d4/gstark/meta-xilinx/recipes-bsp/device-tree/device-
> > tree.bb:do_compile) failed with exit code '1'
> > NOTE: Tasks Summary: Attempted 504 tasks of which 502 didn't need to be
> rerun
> > and 1 failed.
> >
> > and when I look in this directory referenced:
> >
> > kratsg@dc:/local/d4/gstark/poky/build$ ls
> > /local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-
> > tree/1.0-r0/
> > total 40K
> > drwxr-xr-x 9 kratsg atlas 4.0K Jan  2 14:58 .
> > drwxr-xr-x 3 kratsg atlas 4.0K Jan  2 14:50 ..
> > drwxr-xr-x 2 kratsg atlas 4.0K Jan  2 14:58 build
> > -rw-r--r-- 1 kratsg atlas   33 Jan  2 14:58 configure.sstate
> > drwxr-xr-x 3 kratsg atlas 4.0K Jan  2 14:50 gfex drwxr-xr-x 3 kratsg
> atlas 4.0K Jan  2
> > 14:52 license-destdir drwxr-xr-x 2 kratsg atlas 4.0K Jan  2 14:50
> patches drwxr-xr-x
> > 2 kratsg atlas 4.0K Jan  2 14:58 recipe-sysroot drwxr-xr-x 6 kratsg
> atlas 4.0K Jan  2
> > 14:50 recipe-sysroot-native drwxr-xr-x 2 kratsg atlas 4.0K Jan  2 16:06
> temp
> >
> > it seems that it expects everything to be at the top-level... that I
> need some sort of
> > system-top.dts to make device-tree.bb <http://device-tree.bb>  happy.
> Am I doing
> > this wrong? Is my structure wrong or is device-tree.bb <
> http://device-tree.bb>  a bit
> > more pickier than I realized? I also updated u-boot to add the extra
> OEMAKE
> > commands (
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-
> > boot/u-boot-xlnx_2017.1.bbappend) so if those look wrong, let me know.
> >
>
> The S is set to workdir
>
> https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb#L22
>
>

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi,

I've followed along with everything so far. I'm finding that device-tree.bb
is not very happy with my initial structure of device-tree files. Here (
https://github.com/kratsg/meta-l1calo/tree/master/recipes-bsp/device-tree)
you can see my device-tree.bbappend and the associated files.

I was hoping to structure my device tree sources this way, because I will
eventually want

boards/gfex
boards/jfex
boards/...

in the future, and each group has their own set of versioned codes. What
I'm seeing now, when I run `bitbake device-tree` is this:

ERROR: device-tree-1.0-r0 do_compile: Function failed: do_compile (log file
is located at
/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-tree/1.0-r0/temp/log.do_compile.29239)
ERROR: Logfile of failure stored in:
/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-tree/1.0-r0/temp/log.do_compile.29239
Log data follows:
| DEBUG: Executing shell function do_compile
| gcc: error:
/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-tree/1.0-r0/*.dts:
No such file or directory
| gcc: warning: ‘-x assembler-with-cpp’ after last input file has no effect
| gcc: fatal error: no input files
| compilation terminated.
| WARNING:
/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-tree/1.0-r0/temp/run.do_compile.29239:1
exit 1 from 'gcc -E -nostdinc -Ulinux -x assembler-with-cpp
-I/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-tree/1.0-r0
-I/local/d4/gstark/poky/build/tmp/work-shared/gfex-prototype3/kernel-source/arch/arm64/boot/dts
-I/local/d4/gstark/poky/build/tmp/work-shared/gfex-prototype3/kernel-source/arch/arm64/boot/dts/include
-I/local/d4/gstark/poky/build/tmp/work-shared/gfex-prototype3/kernel-source/arch/arm64/boot/dts/xilinx
-o `basename ${DTS_FILE}`.pp ${DTS_FILE}'
| ERROR: Function failed: do_compile (log file is located at
/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-tree/1.0-r0/temp/log.do_compile.29239)
ERROR: Task
(/local/d4/gstark/meta-xilinx/recipes-bsp/device-tree/device-tree.bb:do_compile)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 504 tasks of which 502 didn't need to be
rerun and 1 failed.

and when I look in this directory referenced:

kratsg@dc:/local/d4/gstark/poky/build$ ls
/local/d4/gstark/poky/build/tmp/work/gfex_prototype3-poky-linux/device-tree/1.0-r0/
total 40K
drwxr-xr-x 9 kratsg atlas 4.0K Jan  2 14:58 .
drwxr-xr-x 3 kratsg atlas 4.0K Jan  2 14:50 ..
drwxr-xr-x 2 kratsg atlas 4.0K Jan  2 14:58 build
-rw-r--r-- 1 kratsg atlas   33 Jan  2 14:58 configure.sstate
drwxr-xr-x 3 kratsg atlas 4.0K Jan  2 14:50 gfex
drwxr-xr-x 3 kratsg atlas 4.0K Jan  2 14:52 license-destdir
drwxr-xr-x 2 kratsg atlas 4.0K Jan  2 14:50 patches
drwxr-xr-x 2 kratsg atlas 4.0K Jan  2 14:58 recipe-sysroot
drwxr-xr-x 6 kratsg atlas 4.0K Jan  2 14:50 recipe-sysroot-native
drwxr-xr-x 2 kratsg atlas 4.0K Jan  2 16:06 temp

it seems that it expects everything to be at the top-level... that I need
some sort of system-top.dts to make device-tree.bb happy. Am I doing this
wrong? Is my structure wrong or is device-tree.bb a bit more pickier than I
realized? I also updated u-boot to add the extra OEMAKE commands (
https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bbappend)
so if those look wrong, let me know.

Thanks!

Giordon

On Wed, Dec 13, 2017 at 10:22 AM Nathan Rossi 
wrote:

> On 14 December 2017 at 00:53, Giordon Stark  wrote:
> > Hi Nathan, replies inline.
> >
> > On Wed, Dec 13, 2017 at 8:33 AM Nathan Rossi 
> wrote:
> >>
> >> Hi Giordon,
> >>
> >> Not exactly sure what state your configuration is in, so I'm just
> >> going to cover some things you should check to ensure you have it all
> >> setup such that it should result in u-boot running with the correct
> >> device tree, and using said device trees memory information.
> >>
> >> 1.
> >>
> >> CONFIG_SYS_SDRAM_BASE=0x
> >> CONFIG_SYS_SDRAM_SIZE=0x8000
> >>
> >> These override the use of device tree memory sizes, make sure you have
> >> them set correctly or not set at all.
> >
> >
> > I have tried to override by setting these - and they had no effect. I
> > definitely know my patch was working since I saw the "dirty u-boot"
> version.
> > So I'm not sure why it didn't work.
> >
> >>
> >>
> >> 2. The layer you link to uses MACHINE_DEVICETREE, this variable is no
> >> longer used in meta-xilinx, make sure you are actually building what
> >> you expect from a device tree perspective either with the
> >> device-tree.bb recipe or otherwise. Also note this variable never did
> >> anything with regards to u-boot.

[meta-xilinx] linux-xlnx_2017.1.bb:do_kernel_version_sanity_check failure?

[Giordon Stark]

Hi all,

See log here (
https://gist.github.com/kratsg/ab4db49aaabb1a234164962325dcf029).

I just got back from the holidays and simply attempted to re-run my bitbake
command after making some changes to switch from MACHINE_DEVICETREE to
SRC_URI (with a device-tree.bbappend that I wrote).

However, I seem to be getting some errors. Should I attempt to completely
clean my shared state and try again from scratch or should I update to a
more recent meta-xilinx that includes the reorganization done recently?

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Nathan, replies inline.

On Wed, Dec 13, 2017 at 8:33 AM Nathan Rossi  wrote:

> Hi Giordon,
>
> Not exactly sure what state your configuration is in, so I'm just
> going to cover some things you should check to ensure you have it all
> setup such that it should result in u-boot running with the correct
> device tree, and using said device trees memory information.
>
> 1.
>
> CONFIG_SYS_SDRAM_BASE=0x
> CONFIG_SYS_SDRAM_SIZE=0x8000
>
> These override the use of device tree memory sizes, make sure you have
> them set correctly or not set at all.
>

I have tried to override by setting these - and they had no effect. I
definitely know my patch was working since I saw the "dirty u-boot"
version. So I'm not sure why it didn't work.


>
> 2. The layer you link to uses MACHINE_DEVICETREE, this variable is no
> longer used in meta-xilinx, make sure you are actually building what
> you expect from a device tree perspective either with the
> device-tree.bb recipe or otherwise. Also note this variable never did
> anything with regards to u-boot.
>

I had initially gotten my code structure for machine definitions from
Meta-Xilinx 2 years ago when I started (
https://github.com/Xilinx/meta-xilinx/commit/cad8934cba1ba92a612462ad6fa83b50116668a4#diff-14eb4dffd8249a14ad6a5e72b196b5b7)
and I have a hard time keeping up with all of the changes. It looks like
you just replace it with a dtb file.

Looking at device-tree.bb:
https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/device-tree/device-tree.bb
--
I'm not clear on how to "use" this recipe. What do I need to set?


>
> 3. Your u-boot appears to be configured to use the zynqmp-zcu102 device
> tree?
>
>
> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx/0002-add-gfex-prototype3-defconfig.patch#L27
>
> You will need to pass your device tree in, in order to build a u-boot
> that uses your device tree (and thus your memory config). You can do
> this by putting your device tree in the u-boot source, building it and
> using that device tree for both u-boot and optionally the kernel.
> Alternatively you can build the device tree outside of u-boot and pass
> it in as a blob with EXT_DTB (as suggested by Manju).
>
> For an example of the EXT_DTB method, have a look at this bbappend,
>
> https://github.com/nathanrossi/meta-xilinx/blob/60193934fc1c7717a71f272370aaad1bfeb118b4/recipes-bsp/u-boot/u-boot_2017.09.bbappend
> .
> This hooks up the dtb built by device-tree.bb.
>

It looks like, if I somehow get the device-tree.bb working, I need to
append to the EXTRA_OEMAKE variable for my machine in this bbappend file:
https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bbappend
--
correct? Although I'm not understanding why you reference u-boot here, when
it seems like u-boot-xlnx is what is being used.

Thanks! None of this seems obvious for people new to yocto (or meta-xilinx)
btw.


>
> Regards,
> Nathan
>
> On 14 December 2017 at 00:11, Giordon Stark  wrote:
> > Hi all,
> >
> > Any ideas what else I can do?
> >
> > Giordon
> >
> > On Fri, Dec 8, 2017 at 11:47 AM Giordon Stark  wrote:
> >>
> >> Hi Manju,
> >>
> >> I guess I'm definitely not understanding. I'm using a custom machine
> >> defined here
> >> (
> https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/gfex-prototype3.conf
> )
> >> which does inherit from zcu102-zynqmp -- but I override the
> >> MACHINE_DEVICETREE setting here. From what I understood, u-boot should
> be
> >> picking this up. (My custom layer is in bold below)
> >>
> >> Giordon
> >>
> >> kratsg@dc:/local/d4/gstark/poky/build$ bitbake-layers show-layers
> >> layer path  priority
> >>
> ==
> >> meta  /local/d4/gstark/poky/meta5
> >> meta-poky /local/d4/gstark/poky/meta-poky   5
> >> meta-yocto-bsp/local/d4/gstark/poky/meta-yocto-bsp  5
> >> meta-xilinx   /local/d4/gstark/meta-xilinx  5
> >> meta-oe       /local/d4/gstark/meta-openembedded/meta-oe  6
> >> meta-python   /local/d4/gstark/meta-openembedded/meta-python  7
> >> meta-l1calo   /local/d4/gstark/meta-l1calo  7
> >> workspace /local/d4/gstark/poky/build/workspace 99
> >>
> >>
> >> On Fri, Dec 8, 2017 at 11:39 AM Manjukumar Harthikote Matha
> >>  wrote:
> &g

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi all,

Any ideas what else I can do?

Giordon

On Fri, Dec 8, 2017 at 11:47 AM Giordon Stark  wrote:

> Hi Manju,
>
> I guess I'm definitely not understanding. I'm using a custom machine
> defined here (
> https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/gfex-prototype3.conf)
> which does inherit from zcu102-zynqmp -- but I override the
> MACHINE_DEVICETREE setting here. From what I understood, u-boot should be
> picking this up. (My custom layer is in bold below)
>
> Giordon
>
> kratsg@dc:/local/d4/gstark/poky/build$ bitbake-layers show-layers
> layer path  priority
> ==
> meta  /local/d4/gstark/poky/meta5
> meta-poky /local/d4/gstark/poky/meta-poky   5
> meta-yocto-bsp/local/d4/gstark/poky/meta-yocto-bsp  5
> meta-xilinx   /local/d4/gstark/meta-xilinx  5
> meta-oe   /local/d4/gstark/meta-openembedded/meta-oe  6
> meta-python   /local/d4/gstark/meta-openembedded/meta-python  7
> *meta-l1calo   /local/d4/gstark/meta-l1calo  7*
> workspace /local/d4/gstark/poky/build/workspace 99
>
>
> On Fri, Dec 8, 2017 at 11:39 AM Manjukumar Harthikote Matha <
> manju...@xilinx.com> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Giordon Stark [mailto:kra...@gmail.com]
>> > Sent: Friday, December 08, 2017 9:05 AM
>> > To: Manjukumar Harthikote Matha 
>> > Cc: Mike Looijmans ; Tang, Shaochun <
>> st...@bnl.gov>;
>> > meta-xilinx@yoctoproject.org
>> > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL +
>> u-boot?
>> >
>> > Hi Manju,
>> >
>> > Sure, but what is EXT_DTB and where do I set it/to what value? Googling
>> doesn't
>> > give me a lot of help here.
>> >
>>
>> Compile the dts to dtb and point the location of the DTB in EXT_DTB while
>> compiling u-boot.
>>
>> If you are using meta-xilinx-tools layer:
>> Edit
>> https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/u-boot/u-boot-xlnx_%25.bbappend
>> and add
>> UBOOT_MAKE_TARGET_append = "
>> EXT_DTB=${DEPLOY_DIR_IMAGE}/${MACHINE}-system.dtb"
>>
>> Thanks,
>> Manju
>>
>>
>> > Giordon
>> >
>> > On Fri, Dec 8, 2017 at 11:03 AM Manjukumar Harthikote Matha
>> > mailto:manju...@xilinx.com> > wrote:
>> >
>> >
>> >
>> >
>> >   > -Original Message-
>> >   > From: meta-xilinx-boun...@yoctoproject.org <mailto:meta-xilinx-
>> > boun...@yoctoproject.org>  [mailto:meta-xilinx- <mailto:meta-xilinx->
>> >   > boun...@yoctoproject.org <mailto:boun...@yoctoproject.org> ] On
>> > Behalf Of Giordon Stark
>> >   > Sent: Thursday, December 07, 2017 10:26 PM
>> >   > To: Mike Looijmans > > <mailto:mike.looijm...@topic.nl> >
>> >   > Cc: Tang, Shaochun mailto:st...@bnl.gov> >;
>> meta-
>> > xil...@yoctoproject.org <mailto:meta-xilinx@yoctoproject.org>
>> >   > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board
>> using FSBL +
>> > u-boot?
>> >   >
>> >   > Hi Mike,
>> >   >
>> >   > Is that part of the defconfig or am I looking somewhere else
>> for this? I
>> > suppose
>> >   > you're not talking about the BOOTARGS here...
>> >   >
>> >
>> >   Compile the u-boot against the dtb using EXT_DTB
>> >
>> >   Thanks,
>> >   Manju
>> >
>> >   > Giordon
>> >   >
>> >   > On Fri, Dec 8, 2017 at 12:08 AM Mike Looijmans
>> > mailto:mike.looijm...@topic.nl>
>> >   > <mailto:mike.looijm...@topic.nl <mailto:mike.looijm...@topic.nl>
>> > >
>> > wrote:
>> >   >
>> >   >
>> >   >   Change looks okay, but you (may also) need to apply this
>> to the
>> > bootloader.
>> >   >   u-boot passes the memory size on to the kernel, and the
>> kernel just
>> > follows
>> >   >   what u-boot reports.
>> >   >
>> >   >   On 07-12-17 21:35, Giordon Stark wrote:
>> >   >   > T

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Manju,

I guess I'm definitely not understanding. I'm using a custom machine
defined here (
https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/gfex-prototype3.conf)
which does inherit from zcu102-zynqmp -- but I override the
MACHINE_DEVICETREE setting here. From what I understood, u-boot should be
picking this up. (My custom layer is in bold below)

Giordon

kratsg@dc:/local/d4/gstark/poky/build$ bitbake-layers show-layers
layer path  priority
==
meta  /local/d4/gstark/poky/meta5
meta-poky /local/d4/gstark/poky/meta-poky   5
meta-yocto-bsp/local/d4/gstark/poky/meta-yocto-bsp  5
meta-xilinx   /local/d4/gstark/meta-xilinx  5
meta-oe   /local/d4/gstark/meta-openembedded/meta-oe  6
meta-python   /local/d4/gstark/meta-openembedded/meta-python  7
*meta-l1calo   /local/d4/gstark/meta-l1calo  7*
workspace /local/d4/gstark/poky/build/workspace 99


On Fri, Dec 8, 2017 at 11:39 AM Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

>
>
> > -Original Message-
> > From: Giordon Stark [mailto:kra...@gmail.com]
> > Sent: Friday, December 08, 2017 9:05 AM
> > To: Manjukumar Harthikote Matha 
> > Cc: Mike Looijmans ; Tang, Shaochun <
> st...@bnl.gov>;
> > meta-xilinx@yoctoproject.org
> > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL +
> u-boot?
> >
> > Hi Manju,
> >
> > Sure, but what is EXT_DTB and where do I set it/to what value? Googling
> doesn't
> > give me a lot of help here.
> >
>
> Compile the dts to dtb and point the location of the DTB in EXT_DTB while
> compiling u-boot.
>
> If you are using meta-xilinx-tools layer:
> Edit
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/u-boot/u-boot-xlnx_%25.bbappend
> and add
> UBOOT_MAKE_TARGET_append = "
> EXT_DTB=${DEPLOY_DIR_IMAGE}/${MACHINE}-system.dtb"
>
> Thanks,
> Manju
>
>
> > Giordon
> >
> > On Fri, Dec 8, 2017 at 11:03 AM Manjukumar Harthikote Matha
> > mailto:manju...@xilinx.com> > wrote:
> >
> >
> >
> >
> >   > -Original Message-
> >   > From: meta-xilinx-boun...@yoctoproject.org <mailto:meta-xilinx-
> > boun...@yoctoproject.org>  [mailto:meta-xilinx- <mailto:meta-xilinx->
> >   > boun...@yoctoproject.org <mailto:boun...@yoctoproject.org> ] On
> > Behalf Of Giordon Stark
> >   > Sent: Thursday, December 07, 2017 10:26 PM
> >   > To: Mike Looijmans  > <mailto:mike.looijm...@topic.nl> >
> >   > Cc: Tang, Shaochun mailto:st...@bnl.gov> >;
> meta-
> > xil...@yoctoproject.org <mailto:meta-xilinx@yoctoproject.org>
> >   > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using
> FSBL +
> > u-boot?
> >   >
> >   > Hi Mike,
> >   >
> >   > Is that part of the defconfig or am I looking somewhere else for
> this? I
> > suppose
> >   > you're not talking about the BOOTARGS here...
> >   >
> >
> >   Compile the u-boot against the dtb using EXT_DTB
> >
> >   Thanks,
> >   Manju
> >
> >   > Giordon
> >   >
> >   > On Fri, Dec 8, 2017 at 12:08 AM Mike Looijmans
> > mailto:mike.looijm...@topic.nl>
> >   > <mailto:mike.looijm...@topic.nl <mailto:mike.looijm...@topic.nl>
> > >
> > wrote:
> >   >
> >   >
> >   >   Change looks okay, but you (may also) need to apply this
> to the
> > bootloader.
> >   >   u-boot passes the memory size on to the kernel, and the
> kernel just
> > follows
> >   >   what u-boot reports.
> >   >
> >   >   On 07-12-17 21:35, Giordon Stark wrote:
> >   >   > Thanks a lot for the explanation Nathan (and all).
> >   >   >
> >   >   > When I implement the change (see diff):
> >   >   >
> >   >   > diff --git
> a/conf/machine/boards/gfex/prototype3/system-top.dts
> >   >   > b/conf/machine/boards/gfex/prototype3/system-top.dts
> >   >   > index 4e8ee15..e823bb8 100755
> >   >   > --- a/conf/machine/boards/gfex/prototype3/system-top.dts
> >   >   > +++ b/conf/mac

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Manju,

Sure, but what is EXT_DTB and where do I set it/to what value? Googling
doesn't give me a lot of help here.

Giordon

On Fri, Dec 8, 2017 at 11:03 AM Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

>
>
> > -Original Message-
> > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> > boun...@yoctoproject.org] On Behalf Of Giordon Stark
> > Sent: Thursday, December 07, 2017 10:26 PM
> > To: Mike Looijmans 
> > Cc: Tang, Shaochun ; meta-xilinx@yoctoproject.org
> > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL +
> u-boot?
> >
> > Hi Mike,
> >
> > Is that part of the defconfig or am I looking somewhere else for this? I
> suppose
> > you're not talking about the BOOTARGS here...
> >
>
> Compile the u-boot against the dtb using EXT_DTB
>
> Thanks,
> Manju
>
> > Giordon
> >
> > On Fri, Dec 8, 2017 at 12:08 AM Mike Looijmans  > <mailto:mike.looijm...@topic.nl> > wrote:
> >
> >
> >   Change looks okay, but you (may also) need to apply this to the
> bootloader.
> >   u-boot passes the memory size on to the kernel, and the kernel
> just follows
> >   what u-boot reports.
> >
> >   On 07-12-17 21:35, Giordon Stark wrote:
> >   > Thanks a lot for the explanation Nathan (and all).
> >   >
> >   > When I implement the change (see diff):
> >   >
> >   > diff --git a/conf/machine/boards/gfex/prototype3/system-top.dts
> >   > b/conf/machine/boards/gfex/prototype3/system-top.dts
> >   > index 4e8ee15..e823bb8 100755
> >   > --- a/conf/machine/boards/gfex/prototype3/system-top.dts
> >   > +++ b/conf/machine/boards/gfex/prototype3/system-top.dts
> >   > @@ -26,6 +26,6 @@
> >   >  };
> >   >  memory {
> >   >  device_type = "memory";
> >   > -   reg = <0x0 0x0 0x0 0x8000>, <0x0008
> 0x 0x0
> >   > 0x8000>;
> >   > +   reg = <0x0 0x0 0x0 0x8000>, <0x0008
> 0x
> >   > 0x0003 0x8000>;
> >   >  };
> >   >   };
> >   >
> >   > re-run bitbake, and re-program the board -- we still see 4 GiB
> DRAM. Any
> > ideas?
> >   >
> >   > Giordon
> >   >
> >   > On Wed, Dec 6, 2017 at 8:49 PM Nathan Rossi <
> nat...@nathanrossi.com
> > <mailto:nat...@nathanrossi.com>
> >   > <mailto:nat...@nathanrossi.com <mailto:nat...@nathanrossi.com>
> >>
> > wrote:
> >   >
> >   > On 7 December 2017 at 11:37, Giordon Stark  > <mailto:kra...@gmail.com>
> >   > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> >> wrote:
> >   >  > Hi Alistair,
> >   >  >
> >   >  >
> >   >  > On Wed, Dec 6, 2017 at 7:23 PM Alistair Francis
> > mailto:alistai...@gmail.com>
> >   > <mailto:alistai...@gmail.com <mailto:alistai...@gmail.com>
> >>
> >   >  > wrote:
> >   >  >>
> >   >  >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon Stark <
> kra...@gmail.com
> > <mailto:kra...@gmail.com>
> >   > <mailto:kra...@gmail.com <mailto:kra...@gmail.com> >> wrote:
> >   >  >> > Hi Manju,
> >   >  >> >
> >   >  >> > Indeed, you might be right... I guess now I'm confused
> by why
> > Xilinx is
> >   >  >> > not
> >   >  >> > exporting the HDF to a device tree correctly:
> >   >  >> >
> >   >  >> > Our block design has the DDR set to 16gigs here:
> >   >  >> >
> >   >  >> >
> >   >
> https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12-
> > 06%2018.40.29.png?dl=0
> >   >  >> > Our HDF indicates 2 banks:
> >   >  >> >
> >   >  >> >
> >   >
> https://www.dropbox.com/s/atodjbt6jf5b4aw/Screenshot%202017-12-
> > 06%2018.42.34.png?dl=0
> >   >  >>
> >   >  >> The second bank there is 45GB isn't it (it's hard to
> count the f's)?
> >   >

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Mike,

Is that part of the defconfig or am I looking somewhere else for this? I
suppose you're not talking about the BOOTARGS here...

Giordon

On Fri, Dec 8, 2017 at 12:08 AM Mike Looijmans 
wrote:

> Change looks okay, but you (may also) need to apply this to the bootloader.
> u-boot passes the memory size on to the kernel, and the kernel just follows
> what u-boot reports.
>
> On 07-12-17 21:35, Giordon Stark wrote:
> > Thanks a lot for the explanation Nathan (and all).
> >
> > When I implement the change (see diff):
> >
> > diff --git a/conf/machine/boards/gfex/prototype3/system-top.dts
> > b/conf/machine/boards/gfex/prototype3/system-top.dts
> > index 4e8ee15..e823bb8 100755
> > --- a/conf/machine/boards/gfex/prototype3/system-top.dts
> > +++ b/conf/machine/boards/gfex/prototype3/system-top.dts
> > @@ -26,6 +26,6 @@
> >  };
> >  memory {
> >  device_type = "memory";
> > -   reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x
> 0x0
> > 0x8000>;
> > +   reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x
> > 0x0003 0x8000>;
> >  };
> >   };
> >
> > re-run bitbake, and re-program the board -- we still see 4 GiB DRAM. Any
> ideas?
> >
> > Giordon
> >
> > On Wed, Dec 6, 2017 at 8:49 PM Nathan Rossi  > <mailto:nat...@nathanrossi.com>> wrote:
> >
> > On 7 December 2017 at 11:37, Giordon Stark  > <mailto:kra...@gmail.com>> wrote:
> >  > Hi Alistair,
> >  >
> >  >
> >  > On Wed, Dec 6, 2017 at 7:23 PM Alistair Francis <
> alistai...@gmail.com
> > <mailto:alistai...@gmail.com>>
> >  > wrote:
> >  >>
> >  >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon Stark  > <mailto:kra...@gmail.com>> wrote:
> >  >> > Hi Manju,
> >  >> >
> >  >> > Indeed, you might be right... I guess now I'm confused by why
> Xilinx is
> >  >> > not
> >  >> > exporting the HDF to a device tree correctly:
> >  >> >
> >  >> > Our block design has the DDR set to 16gigs here:
> >  >> >
> >  >> >
> >
> https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12-06%2018.40.29.png?dl=0
> >  >> > Our HDF indicates 2 banks:
> >  >> >
> >  >> >
> >
> https://www.dropbox.com/s/atodjbt6jf5b4aw/Screenshot%202017-12-06%2018.42.34.png?dl=0
> >  >>
> >  >> The second bank there is 45GB isn't it (it's hard to count the
> f's)?
> >  >
> >  >
> >  > In Xilinx SDK, first column is base addr, second column is high
> addr (from
> >  > xparameters.h I assume).  So I'm reading the SDK as:
> >  >
> >  > psu_ddr_0 0x_   -> 0x7fff_
> >  > psu_ddr_1 0x8__ -> 0xb_7fff_
> >  >
> >  > which looks like 2GiBs for the first one, and 15GiB for the
> second. Maybe
> >  > I'm not doing the math right here..
> >  >>
> >  >>
> >  >> >
> >  >> > The device tree right now seems to be saying:
> >  >> >
> >  >> > bank1 @ 0x0 of size 0x8000
> >  >> > bank2 @ 0x0 of size 0x8000
> >  >>
> >  >> The device tree is saying two banks.
> >  >>
> >  >> 1 bank: addr: 0 size of: 0x8000 bytes
> >  >> 2 bank: addr: 0x8 size of 0x8000 bytes
> >  >
> >  >
> >  > How are you seeing this? I'm a bit confused, since I understand
> > registers as
> >  >
> >  > reg = 
> >  >
> >  > but the device tree has a tuple of 4. So I'm not understanding
> what each
> >  > element in the tuple means semantically:
> >
> > Remember address-cells and size-cells are set at 2 words, so the
> > values are 2 sets of 2. Aka 64-bit addresses and sizes.
> >
> >
> https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/boards/gfex/prototype3/zynqmp.dtsi#L16
> >
> >  >
> >  > reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x 0x0
> 0x8000>;
> >  >
> >  > Bank 1: A1=0x0A2=0x0A3=0x0 A4

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Thanks a lot for the explanation Nathan (and all).

When I implement the change (see diff):

diff --git a/conf/machine/boards/gfex/prototype3/system-top.dts
b/conf/machine/boards/gfex/prototype3/system-top.dts
index 4e8ee15..e823bb8 100755
--- a/conf/machine/boards/gfex/prototype3/system-top.dts
+++ b/conf/machine/boards/gfex/prototype3/system-top.dts
@@ -26,6 +26,6 @@
};
memory {
device_type = "memory";
-   reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x 0x0
0x8000>;
+   reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x
0x0003 0x8000>;
};
 };

re-run bitbake, and re-program the board -- we still see 4 GiB DRAM. Any
ideas?

Giordon

On Wed, Dec 6, 2017 at 8:49 PM Nathan Rossi  wrote:

> On 7 December 2017 at 11:37, Giordon Stark  wrote:
> > Hi Alistair,
> >
> >
> > On Wed, Dec 6, 2017 at 7:23 PM Alistair Francis 
> > wrote:
> >>
> >> On Wed, Dec 6, 2017 at 4:45 PM, Giordon Stark  wrote:
> >> > Hi Manju,
> >> >
> >> > Indeed, you might be right... I guess now I'm confused by why Xilinx
> is
> >> > not
> >> > exporting the HDF to a device tree correctly:
> >> >
> >> > Our block design has the DDR set to 16gigs here:
> >> >
> >> >
> https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12-06%2018.40.29.png?dl=0
> >> > Our HDF indicates 2 banks:
> >> >
> >> >
> https://www.dropbox.com/s/atodjbt6jf5b4aw/Screenshot%202017-12-06%2018.42.34.png?dl=0
> >>
> >> The second bank there is 45GB isn't it (it's hard to count the f's)?
> >
> >
> > In Xilinx SDK, first column is base addr, second column is high addr
> (from
> > xparameters.h I assume).  So I'm reading the SDK as:
> >
> > psu_ddr_0 0x_   -> 0x7fff_
> > psu_ddr_1 0x8__ -> 0xb_7fff_
> >
> > which looks like 2GiBs for the first one, and 15GiB for the second. Maybe
> > I'm not doing the math right here..
> >>
> >>
> >> >
> >> > The device tree right now seems to be saying:
> >> >
> >> > bank1 @ 0x0 of size 0x8000
> >> > bank2 @ 0x0 of size 0x8000
> >>
> >> The device tree is saying two banks.
> >>
> >> 1 bank: addr: 0 size of: 0x8000 bytes
> >> 2 bank: addr: 0x8 size of 0x8000 bytes
> >
> >
> > How are you seeing this? I'm a bit confused, since I understand
> registers as
> >
> > reg = 
> >
> > but the device tree has a tuple of 4. So I'm not understanding what each
> > element in the tuple means semantically:
>
> Remember address-cells and size-cells are set at 2 words, so the
> values are 2 sets of 2. Aka 64-bit addresses and sizes.
>
>
> https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/boards/gfex/prototype3/zynqmp.dtsi#L16
>
> >
> > reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x 0x0 0x8000>;
> >
> > Bank 1: A1=0x0A2=0x0A3=0x0 A4=0x8000
> > Bank 2: A1=0x0008 A2=0x A3=0x0 A4=0x8000
>
> It looks like DTG has generated the upper word for the second bank
> size incorrectly? or maybe the issue is that the second bank address
> range is larger than the available memory? Not sure the problem on the
> Vivado/HDF/DTG side.
>
> Either way the reg property should probably be:
>
> reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x 0x0003
> 0x8000>;
>
> 1 bank: addr: 0x0__ size of: 0x0_8000_ bytes
> 2 bank: addr: 0x8__ size of: 0x3_8000_ bytes
>
> 0x3_8000_ + 0x8000_ = 0x4__ == 16 GiB
>
> Regards,
> Nathan
>
> >
> > But the sizes seem wrong to me.
> >
> >>
> >> >
> >> > I'm guessing the 1st and 3rd blocks here (size=0x0) could be safely
> >> > deleted.
> >>
> >> No, don't delete them.
> >>
> >> > So I'm misunderstanding this. Is there a reason for this not to
> match? A
> >> > bug?
> >>
> >> Can you confirm that your project is set to 16GB of memory (I don't
> >> know how to do that). Otherwise you can just edit the device tree.
> >
> >
> > We set the DDR in the PS of the block design to 16 GiB as referenced in
> this
> > screenshot:
> >
> >
> https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12-06%2018.40.29.png?dl=0
> >
> > Thanks a lot for the help so far! Greatly appreciate it,
> >
> > Giordon
> >
> > --
> > ___
> > meta-xilinx mailing list
> > meta-xilinx@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-xilinx
> >
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Alistair,


On Wed, Dec 6, 2017 at 7:23 PM Alistair Francis 
wrote:

> On Wed, Dec 6, 2017 at 4:45 PM, Giordon Stark  wrote:
> > Hi Manju,
> >
> > Indeed, you might be right... I guess now I'm confused by why Xilinx is
> not
> > exporting the HDF to a device tree correctly:
> >
> > Our block design has the DDR set to 16gigs here:
> >
> https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12-06%2018.40.29.png?dl=0
> > Our HDF indicates 2 banks:
> >
> https://www.dropbox.com/s/atodjbt6jf5b4aw/Screenshot%202017-12-06%2018.42.34.png?dl=0
>
> The second bank there is 45GB isn't it (it's hard to count the f's)?
>

In Xilinx SDK, first column is base addr, second column is high addr (from
xparameters.h I assume).  So I'm reading the SDK as:

psu_ddr_0 0x_   -> 0x7fff_
psu_ddr_1 0x8__ -> 0xb_7fff_

which looks like 2GiBs for the first one, and 15GiB for the second. Maybe
I'm not doing the math right here..

>
> >
> > The device tree right now seems to be saying:
> >
> > bank1 @ 0x0 of size 0x8000
> > bank2 @ 0x0 of size 0x8000
>
> The device tree is saying two banks.
>
> 1 bank: addr: 0 size of: 0x8000 bytes
> 2 bank: addr: 0x8 size of 0x8000 bytes
>

How are you seeing this? I'm a bit confused, since I understand registers
as

reg = 

but the device tree has a tuple of 4. So I'm not understanding what each
element in the tuple means semantically:

reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x 0x0 0x8000>;

Bank 1: A1=0x0A2=0x0A3=0x0 A4=0x8000
Bank 2: A1=0x0008 A2=0x A3=0x0 A4=0x8000

But the sizes seem wrong to me.


> >
> > I'm guessing the 1st and 3rd blocks here (size=0x0) could be safely
> deleted.
>
> No, don't delete them.
>
> > So I'm misunderstanding this. Is there a reason for this not to match? A
> > bug?
>
> Can you confirm that your project is set to 16GB of memory (I don't
> know how to do that). Otherwise you can just edit the device tree.
>

We set the DDR in the PS of the block design to 16 GiB as referenced in
this screenshot:

https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12-06%2018.40.29.png?dl=0


Thanks a lot for the help so far! Greatly appreciate it,

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Manju,

Indeed, you might be right... I guess now I'm confused by why Xilinx is not
exporting the HDF to a device tree correctly:

Our block design has the DDR set to 16gigs here:
https://www.dropbox.com/s/r8yzbvlf9kov8ei/Screenshot%202017-12-06%2018.40.29.png?dl=0

Our HDF indicates 2 banks:
https://www.dropbox.com/s/atodjbt6jf5b4aw/Screenshot%202017-12-06%2018.42.34.png?dl=0


The device tree right now seems to be saying:

bank1 @ 0x0 of size 0x8000
bank2 @ 0x0 of size 0x8000

I'm guessing the 1st and 3rd blocks here (size=0x0) could be safely
deleted. So I'm misunderstanding this. Is there a reason for this not to
match? A bug?

On Wed, Dec 6, 2017 at 6:32 PM Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

>
>
> > -Original Message-
> > From: Giordon Stark [mailto:kra...@gmail.com]
> > Sent: Wednesday, December 06, 2017 12:16 PM
> > To: Manjukumar Harthikote Matha 
> > Cc: meta-xilinx@yoctoproject.org; Tang, Shaochun 
> > Subject: Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL +
> u-boot?
> >
> > Hi Manju,
> >
> > The generated device tree section (that I think is relevant) is here:
> > https://github.com/kratsg/meta-
> >
> l1calo/blob/master/conf/machine/boards/gfex/prototype3/system-top.dts#L27-L30
> >
> > memory {
> > device_type = "memory";
> > reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x 0x0 0x8000>;
> };
> >
> >
> Isn't this 4G? 2 banks for 2G each?
>
> Thanks,
> Manju
>
> > which I think looks correct and specifies from 0x0 -> 0x7FFF.
> >
> > Giordon
> >
> > On Wed, Dec 6, 2017 at 2:14 PM Manjukumar Harthikote Matha
> > mailto:manju...@xilinx.com> > wrote:
> >
> >
> >
> >
> >   > -----Original Message-
> >   > From: meta-xilinx-boun...@yoctoproject.org <mailto:meta-xilinx-
> > boun...@yoctoproject.org>  [mailto:meta-xilinx- <mailto:meta-xilinx->
> >   > boun...@yoctoproject.org <mailto:boun...@yoctoproject.org> ] On
> > Behalf Of Giordon Stark
> >   > Sent: Wednesday, December 06, 2017 9:26 AM
> >   > To: meta-xilinx@yoctoproject.org  meta-xilinx@yoctoproject.org>
> >   > Cc: Tang, Shaochun mailto:st...@bnl.gov> >
> >   > Subject: [meta-xilinx] Wrong DRAM set for custom board using
> FSBL + u-
> > boot?
> >   >
> >   > Hi all,
> >   >
> >   > The board I'm using is defined here:
> https://github.com/kratsg/meta-
> >   > l1calo/blob/master/conf/machine/gfex-prototype3.conf but I'm
> noticing
> > that the
> >   > DRAM reported by U-Boot is set to 4 GiB. This would be correct
> for
> > ZCU102, but we
> >   > have 16 GiB DRAM for our custom (v3) board.
> >   >
> >   > Where is this setting configured? Is it part of the device tree?
> If so, why is
> > the device-
> >   > tree-xlnx repository not exporting this correctly?
> >   >
> >
> >   Does the device-tree generated indicate it as 16G?  If your HDF
> has correct
> > settings for 16G, DTG should output correct fragment in the dts/dtsi
> files. You should
> > compile the u-boot code with this dtb.
> >
> >   > Thanks!
> >   >
> >   > Giordon
> >
>
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi Manju,

The generated device tree section (that I think is relevant) is here:
https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/boards/gfex/prototype3/system-top.dts#L27-L30


memory {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>, <0x0008 0x 0x0 0x8000>;
};

which I think looks correct and specifies from 0x0 -> 0x7FFF.

Giordon

On Wed, Dec 6, 2017 at 2:14 PM Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

>
>
> > -Original Message-
> > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> > boun...@yoctoproject.org] On Behalf Of Giordon Stark
> > Sent: Wednesday, December 06, 2017 9:26 AM
> > To: meta-xilinx@yoctoproject.org
> > Cc: Tang, Shaochun 
> > Subject: [meta-xilinx] Wrong DRAM set for custom board using FSBL +
> u-boot?
> >
> > Hi all,
> >
> > The board I'm using is defined here: https://github.com/kratsg/meta-
> > l1calo/blob/master/conf/machine/gfex-prototype3.conf but I'm noticing
> that the
> > DRAM reported by U-Boot is set to 4 GiB. This would be correct for
> ZCU102, but we
> > have 16 GiB DRAM for our custom (v3) board.
> >
> > Where is this setting configured? Is it part of the device tree? If so,
> why is the device-
> > tree-xlnx repository not exporting this correctly?
> >
>
> Does the device-tree generated indicate it as 16G?  If your HDF has
> correct settings for 16G, DTG should output correct fragment in the
> dts/dtsi files. You should compile the u-boot code with this dtb.
>
> > Thanks!
> >
> > Giordon
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi,

I've also tried adding a new defconfig for the board with the following
patch:

+CONFIG_SYS_SDRAM_BASE=0x
+CONFIG_SYS_SDRAM_SIZE=0x8000

but u-boot still reports the DRAM as 4 GiB. I'm at a loss as to why this is
happening. Is there something I'm missing?

On Wed, Dec 6, 2017 at 11:25 AM Giordon Stark  wrote:

> Hi all,
>
> The board I'm using is defined here:
> https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/gfex-prototype3.conf
>  but
> I'm noticing that the DRAM reported by U-Boot is set to 4 GiB. This would
> be correct for ZCU102, but we have 16 GiB DRAM for our custom (v3) board.
>
> Where is this setting configured? Is it part of the device tree? If so,
> why is the device-tree-xlnx repository not exporting this correctly?
>
> Thanks!
>
> Giordon
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Wrong DRAM set for custom board using FSBL + u-boot?

[Giordon Stark]

Hi all,

The board I'm using is defined here:
https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/gfex-prototype3.conf
but
I'm noticing that the DRAM reported by U-Boot is set to 4 GiB. This would
be correct for ZCU102, but we have 16 GiB DRAM for our custom (v3) board.

Where is this setting configured? Is it part of the device tree? If so, why
is the device-tree-xlnx repository not exporting this correctly?

Thanks!

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] U-boot not recognizing correct Ethernet PHY ADDR

[Giordon Stark]

Hi Syed,

I'm using the machine defined here: https://github.com/kratsg/meta-l1calo/ (
https://github.com/kratsg/meta-l1calo/blob/master/conf/machine/gfex-prototype3.conf
).

However this is the current output I'm seeing:
https://gist.github.com/kratsg/9100572d578900cd251c40f1f651d161 where it's
still unable to see the ETH. I have also attached two screenshots of what
this looks like for us in our block design:

https://www.dropbox.com/s/c0xz9t6jm5jds7d/Screenshot%202017-12-06%2011.22.51.png?dl=0

https://www.dropbox.com/s/dzesg3s88axgyao/Screenshot%202017-12-06%2011.23.07.png?dl=0


Thanks a lot. Let me know what we've missed,

Giordon

On Thu, Nov 23, 2017 at 8:56 AM Tang, Shaochun  wrote:

> Thanks Syed.
>
>
>
> Actually, we can find the Ethernet and let it work with the SDK example.
> So I think the hardware should be ok, but I am not sure what the difference
> between FSBL and SDK example.
>
> Have a nice Thanksgiving.
>
>
>
> Best Regards
> Shaochun Tang
>
>
>
> *From: *Syed Syed 
> *Sent: *Thursday, November 23, 2017 7:26 AM
> *To: *Giordon Stark 
> *Cc: *meta-xilinx@yoctoproject.org; Tang, Shaochun 
> *Subject: *RE: [meta-xilinx] U-boot not recognizing correct Ethernet PHY
> ADDR
>
>
>
> >I was hoping that it wasn't the case that the FSBL was the problem. I
> have indeed seen that exact blog post.
> >
> >What seems to be troubling is that the FSBL I'm using is generated using
> 17.2 with Xilinx SDK - so I'm surprised this wouldn't just work out of the
> box. Do you know what / where we can look in FSBL configuration (maybe in
> the BSP configuration) that might be the issue?
>
> There is PCW- PS configuration wizard in Vivado where you configure
> MIO/MDIO and enable ENET0/ENET1 based on your board configuration. If these
> settings are incorrect then the fsbl you build against would fail to
> properly initialize PS ENET system. This is all I know.
> Check the zynqmp TRM for more details.
>
> -syed
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Why no support for FSBL?

[Giordon Stark]

Hi,

You can indeed build the FSBL + boot.bin using the meta-xilinx-tools layer:
https://github.com/Xilinx/meta-xilinx-tools

Giordon

On Mon, Nov 20, 2017 at 3:03 PM Peter Smith  wrote:

> A question, I was wondering why there is no support for building FSBL in a
> similar way to that provided by meta-xilinx for the PMU firmware, is there
> a technical reason or is it just one of those things that has not yet been
> got around to? Thanks in advance Peter.
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] U-boot not recognizing correct Ethernet PHY ADDR

[Giordon Stark]

Hi Syed,

On Wed, Nov 22, 2017 at 11:38 AM Syed Syed  wrote:

> >In particular, the PHY Address I'm trying to get u-boot to use is 0x7 but
> it seems intent on using 0xE. I'm not sure I know how to force it to use
> the right one, or make it auto-detect correctly.
>
> >I initially tried to override the default device tree by changing
> "CONFIG_DEFAULT_DEVICE_TREE" to point to the one I added in my layer -- but
> this causes bitbake to crash with a compilation failure, thinking that
> because u-boot uses a copy of the device tree for the bootloader, that the
> default xilinx one is pointing to 0xE.
> Even if the default phy address passed to the u-boot is incorrect, there
> is an auto-detect of phy address in the code. See relevant code here:
> https://raw.githubusercontent.com/Xilinx/u-boot-xlnx/edc84517d690783b5352278e2369a8cc7b392f60/drivers/net/zynq_gem.c/phy_detection()
> .
> It seems your fsbl is not initializing GEM properly, probably a gpio pin.
> See here:
> https://forums.xilinx.com/t5/Embedded-Linux/Zynq-7010-u-boot-PHY-is-not-detected/td-p/804993
>
>
I was hoping that it wasn't the case that the FSBL was the problem. I have
indeed seen that exact blog post.

What seems to be troubling is that the FSBL I'm using is generated using
17.2 with Xilinx SDK - so I'm surprised this wouldn't just work out of the
box. *Do you know what / where we can look in FSBL configuration (maybe in
the BSP configuration) that might be the issue?*

Thanks for the link to the code here:
https://github.com/Xilinx/u-boot-xlnx/blob/edc84517d690783b5352278e2369a8cc7b392f60/drivers/net/zynq_gem.c#L246-L283
as
this is what I thought u-boot was doing all along, and I was slightly
worried that my custom u-boot DEFCONFIG (to disable SDHCI/MMC/SPL) was
somehow breaking this.

Thanks!

Giordon


> -syed
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] U-boot not recognizing correct Ethernet PHY ADDR

[Giordon Stark]

Hi,

So I have a special defconfig for u-boot that disables SDHCI / MMC / SPL. I
boot right now with FSBL, and I'm able to get to the u-boot command line.

However, it seems I can't get the ethernet brought up when using the
BOOT.bin programmed in the QSPI.  Here's the log:
https://gist.github.com/kratsg/7c4b38b0f9f462262b6d4d50f7b13a8b

In particular, the PHY Address I'm trying to get u-boot to use is 0x7 but
it seems intent on using 0xE. I'm not sure I know how to force it to use
the right one, or make it auto-detect correctly.

I initially tried to override the default device tree by changing
"CONFIG_DEFAULT_DEVICE_TREE" to point to the one I added in my layer -- but
this causes bitbake to crash with a compilation failure, thinking that
because u-boot uses a copy of the device tree for the bootloader, that the
default xilinx one is pointing to 0xE.

Any ideas?

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Custom u-boot-xlnx defconfig breaks spl/u-boot-spl recipe?

[Giordon Stark]

Indeed. I'm now realizing that `make menuconfig` isn't really inheriting
from the xilinx_zynqmp defconfig board at all. So I'm going to copy that
file, and disable all the SPL/SDHCI support there. Thanks!

[side note: why does bitbake -c menuconfig not work for u-boot-xlnx?]

Giordon

On Tue, Nov 21, 2017 at 9:25 AM Nathan Rossi  wrote:

> On 22 November 2017 at 01:12, Giordon Stark  wrote:
> > Hi,
> >
> > Here's the log file:
> > https://gist.github.com/355ccc2aecb8887a03699d68b5a8c2b5
> >
> > and here's the defconfig patch that I applied to u-boot-xlnx:
> > https://gist.github.com/07ade34baf39b8717d879760a15a274c (adds a
> > _defconfig where machine=gfex-prototype3). I'm not sure what
> went
> > wrong...
>
> Your config is missing 'CONFIG_ZYNQ_SDHCI=y'. But you enable MMC
> options specifically 'CONFIG_SPL_MMC_SUPPORT=y'.
>
> >
> > Right now, my machine configuration is somewhat bare, and I haven't
> actually
> > enabled SPL yet. That said, it's curious I'm seeing a problem with that
> when
>
> Your config says otherwise 'CONFIG_SPL=y'. :)
>
> Regards,
> Nathan
>
> > changing out the defconfig?
> >
> > Giordon
> >
> > --
> > ___
> > meta-xilinx mailing list
> > meta-xilinx@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-xilinx
> >
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Custom u-boot-xlnx defconfig breaks spl/u-boot-spl recipe?

[Giordon Stark]

Hi,

Here's the log file:
https://gist.github.com/355ccc2aecb8887a03699d68b5a8c2b5

and here's the defconfig patch that I applied to u-boot-xlnx:
https://gist.github.com/07ade34baf39b8717d879760a15a274c (adds a
_defconfig where machine=gfex-prototype3). I'm not sure what went
wrong...

Right now, my machine configuration is somewhat bare, and I haven't
actually enabled SPL yet. That said, it's curious I'm seeing a problem with
that when changing out the defconfig?

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Why no support for FSBL?

[Giordon Stark]

Hi (resending from right address),

You can indeed build the FSBL + boot.bin using the meta-xilinx-tools layer:
https://github.com/Xilinx/meta-xilinx-tools

Giordon

On Mon, Nov 20, 2017 at 3:03 PM Peter Smith  wrote:

> A question, I was wondering why there is no support for building FSBL in a
> similar way to that provided by meta-xilinx for the PMU firmware, is there
> a technical reason or is it just one of those things that has not yet been
> got around to? Thanks in advance Peter.
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

Reprogrammed the board here using my patch (
https://github.com/kratsg/meta-l1calo/commit/2ddfbfa7a1d6c2a11c3035e3b0e504be793352fc)
and u-boot still hangs at the MMC line. Is there something I missed?

Giordon

On Sat, Nov 18, 2017 at 12:26 PM Giordon Stark  wrote:

> After a bit of hunting down, I did the modifications using the devtool
> helper and wrote my procedure down since I couldn't find a good guide
> online (
> https://github.com/kratsg/meta-l1calo/wiki/Creating-a-patch-for-an-existing-recipe-source-file
> )
>
> Thanks!
>
> Giordon
>
> On Sat, Nov 18, 2017 at 11:36 AM Giordon Stark  wrote:
>
>> That said, I found the config here:
>> https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/xilinx_zynqmp_zcu102.h#L13
>>  and
>> just need to generate a bbappends that's only applied for a specific
>> machine.
>>
>> Giordon
>>
>> On Sat, Nov 18, 2017 at 11:16 AM Giordon Stark  wrote:
>>
>>> I'm also unable to run `bitbake -c menuconfig "virtual/bootloader". I
>>> think I run into a similar error as this SO post (
>>> https://stackoverflow.com/questions/43211384/how-to-get-to-menuconfig-for-u-boot-in-yocto-environment
>>> )
>>>
>>> ERROR: Task do_menuconfig does not exist for target virtual/bootloader
>>> (/local/d4/gstark/meta-xilinx/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bb:do_menuconfig).
>>> Close matches:
>>>   do_configure
>>> ERROR: Command execution failed: 1
>>>
>>> Giordon
>>>
>>> On Sat, Nov 18, 2017 at 11:13 AM Giordon Stark  wrote:
>>>
>>>> (resending with right email, sorry for spam) Incredibly naive question
>>>> since I've been wondering about these things. Is it not possible to write
>>>> this as a patch or a .bbappends and put it in my meta layer (where?). I
>>>> assume the u-boot config is defined in meta-xilinx/classes or
>>>> meta-xilinx/conf as Xilinx maintains their own fork of u-boot I believe.
>>>>
>>>>
>>>> On Sat, Nov 18, 2017 at 10:27 AM Mike Looijmans <
>>>> mike.looijm...@topic.nl> wrote:
>>>>
>>>>> Basically boils down to disabling SD support in u-boot.
>>>>>
>>>>> In OE/Yocto, run "bitbake -c menuconfig virtual/bootloader" and remove
>>>>> the MMC option (and whatever other options you like). Save the
>>>>> configuration as /tmp/defconfig, and exit. Copy the defconfig to the
>>>>> u-boot recipe location and add a line to the SRC_URI to apply it while
>>>>> building.
>>>>>
>>>>> On 17-11-17 21:04, Giordon Stark wrote:
>>>>> > Is it possible to tell u-boot to not boot from MMC? I suspect it's a
>>>>> > configuration flag -- and this is when I try to program the QSPI
>>>>> using
>>>>> > my boot.bin and it would be beneficial to make that work.
>>>>> >
>>>>> > Thanks,
>>>>> >
>>>>> > Giordon
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> Mike Looijmans
>>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Mike Looijmans
>>>>> System Expert
>>>>>
>>>>> TOPIC Products
>>>>> Materiaalweg 4, NL-5681 RJ Best
>>>>> Postbus 440, NL-5680 AK Best
>>>>> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
>>>>> E-mail: mike.looijm...@topicproducts.com
>>>>> Website: www.topicproducts.com
>>>>>
>>>>> Please consider the environment before printing this e-mail
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ___
>>>>> meta-xilinx mailing list
>>>>> meta-xilinx@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>>>>
>>>>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

After a bit of hunting down, I did the modifications using the devtool
helper and wrote my procedure down since I couldn't find a good guide
online (
https://github.com/kratsg/meta-l1calo/wiki/Creating-a-patch-for-an-existing-recipe-source-file
)

Thanks!

Giordon

On Sat, Nov 18, 2017 at 11:36 AM Giordon Stark  wrote:

> That said, I found the config here:
> https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/xilinx_zynqmp_zcu102.h#L13
>  and
> just need to generate a bbappends that's only applied for a specific
> machine.
>
> Giordon
>
> On Sat, Nov 18, 2017 at 11:16 AM Giordon Stark  wrote:
>
>> I'm also unable to run `bitbake -c menuconfig "virtual/bootloader". I
>> think I run into a similar error as this SO post (
>> https://stackoverflow.com/questions/43211384/how-to-get-to-menuconfig-for-u-boot-in-yocto-environment
>> )
>>
>> ERROR: Task do_menuconfig does not exist for target virtual/bootloader
>> (/local/d4/gstark/meta-xilinx/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bb:do_menuconfig).
>> Close matches:
>>   do_configure
>> ERROR: Command execution failed: 1
>>
>> Giordon
>>
>> On Sat, Nov 18, 2017 at 11:13 AM Giordon Stark  wrote:
>>
>>> (resending with right email, sorry for spam) Incredibly naive question
>>> since I've been wondering about these things. Is it not possible to write
>>> this as a patch or a .bbappends and put it in my meta layer (where?). I
>>> assume the u-boot config is defined in meta-xilinx/classes or
>>> meta-xilinx/conf as Xilinx maintains their own fork of u-boot I believe.
>>>
>>>
>>> On Sat, Nov 18, 2017 at 10:27 AM Mike Looijmans 
>>> wrote:
>>>
>>>> Basically boils down to disabling SD support in u-boot.
>>>>
>>>> In OE/Yocto, run "bitbake -c menuconfig virtual/bootloader" and remove
>>>> the MMC option (and whatever other options you like). Save the
>>>> configuration as /tmp/defconfig, and exit. Copy the defconfig to the
>>>> u-boot recipe location and add a line to the SRC_URI to apply it while
>>>> building.
>>>>
>>>> On 17-11-17 21:04, Giordon Stark wrote:
>>>> > Is it possible to tell u-boot to not boot from MMC? I suspect it's a
>>>> > configuration flag -- and this is when I try to program the QSPI using
>>>> > my boot.bin and it would be beneficial to make that work.
>>>> >
>>>> > Thanks,
>>>> >
>>>> > Giordon
>>>> >
>>>> >
>>>>
>>>>
>>>> --
>>>> Mike Looijmans
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Mike Looijmans
>>>> System Expert
>>>>
>>>> TOPIC Products
>>>> Materiaalweg 4, NL-5681 RJ Best
>>>> Postbus 440, NL-5680 AK Best
>>>> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
>>>> E-mail: mike.looijm...@topicproducts.com
>>>> Website: www.topicproducts.com
>>>>
>>>> Please consider the environment before printing this e-mail
>>>>
>>>>
>>>>
>>>> --
>>>> ___
>>>> meta-xilinx mailing list
>>>> meta-xilinx@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>>>
>>>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

That said, I found the config here:
https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/xilinx_zynqmp_zcu102.h#L13
and
just need to generate a bbappends that's only applied for a specific
machine.

Giordon

On Sat, Nov 18, 2017 at 11:16 AM Giordon Stark  wrote:

> I'm also unable to run `bitbake -c menuconfig "virtual/bootloader". I
> think I run into a similar error as this SO post (
> https://stackoverflow.com/questions/43211384/how-to-get-to-menuconfig-for-u-boot-in-yocto-environment
> )
>
> ERROR: Task do_menuconfig does not exist for target virtual/bootloader
> (/local/d4/gstark/meta-xilinx/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bb:do_menuconfig).
> Close matches:
>   do_configure
> ERROR: Command execution failed: 1
>
> Giordon
>
> On Sat, Nov 18, 2017 at 11:13 AM Giordon Stark  wrote:
>
>> (resending with right email, sorry for spam) Incredibly naive question
>> since I've been wondering about these things. Is it not possible to write
>> this as a patch or a .bbappends and put it in my meta layer (where?). I
>> assume the u-boot config is defined in meta-xilinx/classes or
>> meta-xilinx/conf as Xilinx maintains their own fork of u-boot I believe.
>>
>>
>> On Sat, Nov 18, 2017 at 10:27 AM Mike Looijmans 
>> wrote:
>>
>>> Basically boils down to disabling SD support in u-boot.
>>>
>>> In OE/Yocto, run "bitbake -c menuconfig virtual/bootloader" and remove
>>> the MMC option (and whatever other options you like). Save the
>>> configuration as /tmp/defconfig, and exit. Copy the defconfig to the
>>> u-boot recipe location and add a line to the SRC_URI to apply it while
>>> building.
>>>
>>> On 17-11-17 21:04, Giordon Stark wrote:
>>> > Is it possible to tell u-boot to not boot from MMC? I suspect it's a
>>> > configuration flag -- and this is when I try to program the QSPI using
>>> > my boot.bin and it would be beneficial to make that work.
>>> >
>>> > Thanks,
>>> >
>>> > Giordon
>>> >
>>> >
>>>
>>>
>>> --
>>> Mike Looijmans
>>>
>>>
>>> Kind regards,
>>>
>>> Mike Looijmans
>>> System Expert
>>>
>>> TOPIC Products
>>> Materiaalweg 4, NL-5681 RJ Best
>>> Postbus 440, NL-5680 AK Best
>>> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
>>> E-mail: mike.looijm...@topicproducts.com
>>> Website: www.topicproducts.com
>>>
>>> Please consider the environment before printing this e-mail
>>>
>>>
>>>
>>> --
>>> ___
>>> meta-xilinx mailing list
>>> meta-xilinx@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>>
>>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

I'm also unable to run `bitbake -c menuconfig "virtual/bootloader". I think
I run into a similar error as this SO post (
https://stackoverflow.com/questions/43211384/how-to-get-to-menuconfig-for-u-boot-in-yocto-environment
)

ERROR: Task do_menuconfig does not exist for target virtual/bootloader
(/local/d4/gstark/meta-xilinx/recipes-bsp/u-boot/u-boot-xlnx_2017.1.bb:do_menuconfig).
Close matches:
  do_configure
ERROR: Command execution failed: 1

Giordon

On Sat, Nov 18, 2017 at 11:13 AM Giordon Stark  wrote:

> (resending with right email, sorry for spam) Incredibly naive question
> since I've been wondering about these things. Is it not possible to write
> this as a patch or a .bbappends and put it in my meta layer (where?). I
> assume the u-boot config is defined in meta-xilinx/classes or
> meta-xilinx/conf as Xilinx maintains their own fork of u-boot I believe.
>
>
> On Sat, Nov 18, 2017 at 10:27 AM Mike Looijmans 
> wrote:
>
>> Basically boils down to disabling SD support in u-boot.
>>
>> In OE/Yocto, run "bitbake -c menuconfig virtual/bootloader" and remove
>> the MMC option (and whatever other options you like). Save the
>> configuration as /tmp/defconfig, and exit. Copy the defconfig to the
>> u-boot recipe location and add a line to the SRC_URI to apply it while
>> building.
>>
>> On 17-11-17 21:04, Giordon Stark wrote:
>> > Is it possible to tell u-boot to not boot from MMC? I suspect it's a
>> > configuration flag -- and this is when I try to program the QSPI using
>> > my boot.bin and it would be beneficial to make that work.
>> >
>> > Thanks,
>> >
>> > Giordon
>> >
>> >
>>
>>
>> --
>> Mike Looijmans
>>
>>
>> Kind regards,
>>
>> Mike Looijmans
>> System Expert
>>
>> TOPIC Products
>> Materiaalweg 4, NL-5681 RJ Best
>> Postbus 440, NL-5680 AK Best
>> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
>> E-mail: mike.looijm...@topicproducts.com
>> Website: www.topicproducts.com
>>
>> Please consider the environment before printing this e-mail
>>
>>
>>
>> --
>> ___
>> meta-xilinx mailing list
>> meta-xilinx@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

(resending with right email, sorry for spam) Incredibly naive question
since I've been wondering about these things. Is it not possible to write
this as a patch or a .bbappends and put it in my meta layer (where?). I
assume the u-boot config is defined in meta-xilinx/classes or
meta-xilinx/conf as Xilinx maintains their own fork of u-boot I believe.


On Sat, Nov 18, 2017 at 10:27 AM Mike Looijmans 
wrote:

> Basically boils down to disabling SD support in u-boot.
>
> In OE/Yocto, run "bitbake -c menuconfig virtual/bootloader" and remove
> the MMC option (and whatever other options you like). Save the
> configuration as /tmp/defconfig, and exit. Copy the defconfig to the
> u-boot recipe location and add a line to the SRC_URI to apply it while
> building.
>
> On 17-11-17 21:04, Giordon Stark wrote:
> > Is it possible to tell u-boot to not boot from MMC? I suspect it's a
> > configuration flag -- and this is when I try to program the QSPI using
> > my boot.bin and it would be beneficial to make that work.
> >
> > Thanks,
> >
> > Giordon
> >
> >
>
>
> --
> Mike Looijmans
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

Incredibly naive question since I've been wondering about these things. Is
it not possible to write this as a patch or a .bbappends and put it in my
meta layer (where?). I assume the u-boot config is defined in
meta-xilinx/classes or meta-xilinx/conf as Xilinx maintains their own fork
of u-boot I believe.

Giordon

On Sat, Nov 18, 2017 at 10:27 AM Mike Looijmans 
wrote:

> Basically boils down to disabling SD support in u-boot.
>
> In OE/Yocto, run "bitbake -c menuconfig virtual/bootloader" and remove
> the MMC option (and whatever other options you like). Save the
> configuration as /tmp/defconfig, and exit. Copy the defconfig to the
> u-boot recipe location and add a line to the SRC_URI to apply it while
> building.
>
> On 17-11-17 21:04, Giordon Stark wrote:
> > Is it possible to tell u-boot to not boot from MMC? I suspect it's a
> > configuration flag -- and this is when I try to program the QSPI using
> > my boot.bin and it would be beneficial to make that work.
> >
> > Thanks,
> >
> > Giordon
> >
> >
>
>
> --
> Mike Looijmans
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

Here's an image showing what the console looks like:
https://www.dropbox.com/s/c62tabxsmghaccc/Screenshot%202017-11-17%2015.56.49.png?dl=0
from
QSPI boot with where it hangs.

Giordon

On Fri, Nov 17, 2017 at 2:55 PM Giordon Stark  wrote:

> The reason I ask is that when I try to program the QSPI flash with this
> BOOT.bin
>
> //arch = zynqmp; split = false; format = BIN
> the_ROM_image:
> {
>  [fsbl_config]a53_x64
>
>  
> [bootloader]E:\gFEX_pre_production\image\zu19eg_3\zu19eg_3.sdk\fsbl_a53\Debug\fsbl_a53.elf
>  [destination_cpu =
> pmu]E:\gFEX_pre_production\image\giordon\linux\gfex-prototype3\pmu-gfex-prototype3.elf
>  [destination_device =
> pl]E:\gFEX_pre_production\image\zu19eg_3\zu19eg_3.sdk\zcu19eg_top_hw_platform_0\zcu19eg_top.bit
>  [destination_cpu = a53-0, exception_level = el-3,
> trustzone]E:\gFEX_pre_production\image\giordon\linux\gfex-prototype3\arm-trusted-firmware.elf
>  [destination_cpu = a53-0, exception_level =
> el-2]E:\gFEX_pre_production\image\giordon\linux\gfex-prototype3\u-boot.elf
> }
>
> the u-boot line hangs with "MMC: " and nothing else. I think this is
> related to the SD not working at all.
>
> On Fri, Nov 17, 2017 at 2:04 PM Giordon Stark  wrote:
>
>> Is it possible to tell u-boot to not boot from MMC? I suspect it's a
>> configuration flag -- and this is when I try to program the QSPI using my
>> boot.bin and it would be beneficial to make that work.
>>
>> Thanks,
>>
>> Giordon
>>
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

The reason I ask is that when I try to program the QSPI flash with this
BOOT.bin

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
 [fsbl_config]a53_x64
 
[bootloader]E:\gFEX_pre_production\image\zu19eg_3\zu19eg_3.sdk\fsbl_a53\Debug\fsbl_a53.elf
 [destination_cpu =
pmu]E:\gFEX_pre_production\image\giordon\linux\gfex-prototype3\pmu-gfex-prototype3.elf
 [destination_device =
pl]E:\gFEX_pre_production\image\zu19eg_3\zu19eg_3.sdk\zcu19eg_top_hw_platform_0\zcu19eg_top.bit
 [destination_cpu = a53-0, exception_level = el-3,
trustzone]E:\gFEX_pre_production\image\giordon\linux\gfex-prototype3\arm-trusted-firmware.elf
 [destination_cpu = a53-0, exception_level =
el-2]E:\gFEX_pre_production\image\giordon\linux\gfex-prototype3\u-boot.elf
}

the u-boot line hangs with "MMC: " and nothing else. I think this is
related to the SD not working at all.

On Fri, Nov 17, 2017 at 2:04 PM Giordon Stark  wrote:

> Is it possible to tell u-boot to not boot from MMC? I suspect it's a
> configuration flag -- and this is when I try to program the QSPI using my
> boot.bin and it would be beneficial to make that work.
>
> Thanks,
>
> Giordon
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Disable U-Boot MMC?

[Giordon Stark]

Is it possible to tell u-boot to not boot from MMC? I suspect it's a
configuration flag -- and this is when I try to program the QSPI using my
boot.bin and it would be beneficial to make that work.

Thanks,

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card

[Giordon Stark]

Hi Mike,

Thanks -- I was wondering about this, since it's been a struggle to find
information about this. We do have two gotchas that might affect whether we
can use SPL or not.

1) we have a custom FSBL we need to use for the board [custom power-on
sequence, clocks, etc...] that the engineers wrote
2) we do not have a working SD card on the board, a problem with the
placement process

So this gives me a question or two:

- how do I partition the QSPI without being able to initially boot linux on
the board using SD Card boot?
- do I edit my device tree to define the partitions for the kernel to be
aware of -- and how do I make sure I partition exactly like defined?

I will take a look at meta-topic.

Giordon

On Fri, Nov 17, 2017 at 2:01 AM Mike Looijmans 
wrote:

> Much of the zynq booting information on the Xilinx website focuses on
> petalinux and the Xilinx SDK and doesn't apply to the Openembedded/Yocto
> toolflow at all.
>
> The boot flow can be mostly the same as any ARM based board, but Xilinx
> doesn't provide that information anywhere. You can find an example in our
> repo
> though, https://github.com/topic-embedded-products/meta-topic which
> applies to
> the Topic boards, but this should work with the Xilinx boards as well if
> you
> use the appropriate configs and devicetrees.
>
> The QSPI boot procedure for the ZynqMP using Yocto/OE should be:
>
> Partition the QSPI:
> - boot.bin (192k)
> - ATF (128k or whatever your sector size is)
> - u-boot.bin (768k)
> - "rootfs"
>
> Building u-boot SPL using OE should deliver boot.bin and u-boot.img. This
> should also put the PMU firmware into boot.bin using the configuration
> option
> in u-boot (this isn't done for Xilinx boards by default, see meta-topic
> how to
> patch that in).
>
> The arm-trusted-firmware binary (not the elf but the atf-qspi.bin that is
> produced by the arm-trusted-firmware recipe) goes into the second
> partition.
>
> This should get the bootloader up and running.
>
> If you partition the rootfs using UBI, you can put the kernel, devicetree
> and
> rootfs and FPGA bitstream in there. u-boot can read UBI filesystems so you
> don't need separate partitions for these.
>
>
> Tip: Boot to Linux using SD card, then program the QSPI flash using
> "flashcp"
> commands and "ubiformat" for the root.
>
>
> Note that you don't need FSBL or bootgen anywhere in this flow.
>
>
> On 17-11-17 07:17, Giordon Stark wrote:
> > Hi Sandeep,
> >
> > Thanks for the detail! Is this not documented at all anywhere on a Xilinx
> > wiki? I'm surprised, given the slight complexity in the steps, that this
> > procedure isn't as straightforward as for an SD Card boot [but maybe
> that's
> > me]. I suppose I still have a few more questions using concrete examples:
> >
> > My BIF looks like
> >
> > //arch = zynqmp; split = false; format = BIN
> > the_ROM_image:
> > {
> >  [fsbl_config]a53_x64
> >  [bootloader]C:\Users\kratsg\Desktop\zu19eg_3.sdk\fsbl\Debug\fsbl.elf
> >  [destination_cpu = pmu]Z:\gfex-prototype3\pmu-gfex-prototype3.elf
> >  [destination_device =
> >
> pl]C:\Users\kratsg\Desktop\zu19eg_3.sdk\zcu19eg_top_hw_platform_0\zcu19eg_top.bit
> >  [destination_cpu = a53-0, exception_level = el-3,
> > trustzone]Z:\gfex-prototype3\arm-trusted-firmware.elf
> >  [destination_cpu = a53-0, exception_level =
> > el-2]Z:\gfex-prototype3\u-boot.elf
> > }
> >
> > *Why does the BIF not contain the kernel image - as you would do so in
> the
> > procedure for SDCard boot?*
> > *
> > *
> > Next, our DTS files are here:
> >
> https://github.com/kratsg/meta-l1calo/tree/master/conf/machine/boards/gfex/prototype3
> .
> > Specifically, I'm looking at "spi1 = &qspi" in system-top.dts and I will
> > probably need to add the QSPI partitions under this. The point is that I
> make
> > a flash node flash@0(???) { partition1; partition2; partition3;  }.
> *How
> > do I know what to actually write for the flash@0 stuff? It's not clear
> to me
> > how large these blocks should be and how to make sure the offsets are
> correct
> > and can be picked up via u-boot and so on. [I looked here:
> > http://www.wiki.xilinx.com/Linux+ZynqMP+GQSPI+Driver as an example
> since your
> > email about creating MTD partitions wasn't rendered correctly for me, so
> I
> > couldn't read that part, missing an image or something else?]*
> > *
> > *
> > *Finally, I'm a little confused about how you're able to have a Linux
> pr

Re: [meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card

[Giordon Stark]

age can be created using mtd utilities, which can be
> then flashed to the desired mtd partition (mtd3 in our case). While
> creating jffs2 image, make sure to pass correct eraseblock size (can be
> found by sf probe 0 0 0 command on u-boot prompt).
>
>
> Generating jffs2 image
>
> In yocto project you can specify following two parameters in the
> local.conf:
>
> IMAGE_FSTYPES += " jffs2"
>
> JFFS2_ERASEBLOCK = "0x2000"
>
> This will generate .jffs2 file in the deploy area.
>
>
>
>
>
> Separately if you have tar.gz or rootfs directory, you can generate the
> rootfs image on the host machine by following command
>
> mkfs.jffs2 --root= --eraseblock= size> -p -o rootfs.jffs2
>
>
>
>
> Flashing jffs2 image on the partition
>
> It is possible to flash the generated image from u-boot as well as from
> the Linux prompt.
>
> It is necessary to clean /erase the flash before writing new data (though
> Linux will take care).
>
> 1)  From Linux prompt:
>
> a.  Erase the entire partition and also format it to jffs2
>
> # flash_eraseall -j /dev/mtd3
>
> b.  Write the jffs2 image on mtd 3 partition
>
> # flashcp  /dev/mtd3
>
>
>
> 2)  From u-boot prompt
>
> a.  Probe the flash device
>
> > sf probe 0 0 0
>
> b.  Erase the entire partition (here you need to know the offset and
> size)
>
> > sf erase 0x130 0x400
>
> c.  Load the jffs2 image in the memory location (ddr) from sd card
> (other tftp from network)
>
> > fatload mmc 0 0x1000 rootfs.jffs2
>
> d.  Write the image from the memory on to the flash
>
> > sf write 0x1000 0x130 ${filesize}
>
>
>
> 3)  From Linux prompt with tar.gz image (not jffs2)
>
> Rootfs content can be simply copied after mounting jffs2 partition
>
> a.  Erase the entire partition and also format it to jffs2
> (mandatory)
>
> # flash_eraseall -j /dev/mtd3
>
> b.  Determine the location of rootfs.tar.gz image (can be on sd card
> or network. Assuming sd card for now)
>
> i. Mount the sd
> card
>
> #  mount /dev/mmcblk0p1 /media
>
> c.  Mount jffs2 partition on the /mnt
>
> # mount -t  jffs2 /dev/mtdblock3 /mnt
>
> d.  Copy the file system to the jffs2 partition
>
> # cd /mnt/
>
> # tar zxvf /media/rootfs.tar.gz (choose appropriate path here).
> Setting kernel rootfs
>
>
>
> One can use rootfs from the jffs2 partition regardless of the boot-mode.
> Rootfs path can be specified to kernel through bootargs. One can change the
> bootargs from the u-boot prompt.
>
> For sd-boot, the the bootargs for the root partition is set by sdroot0
> variable. You can change the sdroot0 variable to add following to the
> bootargs
>
> root=/dev/mtdblock3 rw rootwait rootfstype=jffs2
>
> u-boot> setenv sdroot0 "setenv bootargs earlycon clk_ignore_unused
> root=/dev/mtdblock3 rw rootwait rootfstype=jffs2"
>
> u-boot> saveenv  # for next boot
>
> u-boot> run sdboot
>
>
>
> Similarly for other bootmodes make sure that the bootargs is set properly.
>
>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* Giordon Stark [mailto:kra...@gmail.com]
> *Sent:* Thursday, November 16, 2017 2:11 PM
> *To:* Sandeep Gundlupet Raju 
> *Cc:* meta-xilinx@yoctoproject.org
> *Subject:* Re: [meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card
>
>
>
> Thanks a lot Sandeep,
>
>
>
> Do you know what you are supposed to do with the filesystem? E.G. if you
> create a bif file, that contains what specifically? The linked User Guide
> seems to indicate not using that, but I'm unclear. I suppose I need the
> following in order:
>
>
>
> - FSBL
>
> - PMU
>
> - ATF
>
> - uramdisk.gz
>
> - devicetree
>
> - u-boot
>
> - Image
>
>
>
> Correct?
>
>
>
> Giordon
>
> On Thu, Aug 17, 2017 at 9:46 PM Sandeep Gundlupet Raju <
> sande...@xilinx.com> wrote:
>
>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* meta-xilinx-boun...@yoctoproject.org [mailto:
> meta-xilinx-boun...@yoctoproject.org] *On Behalf Of *Giordon Stark
> *Sent:* Thursday, August 17, 2017 6:10 PM
> *To:* meta-xilinx@yoctoproject.org
> *Subject:* [meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card
>
>
>
> Hi,
>
>
>
> Many thanks to the folks here for helping me get the SD Card booting
> working (especially with the data duplicator command to burn the SD card
> correctly with partitions). What's the general procedure for having the
> board boot from the QSPI instead of the SD card? Do you need specific
> software on the computer and transfer over JTAG?
>
> Refer UG1209
> https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug1209-embedded-design-tutorial.pdf
>
>
>
> It would be great if someone could point me to a set of instructions.
>
>
>
> Giordon
>
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] malideveloper.arm.com 504 error (gateway time out)

[Giordon Stark]

Thanks, this fixes it.

On Thu, Nov 16, 2017 at 11:24 PM Sandeep Gundlupet Raju 
wrote:

> Hi Girodon,
>
>
>
> Refer this AR https://www.xilinx.com/support/answers/69564.html
>
>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* meta-xilinx-boun...@yoctoproject.org [mailto:
> meta-xilinx-boun...@yoctoproject.org] *On Behalf Of *Manjukumar
> Harthikote Matha
> *Sent:* Thursday, November 16, 2017 1:29 PM
> *To:* Giordon Stark ; meta-xilinx@yoctoproject.org
> *Subject:* Re: [meta-xilinx] malideveloper.arm.com 504 error (gateway
> time out)
>
>
>
> Hi Giordon,
>
>
>
> Seems like it might be down or not working as of now.
>
> Use these mirrors if you like to get the required packages
>
>
> https://github.com/Xilinx/meta-petalinux/blob/master/conf/local.conf.sample#L202-L203
>
>
>
> petalinux.xilinx.com is not accessible directly, but can be wired for
> build purpose.
>
>
>
> Thanks,
>
> Manju
>
>
>
> *From:* meta-xilinx-boun...@yoctoproject.org [
> mailto:meta-xilinx-boun...@yoctoproject.org
> ] *On Behalf Of *Giordon Stark
> *Sent:* Thursday, November 16, 2017 11:26 AM
> *To:* meta-xilinx@yoctoproject.org
> *Subject:* [meta-xilinx] malideveloper.arm.com 504 error (gateway time
> out)
>
>
>
> Hi all,
>
>
>
> I've been trying over the past few hours today to attempt to build a set
> of artifacts to boot my ZynqMP 102. Unfortunately, the hang-up seems to be
> in trying to http-fetch some sources. Does anyone know if this happens
> often or if the only thing I can do is wait?
>
>
>
> Log below,
>
>
>
> Giordon
>
>
>
> kratsg@dc:/local/d4/poky/build$ bitbake zynq-base
>
> Parsing recipes: 100%
> |##|
> Time: 0:00:47
>
> Parsing of 1713 .bb files complete (0 cached, 1713 parsed). 2399 targets,
> 140 skipped, 0 masked, 0 errors.
>
> NOTE: Resolving any missing task queue dependencies
>
>
>
> Build Configuration:
>
> BB_VERSION= "1.32.0"
>
> BUILD_SYS = "x86_64-linux"
>
> NATIVELSBSTRING   = "universal"
>
> TARGET_SYS= "aarch64-poky-linux"
>
> MACHINE   = "gfex-prototype3"
>
> DISTRO= "poky"
>
> DISTRO_VERSION= "2.2.1"
>
> TUNE_FEATURES = "aarch64"
>
> TARGET_FPU= ""
>
> meta
>
> meta-poky
>
> meta-yocto-bsp= "morty:6a1f33cc40bfac33cf030fe41e1a8efd1e5fad6f"
>
> meta-xilinx   = "morty:9304e43528faab0221ef35a3a129a438715c52b2"
>
> meta-oe
>
> meta-python   = "morty:1efa5d623bc64659b57389e50be2568b1355d5f7"
>
> meta-l1calo   = "master:887e347497a4e15558bc5b6babf8f0520e31d431"
>
> common= "morty:47cb62194b800499e65c9fa7c8c2d0a251508151"
>
>
>
> Initialising tasks: 100%
> |###|
> Time: 0:00:05
>
> NOTE: Executing SetScene Tasks
>
> NOTE: Executing RunQueue Tasks
>
> WARNING: libpng-native-1.6.24-r0 do_fetch: Failed to fetch URL
> http://distfiles.gentoo.org/distfiles/libpng-1.6.24.tar.xz, attempting
> MIRRORS if available
>
> WARNING: kernel-module-mali-r5p1-01rel0-r0 do_fetch: Failed to fetch URL
> http://malideveloper.arm.com/downloads/drivers/DX910/r5p1-01rel0/DX910-SW-99002-r5p1-01rel0.tgz,
> attempting MIRRORS if available
>
> ERROR: kernel-module-mali-r5p1-01rel0-r0 do_fetch: Fetcher failure: Fetch
> command export
> PATH="/local/d4/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/local/d4/poky/scripts:/local/d4/poky/build/tmp/sysroots/x86_64-linux/usr/bin/aarch64-poky-linux:/local/d4/poky/build/tmp/sysroots/gfex-prototype3/usr/bin/crossscripts:/local/d4/poky/build/tmp/sysroots/x86_64-linux/usr/sbin:/local/d4/poky/build/tmp/sysroots/x86_64-linux/usr/bin:/local/d4/poky/build/tmp/sysroots/x86_64-linux/sbin:/local/d4/poky/build/tmp/sysroots/x86_64-linux/bin:/local/d4/poky/scripts:/local/d4/poky/bitbake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/users/kratsg/bin";
> export HOME="/users/kratsg"; /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp
> --no-check-certificate -P /local/d4/poky/build/downloads '
> http:

Re: [meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card

[Giordon Stark]

Thanks a lot Sandeep,

Do you know what you are supposed to do with the filesystem? E.G. if you
create a bif file, that contains what specifically? The linked User Guide
seems to indicate not using that, but I'm unclear. I suppose I need the
following in order:

- FSBL
- PMU
- ATF
- uramdisk.gz
- devicetree
- u-boot
- Image

Correct?

Giordon

On Thu, Aug 17, 2017 at 9:46 PM Sandeep Gundlupet Raju 
wrote:

>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* meta-xilinx-boun...@yoctoproject.org [mailto:
> meta-xilinx-boun...@yoctoproject.org] *On Behalf Of *Giordon Stark
> *Sent:* Thursday, August 17, 2017 6:10 PM
> *To:* meta-xilinx@yoctoproject.org
> *Subject:* [meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card
>
>
>
> Hi,
>
>
>
> Many thanks to the folks here for helping me get the SD Card booting
> working (especially with the data duplicator command to burn the SD card
> correctly with partitions). What's the general procedure for having the
> board boot from the QSPI instead of the SD card? Do you need specific
> software on the computer and transfer over JTAG?
>
> Refer UG1209
> https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug1209-embedded-design-tutorial.pdf
>
>
>
> It would be great if someone could point me to a set of instructions.
>
>
>
> Giordon
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] How to boot the ZynqMP?

[Giordon Stark]

Hi Brian, all,

I noticed you add some stuff in local.conf to specify the types of images
being built, e.g.

# add Boot.bin dependency
IMAGE_CLASSES += " xilinx-bootbin"

Where are these defined? How can I see a list of possible choices for this?

Giordon

On Fri, Sep 1, 2017 at 9:40 AM Martin Siegumfeldt  wrote:

> Thanks Manju, I now have it building and it also seems to boot the
> artifacts. The missing display-variable exporting and the potentially also
> the missing reference to the tools-variant of the device-tree-generation
> seems to be the culprit.
>
> Br,
> Martin
>
>
> From: Manjukumar Harthikote Matha 
> Sent: Friday, September 1, 2017 04:40
> To: Manjukumar Harthikote Matha; Mike Looijmans; Brian Hutchinson; Martin
> Siegumfeldt
> Cc: meta-xilinx@yoctoproject.org
> Subject: RE: [meta-xilinx] How to boot the ZynqMP?
>
> Hi All,
>
> Sorry for writing on top. I wanted to summarize the flow which worked for
> me without meta-petalinux layer.
>
> I have poky, meta-xilinx, meta-openembedded and meta-xilinx-tools (all on
> master branch)
>
> If you have a build, please make sure to cleansstate fsbl,pmu-firmware,
> device-tree-generation, bitstream-extraction recipes before you start
>
> 1) Make sure you have meta-oe and meta-python in bblayers.conf (Will apply
> Mike's patch on meta-xilinx-tools)
>
> 2)Either copy
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/conf/machine/include/machine-xilinx-zynqmp.inc
> to local.conf  or include this file from your custom machine
>
> 3) Provide the HDF file using
> a) Local path:
> HDF_BASE = "file://"
> HDF_PATH = "/system.hdf"
> b) Or using git
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/hdf/external-hdf.bb#L9-L10
>
> 4) Provide the path to the installed XSDK in local.conf
> XILINX_SDK_TOOLCHAIN = ""
>
> 5) I had to add export DISPLAY=:1 before this line here
>
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctbase.bbclass#L48
> and
>
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctbase.bbclass#L56
>
>  https://avatars0.githubusercontent.com/u/3189299?v=4&s=400
>
> Xilinx/meta-xilinx-tools
> github.com
> Contribute to meta-xilinx-tools development by creating an account on
> GitHub.
>
>
> We did not observe this issue in Morty, seems to have changed in Pyro or
> master. I am still checking how to make a patch using WHITELIST rather than
> above approach. Any suggestions?
>
> 6) there are two device-tree recipes one in meta-xilinx and one
> meta-xilinx-tools, set the preferred provider to one in meta-xilinx-tools
> in local.conf
> PREFERRED_PROVIDER_virtual/dtb ?= "device-tree-generation"
>
> 7) bitbake the image
> Once the image builds you see the following
> BOOT.bin (this will contain fsbl, pmu, atf, bitstream and u-boot)
> fsbl-.elf
> pmu-firmware-.elf
> -system.dts (DTG generated dts using the HDF provided)
> -system.dtb (DTG generated dtb using the HDF provided)
>
> Other images
> pmu- is from meta-xilinx recipe
>
> Thanks,
> Manju
>
>
> > -Original Message-
> > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> > boun...@yoctoproject.org] On Behalf Of Manjukumar Harthikote Matha
> > Sent: Thursday, August 31, 2017 2:33 PM
> > To: Mike Looijmans ; Brian Hutchinson
> > 
> > Cc: meta-xilinx@yoctoproject.org
> > Subject: Re: [meta-xilinx] How to boot the ZynqMP?
> >
> > [This sender failed our fraud detection checks and may not be who they
> appear to
> > be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> >
> > Hi Mike,
> >
> > > -Original Message-
> > > From: Mike Looijmans [mailto:mike.looijm...@topic.nl]
> > > Sent: Thursday, August 31, 2017 10:52 AM
> > > To: Brian Hutchinson ; Manjukumar Harthikote
> > > Matha 
> > > Cc: Giordon Stark ; Jean-Francois Dagenais
> > > ; meta-xilinx@yoctoproject.org
> > > Subject: Re: [meta-xilinx] How to boot the ZynqMP?
> > >
> > > On 30-08-17 22:20, Brian Hutchinson wrote:
> > > > I too have been wrestling with generating the required images to
> > > > boot the
> > > > ZCU102 from SD Card using the Yocto + meta-xilinx +
> meta-xilinx-tools method.
> > > >
> > > > I'm totally striking out.  And I'm working with a Xilinx FAE and
> > > > striking out!  No problem at all doing this kind of thing for ZCU107
> > > > or Zedboard but
> > > > ZCU102 is different beast for sure

[meta-xilinx] malideveloper.arm.com 504 error (gateway time out)

[Giordon Stark]

Hi all,

I've been trying over the past few hours today to attempt to build a set of
artifacts to boot my ZynqMP 102. Unfortunately, the hang-up seems to be in
trying to http-fetch some sources. Does anyone know if this happens often
or if the only thing I can do is wait?

Log below,

Giordon

kratsg@dc:/local/d4/poky/build$ bitbake zynq-base
Parsing recipes: 100%
|##|
Time: 0:00:47
Parsing of 1713 .bb files complete (0 cached, 1713 parsed). 2399 targets,
140 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "aarch64-poky-linux"
MACHINE   = "gfex-prototype3"
DISTRO= "poky"
DISTRO_VERSION= "2.2.1"
TUNE_FEATURES = "aarch64"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp= "morty:6a1f33cc40bfac33cf030fe41e1a8efd1e5fad6f"
meta-xilinx   = "morty:9304e43528faab0221ef35a3a129a438715c52b2"
meta-oe
meta-python   = "morty:1efa5d623bc64659b57389e50be2568b1355d5f7"
meta-l1calo   = "master:887e347497a4e15558bc5b6babf8f0520e31d431"
common= "morty:47cb62194b800499e65c9fa7c8c2d0a251508151"

Initialising tasks: 100%
|###|
Time: 0:00:05
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: libpng-native-1.6.24-r0 do_fetch: Failed to fetch URL
http://distfiles.gentoo.org/distfiles/libpng-1.6.24.tar.xz, attempting
MIRRORS if available
WARNING: kernel-module-mali-r5p1-01rel0-r0 do_fetch: Failed to fetch URL
http://malideveloper.arm.com/downloads/drivers/DX910/r5p1-01rel0/DX910-SW-99002-r5p1-01rel0.tgz,
attempting MIRRORS if available
ERROR: kernel-module-mali-r5p1-01rel0-r0 do_fetch: Fetcher failure: Fetch
command export
PATH="/local/d4/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/local/d4/poky/scripts:/local/d4/poky/build/tmp/sysroots/x86_64-linux/usr/bin/aarch64-poky-linux:/local/d4/poky/build/tmp/sysroots/gfex-prototype3/usr/bin/crossscripts:/local/d4/poky/build/tmp/sysroots/x86_64-linux/usr/sbin:/local/d4/poky/build/tmp/sysroots/x86_64-linux/usr/bin:/local/d4/poky/build/tmp/sysroots/x86_64-linux/sbin:/local/d4/poky/build/tmp/sysroots/x86_64-linux/bin:/local/d4/poky/scripts:/local/d4/poky/bitbake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/users/kratsg/bin";
export HOME="/users/kratsg"; /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp
--no-check-certificate -P /local/d4/poky/build/downloads '
http://malideveloper.arm.com/downloads/drivers/DX910/r5p1-01rel0/DX910-SW-99002-r5p1-01rel0.tgz'
--progress=dot -v failed with exit code 4, output:
--2017-11-16 13:20:25--
http://malideveloper.arm.com/downloads/drivers/DX910/r5p1-01rel0/DX910-SW-99002-r5p1-01rel0.tgz
Resolving malideveloper.arm.com (malideveloper.arm.com)... 128.135.167.43,
128.135.167.42
Connecting to malideveloper.arm.com
(malideveloper.arm.com)|128.135.167.43|:80...
connected.
HTTP request sent, awaiting response... 504 Gateway Time-out
Retrying.

--2017-11-16 13:20:45--  (try: 2)
http://malideveloper.arm.com/downloads/drivers/DX910/r5p1-01rel0/DX910-SW-99002-r5p1-01rel0.tgz
Connecting to malideveloper.arm.com
(malideveloper.arm.com)|128.135.167.43|:80...
connected.
HTTP request sent, awaiting response... 504 Gateway Time-out
Giving up.


ERROR: kernel-module-mali-r5p1-01rel0-r0 do_fetch: Fetcher failure for URL:
'
http://malideveloper.arm.com/downloads/drivers/DX910/r5p1-01rel0/DX910-SW-99002-r5p1-01rel0.tgz'.
Unable to fetch URL from any source.
ERROR: kernel-module-mali-r5p1-01rel0-r0 do_fetch: Function failed:
base_do_fetch
ERROR: Logfile of failure stored in:
/local/d4/poky/build/tmp/work/gfex_prototype3-poky-linux/kernel-module-mali/r5p1-01rel0-r0/temp/log.do_fetch.14503
ERROR: Task
(/local/d4/meta-xilinx/recipes-graphics/mali/kernel-module-mali.bb:do_fetch)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 1559 tasks of which 891 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:
  /local/d4/meta-xilinx/recipes-graphics/mali/kernel-module-mali.bb:do_fetch
Summary: There were 2 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] How to boot the ZynqMP?

[Giordon Stark]

Hi Mike,

One trick I do is have the machine inherit from the zynq-mpsoc and override
whatever I need... then I usually can just build like normal and expect the
boot.bin as usual. EG: something like

# add MACHINEOVERRIDES .= ":zc706-zynq7" to your machine config otherwise
those
# overrides in recipes won't apply since the machine name is different
require conf/machine/zc706-zynq7.conf

MACHINEOVERRIDES .= ":zc706-zynq7"

MACHINE_DEVICETREE := " \
gfex/prototype2/skeleton.dtsi \
gfex/prototype2/pl.dtsi \
gfex/prototype2/zynq-7000.dtsi \
gfex/prototype2/system.dts \
"

could be sufficient enough to override for your machine correctly.

On Thu, Aug 24, 2017 at 12:36 AM Mike Looijmans 
wrote:

> On 23-08-17 22:46, Manjukumar Harthikote Matha wrote:
> > Hi Mike,
> >
> >>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> -Original Message-
> >> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> >> boun...@yoctoproject.org] On Behalf Of Mike Looijmans
> >> Sent: Tuesday, August 22, 2017 11:02 PM
> >> To: Manjukumar Harthikote Matha ; Giordon Stark
> >> ; Jean-Francois Dagenais 
> >> Cc: meta-xilinx@yoctoproject.org
> >> Subject: Re: [meta-xilinx] How to boot the ZynqMP?
> >>
> >> I managed to get it booting with some manual work.
> >>
> >> - The meta-xilinx overlay delivers the ATF and PMU firmware.
> >> - My own layer delivers u-boot and kernel and devicetree for my own
> board
> >>
> >> The FSBL I've manually built using Vivado/SDK. The trick to get that
> working was that
> >> Vivado version >= 2017.1 was required. It doesn't work (any more) with
> the 2016
> >> versions. I installed 2017.2 and only then the FSBL was able to load
> the PMU and
> >> ATF. Apparently there's a dependency there.
> >>
> >> So all that is left is to automate the process of generating fsbl and
> boot.bin.
> >>
> >> I'm pretty sure this can be done using just u-boot, since u-boot has
> support for ATF
> >> loading and, as I gather from various commits, the PMU as well. It can
> also create a
> >> boot.bin without the aid of bootgen. It provides the first-stage loader
> as well.
> >> However, it seems to a well-kept secret how to actually integrate the
> PMU. I can
> >> generate a bootloader this way, but I don't know where to put the ATF
> and PMU. I
> >> suspect they're to be stored in a FIT image.
> >>
> >> So for now I'm stuck with the much less streamlined FSBL flow.
> >>
> >>
> >> On 22-08-17 20:25, Manjukumar Harthikote Matha wrote:
> >>> Hi Giordon,
> >>>
> >>> meta-xilinx-tools with xsct in your path would enable the same way ,
> >>> instead of using the Vivado GUI to generate fsbl/pmu/boot.bin
> >>>
> >>> http://www.wiki.xilinx.com/Using+meta-xilinx-tools+layer
> >>>
> >>
> >> So how does one use this layer to just generate the FSBL and boot.bin?
> >>
> > Basically on dependencies,
> >
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/conf/machine/include/machine-xilinx-zynqmp.inc
> >
> > The dependency is to build boot.bin once this layer is included by the
> above file.
> > Boot.bin defines dependencies for zynqmp as
> >
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/conf/machine/include/machine-xilinx-zynqmp.inc#L10
> >
> > Meaning boot.bin has dependencies on fsbl, bitstream (if it exists), pmu
> firmware, atf and u-boot to be built and will create a bif file according
> to these settings
> >
> > Each of these BIF_PARTITION_ATTR is associated with additional
> attributed. For example :
> >
> https://github.com/Xilinx/meta-xilinx-tools/blob/master/conf/machine/include/machine-xilinx-zynqmp.inc#L14-L16
> > BIF_PARTITION_ATTR[fsbl] ?= "bootloader"
> > This defines the attrition attribute in the bif
> > BIF_PARTITION_IMAGE[fsbl] ?= "${DEPLOY_DIR_IMAGE}/fsbl-${MACHINE}.elf"
> > This defines where to find the binary generated
> > BIF_PARTITION_DEPENDS[fsbl] ?= "virtual/fsbl"
> > This defines which recipe it depends on to build the required binary
> >
> > This would tra

Re: [meta-xilinx] How to boot the ZynqMP?

[Giordon Stark]

Hi Manju,

Were there changes recently to get this working? When I tried
meta-xilinx-tools back when I wrote the wiki as a second option instead of
going through the GUI -- I kept getting stuck on the PMU FW portion and was
unable to get the board to continue booting (instead it would do a kernel
panic) and I never figured out what happened, especially since I got it
working with XSDK. Are you saying it should work now? If so, I can look
into it.

Does anyone know how to make the partitioning step a bit easier for SD
Card? It seems needlessly complex right now, but I guess it'll improve
later on?

Thanks,

Giordon

On Tue, Aug 22, 2017 at 1:25 PM Manjukumar Harthikote Matha <
manju...@xilinx.com> wrote:

> Hi Giordon,
>
> meta-xilinx-tools with xsct in your path would enable the same way ,
> instead of using the Vivado GUI to generate fsbl/pmu/boot.bin
>
>
>
> http://www.wiki.xilinx.com/Using+meta-xilinx-tools+layer
>
>
>
> Thanks,
>
> Manju
>
>
>
> *From:* meta-xilinx-boun...@yoctoproject.org [mailto:
> meta-xilinx-boun...@yoctoproject.org] *On Behalf Of *Giordon Stark
> *Sent:* Tuesday, August 22, 2017 7:46 AM
> *To:* Mike Looijmans ; Jean-Francois Dagenais <
> jeff.dagen...@gmail.com>
> *Cc:* meta-xilinx@yoctoproject.org
> *Subject:* Re: [meta-xilinx] How to boot the ZynqMP?
>
>
>
> Hi,
>
>
>
> I'll share my experiences as it has been somewhat painful -- but I did
> manage to have success booting from an SD card directly for MPSOC. I'm
> working on QSPI boot -- but I wrote my experiences/guide here:
> https://github.com/kratsg/meta-l1calo/wiki/ZynqMP:-Prepare-and-Boot-Hardware
>
>
>
>
> You can also compare it to how I did it for the Zynq-7 -- to see the
> differences. But this might help you get a bit further if you haven't
> already.
>
>
>
> Giordon
>
> On Tue, Aug 22, 2017 at 12:47 AM Mike Looijmans 
> wrote:
>
> On 22-08-17 02:25, Jean-Francois Dagenais wrote:
> >
> >>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> On Aug 21, 2017, at 04:20, Mike Looijmans  wrote:
> >>
> >>
> >> I recall having done this stuff about half a year ago, and at least
> then I could create an SPL based loader that actually booted. The layer
> above looks like regression to me.
> >
> > Xilinx "official" support is in FSBL for zynqmp. They removed the SPL
> zynqmp stuff from their u-boot fork if I am not mistaken. And they
> configure everything using their own stack including other layers such as
> meta-linaro and meta-petalinux.
> >
>
> I'm not sure they removed it, the u-boot-xlnx fork is about 8 months
> behind on
> mainline u-boot.
>
> Stangely, the mainline version has SPL support, an I actually can get the
> board to boot with SPL. But I can't figure out how to make it load PMU and
> ATF.
>
> There have been dozens of commits from Xilinx to support the zynqmp in
> u-boot
> mainline. None of these are in the Xilnx fork, so I assumed that Xilinx had
> seen the light... Apparently the opposite is true.
>
> >>
> >> Current state is that if I generate FSBL using Vivado SDK I can make it
> load u-boot by generating a boot.bin containing the FSBL and u-boot.elf.
> But then I don't have the PMU firmware and ATF and thus the kernel won't
> run.
> >
> > Had the same problem. This is because we are hanging on to the old trail
> (without the extra layers Xilinx wants us to use).
> >
> >>
> >> I tried putting ATF and PMU firmware from the meta-xilinx build into
> the boot.bin using the proper attributes, but that results in complete and
> utter quiet hangup after power-up. I only see the FSBL start message on the
> uart.
> >
> > I had to fork a machine from zcu102 in u-boot (so I forked u-boot-xlnx)
> in my env. Also forked meta-xilinx-tools such that my machine does the same
> configuration of xilinx-bootbin as zcu102 so the ATF and PMU firmware are
> bundled inside boot.bin. My fork of
> u-boot-xlnx/include/configs/xilinx_zynqmp_zcu102.h is where I tie it all
> together with the right file names for linux image and dtb to match what I
> have put into the partition using wic, and the default names that yocto
> uses for those.
> >
> > It was a bit of a hassle, and a annoyance compared to the ease of build
> of the zynq7 series board, 

Re: [meta-xilinx] How to boot the ZynqMP?

[Giordon Stark]

Hi,

I'll share my experiences as it has been somewhat painful -- but I did
manage to have success booting from an SD card directly for MPSOC. I'm
working on QSPI boot -- but I wrote my experiences/guide here:
https://github.com/kratsg/meta-l1calo/wiki/ZynqMP:-Prepare-and-Boot-Hardware


You can also compare it to how I did it for the Zynq-7 -- to see the
differences. But this might help you get a bit further if you haven't
already.

Giordon

On Tue, Aug 22, 2017 at 12:47 AM Mike Looijmans 
wrote:

> On 22-08-17 02:25, Jean-Francois Dagenais wrote:
> >
> >>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> On Aug 21, 2017, at 04:20, Mike Looijmans  wrote:
> >>
> >>
> >> I recall having done this stuff about half a year ago, and at least
> then I could create an SPL based loader that actually booted. The layer
> above looks like regression to me.
> >
> > Xilinx "official" support is in FSBL for zynqmp. They removed the SPL
> zynqmp stuff from their u-boot fork if I am not mistaken. And they
> configure everything using their own stack including other layers such as
> meta-linaro and meta-petalinux.
> >
>
> I'm not sure they removed it, the u-boot-xlnx fork is about 8 months
> behind on
> mainline u-boot.
>
> Stangely, the mainline version has SPL support, an I actually can get the
> board to boot with SPL. But I can't figure out how to make it load PMU and
> ATF.
>
> There have been dozens of commits from Xilinx to support the zynqmp in
> u-boot
> mainline. None of these are in the Xilnx fork, so I assumed that Xilinx had
> seen the light... Apparently the opposite is true.
>
> >>
> >> Current state is that if I generate FSBL using Vivado SDK I can make it
> load u-boot by generating a boot.bin containing the FSBL and u-boot.elf.
> But then I don't have the PMU firmware and ATF and thus the kernel won't
> run.
> >
> > Had the same problem. This is because we are hanging on to the old trail
> (without the extra layers Xilinx wants us to use).
> >
> >>
> >> I tried putting ATF and PMU firmware from the meta-xilinx build into
> the boot.bin using the proper attributes, but that results in complete and
> utter quiet hangup after power-up. I only see the FSBL start message on the
> uart.
> >
> > I had to fork a machine from zcu102 in u-boot (so I forked u-boot-xlnx)
> in my env. Also forked meta-xilinx-tools such that my machine does the same
> configuration of xilinx-bootbin as zcu102 so the ATF and PMU firmware are
> bundled inside boot.bin. My fork of
> u-boot-xlnx/include/configs/xilinx_zynqmp_zcu102.h is where I tie it all
> together with the right file names for linux image and dtb to match what I
> have put into the partition using wic, and the default names that yocto
> uses for those.
> >
> > It was a bit of a hassle, and a annoyance compared to the ease of build
> of the zynq7 series board, but in the end, learned a lot and am more than
> ever the master of my domain! ;)
> >
>
> At least now I understand why there's so little interest in the MPSOC. The
> licensing alone is a nightmare.
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] [ZynqMP] Booting from QSPI instead of SD Card

[Giordon Stark]

Hi,

Many thanks to the folks here for helping me get the SD Card booting
working (especially with the data duplicator command to burn the SD card
correctly with partitions). What's the general procedure for having the
board boot from the QSPI instead of the SD card? Do you need specific
software on the computer and transfer over JTAG?

It would be great if someone could point me to a set of instructions.

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] ZynqMP XADC in default DTS?

[Giordon Stark]

Hi all,

In the Zynq-7000 series, the default DTS provided here (
https://github.com/Xilinx/linux-xlnx/blob/1aacedaf5318e8ae39cc02916647495c1c2992ab/arch/arm/boot/dts/zynq-7000.dtsi#L77-L83)
comes with XADC baked in by default...

However, in the ZynqMP series, the default DTS provided here (
https://github.com/Xilinx/linux-xlnx/blob/1aacedaf5318e8ae39cc02916647495c1c2992ab/arch/arm64/boot/dts/xilinx/zynqmp.dtsi)
does not come with XADC baked in. It's not clear to me how to add this in
using a "default project" (MPSoC process IPCore with PS-PL clocks disabled)
and the system.dtb provided by the *zcu102-zynqmp* machine option in
bitbake.

Would I, instead, need to add the XADC IP Core into my project, and then
look at the physical addresses and figure out how to add it in my DTS? Or
is there some other way to do it with the default machine, or should I be
making my own machine+dts files?

Thanks,

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Pyserial

[Giordon Stark]

Hi Madhura: see
https://www.openembedded.org/wiki/Layers_FAQ#How_do_I_make_use_of_a_layer.3F


Giordon

On Wed, May 17, 2017 at 8:07 AM Madhura K  wrote:

> I need pyserial -2.7 version. I got source code from this link
> https://pypi.python.org/pypi/pyserial/2.7
> How to add this into rootfs of petalinux package. I am not finding how add
> it.
>  Or how meta-python layer is added?
>
> On Wed, May 17, 2017 at 6:04 PM, Philip Balister 
> wrote:
>
>> On 05/17/2017 08:23 AM, Madhura K wrote:
>> > Hi All,
>> > How to create pyserial python library and install in rootfs of
>> petalinux.
>> > I found these rpm's
>> >
>> http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.1/rpm/cortexa9hf_vfp_neon/
>> > Is there a way to do so for pyserial also?
>>
>> You need to add the meta-python layer.
>>
>> http://layers.openembedded.org/layerindex/recipe/28499/
>>
>> Philip
>>
>> >
>> >
>> >
>>
>
>
>
> --
> Regards,
> Madhura K,
> Software Engineer,
> Vayavya Labs Pvt Ltd.
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Kernel Panic: SD Boot on zcu102-zynqmp

[Giordon Stark]

Thanks a lot! I'm going to try this. Do you know if partitioning the card
gets around this problem in anyway or it will still have issues accessing
the SDcard?

Thanks for the replies,

Giordon
On Wed, Mar 29, 2017 at 06:40 Jean-Francois Dagenais <
jeff.dagen...@gmail.com> wrote:

>
> > On Mar 29, 2017, at 06:26, Mike Looijmans 
> wrote:
> >
> > What I've found so far is that the power management for the SD card is
> somehow broken in the pmufw. To work around it, I disabled the
> ZYNQMP_PM_DOMAINS config option in the kernel. With ZYNQMP_PM_DOMAINS the
> kernel cannot access the SD card if pmufw has been loaded, without
> ZYNQMP_PM_DOMAINS the SD card works okay and the system boots properly.
>
> Thanks for this great info Mike. That, and your previous posts will save
> me hours as I am just about to wrap up my u-boot effort and ready to move
> on to fixing the kernel.
>
> Will let all know of these little things I discover along the way.
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Kernel Panic: SD Boot on zcu102-zynqmp

[Giordon Stark]

I seem to have forgotten PMUFW. So I've added that in, and I manage to get
further.

https://gist.github.com/kratsg/932ca6ff01fb489ee190ea3902c3fc73

>From what I can tell, it's not mounting the rootfs correctly (error -2) but
it seems to be hinting that I should give it an `init=` command but
that feels like something else is wrong.

Giordon

On Mon, Mar 27, 2017 at 6:00 PM Giordon Stark  wrote:

> In particular, this is all I see now:
>
> Xilinx Zynq MP First Stage Boot Loader
> Release 2016.4   Mar 27 2017  -  17:50:52
> Platform: Silicon (3.0), Running on A53-0 (64-bit) Processor, Device Name:
> XCZU9EG
> SD1 with level shifter Boot Mode
> Bitstream download to start now
> PL Configuration done successfully
>   ATF running on XCZU9EG/silicon v3/RTL5.1 at 0xfffea000
> NOTICE:  BL31: Secure code at 0x0
> NOTICE:  BL31: Non secure code at 0x0
> NOTICE:  BL31: v1.2(release):a9e3716
> NOTICE:  BL31: Built : 14:06:27, Mar  7 2017
>
> When I have:
> - FSBL.elf
> - top.bit
> - ATF.elf
> - u-boot.elf
>
> It seems like it hangs at ATF stage.
>
> On Mon, Mar 27, 2017 at 4:00 PM Giordon Stark  wrote:
>
> Hi,
>
> I attempted to get ATF included. I ran `bitbake arm-trusted-firmware` and
> then included the generated ELF in the boot image. Unfortunately, now the
> board doesn't even seem to boot at all (no messages come up in the serial
> console).
>
> I've tried looking through the documentation that Xilinx provides for ATF
> and where to include it, but there isn't any. My best guess is that it
> needs to come after the bitstream but before the u-boot. Unfortunately, I'm
> at a loss and I can't seem to do (what was much simpler and straightforward
> with Zynq-7000 series) an FSBL boot to the OS.
>
> Any tips or links to the full set of steps would be helpful.
>
> Giordon
>
> On Wed, Mar 22, 2017 at 5:46 AM Jason Wu  wrote:
>
>
>
> On 22/03/2017 3:00 PM, Giordon Stark wrote:
> > Thanks for the response!
> >
> > inline comments/questions
> >
> > On Tue, Mar 21, 2017 at 11:44 PM Jason Wu  > <mailto:jason.wu.m...@gmail.com>> wrote:
> >
> >
> >
> > On 22/03/2017 2:42 PM, Jason Wu wrote:
> > >
> > >
> > > On 22/03/2017 2:19 AM, Giordon Stark wrote:
> > >> Hi all,
> > >>
> > >> We've got a rev 1.0 board (HW-Z1-ZCU102) which we're trying to do
> an
> > >> FSBL boot (seeing the lack of success with SPL at the moment in
> the
> > >> meta-xilinx mailing list). There are a few issues:
> > >>
> > >> - uEnv.txt variables set for the device tree file as well as the
> > kernel
> > >> image do not seem to be understood by u-boot at all [it keeps
> > asking for
> > >> system.dtb or "Image" even if we set the variable correctly). For
> > now,
> > >> we just renamed the files to get things working.
> > >>
> > >> - a kernel panic occurs after we manage to change the bootargs.
> > Here is
> > >> the kernel
> > >> panic:
> > https://gist.github.com/anonymous/055a978826d0a2adaf87e7b1f3ca0c70.
> > >> This looks highly similar
> > >> to
> >
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html
> > but
> > >> I'm not sure if there was a solution?
> > >>
> > >> The uEnv.txt looks
> > >> like:
> https://gist.github.com/kratsg/0598f6965deb0c4a03bafb64d9d01c37
> > >> for us right now.
> > >>
> > >> I used the evaluation board bitstream, with Xilinx SDK (2016.4) to
> > >> create an FSBL.elf file (named fsbl.elf) as well as a boot image
> that
> > >> contains the u-boot.elf generated from bitbake (as a datafile in
> the
> > >> third slot).
> > > You need to make sure your FSBL matches the dts/dtb you are used.
> > > I am using hybrid images. I use FSBL + PMU from the system I
> generated
> > > and  ATF + U-boot + kernel + rootfs + dtb from meta-xilinx. I
> > create the
> > > vivado design base on the DTS. I did have some changes to u-boot
> and
> > > kernel dts. This will give full working system. IRC, MMC + sata is
> not
> > > working for me with SPL.
> >
> >
> > How do we make sure the FSBL matches the dts/dtb we are using? As far as
> > I can tell, it is built based on the bitstream file given, and I j

Re: [meta-xilinx] Kernel Panic: SD Boot on zcu102-zynqmp

[Giordon Stark]

In particular, this is all I see now:

Xilinx Zynq MP First Stage Boot Loader
Release 2016.4   Mar 27 2017  -  17:50:52
Platform: Silicon (3.0), Running on A53-0 (64-bit) Processor, Device Name:
XCZU9EG
SD1 with level shifter Boot Mode
Bitstream download to start now
PL Configuration done successfully
  ATF running on XCZU9EG/silicon v3/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x0
NOTICE:  BL31: v1.2(release):a9e3716
NOTICE:  BL31: Built : 14:06:27, Mar  7 2017

When I have:
- FSBL.elf
- top.bit
- ATF.elf
- u-boot.elf

It seems like it hangs at ATF stage.

On Mon, Mar 27, 2017 at 4:00 PM Giordon Stark  wrote:

> Hi,
>
> I attempted to get ATF included. I ran `bitbake arm-trusted-firmware` and
> then included the generated ELF in the boot image. Unfortunately, now the
> board doesn't even seem to boot at all (no messages come up in the serial
> console).
>
> I've tried looking through the documentation that Xilinx provides for ATF
> and where to include it, but there isn't any. My best guess is that it
> needs to come after the bitstream but before the u-boot. Unfortunately, I'm
> at a loss and I can't seem to do (what was much simpler and straightforward
> with Zynq-7000 series) an FSBL boot to the OS.
>
> Any tips or links to the full set of steps would be helpful.
>
> Giordon
>
> On Wed, Mar 22, 2017 at 5:46 AM Jason Wu  wrote:
>
>
>
> On 22/03/2017 3:00 PM, Giordon Stark wrote:
> > Thanks for the response!
> >
> > inline comments/questions
> >
> > On Tue, Mar 21, 2017 at 11:44 PM Jason Wu  > <mailto:jason.wu.m...@gmail.com>> wrote:
> >
> >
> >
> > On 22/03/2017 2:42 PM, Jason Wu wrote:
> > >
> > >
> > > On 22/03/2017 2:19 AM, Giordon Stark wrote:
> > >> Hi all,
> > >>
> > >> We've got a rev 1.0 board (HW-Z1-ZCU102) which we're trying to do
> an
> > >> FSBL boot (seeing the lack of success with SPL at the moment in
> the
> > >> meta-xilinx mailing list). There are a few issues:
> > >>
> > >> - uEnv.txt variables set for the device tree file as well as the
> > kernel
> > >> image do not seem to be understood by u-boot at all [it keeps
> > asking for
> > >> system.dtb or "Image" even if we set the variable correctly). For
> > now,
> > >> we just renamed the files to get things working.
> > >>
> > >> - a kernel panic occurs after we manage to change the bootargs.
> > Here is
> > >> the kernel
> > >> panic:
> > https://gist.github.com/anonymous/055a978826d0a2adaf87e7b1f3ca0c70.
> > >> This looks highly similar
> > >> to
> >
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html
> > but
> > >> I'm not sure if there was a solution?
> > >>
> > >> The uEnv.txt looks
> > >> like:
> https://gist.github.com/kratsg/0598f6965deb0c4a03bafb64d9d01c37
> > >> for us right now.
> > >>
> > >> I used the evaluation board bitstream, with Xilinx SDK (2016.4) to
> > >> create an FSBL.elf file (named fsbl.elf) as well as a boot image
> that
> > >> contains the u-boot.elf generated from bitbake (as a datafile in
> the
> > >> third slot).
> > > You need to make sure your FSBL matches the dts/dtb you are used.
> > > I am using hybrid images. I use FSBL + PMU from the system I
> generated
> > > and  ATF + U-boot + kernel + rootfs + dtb from meta-xilinx. I
> > create the
> > > vivado design base on the DTS. I did have some changes to u-boot
> and
> > > kernel dts. This will give full working system. IRC, MMC + sata is
> not
> > > working for me with SPL.
> >
> >
> > How do we make sure the FSBL matches the dts/dtb we are using? As far as
> > I can tell, it is built based on the bitstream file given, and I just
> > hoped (right now) that the evaluation board's bitstream file provided by
> > Vivado SDK matched the DTS file provided by meta-xilinx [this might be
> > the case]. In the future, not sure how to do this if I'm given just the
> > DTS/DTB.
> One way to do it is to generate the dts with the HDF, just to be sure
> the system is not far different between two dts/dtb.
> >
> >
> > >
> > >>
> > >> *Some side notes:*
> > >>

Re: [meta-xilinx] Kernel Panic: SD Boot on zcu102-zynqmp

[Giordon Stark]

Hi,

I attempted to get ATF included. I ran `bitbake arm-trusted-firmware` and
then included the generated ELF in the boot image. Unfortunately, now the
board doesn't even seem to boot at all (no messages come up in the serial
console).

I've tried looking through the documentation that Xilinx provides for ATF
and where to include it, but there isn't any. My best guess is that it
needs to come after the bitstream but before the u-boot. Unfortunately, I'm
at a loss and I can't seem to do (what was much simpler and straightforward
with Zynq-7000 series) an FSBL boot to the OS.

Any tips or links to the full set of steps would be helpful.

Giordon

On Wed, Mar 22, 2017 at 5:46 AM Jason Wu  wrote:

>
>
> On 22/03/2017 3:00 PM, Giordon Stark wrote:
> > Thanks for the response!
> >
> > inline comments/questions
> >
> > On Tue, Mar 21, 2017 at 11:44 PM Jason Wu  > <mailto:jason.wu.m...@gmail.com>> wrote:
> >
> >
> >
> > On 22/03/2017 2:42 PM, Jason Wu wrote:
> > >
> > >
> > > On 22/03/2017 2:19 AM, Giordon Stark wrote:
> > >> Hi all,
> > >>
> > >> We've got a rev 1.0 board (HW-Z1-ZCU102) which we're trying to do
> an
> > >> FSBL boot (seeing the lack of success with SPL at the moment in
> the
> > >> meta-xilinx mailing list). There are a few issues:
> > >>
> > >> - uEnv.txt variables set for the device tree file as well as the
> > kernel
> > >> image do not seem to be understood by u-boot at all [it keeps
> > asking for
> > >> system.dtb or "Image" even if we set the variable correctly). For
> > now,
> > >> we just renamed the files to get things working.
> > >>
> > >> - a kernel panic occurs after we manage to change the bootargs.
> > Here is
> > >> the kernel
> > >> panic:
> > https://gist.github.com/anonymous/055a978826d0a2adaf87e7b1f3ca0c70.
> > >> This looks highly similar
> > >> to
> >
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html
> > but
> > >> I'm not sure if there was a solution?
> > >>
> > >> The uEnv.txt looks
> > >> like:
> https://gist.github.com/kratsg/0598f6965deb0c4a03bafb64d9d01c37
> > >> for us right now.
> > >>
> > >> I used the evaluation board bitstream, with Xilinx SDK (2016.4) to
> > >> create an FSBL.elf file (named fsbl.elf) as well as a boot image
> that
> > >> contains the u-boot.elf generated from bitbake (as a datafile in
> the
> > >> third slot).
> > > You need to make sure your FSBL matches the dts/dtb you are used.
> > > I am using hybrid images. I use FSBL + PMU from the system I
> generated
> > > and  ATF + U-boot + kernel + rootfs + dtb from meta-xilinx. I
> > create the
> > > vivado design base on the DTS. I did have some changes to u-boot
> and
> > > kernel dts. This will give full working system. IRC, MMC + sata is
> not
> > > working for me with SPL.
> >
> >
> > How do we make sure the FSBL matches the dts/dtb we are using? As far as
> > I can tell, it is built based on the bitstream file given, and I just
> > hoped (right now) that the evaluation board's bitstream file provided by
> > Vivado SDK matched the DTS file provided by meta-xilinx [this might be
> > the case]. In the future, not sure how to do this if I'm given just the
> > DTS/DTB.
> One way to do it is to generate the dts with the HDF, just to be sure
> the system is not far different between two dts/dtb.
> >
> >
> > >
> > >>
> > >> *Some side notes:*
> > >> - the boot from SD Card was not possible until we set the
> switches to
> > >> SW[4:1] = 0001 (the switch at "1" is flipped to "ON" side)
> instead of
> > >> the suggested 0x5 or 0xE (neither of which worked).
> > > IRC 0xE is 0001 on the sw[4:1].
> >
> >
> > This may be because it's upside-down a bit. It's been very confusing
> > trying to figure out what is 1/0 for the switches.
> :). IRC, i was checking it in the xsdb. You can read the mode in xsdb.
> "puts [mrd 0xFF5E0200]" should give you E.
>
> >
> >
> > >> - our bootargs initially set to "root=/dev/mmcblk0p2 rw rootwait"
&g

Re: [meta-xilinx] JTAG versus OS - XADC differences in temperature

[Giordon Stark]

I should note that the reason I ask is that when I program the board
without loading the OS - i find that the Hardware Manager's output over
JTAG is working as expected. When I program the board, and boot from the
SDCard - I find that the JTAG output is not working correctly.

On Fri, Mar 24, 2017 at 1:40 PM Giordon Stark  wrote:

> Hi,
>
> I'm not sure if anyone's seen this before or if I'm doing something wrong.
> http://i.imgur.com/KPRvx42.png - here's a screenshot of what I'm seeing
> through the Hardware Manager for a Zynq-7000 (7020 evaluation) board. In
> the OS, I combine the numbers from three memory-mapped files to calculate
> the temperature of the board.
>
> On average, i'm seeing ~42C from the OS via command line, while I'm seeing
> ~47C over JTAG in the hardware manager. Is there a known discrepancy? Which
> do I trust more?
>
> Command I run:
>
> $ cat /sys/devices/soc0/amba@0/f8007100.ps7-xadc/iio\:device0/in_temp0_*
> | tr '\n' '\t' | awk '{print ($1 + $2)*$3}'
>
> Note that
>
> $ cat /sys/devices/soc0/amba@0/f8007100.ps7-xadc/iio\:device0/in_temp0_*
>
> produces an output like
>
> -2219
> 2584
> 123.040771484
>
> So it just looks like I'm meant to add the first two, and multiply by the
> 3rd -- and this gives me a number in milliCelsius.
>
> Giordon
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] JTAG versus OS - XADC differences in temperature

[Giordon Stark]

Hi,

I'm not sure if anyone's seen this before or if I'm doing something wrong.
http://i.imgur.com/KPRvx42.png - here's a screenshot of what I'm seeing
through the Hardware Manager for a Zynq-7000 (7020 evaluation) board. In
the OS, I combine the numbers from three memory-mapped files to calculate
the temperature of the board.

On average, i'm seeing ~42C from the OS via command line, while I'm seeing
~47C over JTAG in the hardware manager. Is there a known discrepancy? Which
do I trust more?

Command I run:

$ cat /sys/devices/soc0/amba@0/f8007100.ps7-xadc/iio\:device0/in_temp0_* |
tr '\n' '\t' | awk '{print ($1 + $2)*$3}'

Note that

$ cat /sys/devices/soc0/amba@0/f8007100.ps7-xadc/iio\:device0/in_temp0_*

produces an output like

-2219
2584
123.040771484

So it just looks like I'm meant to add the first two, and multiply by the
3rd -- and this gives me a number in milliCelsius.

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Kernel Panic: SD Boot on zcu102-zynqmp

[Giordon Stark]

Thanks for the response!

inline comments/questions

On Tue, Mar 21, 2017 at 11:44 PM Jason Wu  wrote:

>
>
> On 22/03/2017 2:42 PM, Jason Wu wrote:
> >
> >
> > On 22/03/2017 2:19 AM, Giordon Stark wrote:
> >> Hi all,
> >>
> >> We've got a rev 1.0 board (HW-Z1-ZCU102) which we're trying to do an
> >> FSBL boot (seeing the lack of success with SPL at the moment in the
> >> meta-xilinx mailing list). There are a few issues:
> >>
> >> - uEnv.txt variables set for the device tree file as well as the kernel
> >> image do not seem to be understood by u-boot at all [it keeps asking for
> >> system.dtb or "Image" even if we set the variable correctly). For now,
> >> we just renamed the files to get things working.
> >>
> >> - a kernel panic occurs after we manage to change the bootargs. Here is
> >> the kernel
> >> panic:
> https://gist.github.com/anonymous/055a978826d0a2adaf87e7b1f3ca0c70.
> >> This looks highly similar
> >> to
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html
> but
> >> I'm not sure if there was a solution?
> >>
> >> The uEnv.txt looks
> >> like: https://gist.github.com/kratsg/0598f6965deb0c4a03bafb64d9d01c37
> >> for us right now.
> >>
> >> I used the evaluation board bitstream, with Xilinx SDK (2016.4) to
> >> create an FSBL.elf file (named fsbl.elf) as well as a boot image that
> >> contains the u-boot.elf generated from bitbake (as a datafile in the
> >> third slot).
> > You need to make sure your FSBL matches the dts/dtb you are used.
> > I am using hybrid images. I use FSBL + PMU from the system I generated
> > and  ATF + U-boot + kernel + rootfs + dtb from meta-xilinx. I create the
> > vivado design base on the DTS. I did have some changes to u-boot and
> > kernel dts. This will give full working system. IRC, MMC + sata is not
> > working for me with SPL.
>

How do we make sure the FSBL matches the dts/dtb we are using? As far as I
can tell, it is built based on the bitstream file given, and I just hoped
(right now) that the evaluation board's bitstream file provided by Vivado
SDK matched the DTS file provided by meta-xilinx [this might be the case].
In the future, not sure how to do this if I'm given just the DTS/DTB.


> >
> >>
> >> *Some side notes:*
> >> - the boot from SD Card was not possible until we set the switches to
> >> SW[4:1] = 0001 (the switch at "1" is flipped to "ON" side) instead of
> >> the suggested 0x5 or 0xE (neither of which worked).
> > IRC 0xE is 0001 on the sw[4:1].
>

This may be because it's upside-down a bit. It's been very confusing trying
to figure out what is 1/0 for the switches.


> >> - our bootargs initially set to "root=/dev/mmcblk0p2 rw rootwait" but
> >> everything hung at the "Starting kernel..." stage
> >>   - changing the bootargs to "earlycon=cdns,mmio,0xFF00,115200n8
> >> root=/dev/mmcblk0p2 rw rootwait cma=256M" gets us past the hanging
> >> "Starting kernel..." stage, but leads to the kernel panic above
> >> - we are using "morty" everywhere. Should I change to master for
> >> meta-xilinx?
> > I think the best is for you to post your kernel panic message.
> my bad, i did not see you have post the kernel panic log. The problem
> you have is because you did not have the ATF loaded. You need to create
> your boot.bin with atf.
>

How do we create the boot.bin with ATF (ARM trusted firmware)? How do you
know it's because we do not have ATF loaded?

Thanks,

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Kernel Panic: SD Boot on zcu102-zynqmp

[Giordon Stark]

Hi all,

We've got a rev 1.0 board (HW-Z1-ZCU102) which we're trying to do an FSBL
boot (seeing the lack of success with SPL at the moment in the meta-xilinx
mailing list). There are a few issues:

- uEnv.txt variables set for the device tree file as well as the kernel
image do not seem to be understood by u-boot at all [it keeps asking for
system.dtb or "Image" even if we set the variable correctly). For now, we
just renamed the files to get things working.

- a kernel panic occurs after we manage to change the bootargs. Here is the
kernel panic:
https://gist.github.com/anonymous/055a978826d0a2adaf87e7b1f3ca0c70. This
looks highly similar to
https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html but
I'm not sure if there was a solution?

The uEnv.txt looks like:
https://gist.github.com/kratsg/0598f6965deb0c4a03bafb64d9d01c37  for us
right now.

I used the evaluation board bitstream, with Xilinx SDK (2016.4) to create
an FSBL.elf file (named fsbl.elf) as well as a boot image that contains the
u-boot.elf generated from bitbake (as a datafile in the third slot).

*Some side notes:*
- the boot from SD Card was not possible until we set the switches to
SW[4:1] = 0001 (the switch at "1" is flipped to "ON" side) instead of the
suggested 0x5 or 0xE (neither of which worked).
- our bootargs initially set to "root=/dev/mmcblk0p2 rw rootwait" but
everything hung at the "Starting kernel..." stage
  - changing the bootargs to "earlycon=cdns,mmio,0xFF00,115200n8
root=/dev/mmcblk0p2 rw rootwait cma=256M" gets us past the hanging
"Starting kernel..." stage, but leads to the kernel panic above
- we are using "morty" everywhere. Should I change to master for
meta-xilinx?

Does anyone know what else we need to do?

Thanks!

Giordon
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] SPL Method on ZCU102 - Missing files?

[Giordon Stark]

Also, can you point me to instructions on applying this sort of patch? All
I can imagine is you clone the meta-xilinx repo, and make your changes in
it.

Giordon

On Tue, Mar 7, 2017 at 10:55 AM Giordon Stark  wrote:

> Thanks a lot! We've got a board over here in our e-shop so I'll poke at
> this and get back to you soon. It's been somewhat difficult to debug issues
> with booting because nothing shows up on the serial when trying to load the
> SD Card (presumably because the boot.bin isn't working right).
>
> Giordon
>
> On Tue, Mar 7, 2017 at 10:49 AM Nathan Rossi 
> wrote:
>
> On 8 March 2017 at 01:33, Giordon Stark  wrote:
> > Thanks for the response. Short followups.
> >
> > On Tue, Mar 7, 2017 at 9:04 AM Nathan Rossi 
> wrote:
> >>
> >> On 7 March 2017 at 15:40, Giordon Stark  wrote:
> >> > I re-ran on the latest distro (I was on kogoroth and switched to
> morty).
> >> > Here's what I see in the list of files:
> >> > https://gist.github.com/kratsg/04abfb458ae95a8e167dc08cc1250e37
> >> >
> >> > On Mon, Mar 6, 2017 at 6:14 PM Oleg K Dzhimiev 
> wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >>> I have a few questions based on this:
> >> >>> - where is boot.bin?
> >> >>> - where is u-boot.img / u-boot-dtb.img?
> >> >>
> >> >>
> >> >> Check with the poky/meta/recipes-bsp/u-boot/u-boot.inc look for
> >> >> "deploy"
> >> >> function.
> >> >> Also, boot.bin should be the smallest in size.
> >> >
> >> >
> >> > I see the deploy function:
> >> >
> >> >
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc#n203
> >> > but this looks really confusing and hard to read. Comparing to what I
> >> > see
> >> > here
> >> >
> >> > (
> https://github.com/Xilinx/meta-xilinx/blob/morty/conf/machine/include/machine-xilinx-default.inc
> ),
> >> > it looks like "SPL_BINARY" is not set and would need to be set to get
> >> > this
> >> > working. I don't know where to set this. It also looks like,
> similarly,
> >> > UBOOT_ENV is not set as well. So uEnv.txt does not get made.
> >>
> >> Currently ZCU102 does not have boot.bin generated by default, for
> >> couple reasons.
> >>
> >> 1. No one has sent patches for it, and I don't have hardware so I
> >> haven't tested or been able to look at getting it working
> >> 2. u-boot-xlnx has a few different 'zcu102' configs/psu_init setups
> >>
> >> To get it working, SPL_BINARY = "spl/boot.bin" should be enough (you
> >> can set this in conf/local.conf or in the machine.conf) as the
> >> boot.bin should be being built regardless.
> >
> >
> > How do you know that this needs to be set to spl/boot.bin instead of
> > boot.bin? Where does this point to?
>
> It is just pointing to the file that is copied/deployed from the
> u-boot build output.
>
> https://github.com/Xilinx/u-boot-xlnx/blob/master/scripts/Makefile.spl#L156
>
> And for the xilinx boot.bin files, they always get built to spl/.
>
> >
> >>
> >> But you will need to use
> >> u-boot-xlnx, and you will likely need to select a psu_init* that works
> >> for your board
> >> (https://github.com/Xilinx/u-boot-xlnx/tree/master/board/xilinx/zynqmp
> >> there is a few for zcu102).
> >
> >
> > How do you select one? I don't see many options in
> >
> https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc
>
> Source modification, you need to change the defconfig for the board.
> You would need to do it via a patch.
>
> > .
> >
> >>
> >>
> >> Additionally for custom psu_init files, the platform-init recipe
> >> provider setup is not there just yet. There are some patches on my
> >> nrossi/wip branch
> >> (https://github.com/nathanrossi/meta-xilinx/tree/nrossi/wip) for it if
> >> interested.
> >
> >
> > For now, i think the default will work fine as we want to boot the zynqmp
> > via the SPL method. After this, we'll probably want to add custom
> psu_init
> > files that configure power for external FPGAs later.
> >
> >>
> >>
> >> >
> >> >>
> >> >>
> >> >>>
&g

Re: [meta-xilinx] SPL Method on ZCU102 - Missing files?

[Giordon Stark]

Thanks a lot! We've got a board over here in our e-shop so I'll poke at
this and get back to you soon. It's been somewhat difficult to debug issues
with booting because nothing shows up on the serial when trying to load the
SD Card (presumably because the boot.bin isn't working right).

Giordon

On Tue, Mar 7, 2017 at 10:49 AM Nathan Rossi  wrote:

> On 8 March 2017 at 01:33, Giordon Stark  wrote:
> > Thanks for the response. Short followups.
> >
> > On Tue, Mar 7, 2017 at 9:04 AM Nathan Rossi 
> wrote:
> >>
> >> On 7 March 2017 at 15:40, Giordon Stark  wrote:
> >> > I re-ran on the latest distro (I was on kogoroth and switched to
> morty).
> >> > Here's what I see in the list of files:
> >> > https://gist.github.com/kratsg/04abfb458ae95a8e167dc08cc1250e37
> >> >
> >> > On Mon, Mar 6, 2017 at 6:14 PM Oleg K Dzhimiev 
> wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >>> I have a few questions based on this:
> >> >>> - where is boot.bin?
> >> >>> - where is u-boot.img / u-boot-dtb.img?
> >> >>
> >> >>
> >> >> Check with the poky/meta/recipes-bsp/u-boot/u-boot.inc look for
> >> >> "deploy"
> >> >> function.
> >> >> Also, boot.bin should be the smallest in size.
> >> >
> >> >
> >> > I see the deploy function:
> >> >
> >> >
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc#n203
> >> > but this looks really confusing and hard to read. Comparing to what I
> >> > see
> >> > here
> >> >
> >> > (
> https://github.com/Xilinx/meta-xilinx/blob/morty/conf/machine/include/machine-xilinx-default.inc
> ),
> >> > it looks like "SPL_BINARY" is not set and would need to be set to get
> >> > this
> >> > working. I don't know where to set this. It also looks like,
> similarly,
> >> > UBOOT_ENV is not set as well. So uEnv.txt does not get made.
> >>
> >> Currently ZCU102 does not have boot.bin generated by default, for
> >> couple reasons.
> >>
> >> 1. No one has sent patches for it, and I don't have hardware so I
> >> haven't tested or been able to look at getting it working
> >> 2. u-boot-xlnx has a few different 'zcu102' configs/psu_init setups
> >>
> >> To get it working, SPL_BINARY = "spl/boot.bin" should be enough (you
> >> can set this in conf/local.conf or in the machine.conf) as the
> >> boot.bin should be being built regardless.
> >
> >
> > How do you know that this needs to be set to spl/boot.bin instead of
> > boot.bin? Where does this point to?
>
> It is just pointing to the file that is copied/deployed from the
> u-boot build output.
>
> https://github.com/Xilinx/u-boot-xlnx/blob/master/scripts/Makefile.spl#L156
>
> And for the xilinx boot.bin files, they always get built to spl/.
>
> >
> >>
> >> But you will need to use
> >> u-boot-xlnx, and you will likely need to select a psu_init* that works
> >> for your board
> >> (https://github.com/Xilinx/u-boot-xlnx/tree/master/board/xilinx/zynqmp
> >> there is a few for zcu102).
> >
> >
> > How do you select one? I don't see many options in
> >
> https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc
>
> Source modification, you need to change the defconfig for the board.
> You would need to do it via a patch.
>
> > .
> >
> >>
> >>
> >> Additionally for custom psu_init files, the platform-init recipe
> >> provider setup is not there just yet. There are some patches on my
> >> nrossi/wip branch
> >> (https://github.com/nathanrossi/meta-xilinx/tree/nrossi/wip) for it if
> >> interested.
> >
> >
> > For now, i think the default will work fine as we want to boot the zynqmp
> > via the SPL method. After this, we'll probably want to add custom
> psu_init
> > files that configure power for external FPGAs later.
> >
> >>
> >>
> >> >
> >> >>
> >> >>
> >> >>>
> >> >>> - where is the root filesystem (eg: to populate the second
> partition)?
> >> >>> I
> >> >>> only see a ramdisk which goes in the first partition (*cpio.gz)
> >> >>
> >> >>