From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 207BC21A13484 for ; Wed, 3 May 2017 15:55:44 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id m123so2445283wma.0 for ; Wed, 03 May 2017 15:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=asSZJ3JVYRwASL9zFcrDHpB6rvV9mlgmicXh1UjR4HU=; b=XYjxyh2vE7DzcUhYl+NUNJJCiATz7qqGW3GhP1M1bDMH7rtWCOBos9XcFkB4wbSUoP srXwFJAj9e770bvP0cACHgiYmkY5LFPrc5LagQ7cezOs04Py1r+1dK1ckVkc+G8o20W+ RVRiRZpVZDsS9VBJ/rPxl6JdaFf3Ly8SR1uSE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=asSZJ3JVYRwASL9zFcrDHpB6rvV9mlgmicXh1UjR4HU=; b=mY/r7ABYl5AZ/Wia5iU1+vKK7fH1/driVEmfImAtBgJm1NZawd6LdCi/rE6Wed8QFc GMGd7snJTDk/sef3aV6i/49dPvpfZil/0l5T8lDuIzCYjVos/fc/S7XBSfudmIfFzaAg 0iP04AqL/Eetx/DrjYervJPan4lCNj/OyUqaV6x956BPSAtk03lkt+lRZH1tite4cMwu S3YNuRa+X8VGIVEq7WgvUTgRnH6tSDVIIMk056yPLa9bv2KQWe/LUjSKEaOVrPtTJQQw eExw/+5FMJsCl+nt+kBpel3nml6IjL9JyTiE9vcOPDsfvJZBkJhHqvKm8pj+lqXz+3cP pBUQ== X-Gm-Message-State: AN3rC/5pP8QjWm5Z5x+soQq80mXx1BTG5S+2y5yIl2VDhtlYLoPPfx0g XX5+2eeSZhCGKq3l X-Received: by 10.28.234.84 with SMTP id i81mr617242wmh.138.1493852142258; Wed, 03 May 2017 15:55:42 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id s110sm617571wrc.5.2017.05.03.15.55.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 15:55:41 -0700 (PDT) Date: Wed, 3 May 2017 23:55:39 +0100 From: Leif Lindholm To: edk2-devel@lists.01.org Cc: Andrew Fish , "Kinney, Michael D" , "Richardson, Brian" , Ard Biesheuvel , Graeme Gregory , Linaro UEFI , Ryan Harkin , "haojian.zhuang@linaro.org" , Chenhui Sun , Heyi Guo , "Duran, Leo" , Marcin Wojtas , Evan Lloyd , Alan Ott Message-ID: <20170503225539.GQ1657@bivouac.eciton.net> MIME-Version: 1.0 User-Agent: Mutt/1.5.23 (2014-03-12) Subject: [RFC] migration of OpenPlatformPkg to tianocore X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:55:44 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, As some of you may be aware, I have been working around the lack of a clear upstreaming strategy for platform support by keeping such code in a dedicated repository I set up at Linaro for that purpose: https://git.linaro.org/uefi/OpenPlatformPkg.git During discussions at the last Seattle plugfest we finally agreed on the (theoretical) details of how to use the edk2-platforms repository. After that I promised to migrate OpenPlatformPkg across to the edk2-platforms and edk2-non-osi structure, with the explicit end goal from my side that this should become the master branch for each. And now, before the release of HURD 1.0, I have. Current limitations (that I can remember): - A few references to OpenPlatformPkg remain, in ways that do not appear to break any of the platform builds. Most likely this affects dead code, but in case it's been accidentally orphaned, I thought it best to - I have simply nuked all references to Ebl (used in _addition_ to the UEFI shell, which was never the intent) and the efi-toolkit ramdisk driver. - The Marvell Yukon driver that I sent out for review last week has not migrated anywhere, and so has been temporarily disabled Mike suggested I should - USB support on the LeMaker Cello board depends on the patch "OptionRomPkg: add firmware loader driver for Renesas PD72020x" sent out by Ard on 18th of April. - I have dropped some of the binary-only modules from OpenPlatformPkg, and contacted the platform owners with requests for modifications. - The git history is quite messy and will be cleaned up, but I wanted to keep the transition quite visible in the RFC. - I haven't filled anything into the Maintainers.txt files - I am in favour of moving to a fully machine-readable format with wildcards as Laszlo has proposed in the past, and think this would be an excellent point to have that discussion (which can be had separately for edk2-platforms and edk2-non-osi from edk2). - Few of the platforms complete the FV generation stage, and I've inserted a couple of silly hacks to get them to get as far as they do. I think that either I am missing some points of how PACKAGES_PATH is intended to work, or I'm simply hitting corner cases no one has come across before. I could really use some help debugging these issues. (examples below). The below depends on the 3-part series I sent out today for importing DwEmmcDxe and EfiTimeBaseLib from OpenPlatformPkg. But apart from that, I have uploaded branches called devel-OpenPlatformPkg to: https://github.com/tianocore/edk2-platforms/tree/devel-OpenPlatformPkg https://github.com/tianocore/edk2-non-osi/tree/devel-OpenPlatformPkg These branches _will_ be rebased occasionally until they get to a point where they can move out of devel- stage (and hopefully onto master). Build issue description ======================= So, one of the hopefully easier ones is what I'm seeing when trying to build the Juno platform: $ PACKAGES_PATH="/work/maint/edk2-platforms:/work/maint/edk2-non-osi" GCC5_AARCH64_PREFIX=aarch64-linux-gnu- build -a AARCH64 -t GCC5 -p Platform/ARM/Juno/ArmJuno.dsc -b RELEASE -n 9 results in: <<< GenFds.py... : error F003: Output file for RAW section could not be found for Platform/ARM/Juno/AcpiTables/AcpiTables.inf ### build.py... : error 7000: Failed to execute command GenFds -f /work/maint/edk2-platforms/Platform/ARM/Juno/ArmJuno.fdf --conf=/work/maint/edk2/Conf -o /work/maint/edk2/Build/ArmJuno/RELEASE_GCC5 -t GCC5 -b RELEASE -p /work/maint/edk2-platforms/Platform/ARM/Juno/ArmJuno.dsc -a AARCH64 -D "EFI_SOURCE=/work/maint/edk2/EdkCompatibilityPkg" -D "EDK_SOURCE=/work/maint/edk2/EdkCompatibilityPkg" -D "TOOL_CHAIN_TAG=GCC5" -D "TOOLCHAIN=GCC5" -D "TARGET=RELEASE" -D "FAMILY=GCC" -D "WORKSPACE=/work/maint/edk2" -D "EDK_TOOLS_PATH=/work/maint/edk2/BaseTools" -D "ARCH=AARCH64" -D "ECP_SOURCE=/work/maint/edk2/EdkCompatibilityPkg" [/work/maint/edk2] - Failed - >>> And when I copy and paste the above command manually, I get: <<< GenFds.py... /work/maint/edk2-platforms/Platform/ARM/Juno/ArmJuno.dsc(34): error 000E: File/directory not found in workspace /work/maint/edk2-platforms/Platform/ARM/Juno/Platform/ARM/VExpress/ArmVExpress.dsc.inc /work/maint/edk2/Platform/ARM/VExpress/ArmVExpress.dsc.inc >>> So, to an uniformed observer, it seems the portion !include Platform/ARM/VExpress/ArmVExpress.dsc.inc from ArmJuno.dsc gets expanded to "directory ArmJuno.dsc is in" + "Platform/ARM/VExpress/ArmVExpress.dsc.inc" whereas I was hoping for it to try to find a match for "Platform/ARM/VExpress/ArmVExpress.dsc.inc" along PACKAGES_PATH (and find one in edk2-platforms). I also have the impression that something similar is happening in ArmJuno.fdf for the line INF RuleOverride=ACPITABLE Platform/ARM/Juno/AcpiTables/AcpiTables.inf generating the error message from the original build command. But I'm not quite sure how to debug these issues (short of fully figuring out the innards of MultipleWorkspace.py, MetaFileParser.py and a few others). Any ideas of where to look, or even what is going on? Would these cases be expected to work? / Leif