On 6/24/20 10:26 AM, Peng Fan wrote: >> Subject: Re: UEFI support in ARM DomUs >> >> >> On 6/24/20 10:07 AM, Peng Fan wrote: >>>> Subject: Re: UEFI support in ARM DomUs >>>> >>>> >>>> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote: >>>>> On 6/23/20 4:20 AM, Stefano Stabellini wrote: >>>>>> On Mon, 22 Jun 2020, Julien Grall wrote: >>>>>>>>>> For the first part (__XEN_INTERFACE_VERSION__) I think we can >>>>>>>>>> provide it via >>>>>>>>>> >>>>>>>>>> CFLAGS or something. This can also be done for the location of >>>>>>>>>> Xen headers. >>>>>>>>> __XEN_INTERFACE_VERSION__ should work through the CFLAGS. >> An >>>>>>>>> alternative would be to allow the user to specify through the >> Kconfig. >>>>>>>> You mean specifying via Kconfig something like "0x00040d00"? >>>>>>> Possibly yes. >>>>>>> >>>>>>>> And what about the headers? How will we provide their location if >>>>>>>> we decide not to include those >>>>>>>> >>>>>>>> in the tree? >>>>>>> I would do through Kconfig as well. >>>>>> If we specify the external location of the Xen headers via Kconfig, >>>>>> it seems to me that we should be able to detect the interface >>>>>> version automatically from any Makefile as part of the build. No >>>>>> need to ask the user. >>>>>> >>>>>> However, if Oleksandr is thinking of using the Xen headers for the >>>>>> hypercalls definitions, then I think we might not need external >>>>>> headers at all because that is a stable interface, as Julien wrote. >>>>>> We could just define our own few headers for just what you need >>>>>> like Linux >>>> does. >>>>> This is a good idea: I'll try to get the minimal set of headers from >>>>> Linux >>>>> >>>>> instead of Xen as those seem to be well prepared for such a use-case. >>>>> This >>>>> >>>>> way we'll have headers in U-boot tree and guarantee that we have a >>>>> minimal >>>>> >>>>> subset which is easier to maintain. I'll keep you updated on the >>>>> progress >>>> We've managed to strip the headers and remove __XEN__ and the rest >>>> definitions >>>> >>>> we were talking about. So, these are now the minimal required set of >>>> headers >>>> >>>> that allows U-boot to build serial and block drivers. Please take a >>>> look at [1] >>>> >>>> Pull request for comments is at [2] >>> The U-Boot new merge window will be open in 2020/7/1, so I'd suggest >>> the patchset goes to U-Boot mail list for discussion if you wanna the >>> patches gonna merged soon. >> We definitely want the patches to be upstreamed and merged, but before >> that >> >> we also want to make sure that Xen community is happy with what we >> upstream >> >> I believe we resolved most of the concerns such as headers, PIE etc, so this >> can >> >> be done. >> >> BTW, Peng, did you have a chance to try the pvblock driver yet? > Not yet. I could have time to give a test next Monday. I think you not > enable SPL, right?
No, we decided that we can run with U-boot proper, so we can have more flexibility comparing to what we have in SPL. It seems that was the right approach: you can jump to Linux or you can jump to the U-boot provided by Android anyway, whatever your setup > So android dual bootloader feature not enabled. I think this step will depend on the use-case you have: at the moment we have a base build capable of booting Linux kernel, but this can easily be extended with specific defconfig to build in boota command or whatever else is required. > But SPL mostly not have MMU enabled.. > > Regards, > Peng. > >>> Regards, >>> Peng. >>> >>>>>> If you can do that, I think it would be better because we decouple >>>>>> the UBoot build from the Xen build completely. We don't even need >>>>>> the Xen tree checked out to build UBoot. It would be a huge >>>>>> advantage because it makes it far easier to build-test changes for >>>>>> others in the community that don't know about Xen and also it >>>>>> becomes far easier to integrate into any build system. >>>> [1] >>>> >> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldef__;JSUl!!GF_29dbcQIUBPA!kJhWFr5ZO_UWn2oD_I9pDfnn64pZXw1ZBtASsxS9AZwbG65093ZydtlVPy6baPy4oeF957GBNA$ >> ense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.c >> om%2F%3Furl%3Dhttps*3A*2F*2Fgithub__%3BJSUl!!GF_29dbcQIUBPA!mwi >> b3un6-vYBG68zMfurW6-0MuuER5tNmJtOitDpViICNkX0lhig8iPHmZokuM-BLQ >> YpeKYAGQ%24&data=02%7C01%7Cpeng.fan%40nxp.com%7C950d9c0a >> dc514927ce8b08d8180ea4ef%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C >> 0%7C0%7C637285798460563914&sdata=fMrI%2FQotknCsXV0amC4BFl >> 1Hg4vPw3zOMVdAVim2Wcs%3D&reserved=0 . >> com%2Fandr2000%2Fu-boot%2Ftree%2Fpvblock_upstream_v1&data=0 >> 2%7C01%7Cpeng.fan%40nxp.com%7C407d8af24a36483fbdce08d81805ed88 >>>> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637285761021 >> 975 >> 164&sdata=5vWfBbLScICXPZWU%2BU3b7DyONcgxT8iICsxrwUbORZY% >>>> 3D&reserved=0 >>>> >>>> [2] >>>> >> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldef__;JSUl!!GF_29dbcQIUBPA!kJhWFr5ZO_UWn2oD_I9pDfnn64pZXw1ZBtASsxS9AZwbG65093ZydtlVPy6baPy4oeF957GBNA$ >> ense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.c >> om%2F%3Furl%3Dhttps*3A*2F*2Fgithub__%3BJSUl!!GF_29dbcQIUBPA!mwi >> b3un6-vYBG68zMfurW6-0MuuER5tNmJtOitDpViICNkX0lhig8iPHmZokuM-BLQ >> YpeKYAGQ%24&data=02%7C01%7Cpeng.fan%40nxp.com%7C950d9c0a >> dc514927ce8b08d8180ea4ef%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C >> 0%7C0%7C637285798460563914&sdata=fMrI%2FQotknCsXV0amC4BFl >> 1Hg4vPw3zOMVdAVim2Wcs%3D&reserved=0 . >> com%2Fxen-troops%2Fu-boot%2Fpull%2F2&data=02%7C01%7Cpeng.fa >> n%40nxp.com%7C407d8af24a36483fbdce08d81805ed88%7C686ea1d3bc2b4 >> c6fa92cd99c5c301635%7C0%7C0%7C637285761021975164&sdata=%2 >> FmXheEvKssLjjaFKsHBBbqh%2B72jH3uQnE7cpN0J3k8I%3D&reserved=0
