Hi Leif,
Thanks for your remarks.
2016-03-18 16:10 GMT+01:00 Leif Lindholm leif.lindholm@linaro.org:
Hi Marcin,
I have started looking at this.
First some high-level comments:
- It would be really helpful if you could put these patches in some public repo, so that I could cherry-pick them across (and avoid the issues of CR getting dropped in transmission).
I think it's possible, but we have to discuss it internally and will let you know.
- I get several build breakages due to "may be used uninitalized" type situations - both with GCC and CLANG.
- Could you manually enable -Wno-maybe-uninitialized (GCC) or -Wsometimes-uninitialized (CLANG) and clean up these instances? (Add to end of DEFINE GCC_AARCH64_CC_FLAGS line in EDK2 BaseTools/Conf/tools_def.template, then do a git clean -fx in edk2/Conf before rebuilding.)
I added the flags to tools_def.template, performed git clean and rebuild succeeded. Maybe it's a toolchain issue?
- Out of personal interest - which toolchain are you using that doesn't complain about this?
gcc-linaro-aarch64-none-elf-4.8-2014.04_linux/bin/aarch64-none-elf-
- Similar to recent discussions on edk2-devel with Evan Lloyd, we would want Signed-off-by: by at both the poster and the author.
Ok.
- I see you have imported the old EDK ramdisk driver. I keep seeing new ports doing this, even though there is now a ramdisk driver in EDK2 - MdeModulePkg/Universal/Disk/RamDiskDxe. I understand from Heyi that there are differences, and potentially bits missing, but I would really like to see if we can get rid of these non-upstream bits. Could you discuss with Heyi.Guo@linaro.org (optimally with this list on cc) what is missing from RamDiskDxe?
Our main development was created on a Opp and EDK2 baseline from November 2015. For upstream purpose, we rebased onto newest master, however didn't notice that RamDiskDxe appeared in the tree in the meantime, so we will try this solution before submitting v2.
Then some lower-level ones:
- The dependency on I2C_FLAG_NORESTART needs to be resolved. It could be that this would be useful to add to PI spec ... regardless, until it is there it is probably safer to use a higher value in a local definition.
- Needs to be resolved for MvI2cDxe.c and MvEeprom.c.
Ok.
- Drivers/Spi/SpiDxe.inf is lacking an explicit dependency on IoLib, causing a build failure.
With our toolchain we do not see such issue. Can you please provide us with a build log?
Best regards, Jan