答复: [External] Re: configure error and the image content seems to be incorrect
Andrew MS1 Peng
pengms1 at lenovo.com
Tue Jul 23 18:27:43 AEST 2019
发件人: Patrick Venture <venture at google.com>
发送时间: 2019年7月22日 22:34
收件人: Andrew MS1 Peng <pengms1 at lenovo.com>
抄送: openbmc at lists.ozlabs.org; Duke KH Du <dukh at lenovo.com>; Yonghui YH21 Liu <liuyh21 at lenovo.com>
主题: Re: [External] Re: configure error and the image content seems to be incorrect
On Mon, Jul 22, 2019 at 4:44 AM Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>> wrote:
发件人: Patrick Venture <venture at google.com<mailto:venture at google.com>>
发送时间: 2019年7月20日 1:06
收件人: Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>>
抄送: openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>; Duke KH Du <dukh at lenovo.com<mailto:dukh at lenovo.com>>; Yonghui YH21 Liu <liuyh21 at lenovo.com<mailto:liuyh21 at lenovo.com>>
主题: Re: [External] Re: configure error and the image content seems to be incorrect
On Fri, Jul 19, 2019 at 9:46 AM Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>> wrote:
发件人: Patrick Venture <venture at google.com<mailto:venture at google.com>>
发送时间: 2019年7月20日 0:08
收件人: Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>>
抄送: openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>; Duke KH Du <dukh at lenovo.com<mailto:dukh at lenovo.com>>; Yonghui YH21 Liu <liuyh21 at lenovo.com<mailto:liuyh21 at lenovo.com>>
主题: Re: [External] Re: configure error and the image content seems to be incorrect
On Fri, Jul 19, 2019 at 8:58 AM Patrick Venture <venture at google.com<mailto:venture at google.com>> wrote:
On Fri, Jul 19, 2019 at 8:37 AM Patrick Venture <venture at google.com<mailto:venture at google.com>> wrote:
On Fri, Jul 19, 2019 at 4:50 AM Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>> wrote:
Hi Patrick,
Please see my below comments.
Thanks.
Andrew
发件人: Patrick Venture <venture at google.com<mailto:venture at google.com>>
发送时间: 2019年7月19日 0:52
收件人: Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>>
抄送: openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>; Duke KH Du <dukh at lenovo.com<mailto:dukh at lenovo.com>>; Yonghui YH21 Liu <liuyh21 at lenovo.com<mailto:liuyh21 at lenovo.com>>
主题: Re: [External] Re: configure error and the image content seems to be incorrect
On Thu, Jul 18, 2019 at 4:27 AM Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>> wrote:
Hi Patrick,
Could you give me a hand on below problems? Thanks.
1. I compiled the latest version of phosphor-ipmi-flash with OpenBMC SDK environment to build host tool, but encounter configuration error message as below, could you help to take a look at it?
./configure --enable-oe-sdk --host "$(uname -m)" --disable-build-bmc-blob-handler AR=x86_64-openbmc-linux-gcc-ar RANLIB=x86_64-openbmc-linux-gcc-ranlib
checking whether C++ compiler accepts -lgmock... yes
checking whether C++ compiler accepts -pthread... (cached) yes
checking for main in -lgmock... yes
checking for valgrind... no
checking whether to build with code coverage support... no
configure: Enabling OE-SDK at /home/pengms1/SDK/openbmc-sdk/2.8.0/sysroots/core2-64-openbmc-linux
configure: error: conditional "HAVE_SYSTEMD" was never defined.
Usually this means the macro was only invoked conditionally.
Have systemd is only important for the BMC code, so it's unimportant in this case.
It block Makefile generation, how can I do to avoid this error to generate Makefile?
I'll see if I need to always define it -- not sure why you're hitting this and I wasn't, but I'll take a look.
Verified I can reproduce:
checking that generated files are newer than configure... done
configure: error: conditional "HAVE_SYSTEMD" was never defined.
Usually this means the macro was only invoked conditionally.
root at 3b8289721be4:/phosphor-ipmi-flash#
The issue is that although it doesn't use the bmc/Makefile in the configuration, it still needs the variable defined. I moved the systemd search into only the bmc case because the host tool doesn't use systemd.
Follow-on, I'm submitting a patch to fix that momentarily.
To address the other issue, it may behoove us to add some always-on debug logging, so we can see a few things. One approach however, would be to try sending down a 64 byte file instead of the 32MB -- just to make the testing slightly faster.
The other thing is the kernel you're using, I don't use the same one -- perhaps there are differences from openbmc/linux.
We are using the openbmc/kernel. In development phase, we use our DT file from our lenovo meta-layer since it is easy to develop and test. We have been done upstream DT file to mainline kernel and openbmc kernel as below link.
https://github.com/openbmc/linux/blob/dev-5.2/arch/arm/boot/dts/aspeed-bmc-lenovo-hr630.dts
Can you remove the flash property from the lpc_ctrl node and try again? I don't think it's an issue, but it's something different.
• DTS modification is below. (Remove memory-region and flash, transfer data failed )
@@ -40,11 +40,6 @@
#size-cells = <1>;
ranges;
- flash_memory: region at 98000000 {
- no-map;
- reg = <0x98000000 0x00100000>; /* 1M */
- };
-
gfx_memory: framebuffer {
size = <0x01000000>;
alignment = <0x01000000>;
@@ -88,8 +83,6 @@
&lpc_ctrl {
status = "okay";
- memory-region = <&flash_memory>;
- flash = <&spi1>;
};
### journalctl log message:
Jul 19 01:50:27 hr630 ipmid[360]: requesting Aspeed LPC window at 0x40000000 of size 65536
Jul 19 01:50:27 hr630 ipmid[360]: Failed to ioctl Aspeed LPC map with error No such device or address
Jul 19 01:50:27 hr630 ipmid[360]: mappingResult.response 22
Jul 19 01:50:27 hr630 ipmid[360]: requesting Aspeed LPC window at 0x40000000 of size 65536
Jul 19 01:50:27 hr630 ipmid[360]: Failed to ioctl Aspeed LPC map with error No such device or address
Jul 19 01:50:27 hr630 ipmid[360]: mappingResult.response 22
I would not expect it to work without the memory-region.
• DTS modification is below. DTS modification is below. (Remove flash, transfer data successful but the data was incorrect)
@@ -89,7 +89,11 @@
&lpc_ctrl {
status = "okay";
memory-region = <&flash_memory>;
- flash = <&spi1>;
### journalctl log message:
Jul 17 09:45:27 hr630 systemd[1]: Reached target Phosphor-ipmi-flash Prepare BMC to receive update.
Jul 17 09:45:27 hr630 ipmid[289]: requesting Aspeed LPC window at 0x40000000 of size 65536
Ok, so that's interesting.
Did you try only sending a tiny data piece, such as a 64 bytes of random data from the host, and then seeing if that arrives safely. I don't imagine it does, but I wanted to simplify what you're testing.
I have sent a 64 bytes of random data from the host, the detailed info was below.
### host image size (64 Bytes)
pengms1 at hsbmc:~$ ls -l test.bin
-rw-r--r-- 1 pengms1 pengms1 64 7月 23 2019 test.bin
### host image content
pengms1 at hsbmc:~$ hexdump ./test.bin
0000000 3b9a 4062 5888 e95c f874 ecab dac8 890d
0000010 5983 b03e 3add 7d14 4a5f 4bfa 7098 0b04
0000020 3ae7 11ec 42ee e857 eb5e 839a e8d2 c9e3
0000030 4b20 0e61 b824 a0fd 16fd 737b 82ce 0f06
### host memory content
root at hr630:/# devmem2 0x40000000
0x40623b9a
root at hr630:/# devmem2 0x40000004
0xe95c5888
root at hr630:/# devmem2 0x40000008
0xecabf874
root at hr630:/# devmem2 0x4000000C
0x890ddac8
### BMC image content
root at hr630:/run/initramfs# hexdump ./bmc-image
0000000 abc4 ef4e 11f2 b928 2538 fd9c 9f7a 2e00
0000010 78c4 af6e 01f2 a92a 3438 759c 9e76 2e00
0000020 f397 05f0 84e4 64c6 0ac6 b6d0 ef19 cb80
0000030 e9d3 82f0 c4e4 77dc 1bc6 a295 7319 4984
### BMC memory content
root at hr630:/# devmem 0x98000000
0xEF4EABC4
root at hr630:/# devmem 0x98000004
0xB92811F2
root at hr630:/# devmem 0x98000008
0xFD9C2538
root at hr630:/# devmem 0x9800000c
0x2E009F7A
### journalctl log message:
Jul 19 02:00:27 hr630 systemd[1]: Reached target Phosphor-ipmi-flash Prepare BMC to receive update.
Jul 19 02:00:27 hr630 ipmid[338]: requesting Aspeed LPC window at 0x40000000 of size 65536
Jul 19 02:00:27 hr630 ipmid[338]: requesting Aspeed LPC window at 0x40000000 of size 65536
Jul 19 02:00:27 hr630 systemd[1]: Reached target Phosphor-ipmi-flash verify the image contents.
2. According to your suggestion, our BIOS engineer help to reserve host memory addr 0x40000000 with size 256KB and initiate this region with value 0xaa. I can see the value Oxaaaaaaaa from memory addr 0x40000000 via devmem2 tool. The memory region was overwritten during executable burn_my_bmc running, I compared the content between BMC and host image but it was Inconsistent. Could you give me some advice to solve it?
BMC configuration setting:
EXTRA_OECONF += " --enable-reboot-update --enable-static-layout --enable-aspeed-lpc MAPPED_ADDRESS=0x40000000 --enable-reboot-update"
Host tool setting:
./burn_my_bmc --command update --interface ipmilpc --image ./630.mtd --sig ./sig.txt --type static --address 0x40000000 --length 65536
Interesting, so you're seeing the memory getting changed, but the bmc image doesn't match.
Can you point me to your device tree? (for sanity checking)
DT file is below:
https://github.com/LenovoHS/openbmc/blob/master/meta-lenovo/meta-hr630/recipes-kernel/linux/linux-aspeed/aspeed-bmc-lenovo-hr630.dts
What's the SHA for your linux tree (I want to make sure it has the optional feature for aspeed-lpc-ctrl)
I don’t know where can obtain the SHA value of linux tree, could you give me clues or guidance?
You're pointing to a different linux tree for your device-tree, presumably you're not using openbmc/linux?
Do you see any output from journalctl? I asked last time, but this if leads with ipmid can hold some details.
• Only host reserve memory addr 0x40000000 with 256KB, transfer data failed.
## DTS setting:
&lpc_ctrl {
status = "okay";
};
## journalctl log message:
Jul 19 02:06:02 hr630 ipmid[347]: Failed to ioctl Aspeed LPC map with error No such device or address
Jul 19 02:06:02 hr630 ipmid[347]: mappingResult.response 22
Jul 19 02:06:02 hr630 ipmid[347]: requesting Aspeed LPC window at 0x40000000 of size 65536
Jul 19 02:06:02 hr630 ipmid[347]: Failed to ioctl Aspeed LPC map with error No such device or address
Jul 19 02:06:02 hr630 ipmid[347]: mappingResult.response 22
## BMC Registers (It is the same as default value):
(HICR7) devmem 0x1E789088
0x3000FFF8
(HICR8) devmem 0x1E78908c
0xFFF8F007
(HICR5) devmem 0x1E789080
0x00000403
• BMC reserve memory addr 0x98000000 with 1MB and host reserve memory addr 0x40000000 with 256KB, transfer data successful but the data was incorrect.
## DTS setting:
flash_memory: region at 98000000 {
no-map;
reg = <0x98000000 0x00100000>; /* 1M */
};
&lpc_ctrl {
status = "okay";
memory-region = <&flash_memory>;
flash = <&spi1>;
};
## journalctl log message:
Jul 19 02:05:26 hr630 systemd[1]: Reached target Phosphor-ipmi-flash Prepare BMC to receive update.
Jul 19 02:05:26 hr630 ipmid[339]: requesting Aspeed LPC window at 0x40000000 of size 65536
Jul 19 02:05:52 hr630 ipmid[339]: requesting Aspeed LPC window at 0x40000000 of size 65536
Jul 19 02:05:52 hr630 systemd[1]: Reached target Phosphor-ipmi-flash verify the image contents.
Good that you're no longer seeing a problem with this. I wonder if there's something different with the lpc_ctrl in this case since you're specifying the flash node (a version of the driver+config i haven't tested).
## BMC Registers:
(HICR7) devmem 0x1E789088
0x98004000
(HICR8) devmem 0x1E78908c
0xFFFF0000
(HICR5) devmem 0x1E789080
0x00000503
I tested this with a 4K region on aspeed-lpc with the ast2500 and it worked fine, so I do expect it to work... but you may have found some edge case -- you're saying the length for the region should be 64KB, and that should be fine...
Regards,
Andrew
发件人: Patrick Venture <venture at google.com<mailto:venture at google.com>>
发送时间: 2019年7月16日 23:38
收件人: Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>>
抄送: openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>; Duke KH Du <dukh at lenovo.com<mailto:dukh at lenovo.com>>
主题: [External] Re: configure error and the image content seems to be incorrect
On Tue, Jul 16, 2019 at 5:31 AM Andrew MS1 Peng <pengms1 at lenovo.com<mailto:pengms1 at lenovo.com>> wrote:
Hi Patrick,
1. I downloaded the latest version of phosphor-ipmi-flash to build host tool with the SDK environment you provide, but encounter configure error as below, could you help to take a look at it?
Source code hash id
Compile Status
Error message
b90cacdd0c1ab8ea7576d4ca9f20aa5828a84e42
configure successful
fd182168d9d1c852b1047b9eccea56812b614586
1999eef0e6ad3ab4ad6fcf58cce47f352ca5e137
fa06a5f0056e91bfada390c4007fbd3472d75a56
7c2a00e02f1f0169b3e80ef1715002cefc6fa0d0
c9792e75361c86da7f674976eacd03c761021d2f
configure failed
checking whether C++ compiler accepts -lgtest... yes
checking whether C++ compiler accepts -pthread... (cached) yes
checking for main in -lgtest... yes
checking whether C++ compiler accepts -lgmock... yes
checking whether C++ compiler accepts -pthread... (cached) yes
checking for main in -lgmock... yes
checking for valgrind... no
checking whether to build with code coverage support... no
configure: Enabling OE-SDK at /home/pengms1/SDK/openbmc-sdk/2.8.0/sysroots/core2-64-openbmc-linux
configure: error: conditional "HAVE_SYSTEMD" was never defined.
Usually this means the macro was only invoked conditionally.
2. The host tool compiled with phosphor-ipmi-flash hash id b90cacdd0c1ab8ea7576d4ca9f20aa5828a84e42 and BMC flash library compiled with phosphor-ipmi-flash hash id c9792e75361c86da7f674976eacd03c761021d2f, the BMC image can transfer from host side to BMC side via LPC bridge. The image size is correct, but the image content seems to be incorrect as below, could you give us some clues to solve it if this is an issue?
Image of host side
Image of BMC side
pengms1 at hsbmc:/flash_tool$ hexdump -n 64 ./630.mtd
0000000 00be ea00 f014 e59f f014 e59f f014 e59f
0000010 f014 e59f f014 e59f f014 e59f f014 e59f
0000020 0060 0000 00c0 0000 0120 0000 0180 0000
0000030 01e0 0000 0240 0000 02a0 0000 beef dead
root at hr630:~# hexdump -n 64 /run/initramfs/bmc-image
0000000 abc4 ef4e 11f2 b128 2538 fd9c 9f7a 2e00
0000010 78c4 af6e 01f2 a92a 7438 759c 8e76 2e00
0000020 f397 05f0 84e4 6546 0ac6 b6d0 ef19 cb80
0000030 e9d7 82f0 c4e4 75dc 1bc6 a295 7319 49c4
DTS setting:
flash_memory: region at 98000000 {
no-map;
reg = <0x98000000 0x00100000>; /* 1M */
};
BMC configuration setting:
EXTRA_OECONF += " --enable-reboot-update --enable-static-layout --enable-aspeed-lpc MAPPED_ADDRESS=0x98000000 --enable-reboot-update"
Host tool setting:
./burn_my_bmc --command update --interface ipmilpc --image ./630.mtd --sig ./sig.txt --type static --address 2550136832 --length 65536
The address provided for the host:
>>> '0x%x' % 2550136832
'0x98000000'
Is a region of memory on the host that's set aside for this purpose and is mapped via /dev/mem. It's not the address the BMC Is using. You'll need to use a region reserved for this purpose in the host kernel or bios.
Thanks,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190723/9b76e8a3/attachment-0001.htm>
More information about the openbmc
mailing list