My kexec test patches for OpenBMC

[Bruce Mitchell]

-----Bruce Mitchell/US/IBM wrote: -----

>To: Joel Stanley <joel at jms.id.au>
>From: Bruce Mitchell/US/IBM
>Date: 03/05/2021 14:27
>Cc: Andrew Jeffery <andrew at aj.id.au>, OpenBMC Maillist
><openbmc at lists.ozlabs.org>
>Subject: Re: [EXTERNAL] Re: My kexec test patches for OpenBMC
>
>
>-----"openbmc"
><openbmc-bounces+bruce.mitchell=ibm.com at lists.ozlabs.org> wrote:
>-----
>
>>To: Bruce Mitchell <Bruce.Mitchell at ibm.com>
>>From: Joel Stanley
>>Sent by: "openbmc"
>>Date: 02/24/2021 00:04
>>Cc: Andrew Jeffery <andrew at aj.id.au>, OpenBMC Maillist
>><openbmc at lists.ozlabs.org>
>>Subject: [EXTERNAL] Re: My kexec test patches for OpenBMC
>>
>>On Fri, 19 Feb 2021 at 00:53, Bruce Mitchell
>><Bruce.Mitchell at ibm.com> wrote:
>>>
>>> Hello Joel,
>>>
>>> Per your request yesterday, I am emailing the details of my
>>kexec/kdump development efforts.
>>
>>Thanks. Here's what I tested:
>>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_s
>h
>>enki_linux_commits_ast2600-2Dkexec&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1
>Z
>>Og&r=XYNAOU-BEndJr70kO1xkYnetCkaomJrlYQm5DudYzNc&m=oX_dPGCu4X3pBZ
>l
>>Dw0XYgu4z-3G1JebwP-IvlNbEMDE&s=gT3O534rB4ZDIPbf6Z78bKCR_op-JR1uYc
>v
>>bd3z18RA&e=
>>
>
>Your kernel changes are similar to what I had done. Since you know
>the community better than I do, I propose submitting your changes.
>I can do the labor, but want you to get the credit. How would you
>like me to proceed?
>
>>>
>>> I am running QEMU
>>>
>>> qemu-system-arm --version
>>> QEMU emulator version 5.2.0 (v5.1.0-3479-g27ca38d3db)
>>
>>That looks fine. I'm using cedric's tree, but anything that will
>>boot
>>your kernel is fine.
>>
>>> qemu-system-arm -d cpu_reset -M tacoma-bmc -kernel
>>/tmp/tmp.y2fpdAXM1h.kernel -dtb /tmp/tmp.BWkadwNbTf.dtb -initrd
>>/tmp/tmp.jRpFbzfpBs.initrd -drive
>>file=obmc-phosphor-image-witherspoon-tacoma.wic,if=sd,format=raw,
>i
>>ndex=2 -net nic -net
>>user,hostfwd=:127.0.0.1:2222-:22,hostfwd=:127.0.0.1:2443-:443,hos
>t
>>name=qemu -nographic -append "crashkernel=64M
>>console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a"
>>
>>You could simplify your qemu setup if you want. Here's how I
>>tested:
>>
>> $ qemu-system-arm -M tacoma-bmc -nographic -net nic -nic
>>user,hostfwd=::2222-:22,tftp=/srv/tftp/ -kernel
>>aspeed-g5-dev/arch/arm/boot/zImage -dtb
>>aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb -initrd
>>~/dev/kernels/misc/rootfs.cpio.xz
>>
>>This uses a small initramfs with the kexec utility, and has a
>copy
>>of
>>the kernel, initrd and dtb inside to make testing easy.
>>
>>Or, if you want, you can copy files into the system over the ssh
>>port:
>>
>>I have this in my ~/.ssh/config:
>>
>>Host qemu
>> Hostname localhost
>> Port 2222
>> User root
>> UserKnownHostsFile /dev/null
>> StrictHostKeyChecking no
>>
>>And then you can use scp like this:
>>
>>scp aspeed-g5-dev/arch/arm/boot/zImage
>>aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb
>>/home/joel/dev/kernels/misc/rootfs.cpio.xz qemu:
>>
>>> From OpenBMC within QEMU I am using the following to test kexec
>>>
>>> kexec -d -l /home/kexec_files/tmp.y2fpdAXM1h.kernel
>>--initrd=/home/kexec_files/tmp.jRpFbzfpBs.initrd
>>--dtb=/home/kexec_files/tmp.BWkadwNbTf.dtb --append="earlycon
>>console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a 1 maxcpus=1
>>reset_devices"
>>> kexec -d -e
>>
>>Here's how I was running it:
>>
>># kexec -l zImage --dtb aspeed-bmc-opp-tacoma.dtb --initrd
>>rootfs.cpio.xz
>># kexec -e
>>
>>I haven't set a new command line, so it uses the command line
>from
>>the
>>device tree (console=ttyS4,115200n8).
>>
>>With my patch we will not get the secondary CPU:
>>
>>[ 0.039517] ASPEED AST2600 rev A1 (05010303)
>>[ 0.042030] smp: Bringing up secondary CPUs .
>>[ 1.163950] CPU1: failed to come online
>>[ 1.167999] smp: Brought up 1 node, 1 CPU
>>[ 1.168164] SMP: Total of 1 processors activated (2250.00
>>BogoMIPS).
>>
>>That should be the next step in working on the kexec patches. We
>>want
>>the secondary CPU to be in a state such that the new kernel can
>>take
>>control as it would in a firmware boot.
>>
>>Note that this didn't require any changes to the system beyond
>the
>>kernel patch. I'm using the same defconfig as we have in the
>tree.
>>
>>Cheers,
>>
>>Joel
>>
>>
>
>Hello Joel,
>
>Thanks again for your advice and sharing your wisdom.
>I am being urged by our manager to get this up-streamed
>sooner rather than later. How can I best work with the
>system to make this happen?
>
>Thank you!
>
>--
>Bruce
>
>

Hi Joel and Andrew,

I cannot find any response to this thread in my inbox,
however I may still have missed it.

"Joel's kernel changes are similar to what I had done. Since you know
the community better than I do, I propose submitting your changes.
I can do the labor, but want you to get the credit. How would you
like me to proceed?"

Also openbmc/meta-aspeed/MAINTAINERS and the
Linux ARM/ASPEED MACHINE SUPPORT MAINTAINERS
can communicate faster with Joel than I.

I am seeking direction on how to be effective in making this
happen that works with the community.

Thank you!

--
Bruce