On 06/01/2017 11:50 PM, Paratey, Swapnil wrote:
So you may have noticed that I did commit this, but then I had to
revert it again, as it breaks the build on ARM. Didn't you need the
change specifically for ARM? If so, how come you didn't build test
it there?
I would be surprised if this change is necessary for ARM as we don't
support com1.
Cheers,
Can I see the error messages of the build fail (specifically for my
patch if possible)?
If not, the following is what I have tried.
I tried the ARM build myself and the build is failing for PCI-related
code where
I didn't use "#ifdef CONFIG_HAS_PCI" macro. Specifically this is in the
switch
case statements for bridge_bdf, device and port_bdf inside
the parse_namevalue_pairs function. After adding the macros, the build
didn't
fail (gave no errors) for both 32-bit and 64-bit ARM builds. I verified
this by
looking at the xen-syms file generated and they mentioned their
architectures appropriately. Please note, I have used chroot to
cross-compile
the ARM builds.
Now, the code flow for this patch originally starts at __start_xen
(which has an x86
architecture start point - arch/x86/boot/x86_64.S). I tried searching
for this
__start_xen function in the xen-syms generated from the ARM builds for both
32-bit and 64-bit ARM and I couldn't find this function. Hence, I'm
assuming ARM
doesn't use __start_xen() (apart from the fact that it's in the x86
folder).
The C entry point for ARM is called start_xen.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel