On Wed, Oct 18, 2017 at 8:17 AM, Nathan Rossi <nat...@nathanrossi.com> wrote:
> On 13 October 2017 at 22:57, Nathan Rossi <nat...@nathanrossi.com> wrote:
>> On 13 October 2017 at 03:59, Manjukumar Harthikote Matha
>> <manju...@xilinx.com> wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
>>>> Sent: Tuesday, October 10, 2017 11:51 PM
>>>> To: Manjukumar Harthikote Matha <manju...@xilinx.com>
>>>> Cc: Alistair Francis <alistai...@gmail.com>; meta-xilinx@yoctoproject.org
>>>> Subject: Re: [meta-xilinx] [PATCH 5/7] Update recipes for Xilinx v2017.3
>>>> release
>>>>
>>>> On 11 October 2017 at 09:05, Manjukumar Harthikote Matha
>>>> <manju...@xilinx.com> wrote:
>>>> > Hi Nathan,
>>>> >
>>>> >> -----Original Message-----
>>>> >> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>>>> >> boun...@yoctoproject.org] On Behalf Of Alistair Francis
>>>> >> Sent: Tuesday, October 10, 2017 3:13 PM
>>>> >> To: Nathan Rossi <nat...@nathanrossi.com>
>>>> >> Cc: meta-xilinx@yoctoproject.org
>>>> >> Subject: Re: [meta-xilinx] [PATCH 5/7] Update recipes for Xilinx
>>>> >> v2017.3 release
>>>> >>
>>>> >> On Sat, Oct 7, 2017 at 2:57 AM, Nathan Rossi <nat...@nathanrossi.com>
>>>> >> wrote:
>>>> >> > Update the arm-trusted-firmware, pmu-firmware, u-boot-xlnx,
>>>> >> > linux-xlnx, qemu-xilinx and qemu-devicetrees recipes for to the
>>>> >> > 'xilinx-v2017.3'
>>>> >> > release tags.
>>>> >> >
>>>> >> > Drop/update existing patches where applicable.
>>>> >> >
>>>> >> > Signed-off-by: Nathan Rossi <nat...@nathanrossi.com>
>>>> >>
>>>> >> Reviewed-by: Alistair Francis <alistair.fran...@xilinx.com>
>>>> >>
>>>> >> Thanks,
>>>> >> Alistair
>>>> >>
>>>> >> > ---
>>>> >
>>>> > <.....>
>>>> >
>>>> >> > diff --git
>>>> >> > a/recipes-bsp/u-boot/u-boot-xlnx/v2017.1/arm-zynqmp-xilinx_zynqmp.h
>>>> >> > -Au
>>>> >> > to-boot-in-JTAG-if-imag.patch
>>>> >> > b/recipes-bsp/u-boot/u-boot-xlnx/v2017.3/arm-zynqmp-xilinx_zynqmp.h
>>>> >> > -Au
>>>> >> > to-boot-in-JTAG-if-imag.patch
>>>> >> > similarity index 100%
>>>> >> > rename from
>>>> >> > recipes-bsp/u-boot/u-boot-xlnx/v2017.1/arm-zynqmp-xilinx_zynqmp.h-A
>>>> >> > uto -boot-in-JTAG-if-imag.patch rename to
>>>> >> > recipes-bsp/u-boot/u-boot-xlnx/v2017.3/arm-zynqmp-xilinx_zynqmp.h-A
>>>> >> > uto -boot-in-JTAG-if-imag.patch diff --git
>>>> >
>>>> > meta-xilinx should not be a holding ground for non upstreamable patches.
>>>> > Implementation has to be from kernel-fitimage.bbclass inclusion.
>>>> > Please don't add this in meta-xilinx
>>>> >
>>>>
>>>> This is not adding it, just moving the existing patch to apply to the
>>>> newer u-boot
>>>> recipe.
>>>>
>>>
>>> Agreed, we are porting a non-upstreamable patch regardless.
>>>> It does however need to go though.
>>>
>>> I completely disagree, it's not an option to proceed. I cannot accept this
>>> path.
>>
>> I'm not sure what you mean exactly, there are a few non-upstreamable
>> patches in meta-xilinx. Some of them were contributed by you.
>>
>> This patch even though it is primarily just a BSP/runqemu config patch
>> is also an outlier in that it has an implementation that was generic
>> enough to be considered for upstream inclusion.
>>
>> If it is just a case of having the Upstream-Status field updated to
>> represent this from Denied to "Inappropriate [runqemu bsp config]", I
>> can update the patch.
>>
>>>
>>> But I have not had a chance to sort that out yet,
>>>> the biggest problem with using fit is that it would need to embed the
>>>> rootfs (which is
>>>> passed at runqemu time). Which means that using a disk interface is a
>>>> better way to
>>>> go, but since qemu boots u-boot instead of a kernel directly it is not so
>>>> straight
>>>> forward to pass the root= param to the kernel.
>>>>
>>>
>>> We could also look into kernel-fitimage.bbclass to introduce the fit to
>>> resolve.
>>
>> For reference simply changing to fitimage only moves the goal post,
>> since a patch would still need to be made to u-boot, and there is no
>> guarantee that it would be accepted upstream.
>>
>> I had been looking at setting it up so that for zcu102 runqemu boots
>> from a full disk image, which was essentially the same as a image that
>> would be booted on the board itself. This would avoid any qemu/runqemu
>> specific changes and would help validate board boot flows with
>> runqemu. However I have not looked into the details, so there might be
>> issues with that approach too.
>
> So I had a better look at this, there are some issues to fix but
> otherwise this works nicely booting from a SD disk image. I've added
> the boot log below. Going to hold off doing anything further on this
> until I get opinions on the idea/implementation.
>
> I have pushed the WIP changes here:
> https://github.com/nathanrossi/meta-xilinx/commit/2df8e3b6131d4909814cfa565041d7dcc203f65a
Overall I think this is a good direction.
Ideally what would be nice is a single flow that works on QEMU and HW
with the same images. I think SD booting gets us there as we can
attach a SD card image to QEMU OR dd the SD card image to a physical
SD card to boot.
Manju mentioned there is some SD card image support in Yocto, maybe
that is worth using to produce a single image that supports QEMU and
HW?
I guess FSBL will throw a spanner in the works there, but hopefully we
can set it up so SD boot works with FSBL on HW and u-boot SPL on QEMU.
Thanks,
Alistair
>
> There are however two changes that need to be made to oe-core to have
> this build/boot work correctly:
>
> 1. is a bit of a hack, but QEMU rounds down the image size for SD
> cards to match the advertise-able size. Essentially the block device
> needs to be a multiple of 256K. This change handles that by setting up
> the sparse image file to be padded to the boundary.
>
> 2. just ignores "vmtypes" overrides if the QB_ROOTFS_OPT is set, this
> change seems sane to upstream.
>
> diff --git a/scripts/lib/wic/plugins/imager/direct.py
> b/scripts/lib/wic/plugins/imager/direct.py
> index 60317eed22..e54d6f7364 100644
> --- a/scripts/lib/wic/plugins/imager/direct.py
> +++ b/scripts/lib/wic/plugins/imager/direct.py
> @@ -444,6 +444,12 @@ class PartitionedImage():
>
> self.min_size *= self.sector_size
>
> + logger.debug("Disk size was minimum %d bytes", self.min_size)
> + min_size_boundary = self.min_size % (256 * 1024)
> + if min_size_boundary != 0:
> + logger.debug("Disk size was not on boundary, over by %d
> bytes", min_size_boundary)
> + self.min_size += (256 * 1024) - min_size_boundary
> +
> def _create_partition(self, device, parttype, fstype, start, size):
> """ Create a partition on an image described by the 'device'
> object. """
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index df76270904..e7a3da1f4e 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -1007,7 +1007,8 @@ class BaseConfig(object):
> self.rootfs_options = '-initrd %s' % self.rootfs
> else:
> vm_drive = ''
> - if self.fstype in self.vmtypes:
> + # Only apply vmtype rules if a custom rootfs_opt was not set
> + if self.fstype in self.vmtypes and not(qb_rootfs_opt):
> if self.fstype == 'iso':
> vm_drive = '-drive file=%s,if=virtio,media=cdrom'
> % self.rootfs
> elif self.get('QB_DRIVE_TYPE'):
>
> Regards,
> Nathan
>
> == Boot log ==
>
> PMU Firmware 2017.3 Oct 18 2017 17:20:41
> <debug_uart> Debug uart enabled
>
> U-Boot SPL 2017.01 (Oct 18 2017 - 21:51:59)
> EL Level: EL3
> Trying to boot from MMC1
> reading u-boot.bin
> reading atf-uboot.ub
> reading atf-uboot.ub
> NOTICE: ATF running on XCZUUNKN/QEMU v1/RTL0.0 at 0xfffea000, with PMU
> firmware
> NOTICE: BL31: Secure code at 0x0
> NOTICE: BL31: Non secure code at 0x8000000
> NOTICE: BL31: v1.3(release):f9b244beaa
> NOTICE: BL31: Built : 17:35:00, Oct 18 2017
> PMUFW: v0.3
>
>
> U-Boot 2017.01 (Oct 18 2017 - 21:51:59 +1000) Xilinx ZynqMP ZCU102 rev1.0
>
> I2C: ready
> DRAM: 4 GiB
> EL Level: EL2
> Chip ID: xczuunkn
> MMC: sdhci@ff170000: 0 (SD)
> reading uboot.env
>
> ** Unable to read "uboot.env" from mmc0:1 **
> Using default environment
>
> In: serial@ff000000
> Out: serial@ff000000
> Err: serial@ff000000
> Bootmode: SD_MODE
> Net: ZYNQ GEM: ff0e0000, phyaddr c, interface rgmii-id
> I2C EEPROM MAC address read failed
>
> Warning: ethernet@ff0e0000 (eth0) using random MAC address - fe:40:e7:4e:c5:37
> eth0: ethernet@ff0e0000
> Hit any key to stop autoboot: 0
> switch to partitions #0, OK
> mmc0 is current device
> Device: sdhci@ff170000
> Manufacturer ID: aa
> OEM: 5859
> Name: QEMU!
> Tran Speed: 25000000
> Rd Block Len: 512
> SD version 1.0
> High Capacity: No
> Capacity: 37.8 MiB
> Bus Width: 4-bit
> Erase Group Size: 512 Bytes
> reading uEnv.txt
> 498 bytes read in 7 ms (69.3 KiB/s)
> Loaded environment from uEnv.txt
> Importing environment from SD ...
> Running uenvcmd ...
> reading Image
> 13238784 bytes read in 2223 ms (5.7 MiB/s)
> reading Image-zynqmp-zcu102-rev1.0.dtb
> 37381 bytes read in 17 ms (2.1 MiB/s)
> ## Flattened Device Tree blob at 04000000
> Booting using the fdt blob at 0x4000000
> Loading Device Tree to 000000000fff3000, end 000000000ffff204 ... OK
>
> Starting kernel ...
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> ...
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 1034240
> [ 0.000000] Kernel command line: earlycon clk_ignore_unused
> rootfstype=ext4 root=/dev/mmcblk0p2 rw rootwait
> ...
> [ 9.107357] xilinx-drm xilinx_drm: fb0: frame buffer device
> [ 9.113044] mmc0: new SD card at address 4567
> [ 9.120224] mmcblk0: mmc0:4567 QEMU! 37.8 MiB
> [ 9.132279] mmcblk0: p1 p2
> [ 9.139120] [drm] Initialized xilinx_drm 1.0.0 20130509 on minor 0
> [ 9.147389] input: gpio-keys as /devices/platform/gpio-keys/input/input0
> [ 9.153627] rtc_zynqmp ffa60000.rtc: setting system clock to
> 2106-02-07 06:28:15 UTC (4294967295)
> [ 9.156156] clk: Not disabling unused clocks
> [ 9.157958] ALSA device list:
> [ 9.158230] #0: DisplayPort monitor
> [ 9.208373] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
> data mode. Opts: (null)
> [ 9.209312] VFS: Mounted root (ext4 filesystem) on device 179:2.
> ...
> root@zcu102-zynqmp:~# mount
> /dev/root on / type ext4 (rw,relatime,data=ordered)
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
