Hi Leif, I have make a new multiboot support patch V3.5, because Ian has fixed the bugs in his branch.
To Ian: Once Xen can support multiple blanks of RAM, please let me know, then I can test the latest linaro-edk2 with GRUB and Xen.
Some pending change: (1)delete "grub_arm64_disable_caches_mmu" and the relevant code(misc.c and misc_irq.S)(waiting for stub-xen) (2)non-stub xen boot switch to stub-xen boot (waiting for stub-xen) (3)grub coding style (maybe I need to improve it in somewhere) (6)integrate multiboot_fdt.c back to multiboot.c (will make a new patch/branch for it, but I think multiboot_fdt.c make multiboot.c more generic)
Will update the wiki patch, in case someone want to try it.
Notice: This patch bases on master branch of upstream grub This patch only can works with the multiboot-improvements-v2 branch of Ian's xen repo(git://xenbits.xen.org/people/ianc/xen.git), because the compatible streams have changed.
On Fri, 2014-06-27 at 22:02 +0800, Fu Wei wrote:
Hi Leif, I have make a new multiboot support patch V3.5, because Ian has fixed the bugs in his branch.
FYI I tried v3.4 of this patch (because -ENOPATCH here) on a Juno board and got: [...]Welcome to GRUB!
[...]error: no such device: boot. [...]GNU GRUB version 2.02~beta2
Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.
grub>
Synchronous Exception at 0x00000000FEB2B808
([...] are ANSI escape codes which I've removed)
I didn't have a chance to press any keys, this happened without any input etc. The Synchronous Exception messages just keep repeating with the same address.
This was based on: commit 0901e7855f922e770cbfeb58262cb8fded518190 Author: Colin Watson cjwatson@ubuntu.com Date: Tue Jul 8 23:54:30 2014 +0100
Fix an infinite loop in grub-mkconfig
To Ian: Once Xen can support multiple blanks of RAM, please let me know, then I can test the latest linaro-edk2 with GRUB and Xen.
I've started having a look at this but it looks like it will be a while before I complete it. Can you remind me what the issue is? If Xen sees multiple banks of memory which represent an address map which is too sparse it should try and continue with just the first bank. Obviously not ideal, but should work, I think.
Ian.
Hi, Ian,
I *guess* that "bug" come from uefi. At least, I think "Synchronous Exception" come from uefi. But I have not the Juno board. So I have not chance to test it, although I want to test it in a real hardware.
For now, Xen can not work with the new linaro-edk2, because the new one will try to allocate the memory from the "high" bank(if we have two banks of memory).
Please try my repo: https://git.linaro.org/people/fu.wei/grub.git branch : multiboot_xen_support_upstream_dev
I agree with you for the multiple banks of memory. Will try to use the first bank, and report the result here. :-)
Great thanks!!
On 07/21/2014 08:45 PM, Ian Campbell wrote:
On Fri, 2014-06-27 at 22:02 +0800, Fu Wei wrote:
Hi Leif, I have make a new multiboot support patch V3.5, because Ian has fixed the bugs in his branch.
FYI I tried v3.4 of this patch (because -ENOPATCH here) on a Juno board and got: [...]Welcome to GRUB! [...]error: no such device: boot. [...]GNU GRUB version 2.02~beta2 Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. grub> Synchronous Exception at 0x00000000FEB2B808 ([...] are ANSI escape codes which I've removed)
I didn't have a chance to press any keys, this happened without any input etc. The Synchronous Exception messages just keep repeating with the same address.
This was based on: commit 0901e7855f922e770cbfeb58262cb8fded518190 Author: Colin Watson cjwatson@ubuntu.com Date: Tue Jul 8 23:54:30 2014 +0100 Fix an infinite loop in grub-mkconfig
To Ian: Once Xen can support multiple blanks of RAM, please let me know, then I can test the latest linaro-edk2 with GRUB and Xen.
I've started having a look at this but it looks like it will be a while before I complete it. Can you remind me what the issue is? If Xen sees multiple banks of memory which represent an address map which is too sparse it should try and continue with just the first bank. Obviously not ideal, but should work, I think.
Ian.
On Mon, Jul 21, 2014 at 8:47 PM, Fu Wei fu.wei@linaro.org wrote:
Hi, Ian,
I *guess* that "bug" come from uefi. At least, I think "Synchronous Exception" come from uefi. But I have not the Juno board. So I have not chance to test it, although I want to test it in a real hardware.
For now, Xen can not work with the new linaro-edk2, because the new one will try to allocate the memory from the "high" bank(if we have two banks of memory).
Please try my repo: https://git.linaro.org/people/fu.wei/grub.git branch : multiboot_xen_support_upstream_dev
I agree with you for the multiple banks of memory. Will try to use the first bank, and report the result here. :-)
Yes, I had to limit allocations to the low bank on the FVP model in the stub. My first patch series avoided this problem by marking the memory used to load modules as a mem-reserve region in the memory map so XEN would not try to use that memory (when it freed the modules it would check against reserved regions before trying to re-use the memory.) The upper banks can be accessed, but not mapped by XEN.
I don't have a generic solution for this yet.
Roy
Great thanks!!
On 07/21/2014 08:45 PM, Ian Campbell wrote:
On Fri, 2014-06-27 at 22:02 +0800, Fu Wei wrote:
Hi Leif, I have make a new multiboot support patch V3.5, because Ian has fixed the bugs in his branch.
FYI I tried v3.4 of this patch (because -ENOPATCH here) on a Juno board and got: [...]Welcome to GRUB!
[...]error: no such device: boot. [...]GNU GRUB version 2.02~beta2 Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. grub> Synchronous Exception at 0x00000000FEB2B808([...] are ANSI escape codes which I've removed)
I didn't have a chance to press any keys, this happened without any input etc. The Synchronous Exception messages just keep repeating with the same address.
This was based on: commit 0901e7855f922e770cbfeb58262cb8fded518190 Author: Colin Watson cjwatson@ubuntu.com Date: Tue Jul 8 23:54:30 2014 +0100
Fix an infinite loop in grub-mkconfigTo Ian: Once Xen can support multiple blanks of RAM, please let me know, then I can test the latest linaro-edk2 with GRUB and Xen.
I've started having a look at this but it looks like it will be a while before I complete it. Can you remind me what the issue is? If Xen sees multiple banks of memory which represent an address map which is too sparse it should try and continue with just the first bank. Obviously not ideal, but should work, I think.
Ian.
-- Best regards,
Fu Wei Enterprise Server Engineer From Red Hat LEG Team Linaro.org | Open source software for ARM SoCs Ph: +86 186 2020 4684 (mobile) IRC: fuwei Skype: tekkamanninja Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-uefi
On Mon, 2014-07-21 at 20:54 -0700, Roy Franz wrote:
On Mon, Jul 21, 2014 at 8:47 PM, Fu Wei fu.wei@linaro.org wrote:
I agree with you for the multiple banks of memory. Will try to use the first bank, and report the result here. :-)
Yes, I had to limit allocations to the low bank on the FVP model in the stub. My first patch series avoided this problem by marking the memory used to load modules as a mem-reserve region in the memory map so XEN would not try to use that memory (when it freed the modules it would check against reserved regions before trying to re-use the memory.) The upper banks can be accessed, but not mapped by XEN.
I don't have a generic solution for this yet.
Irrespective of Xen's (lack of) support for multiple memory banks we (by which I mean I) should make it handle the case where the initial modules are not in regions which it considers to be RAM and/or reserved regions which are not RAM.
Based on the description it seems that the problem is probably in discard_initial_modules() which will free the modules without checking if they are within RAM so it runs off the end of the frametable array, does that sound right?
If you comment out the call to dt_unreserved_regions in that function does it work OK? If so then I'll figure out a proper solution.
Ian.
On Tue, Jul 22, 2014 at 2:00 AM, Ian Campbell Ian.Campbell@citrix.com wrote:
On Mon, 2014-07-21 at 20:54 -0700, Roy Franz wrote:
On Mon, Jul 21, 2014 at 8:47 PM, Fu Wei fu.wei@linaro.org wrote:
I agree with you for the multiple banks of memory. Will try to use the first bank, and report the result here. :-)
Yes, I had to limit allocations to the low bank on the FVP model in the stub. My first patch series avoided this problem by marking the memory used to load modules as a mem-reserve region in the memory map so XEN would not try to use that memory (when it freed the modules it would check against reserved regions before trying to re-use the memory.) The upper banks can be accessed, but not mapped by XEN.
I don't have a generic solution for this yet.
Irrespective of Xen's (lack of) support for multiple memory banks we (by which I mean I) should make it handle the case where the initial modules are not in regions which it considers to be RAM and/or reserved regions which are not RAM.
Based on the description it seems that the problem is probably in discard_initial_modules() which will free the modules without checking if they are within RAM so it runs off the end of the frametable array, does that sound right?
If you comment out the call to dt_unreserved_regions in that function does it work OK? If so then I'll figure out a proper solution.
Yes, it is the discard_initial_modules() that is the problem - if that tries to free and use memory from modules that is in the high bank it goes boom. My initial DT hack accidentally avoided this by making the modules reserved regions which made this operation a NOP.
If we add proper handling of modules outside of the frametable this takes care of most of the ugliness. The remaining issue is that the EFI memory map is generally much more sparse that the DT memory banks, so the logic used to avoid over-sparseness will need to be updated. A pathological EFI memory map could be very sparse at the beginning and cause too little memory to be used.
Roy
Ian.
On Tue, 2014-07-22 at 11:47 +0800, Fu Wei wrote:
Hi, Ian,
I *guess* that "bug" come from uefi. At least, I think "Synchronous Exception" come from uefi. But I have not the Juno board. So I have not chance to test it, although I want to test it in a real hardware.
Please try my repo: https://git.linaro.org/people/fu.wei/grub.git branch : multiboot_xen_support_upstream_dev
I'm afraid that this behaves the same :-/
FYI upstream master does the same so I don't think this is your fault.
Ian.
On 07/22/2014 05:49 PM, Ian Campbell wrote:
On Tue, 2014-07-22 at 11:47 +0800, Fu Wei wrote:
Hi, Ian,
I *guess* that "bug" come from uefi. At least, I think "Synchronous Exception" come from uefi. But I have not the Juno board. So I have not chance to test it, although I want to test it in a real hardware.
Please try my repo: https://git.linaro.org/people/fu.wei/grub.git branch : multiboot_xen_support_upstream_dev
I'm afraid that this behaves the same :-/
FYI upstream master does the same so I don't think this is your fault.
Thanks for testing it! I think so.
Could you test it with grub.cfg??
Ian.
On Tue, 2014-07-22 at 17:56 +0800, Fu Wei wrote:
On 07/22/2014 05:49 PM, Ian Campbell wrote:
On Tue, 2014-07-22 at 11:47 +0800, Fu Wei wrote:
Hi, Ian,
I *guess* that "bug" come from uefi. At least, I think "Synchronous Exception" come from uefi. But I have not the Juno board. So I have not chance to test it, although I want to test it in a real hardware.
Please try my repo: https://git.linaro.org/people/fu.wei/grub.git branch : multiboot_xen_support_upstream_dev
I'm afraid that this behaves the same :-/
FYI upstream master does the same so I don't think this is your fault.
Thanks for testing it! I think so.
Could you test it with grub.cfg??
I would if I knew how ;-)
Ian.
On 07/22/2014 06:26 PM, Ian Campbell wrote:
On Tue, 2014-07-22 at 17:56 +0800, Fu Wei wrote:
On 07/22/2014 05:49 PM, Ian Campbell wrote:
On Tue, 2014-07-22 at 11:47 +0800, Fu Wei wrote:
Hi, Ian,
I *guess* that "bug" come from uefi. At least, I think "Synchronous Exception" come from uefi. But I have not the Juno board. So I have not chance to test it, although I want to test it in a real hardware.
Please try my repo: https://git.linaro.org/people/fu.wei/grub.git branch : multiboot_xen_support_upstream_dev
I'm afraid that this behaves the same :-/
FYI upstream master does the same so I don't think this is your fault.
Thanks for testing it! I think so.
Could you test it with grub.cfg??
I would if I knew how ;-)
Something like this: https://staging.validation.linaro.org/scheduler/job/46542 :-)
Ian.
-
Fu Wei -
Ian Campbell -
Roy Franz