Re: [edk2] [PATCH edk2-platforms 3/3] Silicon/SynQuacer: add support for DEBUG output on second UART
> Date: Fri, 11 Jan 2019 17:58:44 + > From: Leif Lindholm > > On Wed, Dec 26, 2018 at 02:25:30PM +0100, Ard Biesheuvel wrote: > > On headless server systems where the PL011 serial port is the primary > > console, having DEBUG output on the same port can be annoying, since > > DEBUG output gets lost when the console driver clears the screen or > > positions the cursor using control characters. > > > > So add the ability to emit the DEBUG output on the DesignWare FUART > > (which is exposed via the LS connector on DeveloperBox) > > >From what I can tell, the DesignWare component is 8250-compatible, yet > here we're using the 16550 driver. I presume this makes no difference > for how we're using it, but could you add a comment to this effect to > the commit message? (If the FUART is indeed a 16550 clone, please add > a statement to that effect instead.) The DesignWare component is (largely) 16550-compatible. But the FIFO's are optional and if they're not included you'll end up with something that's probably closer to an 16450. I suspect in most cases SoC designers will include the FIFO's though since without them you really can't use the port at anything but the slowest speeds. Cheers, Mark ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Change EDK II to an Apache 2.0 License
> From: "Doran, Mark" > Date: Fri, 7 Dec 2018 17:44:15 + > > Hi Mark: > > Thanks for your note. The terms and conditions for EDK II code include two > elements today and they have to be considered together. Namely the > Contributor Agreement and the two clause BSD outbound terms. Together those > terms sum to a direct equivalent of the terms contained in the Apache 2.0. > As such the advice we have received confirms that in practical terms > changing the existing Contributor Agreement and code license tuple to the > singular Apache 2.0 should not make any material difference to contributors > or consumers of the EDK II code. In other words, if you are already > supporting platforms that include code under the existing T's & C's then the > proposed change should not be an impediment to continuing that or supporting > future platforms based on EDK II code. But the contributor agreement only applies for people that want to contribute their code back to the EDK II codebase. For end-users of the code, or people that want to simply distribute the code or binaries, Apacche 2.0 adds several additional restrictions over two clause BSD. > I recognize that changing something like this is somewhat unusual, but there > are precedents (OpenSSL for example). On balance we believe the benefits of > switching to an OSI-approved license formulation and removing the need for > future contributors to sign up to a Contributor Agreement outweigh the > effort the project will make to effect the change. Both of those results > should make it easier for people to jump in and work on the code -- and > that's what we are after here: taking away potential barriers to > participation. Funny you mention OpenSSL. That was a pretty controversial move. Several code authors did not agree with the license change and they had to rewrite some of the codebase to replace that code. Their original plan was also to simply change the license on code from authors that they couldn't track down. Not sure if they followed through on that, but if they did, that's totally unacceptable. Since the license change, code from OpenSSL can no longer be integrated into OpenBSD. And as a consequence software like OpenSSH is slowly moving from away from using OpenSSL code, integrating BSD-licensed implementations of the necessary algorithms instead. To be honest these precedennts are an important reason why I wanted to point out that Apache 2.0 is not universally accepted as a non-restrictive license. > I don't suppose we could ever pick one license that would please absolutely > everyone for something like this -- it will always be a compromise, I know. > I think in this case feedback we have had from various project participants > including those from commercial ventures and open source community inform > the choice. The qualitative summary of that comes down to providing terms > with the least amount of strings as possible while also giving patent > protections for users of the code. When we first started TianoCore there > really wasn't a suitable license that did both those things and that's how > we ended up with the two-element terms we have today. As I think I said > elsewhere, had Apache 2.0 existed at the time, that's probably what we would > have picked in the first place. > > Fundamentally though we believe the proposed terms are no more restrictive > than what already applies so if that was your concern, that the intent was > to make the environment more restrictive, that is definitely not the case. Thanks for taking the time to write this reply. I appreciate it. And I really don't want this to turn into another lengthy discussion about the pros and cons of different licenses. Our time is better spent on writing good software. > -- > Cheers, > > Mark. Thanks, Mark. > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Mark Kettenis > > Sent: Friday, December 7, 2018 2:52 AM > > To: Kinney, Michael D > > Cc: Kinney, Michael D ; edk2- > > de...@lists.01.org > > Subject: Re: [edk2] [RFC] Change EDK II to an Apache 2.0 License > > > > > From: "Kinney, Michael D" > > > Date: Thu, 29 Nov 2018 18:39:28 + > > > > As an OpenBSD developer I feel I have to point out that the OpenBSD > > project considers Apache 2.0 to be a *restrictive* license. > > > > http://www.openbsd.org/policy.html > > > > We (currently) don't include EDK II code in the OpenBSD OS itself, but > > do support ARM boards that boot using EDK II-based firmware that has > > to be included on the same boot media as the OS. So to license change > > would restr
Re: [edk2] [RFC] Change EDK II to an Apache 2.0 License
> From: "Kinney, Michael D" > Date: Thu, 29 Nov 2018 18:39:28 + As an OpenBSD developer I feel I have to point out that the OpenBSD project considers Apache 2.0 to be a *restrictive* license. http://www.openbsd.org/policy.html We (currently) don't include EDK II code in the OpenBSD OS itself, but do support ARM boards that boot using EDK II-based firmware that has to be included on the same boot media as the OS. So to license change would restrict us (the OpenBSD prject) and potentially others from distributing working boot media for such boards under a "no strings attached" license. Personally, I also think clause 4b of the Apache 2.0 license is too problematic for truly open source software. Adding the required notice for every change that is made is obviously unworkable as I've never seen such notices in modified Apache 2.0 codebases... All-in-all, from my point of view replacing a simple, easy to understand, permissive license with a more complicated legal document that imposes additional restrictions would be a step backwards. No doubt Intel's lawyers have a different opinion. Cheers, Mark Kettenis > Hello, > > This RFC follows up on the proposal from Mark Doran to change the > EDK II Project to an Apache 2.0 License. > > https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html > > > ** Please provide feedback on the proposal by Friday 12/7/18. ** > > I will be following up with pointers to public GitHub branches that > contain the initial set of changes in steps (1) and (2) below for > review. > > The proposal is to perform this change to edk2/master in the steps listed > below. The license change will not be applied to any of the other existing > branches in the edk2 repository. > > 1) Change all files with a BSD 2-Clause license and only a single >copyright statement by Intel Corporation to an Apache 2.0 license >and add an SPDX-License-Identifier statement. > >== >SPDX-License-Identifier: Apache-2.0 > >Licensed under the Apache License, Version 2.0 (the "License"); >you may not use this file except in compliance with the License. >You may obtain a copy of the License at > >http://www.apache.org/licenses/LICENSE-2.0 > >Unless required by applicable law or agreed to in writing, software >distributed under the License is distributed on an "AS IS" BASIS, >WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. >See the License for the specific language governing permissions and >limitations under the License. >== > > 2) Update Readme.md and License.txt in the root of the edk2 repository to >state that content is covered by a mix of BSD 2-Clause and Apache 2.0 >licenses. > > 3) Update all documentation to state that content submitted under the >Apache 2.0 license no longer requires the Tianocore Contribution >Agreement which means the following line is not required in commit >messages for changes to files that are covered by an Apache 2.0 License. > >Contributed-under: TianoCore Contribution Agreement 1.1 > > 4) Create Wiki page(s) that provide the details of the Apache 2.0 License >change and provide the status of the license change for each package >in the edk2 repository. Also provide a list of the additional copyright >holders that need to be contacted to accept the change to an Apache 2.0 >License along with the status of that acceptance. > > 5) After all copyright holders have accepted the change to an Apache 2.0 >License, change the remaining files from BSD 2-Clause to Apache 2.0. > > 6) Update Readme.md and License.txt in the edk2 repository to state that >Apache 2.0 is the preferred license for the EDK II project. > > Best regards, > > Mike > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Silicon/SynQuacer: remove bogus PL011 _HID from DSDT ACPI table
> From: Ard Biesheuvel
> Date: Mon, 19 Nov 2018 08:03:38 -0800
>
> PL011 is not a valid ACPI identifier so don't expose it as a _CID.
> Since _CID (Comptable ID) is optional, let's just drop it.
Heh, I Noticed that one when adding ACPI support for OpenBSD/arm64.
Reviewed-by: Mark Kettenis
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> index 3f73c191d4d6..7c7677f1fea0 100644
> --- a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> +++ b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> @@ -135,7 +135,6 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "SNI",
> "SYNQUACR",
> // UART PL011
> Device (COM0) {
>Name (_HID, "ARMH0011")
> - Name (_CID, "PL011")
>Name (_UID, Zero)
>Name (_CRS, ResourceTemplate () {
> Memory32Fixed (ReadWrite, FixedPcdGet32 (PcdSerialRegisterBase),
> 0x1000)
> --
> 2.17.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [platforms: PATCH v2 0/9] Armada7k8k DT/ACPI support
> From: Marcin Wojtas > Date: Tue, 7 Aug 2018 13:28:19 +0200 > > wt., 7 sie 2018 o 11:18 Ard Biesheuvel napisał(a): > > > > On 7 August 2018 at 10:58, Marcin Wojtas wrote: > > > Hi, > > > > > > The second version of the patchset modifies AcpiTables > > > directory structure in order to avoid passing relative > > > paths in the boards' .inf files. > > > > > > The patches are available in the github: > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/dt-acpi-upstream-r20180807 > > > > > > I'm looking forward to review and any comments/remarks. > > > > > > Best regards, > > > Marcin > > > > > > Marcin Wojtas (9): > > > Marvell/Armada7k8k: Import device tree > > > Marvell/Armada7k8k: Enable including additional DXE FV components > > > Marvell/Armada70x0Db: Enable device tree support > > > Marvell/Armada80x0Db: Enable device tree support > > > Marvell/Armada80x0McBin: Enable device tree support > > > Marvell/Armada7k8k: Add common ACPI tables > > > Marvell/Armada70x0Db: Enable ACPI support > > > Marvell/Armada80x0Db: Enable ACPI support > > > Marvell/Armada80x0McBin: Enable ACPI support > > > > > > > Reviewed-by: Ard Biesheuvel > > > > Pushed as 02daa58c21f8..89c6c77b3d91 > > > > Thank you! > Marcin Thank you Marcin! My MACCHIATObin is now running OpenBSD/arm64 on firmware based on unmodified mainline ATF and mainline EDK II. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 3/4] Platform/SolidRun: Add Hummingboard ACPI tables
Hi Chris, I noticed that in the DSDT for this platform, the _DSD for some devices uses the Device Porperties UUID. Existing uses of this UUID on ARM platforms within the edk2 use device properties aligned with the DeviceTree specification (https://www.devicetree.org/). The device properties in this patch clearly are not, even though existing bindings for the i.MX6 hardware you're targetting exist. I also noted that the "RegisterBasePA" property duplicates information provided by _CRS, which is something that the Device Properties UUID specification explicitly forbids. Cheers, Mark ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
