[PATCH RFC 0/6] Various fixes for purgatory and ARM64

[PATCH RFC 0/6] Various fixes for purgatory and ARM64

[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 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(-)

-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH RFC 1/6] purgatory: Fix memcmp for src address increment

[Pratyush Anand]

src addresses are not being incremented, so only first byte is compared
instead of first len bytes.

Signed-off-by: Pratyush Anand <panand@redhat.com>
---
 purgatory/string.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/purgatory/string.c b/purgatory/string.c
index 4f35613ef751..f06c460b08f8 100644
--- a/purgatory/string.c
+++ b/purgatory/string.c
@@ -46,6 +46,8 @@ int memcmp(void *src1, void *src2, size_t len)
 		if (*s1 != *s2) {
 			return *s2 - *s1;
 		}
+		s1++;
+		s2++;
 	}
 	return 0;
 	
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment

[Geoff Levand]

On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> 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 <geoff@infradead.org>




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment

[Simon Horman]

On Fri, Apr 17, 2015 at 09:55:44AM -0700, Geoff Levand wrote:
> On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> > 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 <geoff@infradead.org>

Hi Pratyush,

If you'd like me to take this plase repost it with Geoff's Ack
and without "RFC".

Thanks

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment

[Pratyush Anand]

On Monday 20 April 2015 05:55 AM, Simon Horman wrote:
> On Fri, Apr 17, 2015 at 09:55:44AM -0700, Geoff Levand wrote:
>> On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
>>> 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 <geoff@infradead.org>
>
> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment

[Simon Horman]

On Wed, Apr 22, 2015 at 04:49:30PM +0530, Pratyush Anand wrote:
> 
> 
> On Monday 20 April 2015 05:55 AM, Simon Horman wrote:
> >On Fri, Apr 17, 2015 at 09:55:44AM -0700, Geoff Levand wrote:
> >>On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> >>>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 <geoff@infradead.org>
> >
> >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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero

[Pratyush Anand]

If ptr->len is zero we do not need to update sha256.

Signed-off-by: Pratyush Anand <panand@redhat.com>
---
 purgatory/purgatory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
index 3bbcc0935ad5..f8ed69b8fbfb 100644
--- a/purgatory/purgatory.c
+++ b/purgatory/purgatory.c
@@ -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);
 	}
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero

[Geoff Levand]

On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> If ptr->len is zero we do not need to update sha256.

Looks OK.  Did you find this sped things up?

Acked-by: Geoff Levand <geoff@infradead.org>


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero

[Pratyush Anand]

On Friday 17 April 2015 10:28 PM, Geoff Levand wrote:
> On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
>> If ptr->len is 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

>
> Acked-by: Geoff Levand <geoff@infradead.org>
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero

[Baoquan He]

On 04/16/15 at 10:17pm, Pratyush Anand wrote:
> If ptr->len is zero we do not need to update sha256.
> 
> Signed-off-by: Pratyush Anand <panand@redhat.com>
> ---
>  purgatory/purgatory.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
> index 3bbcc0935ad5..f8ed69b8fbfb 100644
> --- a/purgatory/purgatory.c
> +++ b/purgatory/purgatory.c
> @@ -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

>  		sha256_update(&ctx, (uint8_t *)((uintptr_t)ptr->start),
>  			      ptr->len);
>  	}
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero

[Pratyush Anand]

On Monday 20 April 2015 08:31 AM, Baoquan He wrote:
> On 04/16/15 at 10:17pm, Pratyush Anand wrote:
>> If ptr->len is zero we do not need to update sha256.
>>
>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>> ---
>>   purgatory/purgatory.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/purgatory/purgatory.c b/purgatory/purgatory.c
>> index 3bbcc0935ad5..f8ed69b8fbfb 100644
>> --- a/purgatory/purgatory.c
>> +++ b/purgatory/purgatory.c
>> @@ -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.
>


I think you are right, we can skip this.

~Pratyush

> void sha256_update( sha256_context *ctx, const uint8_t *input, size_t
> length )
> {
>          size_t left, fill;
>
>          if( ! length ) return;
>
> ...
> }
>
> Thanks
> Baoquan
>
>>   		sha256_update(&ctx, (uint8_t *)((uintptr_t)ptr->start),
>>   			      ptr->len);
>>   	}
>> --
>> 2.1.0
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH RFC 3/6] arm64: allocate memory for other segments after kernel

[Pratyush Anand]

In case of KEXEC_ON_CRASH, load other segments after the addresses where
kernel segments finish.

Signed-off-by: Pratyush Anand <panand@redhat.com>
---
 kexec/arch/arm64/crashdump-arm64.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
index 41266f294589..75f4e4d269ca 100644
--- a/kexec/arch/arm64/crashdump-arm64.c
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -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);
 }
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel

[Geoff Levand]

On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> In case of KEXEC_ON_CRASH, load other segments after the addresses where
> kernel segments finish.
> 
> Signed-off-by: Pratyush Anand <panand@redhat.com>
> ---
>  kexec/arch/arm64/crashdump-arm64.c | 3 ++-

This one should be folded into Takahiro's latest patches.

-Geoff


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel

[Baoquan He]

On 04/16/15 at 10:17pm, Pratyush Anand wrote:
> In case of KEXEC_ON_CRASH, load other segments after the addresses where
> kernel segments finish.
> 
> Signed-off-by: Pratyush Anand <panand@redhat.com>
> ---
>  kexec/arch/arm64/crashdump-arm64.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
> index 41266f294589..75f4e4d269ca 100644
> --- a/kexec/arch/arm64/crashdump-arm64.c
> +++ b/kexec/arch/arm64/crashdump-arm64.c
> @@ -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.

>  }
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel

[Pratyush Anand]

On Monday 20 April 2015 08:51 AM, Baoquan He wrote:
> On 04/16/15 at 10:17pm, Pratyush Anand wrote:
>> In case of KEXEC_ON_CRASH, load other segments after the addresses where
>> kernel segments finish.
>>
>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>> ---
>>   kexec/arch/arm64/crashdump-arm64.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
>> index 41266f294589..75f4e4d269ca 100644
>> --- a/kexec/arch/arm64/crashdump-arm64.c
>> +++ b/kexec/arch/arm64/crashdump-arm64.c
>> @@ -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.

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



>
>>   }
>> --
>> 2.1.0
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel

[AKASHI Takahiro]

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.

On 04/21/2015 01:19 PM, Pratyush Anand wrote:
>
>
> On Monday 20 April 2015 08:51 AM, Baoquan He wrote:
>> On 04/16/15 at 10:17pm, Pratyush Anand wrote:
>>> In case of KEXEC_ON_CRASH, load other segments after the addresses where
>>> kernel segments finish.
>>>
>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>> ---
>>>   kexec/arch/arm64/crashdump-arm64.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
>>> index 41266f294589..75f4e4d269ca 100644
>>> --- a/kexec/arch/arm64/crashdump-arm64.c
>>> +++ b/kexec/arch/arm64/crashdump-arm64.c
>>> @@ -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.
>
> 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.

> 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.

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)

diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 2c5238c..642c4a9 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -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

>
> Not sure, if understood the question and replied well.
>
> ~Pratyush
>
>
>
>>
>>>   }
>>> --
>>> 2.1.0
>>>
>>>
>>> _______________________________________________
>>> kexec mailing list
>>> kexec@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/kexec
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel

[AKASHI Takahiro]

Geoff,

On 04/21/2015 07:06 PM, AKASHI Takahiro wrote:
> 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.
>
> On 04/21/2015 01:19 PM, Pratyush Anand wrote:
>>
>>
>> On Monday 20 April 2015 08:51 AM, Baoquan He wrote:
>>> On 04/16/15 at 10:17pm, Pratyush Anand wrote:
>>>> In case of KEXEC_ON_CRASH, load other segments after the addresses where
>>>> kernel segments finish.
>>>>
>>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>>> ---
>>>>   kexec/arch/arm64/crashdump-arm64.c | 3 ++-
>>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
>>>> index 41266f294589..75f4e4d269ca 100644
>>>> --- a/kexec/arch/arm64/crashdump-arm64.c
>>>> +++ b/kexec/arch/arm64/crashdump-arm64.c
>>>> @@ -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.
>>
>> 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.
>
>> 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.
>
> 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)

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

> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 2c5238c..642c4a9 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -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
>
>>
>> Not sure, if understood the question and replied well.
>>
>> ~Pratyush
>>
>>
>>
>>>
>>>>   }
>>>> --
>>>> 2.1.0
>>>>
>>>>
>>>> _______________________________________________
>>>> kexec mailing list
>>>> kexec@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/kexec
>>>
>>> _______________________________________________
>>> kexec mailing list
>>> kexec@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/kexec
>>>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH RFC 4/6] arm64: support reuse-cmdline option

[Pratyush Anand]

--reuse-cmdline uses cmdline argument of primary kernel. Support this
feature for ARM64.

Signed-off-by: Pratyush Anand <panand@redhat.com>
---
 kexec/arch/arm64/include/arch/options.h | 7 +++++--
 kexec/arch/arm64/kexec-arm64.c          | 8 +++++++-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/arm64/include/arch/options.h b/kexec/arch/arm64/include/arch/options.h
index 0d5987b18a25..afe3e9827ff3 100644
--- a/kexec/arch/arm64/include/arch/options.h
+++ b/kexec/arch/arm64/include/arch/options.h
@@ -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;
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 391fec1fa161..34e4ebf1eb23 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -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__,
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 4/6] arm64: support reuse-cmdline option

[Geoff Levand]

On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> --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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH RFC 5/6] arm64: Add support for binary image

[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 <panand@redhat.com>
---
 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(-)

diff --git a/kexec/arch/arm64/crashdump-arm64.h b/kexec/arch/arm64/crashdump-arm64.h
index d4fd3f2288c9..d53fa34de37a 100644
--- a/kexec/arch/arm64/crashdump-arm64.h
+++ b/kexec/arch/arm64/crashdump-arm64.h
@@ -17,6 +17,7 @@
 #define CRASH_MAX_MEMORY_RANGES	32
 
 extern 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);
diff --git a/kexec/arch/arm64/include/arch/options.h b/kexec/arch/arm64/include/arch/options.h
index afe3e9827ff3..af14102220ea 100644
--- a/kexec/arch/arm64/include/arch/options.h
+++ b/kexec/arch/arm64/include/arch/options.h
@@ -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;
 };
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 34e4ebf1eb23..190037c75186 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -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. */
 		}
diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h
index 61e15032cbd6..7e4d0568bd01 100644
--- a/kexec/arch/arm64/kexec-arm64.h
+++ b/kexec/arch/arm64/kexec-arm64.h
@@ -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);
diff --git a/kexec/arch/arm64/kexec-image-arm64.c b/kexec/arch/arm64/kexec-image-arm64.c
index b025dc6c0185..2ce68293a37b 100644
--- a/kexec/arch/arm64/kexec-image-arm64.c
+++ b/kexec/arch/arm64/kexec-image-arm64.c
@@ -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)
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 5/6] arm64: Add support for binary image

[Geoff Levand]

On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> 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.

> diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h
> index 61e15032cbd6..7e4d0568bd01 100644
> --- a/kexec/arch/arm64/kexec-arm64.h
> +++ b/kexec/arch/arm64/kexec-arm64.h
> @@ -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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 5/6] arm64: Add support for binary image

[Geoff Levand]

Hi,

On Fri, 2015-04-17 at 10:07 -0700, Geoff Levand wrote:
> On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> > 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 5/6] arm64: Add support for binary image

[Pratyush Anand]

On Friday 17 April 2015 11:30 PM, Geoff Levand wrote:
> Hi,
>
> On Fri, 2015-04-17 at 10:07 -0700, Geoff Levand wrote:
>> On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
>>> 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.
>

ok.

> Thanks.
>
> [1]  git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git master
>
> -Geoff
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 5/6] arm64: Add support for binary image

[Baoquan He]

On 04/16/15 at 10:17pm, Pratyush Anand wrote:
> 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 <panand@redhat.com>
> ---

Seems there's a function get_kernel_page_offset used to get page_offset
automatically in arm. arm64 should have it either.


>  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(-)
> 
> diff --git a/kexec/arch/arm64/crashdump-arm64.h b/kexec/arch/arm64/crashdump-arm64.h
> index d4fd3f2288c9..d53fa34de37a 100644
> --- a/kexec/arch/arm64/crashdump-arm64.h
> +++ b/kexec/arch/arm64/crashdump-arm64.h
> @@ -17,6 +17,7 @@
>  #define CRASH_MAX_MEMORY_RANGES	32
>  
>  extern 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);
> diff --git a/kexec/arch/arm64/include/arch/options.h b/kexec/arch/arm64/include/arch/options.h
> index afe3e9827ff3..af14102220ea 100644
> --- a/kexec/arch/arm64/include/arch/options.h
> +++ b/kexec/arch/arm64/include/arch/options.h
> @@ -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;
>  };
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 34e4ebf1eb23..190037c75186 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -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. */
>  		}
> diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h
> index 61e15032cbd6..7e4d0568bd01 100644
> --- a/kexec/arch/arm64/kexec-arm64.h
> +++ b/kexec/arch/arm64/kexec-arm64.h
> @@ -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);
> diff --git a/kexec/arch/arm64/kexec-image-arm64.c b/kexec/arch/arm64/kexec-image-arm64.c
> index b025dc6c0185..2ce68293a37b 100644
> --- a/kexec/arch/arm64/kexec-image-arm64.c
> +++ b/kexec/arch/arm64/kexec-image-arm64.c
> @@ -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)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 5/6] arm64: Add support for binary image

[Pratyush Anand]

On Monday 20 April 2015 12:54 PM, Baoquan He wrote:
> On 04/16/15 at 10:17pm, Pratyush Anand wrote:
>> >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<panand@redhat.com>
>> >---
> Seems there's a function get_kernel_page_offset used to get page_offset
> automatically 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 5/6] arm64: Add support for binary image

[Baoquan He]

On 04/21/15 at 10:12am, Pratyush Anand wrote:
> 
> 
> On Monday 20 April 2015 12:54 PM, Baoquan He wrote:
> >On 04/16/15 at 10:17pm, Pratyush Anand wrote:
> >>>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<panand@redhat.com>
> >>>---
> >Seems there's a function get_kernel_page_offset used to get page_offset
> >automatically 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.

Well, this looks good. Try --page-offset and then fetch it in
/proc/kallsysms if not specificed by user. ARM64 should have this too.

> 
> May be for ARM64, we can read it like "value of symbol _text in
> /proc/kallsyms & 0xfffffffffff00000".
> 
> ~Pratyush
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 5/6] arm64: Add support for binary image

[Pratyush Anand]

On Wednesday 22 April 2015 08:23 AM, Baoquan He wrote:
> On 04/21/15 at 10:12am, Pratyush Anand wrote:
>>
>>
>> On Monday 20 April 2015 12:54 PM, Baoquan He wrote:
>>> On 04/16/15 at 10:17pm, Pratyush Anand wrote:
>>>>> 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<panand@redhat.com>
>>>>> ---
>>> Seems there's a function get_kernel_page_offset used to get page_offset
>>> automatically 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.
>
> Well, this looks good. Try --page-offset and then fetch it in
> /proc/kallsysms if not specificed by user. ARM64 should have this too.
>
>>

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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission

[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 <panand@redhat.com>
---
 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(-)

diff --git a/kexec/arch/arm64/include/arch/options.h b/kexec/arch/arm64/include/arch/options.h
index af14102220ea..a1f6f2cb00be 100644
--- a/kexec/arch/arm64/include/arch/options.h
+++ b/kexec/arch/arm64/include/arch/options.h
@@ -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;
 };
 
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 190037c75186..5c7445b86305 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -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));
 
diff --git a/purgatory/arch/arm64/entry.S b/purgatory/arch/arm64/entry.S
index 140e91d87ab1..fdb2fca774e7 100644
--- a/purgatory/arch/arm64/entry.S
+++ b/purgatory/arch/arm64/entry.S
@@ -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
diff --git a/purgatory/arch/arm64/purgatory-arm64.c b/purgatory/arch/arm64/purgatory-arm64.c
index 25960c30bd05..1b88bb799f54 100644
--- a/purgatory/arch/arm64/purgatory-arm64.c
+++ b/purgatory/arch/arm64/purgatory-arm64.c
@@ -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)
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission

[Minfei Huang]

On 04/16/15 at 10:17pm, Pratyush Anand wrote:
> 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 <panand@redhat.com>
> ---
>  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(-)
> 
> diff --git a/kexec/arch/arm64/include/arch/options.h b/kexec/arch/arm64/include/arch/options.h
> index af14102220ea..a1f6f2cb00be 100644
> --- a/kexec/arch/arm64/include/arch/options.h
> +++ b/kexec/arch/arm64/include/arch/options.h
> @@ -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;
>  };
>  
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 190037c75186..5c7445b86305 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -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));
>  
> diff --git a/purgatory/arch/arm64/entry.S b/purgatory/arch/arm64/entry.S
> index 140e91d87ab1..fdb2fca774e7 100644
> --- a/purgatory/arch/arm64/entry.S
> +++ b/purgatory/arch/arm64/entry.S
> @@ -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

Since arm64_sink_lsr_val is declared as uint32_t, it is better to keep
the same format here.

Thanks
Minfei

> +size arm64_sink_lsr_val
> diff --git a/purgatory/arch/arm64/purgatory-arm64.c b/purgatory/arch/arm64/purgatory-arm64.c
> index 25960c30bd05..1b88bb799f54 100644
> --- a/purgatory/arch/arm64/purgatory-arm64.c
> +++ b/purgatory/arch/arm64/purgatory-arm64.c
> @@ -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)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission

[Pratyush Anand]

On Friday 17 April 2015 11:06 AM, Minfei Huang wrote:
>>   	.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.
>

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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission

[Baoquan He]

On 04/17/15 at 11:07am, Pratyush Anand wrote:
> 
> 
> On Friday 17 April 2015 11:06 AM, Minfei Huang wrote:
> >>  	.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.

".word" only stores 16bit, doesn't it? Should it be ".int" or ".long"?
You can check gnu as manual for reference.

Thanks
Baoquan

> >
> 
> 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
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission

[Pratyush Anand]

On Monday 20 April 2015 08:28 AM, Baoquan He wrote:
> On 04/17/15 at 11:07am, Pratyush Anand wrote:
>>
>>
>> On Friday 17 April 2015 11:06 AM, Minfei Huang wrote:
>>>>   	.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.
>
> ".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

> You can check gnu as manual for reference.
>
> Thanks
> Baoquan
>
>>>
>>
>> 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
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission

[Geoff Levand]

On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> 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.
> 
> @@ -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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission

[Pratyush Anand]

On Friday 17 April 2015 10:52 PM, Geoff Levand wrote:
> On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
>> 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.
>>
>> @@ -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 :(

> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 0/6] Various fixes for purgatory and ARM64

[Simon Horman]

Hi,

On Thu, Apr 16, 2015 at 10:17:23PM +0530, Pratyush Anand wrote:
> 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 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)

I'm more than happy to consider accepting patches into my
kexec tree if they are in a suitable state.

> 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(-)
> 
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 0/6] Various fixes for purgatory and ARM64

[Dave Young]

On 04/16/15 at 10:17pm, Pratyush Anand wrote:
> 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 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(-)
> 
> -- 
> 2.1.0
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.fedoraproject.org
> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 0/6] Various fixes for purgatory and ARM64

[Pratyush Anand]

On Friday 17 April 2015 06:57 AM, Dave Young wrote:
> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH RFC 0/6] Various fixes for purgatory and ARM64

[Geoff Levand]

Hi Pratyush,

On Thu, 2015-04-16 at 22:17 +0530, Pratyush Anand wrote:
> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec