Hi Geoff,
Historically this layer has worked regardless of Yocto upstream changes, the
reason is that it is dependent on Xilinx tools rather than Yocto OE-core
changes. One of the recent changes that happened in Thud was
device-tree.bbclass, which impacts the device tree generation. We have
Patch merged after rebase to sit on top of some checksum changes in
xsct-tarball class in 2019.1
-Original Message-
From: Jaewon Lee
Sent: Thursday, March 21, 2019 9:40 AM
To: 'Jean-Francois Dagenais'
Cc: Manjukumar Harthikote Matha ;
meta-xilinx@yoctoproject.org
Subject: RE:
Hi Jean,
Ok you are right.
This would be needed for cases where you are using the same build directory for
multiple release builds
Thanks for the patch
Thanks,
Jaewon
-Original Message-
From: Jean-Francois Dagenais
Sent: Thursday, March 21, 2019 8:33 AM
To: Jaewon Lee
Cc: Manjukumar
> -Original Message-
> From: Mike Looijmans [mailto:mike.looijm...@topic.nl]
> Sent: Thursday, March 21, 2019 5:55 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@lists.yoctoproject.org
> Subject: Re: Loading FPGA firmware broken in 2018.3
>
> On 21-03-19 07:33, Mike Looijmans
Hi guys,
> On Mar 21, 2019, at 09:03, Mike Looijmans wrote:
>
> The SD and eMMC controller has become terribly slow in 2018.3:
>
> # echo 3 > /proc/sys/vm/drop_caches
>
> # dd if=/dev/mmcblk0 of=/dev/null bs=1M count=20
> 20+0 records in
> 20+0 records out
> 20971520 bytes (20.0MB) copied,
Mike, although I have not made any measurements I have noticed in the last
few days (coincidentally I have been doing a lot of work with a ZCU102)
that the SD interface seemed a bit slow. Are you seeing this on Zynq 7K or
US+ MPSoC?
Best Regards
Peter
On Thu, 21 Mar 2019 at 16:38, Mike Looijmans
The SD and eMMC controller has become terribly slow in 2018.3:
# echo 3 > /proc/sys/vm/drop_caches
# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 4.972666 seconds, 4.0MB/s
# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=20
20+0
> On Mar 20, 2019, at 14:34, Jaewon Lee wrote:
>
> Hi Jean,
>
> Just tested this again, as long as the tarball is there in downloads, it
> will not redownload.
> If it starts with a fresh tmp directory, xsct-tarball will reextract to
> tmp/sysroots-xsct, but will not redownload tarball
>
On 21-03-19 07:33, Mike Looijmans wrote:
> On 20-03-19 18:46, Manjukumar Harthikote Matha wrote:
>> Hi Mike,
>>
>> We tested by loadingĀ both the vivado generated and bootgen generated
>> bitstreams using 2018.3 and it worked fine, we are able to see Done and leds
>> glowing as per our design.
Hi Jean,
Just tested this again, as long as the tarball is there in downloads, it will
not redownload.
If it starts with a fresh tmp directory, xsct-tarball will reextract to
tmp/sysroots-xsct, but will not redownload tarball
Please check again
Thanks,
Jaewon
-Original Message-
10 matches
Mail list logo