I think we will need to map the uart explicitly, which is complex as that in turn implies seeing up something like the fixmap for the decompressor... not impossible but additional complexity to be sure. At least on 64 bits the high half should not conflict with any physical addresses. Either that or be able to add pagetables to map the mmio directly or via a #PF handler like we already have in the early kernel. Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >On Sat, Jul 13, 2013 at 7:53 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> On 07/12/2013 11:47 PM, Yinghai Lu wrote: >>> >>> for 32 bit, that is ok. >>> for 64 bit via 32bit bootloader, arch/x86/boot/compressed/head_64.S >>> will set page table for first 4G still ok. >>> for 64 bit via 64bit loader, like kexec via bzImage64, First >Kernel/Kexec only >>> set ident mapping for usable range, so mmio just under 64 is not >mapped. >>> >>> Looks like we need to update boot.txt to add requirement for 64bit >bootloader >>> that 0-4G need to be all ident mapping? >>> >> >> I think that is an unrealistic requirement, especially if this is the >> sole user. > >That will cause regression for: >64bit system with kexec/kdump bzImage64. >if second kernel carry "console=uart,mmio,0xABCD0000" > >or we can extend kexec-tools to make it scan second kernel command line >string >and one entry into image->segment[] > >Yinghai -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
