Various fixes for purgatory and ARM64
Subsystems (2)
cover Various fixes for purgatory and ARM64
These patches can be applied on top of Geoff's Kexec [1] and Takahiro's Kdump [2] patches and are available in my tree [3].
First two patches are for purgatory. 1st patch is a very important fix for sha verification. 2nd patch is good to have.
Rest all patches are fixes and addon for ARM64.
These patchset adds three extra command line options for ARM64.
--page-offset: Needed for binary image only. Default value is0xfffffe0000000000.
--port-lsr: It is UART's Line status register address. Normally for a
UART based on 8250, 16450 or 16550 should have value as --port's value + 0x14.
--port-lsr-val: It is the SET value of LSR register for TX buffer to be
empty. Normally for above UARTs it should be 0x60
[1] git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git
: master
[2] git://git.linaro.org/people/takahiro.akashi/kexec-tools.git :
kdump/v0.10
[3] https://github.com/pratyushanand/kexec-tools.git : master (6c8a63f701e9)
Pratyush Anand (6):
purgatory: Fix memcmp for src address increment
purgatory: No need to sha256 update if ptr->len is zero
arm64: allocate memory for other segments after kernel
arm64: support reuse-cmdline option
arm64: Add support for binary image
arm64: wait for transmit completion before next character transmission
kexec/arch/arm64/crashdump-arm64.c | 3 +- kexec/arch/arm64/crashdump-arm64.h | 1 + kexec/arch/arm64/include/arch/options.h | 21 +++++++++++-- kexec/arch/arm64/kexec-arm64.c | 28 ++++++++++++++++- kexec/arch/arm64/kexec-arm64.h | 2 ++ kexec/arch/arm64/kexec-image-arm64.c | 54 ++++++++++++++++++++++++++++++--- purgatory/arch/arm64/entry.S | 10 ++++++ purgatory/arch/arm64/purgatory-arm64.c | 22 +++++++++++++- purgatory/purgatory.c | 2 ++ purgatory/string.c | 2 ++ 10 files changed, 135 insertions(+), 10 deletions(-)
Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
RFC PATCH 1/6 purgatory: Fix memcmp for src address increment
src addresses are not being incremented, so only first byte is compared instead of first len bytes.
--- purgatory/string.c | 2 ++ 1 file changed, 2 insertions(+)
purgatory/string.c +2 -0
@@ -46,6 +46,8 @@ int memcmp(void *src1, void *src2, size_t len)if (*s1 != *s2) {return *s2 - *s1; } + s1++; + s2++; }return 0 ;
Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment
Quoted 2 lines · Pratyush Anand
src addresses are not being incremented, so only first byte is compared instead of first len bytes.
So I guess this means we never really had proper error checking in purgatory... Better merge this one.
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment
Quoted 8 lines · Geoff Levand
Quoted 2 lines · Pratyush Anand
src addresses are not being incremented, so only first byte is compared instead of first len bytes.
So I guess this means we never really had proper error checking in purgatory... Better merge this one.
Acked-by Geoff Levand <[email protected]>
Hi Pratyush,
If you'd like me to take this plase repost it with Geoff's Ack and without "RFC".
Thanks
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment
Quoted 8 lines · Simon Horman
Quoted 7 lines · Geoff Levand
Quoted 2 lines · Pratyush Anand
src addresses are not being incremented, so only first byte is compared instead of first len bytes.
So I guess this means we never really had proper error checking in purgatory... Better merge this one.
Quoted 7 lines
Quoted 1 line
Acked-by Geoff Levand <[email protected]>Hi Pratyush,
If you'd like me to take this plase repost it with Geoff's Ack and without "RFC".
It is already now in Geoff's tree so may be I do not resend it.
~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment
Quoted 13 lines · Pratyush Anand
Quoted 10 lines · Simon Horman
Quoted 8 lines · Geoff Levand
Quoted 2 lines · Pratyush Anand
src addresses are not being incremented, so only first byte is compared instead of first len bytes.
So I guess this means we never really had proper error checking in purgatory... Better merge this one.
Acked-by Geoff Levand <[email protected]>
Quoted 7 lines
Quoted 5 lines
Hi Pratyush,
If you'd like me to take this plase repost it with Geoff's Ack and without "RFC".
It is already now in Geoff's tree so may be I do not resend it.
I'm a little unsure of the nature of Geoff's tree. But if anything is ready to be merged into my tree in preparation for the next official release then I'm all ears.
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
RFC PATCH 2/6 purgatory: No need to sha256 update if ptr->len is zero
In reply to Pratyush AnandIf ptr->len is zero we do not need to update sha256.
--- purgatory/purgatory.c | 2 ++ 1 file changed, 2 insertions(+)
purgatory/purgatory.c +2 -0
@@ -18,6 +18,8 @@ int verify_sha256_digest(void)sha256_starts (&ctx); end = &sha256_regions[sizeof (sha256_regions)/sizeof (sha256_regions[0 ])];for (ptr = sha256_regions; ptr < end; ptr++) { +if (ptr->len ==0 ) +continue ;sha256_update (&ctx, (uint8_t *)((uintptr_t )ptr->start), ptr->len); }
Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero
Quoted 1 line · Pratyush Anand
If
ptr->lenis zero we do not need to update sha256.
Looks OK. Did you find this sped things up?
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero
Quoted 4 lines · Geoff Levand
Quoted 1 line · Pratyush Anand
If
ptr->lenis zero we do not need to update sha256.Looks OK. Did you find this sped things up?
No.. I am working for that..
Speed is good when sha256 is prepared in update_purgatory..just a sec.. while it is 2 min during verification..
one diff is that purgatory is using byte copy in memcpy while kexec had generic memcpy which has byte/word/page copy features.
But, Most likely speed is low because dcache is disabled.
So I am working to enable d-cache and identity mapped mmu table for crashdump regions in purgatory.
~Pratyush
Quoted 9 lines
Acked-by Geoff Levand <[email protected]>_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero
In reply to Pratyush AnandQuoted 12 lines · Pratyush Anand
If
ptr->lenis zero we do not need to update sha256.Signed-off-by Pratyush Anand <[email protected]>--- purgatory/purgatory.c | 2 ++ 1 file changed, 2 insertions(+)purgatory/purgatory.c +0
-0
purgatory/purgatory.c int verify_sha256_digest(void) · line 22
Quoted 5 lines
purgatory/purgatory.c +2
-0@@ -18,6 +18,8 @@ int verify_sha256_digest(void)sha256_starts (&ctx); end = &sha256_regions[sizeof (sha256_regions)/sizeof (sha256_regions[0 ])];for (ptr = sha256_regions; ptr < end; ptr++) { +if (ptr->len ==0 ) +continue ;
Hi Pratyush,
I don't think this is necessary, but don't object to it strongly. Since sha256_update will check the length and return immediately if it's 0.
void sha256_update( sha256_context *ctx, const uint8_t *input, size_t length )
{
size_t left, fill;
if( ! length ) return;...
}
Thanks
Baoquan
Quoted 11 lines
purgatory/purgatory.c +0
-0sha256_update (&ctx, (uint8_t *)((uintptr_t )ptr->start), ptr->len); }Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero
Quoted 21 lines · Baoquan He
Quoted 12 lines · Pratyush Anand
If
ptr->lenis zero we do not need to update sha256.Signed-off-by Pratyush Anand <[email protected]>--- purgatory/purgatory.c | 2 ++ 1 file changed, 2 insertions(+)purgatory/purgatory.c +0
-0purgatory/purgatory.c int verify_sha256_digest(void) · line 22
Quoted 5 lines
purgatory/purgatory.c +2
-0@@ -18,6 +18,8 @@ int verify_sha256_digest(void)sha256_starts (&ctx); end = &sha256_regions[sizeof (sha256_regions)/sizeof (sha256_regions[0 ])];for (ptr = sha256_regions; ptr < end; ptr++) { +if (ptr->len ==0 ) +continue ;Hi Pratyush,
Quoted 4 lines
I don't think this is necessary, but don't object to it strongly. Since
sha256_updatewill check the length and return immediately if it's 0.
I think you are right, we can skip this.
~Pratyush
Quoted 25 lines
void
sha256_update( sha256_context *ctx, const uint8_t *input, size_t length ){ size_t left, fill; if( ! length ) return;...
}Thanks
BaoquanQuoted 11 lines
purgatory/purgatory.c +0
-1sha256_update (&ctx, (uint8_t *)((uintptr_t )ptr->start), ptr->len); } --2.1.0
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 5 lines
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
RFC PATCH 3/6 arm64: allocate memory for other segments after kernel
In reply to Pratyush AnandIn case of KEXEC_ON_CRASH, load other segments after the addresses where kernel segments finish.
--- kexec/arch/arm64/crashdump-arm64.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kexec/arch/arm64/crashdump-arm64.c +2 -1
@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info)off_t locate_dtb_in_crashmem (struct kexec_info *info,off_t dtb_size) {return locate_hole (info, dtb_size,128UL *1024 , - crash_reserved_mem.start, crash_reserved_mem.end,1 ); + crash_reserved_mem.start + arm64_mem.text_offset + + arm64_mem.image_size, crash_reserved_mem.end,1 ); }
Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel
Quoted 6 lines · Pratyush Anand
In case of
KEXEC_ON_CRASH, load other segments after the addresses where kernel segments finish.Signed-off-by Pratyush Anand <[email protected]>--- kexec/arch/arm64/crashdump-arm64.c | 3 ++-
This one should be folded into Takahiro's latest patches.
-Geoff
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel
In reply to Pratyush AnandQuoted 13 lines · Pratyush Anand
In case of
KEXEC_ON_CRASH, load other segments after the addresses where kernel segments finish.Signed-off-by Pratyush Anand <[email protected]>--- kexec/arch/arm64/crashdump-arm64.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)kexec/arch/arm64/crashdump-arm64.c +0
-0
kexec/arch/arm64/crashdump-arm64.c void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info) · line 316
Quoted 6 lines
kexec/arch/arm64/crashdump-arm64.c +2
-1@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info)off_t locate_dtb_in_crashmem (struct kexec_info *info,off_t dtb_size) {return locate_hole (info, dtb_size,128UL *1024 , - crash_reserved_mem.start, crash_reserved_mem.end,1 ); + crash_reserved_mem.start + arm64_mem.text_offset + + arm64_mem.image_size, crash_reserved_mem.end,1 );
So you have decided to hard code the sequence of segment. It seems not good. Why don't do it by calling add_buffer_phys_virt() or implement a similar function if you don't like add_buffer_phys_virt.
Quoted 9 lines
kexec/arch/arm64/crashdump-arm64.c +0
-0}Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel
Quoted 9 lines · Baoquan He
Quoted 8 lines · Pratyush Anand
In case of
KEXEC_ON_CRASH, load other segments after the addresses where kernel segments finish.Signed-off-by Pratyush Anand <[email protected]>--- kexec/arch/arm64/crashdump-arm64.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Quoted 15 lines
kexec/arch/arm64/crashdump-arm64.c void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info) · line 316
Quoted 11 lines
kexec/arch/arm64/crashdump-arm64.c +2
-1@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info)off_t locate_dtb_in_crashmem (struct kexec_info *info,off_t dtb_size) {return locate_hole (info, dtb_size,128UL *1024 , - crash_reserved_mem.start, crash_reserved_mem.end,1 ); + crash_reserved_mem.start + arm64_mem.text_offset + + arm64_mem.image_size, crash_reserved_mem.end,1 );So you have decided to hard code the sequence of segment. It seems not good. Why don't do it by calling
add_buffer_phys_virt()or implement a similar function if you don't likeadd_buffer_phys_virt.
I agree that code is a bit tightly coupled here. I think, Takahiro can comment better.
arm64 does use add_buffer_phys_virt to add all the buffers into segment list. arm64_load_other_segments function adds buffers for all segments other than kernel and elfcorehdr. This function calls add_buffer_phys_virt to load different segments like dtb, initrd and purgatory. Only limitation we are putting that we find free area for all these segments after the area where kernel finishes. Currently load sequence is like dtb, initrd and then purgatory. But I believe, even if we use other load sequence in arm64_load_other_segments, it should work.
Not sure, if understood the question and replied well.
~Pratyush
Quoted 11 lines
Quoted 10 lines
kexec/arch/arm64/crashdump-arm64.c +0
-1} --2.1.0
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 5 lines
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel
Prayush,
Cc: Geoff
Please add me to Cc if you intend to modify my part of kexec-tools since I don't subscribe kexec ML, and keep in mind that my repo on git.linaro.org is not for public review.
Quoted 28 lines · Pratyush Anand
Quoted 9 lines · Baoquan He
Quoted 8 lines · Pratyush Anand
In case of
KEXEC_ON_CRASH, load other segments after the addresses where kernel segments finish.Signed-off-by Pratyush Anand <[email protected]>--- kexec/arch/arm64/crashdump-arm64.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)Quoted 15 lines
kexec/arch/arm64/crashdump-arm64.c void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info) · line 316
Quoted 11 lines
kexec/arch/arm64/crashdump-arm64.c +2
-1@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info)off_t locate_dtb_in_crashmem (struct kexec_info *info,off_t dtb_size) {return locate_hole (info, dtb_size,128UL *1024 , - crash_reserved_mem.start, crash_reserved_mem.end,1 ); + crash_reserved_mem.start + arm64_mem.text_offset + + arm64_mem.image_size, crash_reserved_mem.end,1 );So you have decided to hard code the sequence of segment. It seems not good. Why don't do it by calling
add_buffer_phys_virt()or implement a similar function if you don't likeadd_buffer_phys_virt.
Quoted 1 line
I agree that code is a bit tightly coupled here. I think, Takahiro can comment better.
The *hard-coded* segments order is attributed to Geoff's original code.
Quoted 5 lines
arm64 does use
add_buffer_phys_virtto add all the buffers into segment list.arm64_load_other_segmentsfunction adds buffers for all segments other than kernel and elfcorehdr. This function callsadd_buffer_phys_virtto load different segments like dtb, initrd and purgatory. Only limitation we are putting that we find free area for all these segments after the area where kernel finishes. Currently load sequence is like dtb, initrd and then purgatory. But I believe, even if we use other load sequence inarm64_load_other_segments, it should work.
I think that add_buffer_phys_virt() should be used instead of locate_hole() to remove this enforced ordering because locate_hole() assumes that segments in struct info be sorted properly.
I'm trying the following hack: (pls ignore #if's)
kexec/arch/arm64/kexec-arm64.c +37 -12
@@ -583,6 +583,7 @@ int arm64_load_other_segments(struct kexec_info *info,struct mem_ehdr ehdr;unsigned long dtb_max;unsigned long dtb_base; +unsigned long hole_min, hole_max;char *initrd_buf =NULL ;uint64_t purgatory_sink;unsigned long purgatory_base;
@@ -639,17 +640,28 @@ int arm64_load_other_segments(struct kexec_info *info,* to the DTB size for any DTB growth. */ - dtb_max = dtb_2.size +2 *1024 ; +if (info->kexec_flags &KEXEC_ON_CRASH ) { +#if 1 + hole_min = crash_reserved_mem.start; +#else + hole_min = crash_reserved_mem.start + arm64_mem.text_offset + + arm64_mem.image_size; +#endif + hole_max = crash_reserved_mem.end; + }else { + hole_min = arm64_mem.memstart + arm64_mem.text_offset + + arm64_mem.image_size; + hole_max =ULONG_MAX ; + } -if (info->kexec_flags &KEXEC_ON_CRASH ) - dtb_base =locate_dtb_in_crashmem (info, dtb_max); -else - dtb_base =locate_hole (info, dtb_max,128UL *1024 , - arm64_mem.memstart + arm64_mem.text_offset - + arm64_mem.image_size, -_ALIGN_UP (arm64_mem.memstart + arm64_mem.text_offset, -512UL *1024 *1024 ), -1 ); + dtb_max = dtb_2.size +2 *1024 ; +#if 1 + dtb_base =add_buffer_phys_virt (info, dtb_2.buf, dtb_2.size, dtb_max, +128UL *1024 , hole_min, hole_max,1 ,0 ); +#else + dtb_base =locate_hole (info, dtb_max,128UL *1024 , + hole_min, hole_max,1 ); +#endif dbgprintf ("dtb: base %lx, size %lxh (%ld)\n" , dtb_base, dtb_2.size, dtb_2.size);
@@ -670,8 +686,14 @@ int arm64_load_other_segments(struct kexec_info *info,/* Put the initrd after the DTB with an alignment of * page size. */ +#if 1 + initrd_base =add_buffer_phys_virt (info, initrd_buf, + initrd_size, initrd_size,0 , + hole_min, hole_max,1 ,0 ); +#else initrd_base =locate_hole (info, initrd_size,0 , - dtb_base + dtb_max,-1 ,1 ); + dtb_base + dtb_max, hole_max,1 ); +#endif dbgprintf ("initrd: base %lx, size %lxh (%ld)\n" , initrd_base, initrd_size, initrd_size);
@@ -695,12 +717,14 @@ int arm64_load_other_segments(struct kexec_info *info,return -EINVAL ; } +#if 0 add_segment_phys_virt (info, dtb_2.buf, dtb_2.size, dtb_base, dtb_2.size,0 );if (arm64_opts.initrd)add_segment_phys_virt (info, initrd_buf, initrd_size, initrd_base, initrd_size,0 ); +#endif if (arm64_opts.lite) info->entry = (void *)kernel_entry;
@@ -714,8 +738,13 @@ int arm64_load_other_segments(struct kexec_info *info,return -EBADF ; } +#if 1 +elf_rel_build_load (info, &info->rhdr, purgatory, purgatory_size, + hole_min, hole_max,1 ,0 ); +#else elf_rel_build_load (info, &info->rhdr, purgatory, purgatory_size, - purgatory_base,ULONG_MAX ,1 ,0 ); + purgatory_base, hole_max,1 ,0 ); +#endif info->entry = (void *)elf_rel_get_addr (&info->rhdr,"purgatory_start" );
Thanks,
-Takahiro AKASHI
Quoted 23 lines
Not sure, if understood the question and replied well.
~Pratyush
Quoted 16 lines
Quoted 10 lines
kexec/arch/arm64/crashdump-arm64.c +0
-1} --2.1.0
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel
Geoff,
Quoted 46 lines · AKASHI Takahiro
Prayush,
Cc: GeoffPlease add me to Cc if you intend to modify my part of kexec-tools since I don't subscribe kexec ML, and keep in mind that my repo on git.linaro.org is not for public review.
Quoted 28 lines · Pratyush Anand
Quoted 9 lines · Baoquan He
Quoted 8 lines · Pratyush Anand
In case of
KEXEC_ON_CRASH, load other segments after the addresses where kernel segments finish.Signed-off-by Pratyush Anand <[email protected]>--- kexec/arch/arm64/crashdump-arm64.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)Quoted 15 lines
kexec/arch/arm64/crashdump-arm64.c void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info) · line 316
Quoted 11 lines
kexec/arch/arm64/crashdump-arm64.c +2
-1@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info)off_t locate_dtb_in_crashmem (struct kexec_info *info,off_t dtb_size) {return locate_hole (info, dtb_size,128UL *1024 , - crash_reserved_mem.start, crash_reserved_mem.end,1 ); + crash_reserved_mem.start + arm64_mem.text_offset + + arm64_mem.image_size, crash_reserved_mem.end,1 );So you have decided to hard code the sequence of segment. It seems not good. Why don't do it by calling
add_buffer_phys_virt()or implement a similar function if you don't likeadd_buffer_phys_virt.Quoted 1 line
I agree that code is a bit tightly coupled here. I think, Takahiro can comment better.
The *hard-coded* segments order is attributed to Geoff's original code.
Quoted 5 lines
arm64 does use
add_buffer_phys_virtto add all the buffers into segment list.arm64_load_other_segmentsfunction adds buffers for all segments other than kernel and elfcorehdr. This function callsadd_buffer_phys_virtto load different segments like dtb, initrd and purgatory. Only limitation we are putting that we find free area for all these segments after the area where kernel finishes. Currently load sequence is like dtb, initrd and then purgatory. But I believe, even if we use other load sequence inarm64_load_other_segments, it should work.
Quoted 4 lines
I think that
add_buffer_phys_virt()should be used instead oflocate_hole()to remove this enforced ordering becauselocate_hole()assumes that segments in struct info be sorted properly.
I'm trying the following hack: (pls ignore #if's)
If you agree, please think of taking my patch (the last commit) in v0.12 in my repo. (I tested the code in case of kexec as well as kdump with 4MB initrd.)
-Takahiro AKASHI
Quoted 97 lines
kexec/arch/arm64/kexec-arm64.c +37
-12@@ -583,6 +583,7 @@ int arm64_load_other_segments(struct kexec_info *info,struct mem_ehdr ehdr;unsigned long dtb_max;unsigned long dtb_base; +unsigned long hole_min, hole_max;char *initrd_buf =NULL ;uint64_t purgatory_sink;unsigned long purgatory_base;@@ -639,17 +640,28 @@ int arm64_load_other_segments(struct kexec_info *info,* to the DTB size for any DTB growth. */ - dtb_max = dtb_2.size +2 *1024 ; +if (info->kexec_flags &KEXEC_ON_CRASH ) { +#if 1 + hole_min = crash_reserved_mem.start; +#else + hole_min = crash_reserved_mem.start + arm64_mem.text_offset + + arm64_mem.image_size; +#endif + hole_max = crash_reserved_mem.end; + }else { + hole_min = arm64_mem.memstart + arm64_mem.text_offset + + arm64_mem.image_size; + hole_max =ULONG_MAX ; + } -if (info->kexec_flags &KEXEC_ON_CRASH ) - dtb_base =locate_dtb_in_crashmem (info, dtb_max); -else - dtb_base =locate_hole (info, dtb_max,128UL *1024 , - arm64_mem.memstart + arm64_mem.text_offset - + arm64_mem.image_size, -_ALIGN_UP (arm64_mem.memstart + arm64_mem.text_offset, -512UL *1024 *1024 ), -1 ); + dtb_max = dtb_2.size +2 *1024 ; +#if 1 + dtb_base =add_buffer_phys_virt (info, dtb_2.buf, dtb_2.size, dtb_max, +128UL *1024 , hole_min, hole_max,1 ,0 ); +#else + dtb_base =locate_hole (info, dtb_max,128UL *1024 , + hole_min, hole_max,1 ); +#endif dbgprintf ("dtb: base %lx, size %lxh (%ld)\n" , dtb_base, dtb_2.size, dtb_2.size);@@ -670,8 +686,14 @@ int arm64_load_other_segments(struct kexec_info *info,/* Put the initrd after the DTB with an alignment of * page size. */ +#if 1 + initrd_base =add_buffer_phys_virt (info, initrd_buf, + initrd_size, initrd_size,0 , + hole_min, hole_max,1 ,0 ); +#else initrd_base =locate_hole (info, initrd_size,0 , - dtb_base + dtb_max,-1 ,1 ); + dtb_base + dtb_max, hole_max,1 ); +#endif dbgprintf ("initrd: base %lx, size %lxh (%ld)\n" , initrd_base, initrd_size, initrd_size);@@ -695,12 +717,14 @@ int arm64_load_other_segments(struct kexec_info *info,return -EINVAL ; } +#if 0 add_segment_phys_virt (info, dtb_2.buf, dtb_2.size, dtb_base, dtb_2.size,0 );if (arm64_opts.initrd)add_segment_phys_virt (info, initrd_buf, initrd_size, initrd_base, initrd_size,0 ); +#endif if (arm64_opts.lite) info->entry = (void *)kernel_entry;@@ -714,8 +738,13 @@ int arm64_load_other_segments(struct kexec_info *info,return -EBADF ; } +#if 1 +elf_rel_build_load (info, &info->rhdr, purgatory, purgatory_size, + hole_min, hole_max,1 ,0 ); +#else elf_rel_build_load (info, &info->rhdr, purgatory, purgatory_size, - purgatory_base,ULONG_MAX ,1 ,0 ); + purgatory_base, hole_max,1 ,0 ); +#endif info->entry = (void *)elf_rel_get_addr (&info->rhdr,"purgatory_start" );
Quoted 26 lines
Thanks,
-Takahiro AKASHIQuoted 23 lines
Not sure, if understood the question and replied well.
~Pratyush
Quoted 16 lines
Quoted 10 lines
kexec/arch/arm64/crashdump-arm64.c +0
-1} --2.1.0
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
RFC PATCH 4/6 arm64: support reuse-cmdline option
In reply to Pratyush Anand--reuse-cmdline uses cmdline argument of primary kernel. Support this feature for ARM64.
--- kexec/arch/arm64/include/arch/options.h | 7 +++++-- kexec/arch/arm64/kexec-arm64.c | 8 +++++++- 2 files changed, 12 insertions(+), 3 deletions(-)
kexec/arch/arm64/include/arch/options.h +5 -2
@@ -6,7 +6,8 @@#define OPT_INITRD ((OPT_MAX)+2)#define OPT_LITE ((OPT_MAX)+3)#define OPT_PORT ((OPT_MAX)+4) -#define OPT_ARCH_MAX ((OPT_MAX)+5) +#define OPT_REUSE_CMDLINE ((OPT_MAX+5)) +#define OPT_ARCH_MAX ((OPT_MAX)+6)#define KEXEC_ARCH_OPTIONS \ KEXEC_OPTIONS \
@@ -17,6 +18,7 @@ { "lite", 0, NULL, OPT_LITE }, \ { "port", 1, NULL, OPT_PORT }, \ { "ramdisk", 1, NULL, OPT_INITRD }, \ + { "reuse-cmdline", 0, NULL, OPT_REUSE_CMDLINE }, \ #define KEXEC_ARCH_OPT_STR KEXEC_OPT_STR /* Only accept long arch options. */ #define KEXEC_ALL_OPTIONS KEXEC_ARCH_OPTIONS
@@ -29,7 +31,8 @@ static const char arm64_opts_usage[] __attribute__ ((unused)) =" --initrd=FILE Use FILE as the kernel initial ramdisk.\n" " --lite Fast reboot, no memory integrity checks.\n" " --port=ADDRESS Purgatory output to port ADDRESS.\n" -" --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n" ; +" --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n" +" --reuse-cmdline Use command line arg of primary kernel.\n" ;struct arm64_opts {const char *command_line;
kexec/arch/arm64/kexec-arm64.c +7 -1
@@ -74,13 +74,18 @@ int arch_process_options(int argc, char **argv) { 0 } };int opt; +const char *append =NULL ; +char *tmp_cmdline =NULL ;for (opt =0 ; opt !=-1 ; ) { opt =getopt_long (argc, argv, short_options, options,0 );switch (opt) {case OPT_APPEND : - arm64_opts.command_line = optarg; + append = optarg; +break ; +case OPT_REUSE_CMDLINE : + tmp_cmdline =get_command_line ();break ;case OPT_DTB : arm64_opts.dtb = optarg;
@@ -99,6 +104,7 @@ int arch_process_options(int argc, char **argv) } } + arm64_opts.command_line =concat_cmdline (tmp_cmdline, append); kexec_debug =1 ;// FIXME: for debugging only. dbgprintf("%s:%d: command_line: %s\n", __func__, __LINE__,
Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 4/6] arm64: support reuse-cmdline option
Quoted 2 lines · Pratyush Anand
--reuse-cmdline uses cmdline argument of primary kernel. Support this feature for ARM64.
Looks OK, I'll add this to my arm64 series.
-Geoff
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
RFC PATCH 5/6 arm64: Add support for binary image
In reply to Pratyush AnandThis patch adds support to use binary image ie arch/arm64/boot/Image.
Binary image does not have sufficient knowledge to extract page offset information, which is needed by kexec tool. Use a new command parameter --page-offset, so that user can provide page offset information for liner mapping.
--- kexec/arch/arm64/crashdump-arm64.h | 1 + kexec/arch/arm64/include/arch/options.h | 10 ++++-- kexec/arch/arm64/kexec-arm64.c | 3 ++ kexec/arch/arm64/kexec-arm64.h | 2 ++ kexec/arch/arm64/kexec-image-arm64.c | 54 ++++++++++++++++++++++++++++++--- 5 files changed, 63 insertions(+), 7 deletions(-)
kexec/arch/arm64/crashdump-arm64.h +1 -0
@@ -17,6 +17,7 @@#define CRASH_MAX_MEMORY_RANGES 32extern struct memory_ranges usablemem_rgns; +extern struct memory_range crash_reserved_mem;int load_crashdump_segments (struct kexec_info *info,char **option);void modify_ehdr_for_crashmem (struct mem_ehdr *ehdr);
kexec/arch/arm64/include/arch/options.h +7 -3
@@ -5,9 +5,10 @@#define OPT_DTB ((OPT_MAX)+1)#define OPT_INITRD ((OPT_MAX)+2)#define OPT_LITE ((OPT_MAX)+3) -#define OPT_PORT ((OPT_MAX)+4) -#define OPT_REUSE_CMDLINE ((OPT_MAX+5)) -#define OPT_ARCH_MAX ((OPT_MAX)+6) +#define OPT_PAGE_OFFSET ((OPT_MAX)+4) +#define OPT_PORT ((OPT_MAX)+5) +#define OPT_REUSE_CMDLINE ((OPT_MAX+6)) +#define OPT_ARCH_MAX ((OPT_MAX)+7)#define KEXEC_ARCH_OPTIONS \ KEXEC_OPTIONS \
@@ -16,6 +17,7 @@ { "dtb", 1, NULL, OPT_DTB }, \ { "initrd", 1, NULL, OPT_INITRD }, \ { "lite", 0, NULL, OPT_LITE }, \ + { "page-offset", 1, NULL, OPT_PAGE_OFFSET }, \ { "port", 1, NULL, OPT_PORT }, \ { "ramdisk", 1, NULL, OPT_INITRD }, \ { "reuse-cmdline", 0, NULL, OPT_REUSE_CMDLINE }, \
@@ -30,6 +32,7 @@ static const char arm64_opts_usage[] __attribute__ ((unused)) =" --dtb=FILE Use FILE as the device tree blob.\n" " --initrd=FILE Use FILE as the kernel initial ramdisk.\n" " --lite Fast reboot, no memory integrity checks.\n" +" --page-offset Kernel page-offset for binary image load.\n" " --port=ADDRESS Purgatory output to port ADDRESS.\n" " --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n" " --reuse-cmdline Use command line arg of primary kernel.\n" ;
@@ -38,6 +41,7 @@ struct arm64_opts {const char *command_line;const char *dtb;const char *initrd; +uint64_t page_offset;uint64_t port;int lite; };
kexec/arch/arm64/kexec-arm64.c +3 -0
@@ -99,6 +99,9 @@ int arch_process_options(int argc, char **argv)case OPT_PORT : arm64_opts.port =strtoull (optarg,NULL ,0 );break ; +case OPT_PAGE_OFFSET : + arm64_opts.page_offset =strtoull (optarg,NULL ,0 ); +break ;default :break ;/* Ignore core and unknown options. */ }
kexec/arch/arm64/kexec-arm64.h +2 -0
@@ -17,6 +17,8 @@#define BOOT_BLOCK_LAST_COMP_VERSION 16#define COMMAND_LINE_SIZE 512 +#define ARM64_DEFAULT_PAGE_OFFSET 0xfffffe0000000000 +int elf_arm64_probe (const char *kernel_buf,off_t kernel_size);int elf_arm64_load (int argc,char **argv,const char *kernel_buf,off_t kernel_size,struct kexec_info *info);
kexec/arch/arm64/kexec-image-arm64.c +50 -4
72 lines not on this page · raw message
Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 5/6] arm64: Add support for binary image
Quoted 6 lines · Pratyush Anand
This patch adds support to use binary image ie
arch/arm64/boot/Image.Binary image does not have sufficient knowledge to extract page offset information, which is needed by kexec tool. Use a new command parameter --page-offset, so that user can provide page offset information for liner mapping.
This looks OK. I'll add it to my arm64 series.
kexec/arch/arm64/kexec-arm64.h line 21
Quoted 10 lines
kexec/arch/arm64/kexec-arm64.h +2
-0@@ -17,6 +17,8 @@#define BOOT_BLOCK_LAST_COMP_VERSION 16#define COMMAND_LINE_SIZE 512 +#define ARM64_DEFAULT_PAGE_OFFSET 0xfffffe0000000000 +
Since this is only used in kexec-image-arm64.c, I'll move it there.
-Geoff
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 5/6] arm64: Add support for binary image
Hi,
Quoted 9 lines · Geoff Levand
Quoted 6 lines · Pratyush Anand
This patch adds support to use binary image ie
arch/arm64/boot/Image.Binary image does not have sufficient knowledge to extract page offset information, which is needed by kexec tool. Use a new command parameter --page-offset, so that user can provide page offset information for liner mapping.
This looks OK. I'll add it to my arm64 series.
I tried to apply this but it failed. Please rebase to my latest [1] and repost. Any extra that crashdump needs should go to Takahiro.
Thanks.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git master
-Geoff
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 5/6] arm64: Add support for binary image
Quoted 11 lines · Geoff Levand
Hi,
Quoted 8 lines · Geoff Levand
Quoted 6 lines · Pratyush Anand
This patch adds support to use binary image ie
arch/arm64/boot/Image.Binary image does not have sufficient knowledge to extract page offset information, which is needed by kexec tool. Use a new command parameter --page-offset, so that user can provide page offset information for liner mapping.
Quoted 5 lines
Quoted 1 line
This looks OK. I'll add it to my arm64 series.
I tried to apply this but it failed. Please rebase to my latest [1] and repost. Any extra that crashdump needs should go to Takahiro.
ok.
Quoted 4 lines
Thanks.
[1]
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.gitmaster
Quoted 8 lines
-Geoff
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 5/6] arm64: Add support for binary image
In reply to Pratyush AnandQuoted 9 lines · Pratyush Anand
This patch adds support to use binary image ie
arch/arm64/boot/Image.Binary image does not have sufficient knowledge to extract page offset information, which is needed by kexec tool. Use a new command parameter --page-offset, so that user can provide page offset information for liner mapping.
Signed-off-by Pratyush Anand <[email protected]>---
Seems there's a function get_kernel_page_offset used to get page_offset automatically in arm. arm64 should have it either.
Quoted 174 lines
kexec/arch/arm64/crashdump-arm64.h | 1 + kexec/arch/arm64/include/arch/options.h | 10 ++++-- kexec/arch/arm64/kexec-arm64.c | 3 ++ kexec/arch/arm64/kexec-arm64.h | 2 ++ kexec/arch/arm64/kexec-image-arm64.c | 54 ++++++++++++++++++++++++++++++--- 5 files changed, 63 insertions(+), 7 deletions(-)kexec/arch/arm64/crashdump-arm64.h +1
-0@@ -17,6 +17,7 @@#define CRASH_MAX_MEMORY_RANGES 32extern struct memory_ranges usablemem_rgns; +extern struct memory_range crash_reserved_mem;int load_crashdump_segments (struct kexec_info *info,char **option);void modify_ehdr_for_crashmem (struct mem_ehdr *ehdr);kexec/arch/arm64/include/arch/options.h +7
-3@@ -5,9 +5,10 @@#define OPT_DTB ((OPT_MAX)+1)#define OPT_INITRD ((OPT_MAX)+2)#define OPT_LITE ((OPT_MAX)+3) -#define OPT_PORT ((OPT_MAX)+4) -#define OPT_REUSE_CMDLINE ((OPT_MAX+5)) -#define OPT_ARCH_MAX ((OPT_MAX)+6) +#define OPT_PAGE_OFFSET ((OPT_MAX)+4) +#define OPT_PORT ((OPT_MAX)+5) +#define OPT_REUSE_CMDLINE ((OPT_MAX+6)) +#define OPT_ARCH_MAX ((OPT_MAX)+7)#define KEXEC_ARCH_OPTIONS \ KEXEC_OPTIONS \@@ -16,6 +17,7 @@ { "dtb", 1, NULL, OPT_DTB }, \ { "initrd", 1, NULL, OPT_INITRD }, \ { "lite", 0, NULL, OPT_LITE }, \ + { "page-offset", 1, NULL, OPT_PAGE_OFFSET }, \ { "port", 1, NULL, OPT_PORT }, \ { "ramdisk", 1, NULL, OPT_INITRD }, \ { "reuse-cmdline", 0, NULL, OPT_REUSE_CMDLINE }, \@@ -30,6 +32,7 @@ static const char arm64_opts_usage[] __attribute__ ((unused)) =" --dtb=FILE Use FILE as the device tree blob.\n" " --initrd=FILE Use FILE as the kernel initial ramdisk.\n" " --lite Fast reboot, no memory integrity checks.\n" +" --page-offset Kernel page-offset for binary image load.\n" " --port=ADDRESS Purgatory output to port ADDRESS.\n" " --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n" " --reuse-cmdline Use command line arg of primary kernel.\n" ;@@ -38,6 +41,7 @@ struct arm64_opts {const char *command_line;const char *dtb;const char *initrd; +uint64_t page_offset;uint64_t port;int lite; };kexec/arch/arm64/kexec-arm64.c +3
-0@@ -99,6 +99,9 @@ int arch_process_options(int argc, char **argv)case OPT_PORT : arm64_opts.port =strtoull (optarg,NULL ,0 );break ; +case OPT_PAGE_OFFSET : + arm64_opts.page_offset =strtoull (optarg,NULL ,0 ); +break ;default :break ;/* Ignore core and unknown options. */ }kexec/arch/arm64/kexec-arm64.h +2
-0@@ -17,6 +17,8 @@#define BOOT_BLOCK_LAST_COMP_VERSION 16#define COMMAND_LINE_SIZE 512 +#define ARM64_DEFAULT_PAGE_OFFSET 0xfffffe0000000000 +int elf_arm64_probe (const char *kernel_buf,off_t kernel_size);int elf_arm64_load (int argc,char **argv,const char *kernel_buf,off_t kernel_size,struct kexec_info *info);kexec/arch/arm64/kexec-image-arm64.c +50
-4@@ -8,7 +8,9 @@#include <errno.h> #include <getopt.h> #include <libfdt.h> +#include <stdlib.h> +#include "crashdump-arm64.h" #include "dt-ops.h" #include "image-header.h" #include "kexec-arm64.h" @@ -31,15 +33,59 @@ int image_arm64_probe(const char *kernel_buf, off_t kernel_size)dbgprintf ("%s: PE format: %s\n" , __func__, (arm64_header_check_pe_sig (h) ?"yes" :"no" )); -fprintf (stderr,"kexec: arm64 binary Image files are currently NOT SUPPORTED.\n" ); - -return -1 ; +return 0 ; }int image_arm64_load (int argc,char **argv,const char *kernel_buf,off_t kernel_size,struct kexec_info *info) { -return -ENOSYS ; +int result; +uint64_t start; +const struct arm64_image_header *h; +char *header_option =NULL ; + + h = (const struct arm64_image_header *)(kernel_buf); + + arm64_mem.text_offset =le64_to_cpu (h->text_offset); + arm64_mem.image_size =le64_to_cpu (h->image_size); + +if (!arm64_opts.page_offset) + arm64_mem.page_offset =ARM64_DEFAULT_PAGE_OFFSET ; +else + arm64_mem.page_offset = arm64_opts.page_offset; + +if (info->kexec_flags &KEXEC_ON_CRASH ) { + result =load_crashdump_segments (info, &header_option); + +if (result) { +fprintf (stderr,"kexec: load crashdump segments failed.\n" ); +return -1 ; + } + start = crash_reserved_mem.start; + }else { + result =parse_iomem_single ("Kernel code\n" , &start,NULL ); + +if (result) { +fprintf (stderr,"kexec: Could not get kernel code address.\n" ); +return -1 ; + } + start -= arm64_mem.text_offset; + } + +/* Add kernel */ +add_segment_phys_virt (info, kernel_buf, kernel_size, + start + arm64_mem.text_offset, + kernel_size,0 ); + + info->entry = (void *)start + arm64_mem.text_offset; + + result =arm64_load_other_segments (info, (unsigned long )info->entry, + header_option); + +if (header_option) +free (header_option); + +return result; }void image_arm64_usage (void )Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 5/6] arm64: Add support for binary image
Quoted 8 lines · Baoquan He
Quoted 7 lines · Pratyush Anand
Quoted 7 lines
This patch adds support to use binary image ie
arch/arm64/boot/Image.Binary image does not have sufficient knowledge to extract page offset information, which is needed by kexec tool. Use a new command parameter --page-offset, so that user can provide page offset information for liner mapping.
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Signed-off-by Pratyush Anand<[email protected]>---
Seems there's a function
get_kernel_page_offsetused to getpage_offsetautomatically in arm. arm64 should have it either.
ARM still takes user option for --page-offset in user_page_offset variable and then cross check that value with one found in /proc/kallsyms.
May be for ARM64, we can read it like "value of symbol _text in /proc/kallsyms & 0xfffffffffff00000".
~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 5/6] arm64: Add support for binary image
Quoted 13 lines · Pratyush Anand
Quoted 10 lines · Baoquan He
Quoted 9 lines · Pratyush Anand
Quoted 9 lines
This patch adds support to use binary image ie
arch/arm64/boot/Image.Binary image does not have sufficient knowledge to extract page offset information, which is needed by kexec tool. Use a new command parameter --page-offset, so that user can provide page offset information for liner mapping.
Signed-off-by Pratyush Anand<[email protected]>---
Quoted 8 lines
Quoted 4 lines
Seems there's a function
get_kernel_page_offsetused to getpage_offsetautomatically in arm. arm64 should have it either.ARM still takes user option for --page-offset in
user_page_offsetvariable and then cross check that value with one found in/proc/kallsyms.
Well, this looks good. Try --page-offset and then fetch it in /proc/kallsysms if not specificed by user. ARM64 should have this too.
Quoted 10 lines
May be for ARM64, we can read it like "value of symbol
_textin/proc/kallsyms&0xfffffffffff00000".~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 5/6] arm64: Add support for binary image
Quoted 19 lines · Baoquan He
Quoted 18 lines · Pratyush Anand
Quoted 14 lines · Baoquan He
Quoted 9 lines · Pratyush Anand
Quoted 9 lines
This patch adds support to use binary image ie
arch/arm64/boot/Image.Binary image does not have sufficient knowledge to extract page offset information, which is needed by kexec tool. Use a new command parameter --page-offset, so that user can provide page offset information for liner mapping.
Signed-off-by Pratyush Anand<[email protected]>---
Seems there's a function
get_kernel_page_offsetused to getpage_offsetautomatically in arm. arm64 should have it either.
Quoted 8 lines
Quoted 3 lines
ARM still takes user option for --page-offset in
user_page_offsetvariable and then cross check that value with one found in/proc/kallsyms.Well, this looks good. Try --page-offset and then fetch it in
/proc/kallsysmsif not specificed by user. ARM64 should have this too.Quoted 1 line
OK... Will do that.
@Geoff: I will send this patch in two parts. First will apply on top of your patches. Second will apply after Takahiro's patch.
~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
RFC PATCH 6/6 arm64: wait for transmit completion before next character transmission
In reply to Pratyush AnandPrevious transmission must be completed before next character to be transmitted, otherwise TX buffer may saturate and we will not see all the characters on screen.
--- kexec/arch/arm64/include/arch/options.h | 10 +++++++++- kexec/arch/arm64/kexec-arm64.c | 17 +++++++++++++++++ purgatory/arch/arm64/entry.S | 10 ++++++++++ purgatory/arch/arm64/purgatory-arm64.c | 22 +++++++++++++++++++++- 4 files changed, 57 insertions(+), 2 deletions(-)
kexec/arch/arm64/include/arch/options.h +9 -1
@@ -8,7 +8,9 @@#define OPT_PAGE_OFFSET ((OPT_MAX)+4)#define OPT_PORT ((OPT_MAX)+5)#define OPT_REUSE_CMDLINE ((OPT_MAX+6)) -#define OPT_ARCH_MAX ((OPT_MAX)+7) +#define OPT_PORT_LSR ((OPT_MAX)+7) +#define OPT_PORT_LSR_VAL ((OPT_MAX)+8) +#define OPT_ARCH_MAX ((OPT_MAX)+9)#define KEXEC_ARCH_OPTIONS \ KEXEC_OPTIONS \
@@ -19,6 +21,8 @@ { "lite", 0, NULL, OPT_LITE }, \ { "page-offset", 1, NULL, OPT_PAGE_OFFSET }, \ { "port", 1, NULL, OPT_PORT }, \ + { "port-lsr", 1, NULL, OPT_PORT_LSR }, \ + { "port-lsr-val", 1, NULL, OPT_PORT_LSR_VAL }, \ { "ramdisk", 1, NULL, OPT_INITRD }, \ { "reuse-cmdline", 0, NULL, OPT_REUSE_CMDLINE }, \
@@ -34,6 +38,8 @@ static const char arm64_opts_usage[] __attribute__ ((unused)) =" --lite Fast reboot, no memory integrity checks.\n" " --page-offset Kernel page-offset for binary image load.\n" " --port=ADDRESS Purgatory output to port ADDRESS.\n" +" --port-lsr=ADDRESS Purgatory output port line status ADDRESS.\n" +" --port-lsr-val=VALUE Purgatory output port Line status expected SET value when TX empty.\n" " --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n" " --reuse-cmdline Use command line arg of primary kernel.\n" ;
@@ -43,6 +49,8 @@ struct arm64_opts {const char *initrd;uint64_t page_offset;uint64_t port; +uint64_t port_lsr; +uint32_t port_lsr_val;int lite; };
kexec/arch/arm64/kexec-arm64.c +17 -0
@@ -99,6 +99,12 @@ int arch_process_options(int argc, char **argv)case OPT_PORT : arm64_opts.port =strtoull (optarg,NULL ,0 );break ; +case OPT_PORT_LSR : + arm64_opts.port_lsr =strtoull (optarg,NULL ,0 ); +break ; +case OPT_PORT_LSR_VAL : + arm64_opts.port_lsr_val =strtoull (optarg,NULL ,0 ); +break ;case OPT_PAGE_OFFSET : arm64_opts.page_offset =strtoull (optarg,NULL ,0 );break ;
@@ -594,6 +600,8 @@ int arm64_load_other_segments(struct kexec_info *info,unsigned long dtb_base;char *initrd_buf =NULL ;uint64_t purgatory_sink; +uint64_t purgatory_sink_lsr; +uint32_t purgatory_sink_lsr_val;unsigned long purgatory_base;struct dtb dtb_1 = {.name ="dtb_1" };struct dtb dtb_2 = {.name ="dtb_2" };
@@ -615,6 +623,9 @@ int arm64_load_other_segments(struct kexec_info *info,dbgprintf ("%s:%d: purgatory sink: 0x%" PRIx64"\n" , __func__, __LINE__, purgatory_sink); + purgatory_sink_lsr = arm64_opts.port_lsr; + purgatory_sink_lsr_val = arm64_opts.port_lsr_val; +if (arm64_opts.dtb) { dtb_2.buf =slurp_file (arm64_opts.dtb, &dtb_2.size);assert (dtb_2.buf);
@@ -732,6 +743,12 @@ int arm64_load_other_segments(struct kexec_info *info,elf_rel_set_symbol (&info->rhdr,"arm64_sink" , &purgatory_sink,sizeof (purgatory_sink)); +elf_rel_set_symbol (&info->rhdr,"arm64_sink_lsr" , + &purgatory_sink_lsr,sizeof (purgatory_sink_lsr)); + +elf_rel_set_symbol (&info->rhdr,"arm64_sink_lsr_val" , + &purgatory_sink_lsr_val,sizeof (purgatory_sink_lsr_val)); +elf_rel_set_symbol (&info->rhdr,"arm64_kernel_entry" , &kernel_entry,sizeof (kernel_entry));
purgatory/arch/arm64/entry.S +10 -0
@@ -43,6 +43,11 @@ arm64_sink: .quad 0 size arm64_sink +.globl arm64_sink_lsr +arm64_sink_lsr: + .quad 0 +size arm64_sink_lsr + .globl arm64_kernel_entry arm64_kernel_entry: .quad 0
@@ -52,3 +57,8 @@ size arm64_kernel_entry arm64_dtb_addr: .quad 0 size arm64_dtb_addr + +.globl arm64_sink_lsr_val +arm64_sink_lsr_val: + .word 0 +size arm64_sink_lsr_val
purgatory/arch/arm64/purgatory-arm64.c +21 -1
@@ -8,18 +8,38 @@/* Symbols set by kexec. */ extern uint32_t *arm64_sink; +extern uint32_t *arm64_sink_lsr; +extern uint32_t arm64_sink_lsr_val;extern void (*arm64_kernel_entry)(uint64_t );extern uint64_t arm64_dtb_addr; +static void wait_for_xmit_complete (void ) +{ +volatile uint32_t status; +volatile uint32_t *status_reg = (volatile uint32_t *)arm64_sink_lsr; + +if (!arm64_sink_lsr) +return ; + +while (1 ) { + status = *status_reg; +if ((status & arm64_sink_lsr_val) == arm64_sink_lsr_val) +break ; + } +} +void putchar (int ch) {if (!arm64_sink)return ; +wait_for_xmit_complete (); *arm64_sink = ch; -if (ch =='\n' ) +if (ch =='\n' ) { +wait_for_xmit_complete (); *arm64_sink ='\r' ; + } }void setup_arch (void )
Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission
Quoted 120 lines · Pratyush Anand
Previous transmission must be completed before next character to be transmitted, otherwise TX buffer may saturate and we will not see all the characters on screen.
Signed-off-by Pratyush Anand <[email protected]>--- kexec/arch/arm64/include/arch/options.h | 10 +++++++++- kexec/arch/arm64/kexec-arm64.c | 17 +++++++++++++++++ purgatory/arch/arm64/entry.S | 10 ++++++++++ purgatory/arch/arm64/purgatory-arm64.c | 22 +++++++++++++++++++++- 4 files changed, 57 insertions(+), 2 deletions(-)kexec/arch/arm64/include/arch/options.h +9
-1@@ -8,7 +8,9 @@#define OPT_PAGE_OFFSET ((OPT_MAX)+4)#define OPT_PORT ((OPT_MAX)+5)#define OPT_REUSE_CMDLINE ((OPT_MAX+6)) -#define OPT_ARCH_MAX ((OPT_MAX)+7) +#define OPT_PORT_LSR ((OPT_MAX)+7) +#define OPT_PORT_LSR_VAL ((OPT_MAX)+8) +#define OPT_ARCH_MAX ((OPT_MAX)+9)#define KEXEC_ARCH_OPTIONS \ KEXEC_OPTIONS \@@ -19,6 +21,8 @@ { "lite", 0, NULL, OPT_LITE }, \ { "page-offset", 1, NULL, OPT_PAGE_OFFSET }, \ { "port", 1, NULL, OPT_PORT }, \ + { "port-lsr", 1, NULL, OPT_PORT_LSR }, \ + { "port-lsr-val", 1, NULL, OPT_PORT_LSR_VAL }, \ { "ramdisk", 1, NULL, OPT_INITRD }, \ { "reuse-cmdline", 0, NULL, OPT_REUSE_CMDLINE }, \@@ -34,6 +38,8 @@ static const char arm64_opts_usage[] __attribute__ ((unused)) =" --lite Fast reboot, no memory integrity checks.\n" " --page-offset Kernel page-offset for binary image load.\n" " --port=ADDRESS Purgatory output to port ADDRESS.\n" +" --port-lsr=ADDRESS Purgatory output port line status ADDRESS.\n" +" --port-lsr-val=VALUE Purgatory output port Line status expected SET value when TX empty.\n" " --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n" " --reuse-cmdline Use command line arg of primary kernel.\n" ;@@ -43,6 +49,8 @@ struct arm64_opts {const char *initrd;uint64_t page_offset;uint64_t port; +uint64_t port_lsr; +uint32_t port_lsr_val;int lite; };kexec/arch/arm64/kexec-arm64.c +17
-0@@ -99,6 +99,12 @@ int arch_process_options(int argc, char **argv)case OPT_PORT : arm64_opts.port =strtoull (optarg,NULL ,0 );break ; +case OPT_PORT_LSR : + arm64_opts.port_lsr =strtoull (optarg,NULL ,0 ); +break ; +case OPT_PORT_LSR_VAL : + arm64_opts.port_lsr_val =strtoull (optarg,NULL ,0 ); +break ;case OPT_PAGE_OFFSET : arm64_opts.page_offset =strtoull (optarg,NULL ,0 );break ;@@ -594,6 +600,8 @@ int arm64_load_other_segments(struct kexec_info *info,unsigned long dtb_base;char *initrd_buf =NULL ;uint64_t purgatory_sink; +uint64_t purgatory_sink_lsr; +uint32_t purgatory_sink_lsr_val;unsigned long purgatory_base;struct dtb dtb_1 = {.name ="dtb_1" };struct dtb dtb_2 = {.name ="dtb_2" };@@ -615,6 +623,9 @@ int arm64_load_other_segments(struct kexec_info *info,dbgprintf ("%s:%d: purgatory sink: 0x%" PRIx64"\n" , __func__, __LINE__, purgatory_sink); + purgatory_sink_lsr = arm64_opts.port_lsr; + purgatory_sink_lsr_val = arm64_opts.port_lsr_val; +if (arm64_opts.dtb) { dtb_2.buf =slurp_file (arm64_opts.dtb, &dtb_2.size);assert (dtb_2.buf);@@ -732,6 +743,12 @@ int arm64_load_other_segments(struct kexec_info *info,elf_rel_set_symbol (&info->rhdr,"arm64_sink" , &purgatory_sink,sizeof (purgatory_sink)); +elf_rel_set_symbol (&info->rhdr,"arm64_sink_lsr" , + &purgatory_sink_lsr,sizeof (purgatory_sink_lsr)); + +elf_rel_set_symbol (&info->rhdr,"arm64_sink_lsr_val" , + &purgatory_sink_lsr_val,sizeof (purgatory_sink_lsr_val)); +elf_rel_set_symbol (&info->rhdr,"arm64_kernel_entry" , &kernel_entry,sizeof (kernel_entry));purgatory/arch/arm64/entry.S +5
-0@@ -43,6 +43,11 @@ arm64_sink: .quad 0 size arm64_sink +.globl arm64_sink_lsr +arm64_sink_lsr: + .quad 0 +size arm64_sink_lsr + .globl arm64_kernel_entry arm64_kernel_entry: .quad 0
purgatory/arch/arm64/entry.S size arm64_kernel_entry · line 63
Quoted 7 lines
purgatory/arch/arm64/entry.S +4
-0@@ -52,3 +57,8 @@ size arm64_kernel_entry arm64_dtb_addr: .quad 0 size arm64_dtb_addr + +.globl arm64_sink_lsr_val +arm64_sink_lsr_val: + .word 0
Since arm64_sink_lsr_val is declared as uint32_t, it is better to keep the same format here.
Thanks
Minfei
Quoted 53 lines
purgatory/arch/arm64/entry.S +1
-0+size arm64_sink_lsr_valpurgatory/arch/arm64/purgatory-arm64.c +21
-1@@ -8,18 +8,38 @@/* Symbols set by kexec. */ extern uint32_t *arm64_sink; +extern uint32_t *arm64_sink_lsr; +extern uint32_t arm64_sink_lsr_val;extern void (*arm64_kernel_entry)(uint64_t );extern uint64_t arm64_dtb_addr; +static void wait_for_xmit_complete (void ) +{ +volatile uint32_t status; +volatile uint32_t *status_reg = (volatile uint32_t *)arm64_sink_lsr; + +if (!arm64_sink_lsr) +return ; + +while (1 ) { + status = *status_reg; +if ((status & arm64_sink_lsr_val) == arm64_sink_lsr_val) +break ; + } +} +void putchar (int ch) {if (!arm64_sink)return ; +wait_for_xmit_complete (); *arm64_sink = ch; -if (ch =='\n' ) +if (ch =='\n' ) { +wait_for_xmit_complete (); *arm64_sink ='\r' ; + } }void setup_arch (void )Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission
Quoted 9 lines · Minfei Huang
Quoted 6 lines
.quad 0
purgatory/arch/arm64/entry.S size arm64_kernel_entry · line 63
Quoted 5 lines
size
arm64_dtb_addrpurgatory/arch/arm64/entry.S +4
-0+ +.globl arm64_sink_lsr_val +arm64_sink_lsr_val: + .word 0Since
arm64_sink_lsr_valis declared asuint32_t, it is better to keep the same format here.
I thought .word will do the same. But may be I am wrong. What is the good syntax for uint32_t.
~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission
Quoted 11 lines · Pratyush Anand
Quoted 8 lines · Minfei Huang
Quoted 6 lines
.quad 0
purgatory/arch/arm64/entry.S size arm64_kernel_entry · line 63
Quoted 5 lines
size
arm64_dtb_addrpurgatory/arch/arm64/entry.S +4
-0+ +.globl arm64_sink_lsr_val +arm64_sink_lsr_val: + .word 0Since
arm64_sink_lsr_valis declared asuint32_t, it is better to keep the same format here.
".word" only stores 16bit, doesn't it? Should it be ".int" or ".long"? You can check gnu as manual for reference.
Thanks
Baoquan
Quoted 11 lines
Quoted 1 line
I thought .word will do the same. But may be I am wrong. What is the good syntax for
uint32_t.~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission
Quoted 13 lines · Baoquan He
Quoted 11 lines · Pratyush Anand
Quoted 8 lines · Minfei Huang
Quoted 6 lines
.quad 0
purgatory/arch/arm64/entry.S size arm64_kernel_entry · line 63
Quoted 5 lines
size
arm64_dtb_addrpurgatory/arch/arm64/entry.S +4
-0+ +.globl arm64_sink_lsr_val +arm64_sink_lsr_val: + .word 0Since
arm64_sink_lsr_valis declared asuint32_t, it is better to keep the same format here.
Quoted 1 line
".word" only stores 16bit, doesn't it? Should it be ".int" or ".long"?
I see that .word, .int and .long all reserve 4 bytes for ARM64. But may be using .int could be better.
However, as Geoff suggested to remove port-lsr and port-lsr-val, so we will not need these.
~Pratyush
Quoted 17 lines
You can check gnu as manual for reference.
Thanks
BaoquanQuoted 11 lines
Quoted 1 line
I thought .word will do the same. But may be I am wrong. What is the good syntax for
uint32_t.~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 5 lines
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission
In reply to Pratyush Anandkexec/arch/arm64/include/arch/options.h static const char arm64_opts_usage[] __attribute__ ((unused)) = · line 44
Quoted 12 lines · Pratyush Anand
Previous transmission must be completed before next character to be transmitted, otherwise TX buffer may saturate and we will not see all the characters on screen.
kexec/arch/arm64/include/arch/options.h +2
-0@@ -34,6 +38,8 @@ static const char arm64_opts_usage[] __attribute__ ((unused)) =" --lite Fast reboot, no memory integrity checks.\n" " --page-offset Kernel page-offset for binary image load.\n" " --port=ADDRESS Purgatory output to port ADDRESS.\n" +" --port-lsr=ADDRESS Purgatory output port line status ADDRESS.\n" +" --port-lsr-val=VALUE Purgatory output port Line status expected SET value when TX empty.\n" " --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n" " --reuse-cmdline Use command line arg of primary kernel.\n" ;
We just need to put some chars to the screen, so I want to avoid a lot of parameters.
Usually the status register is at a fixed offset from the TX port. Is that not the case for the ARM uarts?
Can't we just poll port-lsr until empty then start writing again? That will at least eliminate port-lsr-val.
-Geoff
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission
Quoted 5 lines · Geoff Levand
Quoted 4 lines · Pratyush Anand
Previous transmission must be completed before next character to be transmitted, otherwise TX buffer may saturate and we will not see all the characters on screen.
Quoted 12 lines
kexec/arch/arm64/include/arch/options.h static const char arm64_opts_usage[] __attribute__ ((unused)) = · line 44
Quoted 8 lines
kexec/arch/arm64/include/arch/options.h +2
-0@@ -34,6 +38,8 @@ static const char arm64_opts_usage[] __attribute__ ((unused)) =" --lite Fast reboot, no memory integrity checks.\n" " --page-offset Kernel page-offset for binary image load.\n" " --port=ADDRESS Purgatory output to port ADDRESS.\n" +" --port-lsr=ADDRESS Purgatory output port line status ADDRESS.\n" +" --port-lsr-val=VALUE Purgatory output port Line status expected SET value when TX empty.\n" " --ramdisk=FILE Use FILE as the kernel initial ramdisk.\n" " --reuse-cmdline Use command line arg of primary kernel.\n" ;We just need to put some chars to the screen, so I want to avoid a lot of parameters.
I was not able to get even two lines print without it :(
Quoted 6 lines
Usually the status register is at a fixed offset from the TX port. Is that not the case for the ARM uarts?
Can't we just poll port-lsr until empty then start writing again? That will at least eliminate port-lsr-val.
infact my first version was using a direct offset with port. Both are fixed in most of the cases as offset 0x14 and value 0x60.
OK, I will remove the param for now. if someone finds any different values then later on we can add it.
~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Hi,
Quoted 20 lines · Pratyush Anand
These patches can be applied on top of Geoff's Kexec [1] and Takahiro's Kdump [2] patches and are available in my tree [3].
First two patches are for purgatory. 1st patch is a very important fix for sha verification. 2nd patch is good to have.
Rest all patches are fixes and addon for ARM64.
These patchset adds three extra command line options for ARM64.
--page-offset: Needed for binary image only. Default value is
0xfffffe0000000000.--port-lsr: It is UART's Line status register address. Normally for a
UART based on 8250, 16450 or 16550 should have value as --port's value +0x14.--port-lsr-val: It is the SET value of LSR register for TX buffer to be
empty. Normally for above UARTs it should be0x60
Quoted 6 lines
[1]
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git
: master
[2]git://git.linaro.org/people/takahiro.akashi/kexec-tools.git:
kdump/v0.10
[3] https://github.com/pratyushanand/kexec-tools.git : master (6c8a63f701e9)
I'm more than happy to consider accepting patches into my kexec tree if they are in a suitable state.
Quoted 8 lines
Pratyush Anand (6):
purgatory: Fix memcmp for src address increment
purgatory: No need to sha256 update ifptr->lenis zero
arm64: allocate memory for other segments after kernel
arm64: support reuse-cmdline option
arm64: Add support for binary image
arm64: wait for transmit completion before next character transmission
Quoted 21 lines
kexec/arch/arm64/crashdump-arm64.c | 3 +- kexec/arch/arm64/crashdump-arm64.h | 1 + kexec/arch/arm64/include/arch/options.h | 21 +++++++++++-- kexec/arch/arm64/kexec-arm64.c | 28 ++++++++++++++++- kexec/arch/arm64/kexec-arm64.h | 2 ++ kexec/arch/arm64/kexec-image-arm64.c | 54 ++++++++++++++++++++++++++++++--- purgatory/arch/arm64/entry.S | 10 ++++++ purgatory/arch/arm64/purgatory-arm64.c | 22 +++++++++++++- purgatory/purgatory.c | 2 ++ purgatory/string.c | 2 ++ 10 files changed, 135 insertions(+), 10 deletions(-)Signature · 7 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 35 lines · Pratyush Anand
These patches can be applied on top of Geoff's Kexec [1] and Takahiro's Kdump [2] patches and are available in my tree [3].
First two patches are for purgatory. 1st patch is a very important fix for sha verification. 2nd patch is good to have.
Rest all patches are fixes and addon for ARM64.
These patchset adds three extra command line options for ARM64.
--page-offset: Needed for binary image only. Default value is
0xfffffe0000000000.--port-lsr: It is UART's Line status register address. Normally for a
UART based on 8250, 16450 or 16550 should have value as --port's value +0x14.--port-lsr-val: It is the SET value of LSR register for TX buffer to be
empty. Normally for above UARTs it should be0x60[1]
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git
: master
[2]git://git.linaro.org/people/takahiro.akashi/kexec-tools.git:
kdump/v0.10
[3] https://github.com/pratyushanand/kexec-tools.git : master (6c8a63f701e9)Pratyush Anand (6):
purgatory: Fix memcmp for src address increment
purgatory: No need to sha256 update ifptr->lenis zero
arm64: allocate memory for other segments after kernel
arm64: support reuse-cmdline option
arm64: Add support for binary image
arm64: wait for transmit completion before next character transmission
Quoted 21 lines
kexec/arch/arm64/crashdump-arm64.c | 3 +- kexec/arch/arm64/crashdump-arm64.h | 1 + kexec/arch/arm64/include/arch/options.h | 21 +++++++++++-- kexec/arch/arm64/kexec-arm64.c | 28 ++++++++++++++++- kexec/arch/arm64/kexec-arm64.h | 2 ++ kexec/arch/arm64/kexec-image-arm64.c | 54 ++++++++++++++++++++++++++++++--- purgatory/arch/arm64/entry.S | 10 ++++++ purgatory/arch/arm64/purgatory-arm64.c | 22 +++++++++++++- purgatory/purgatory.c | 2 ++ purgatory/string.c | 2 ++ 10 files changed, 135 insertions(+), 10 deletions(-)Signature · 6 lines
2.1.0 _______________________________________________ kexec mailing list [email protected] https://lists.fedoraproject.org/mailman/listinfo/kexec
Hi, Pratyush
For these kexec-tools patches, it is not necessary to cc Fedora kexec list. The Fedora kexec list is only for Fedora part, mostly kdump initrd related code. Also it is subscriber only list so it will be unconvinient for other people to review upstream patches.
Thanks
Dave
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 7 lines · Dave Young
Hi, Pratyush
For these kexec-tools patches, it is not necessary to cc Fedora kexec list. The Fedora kexec list is only for Fedora part, mostly kdump initrd related code. Also it is subscriber only list so it will be unconvinient for other people to review upstream patches.
Thanks Dave. I will take care.
~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Hi Pratyush,
Quoted 2 lines · Pratyush Anand
These patches can be applied on top of Geoff's Kexec [1] and Takahiro's Kdump [2] patches and are available in my tree [3].
Thanks for putting these together. They look good for the most part.
-Geoff
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec