Beside CentOS 6.X , any other oS supported, how about Fedora, Ubuntu ?? #3

jwang3089 · 2015-03-25T17:43:59Z

Hi,

Any other OS is supported for this BMC, like Fedora or Ubuntu and the versions??

Regards

linlynn · 2015-03-27T01:02:24Z

if you are talking about build enviornment for openBMC , I think yes ,it support ubuntu/fedora,if you need more details ,here is link https://www.yoctoproject.org/documentation

tfangit · 2015-04-14T18:00:00Z

@jwang3089 Yes. Ubuntu/fedora are supported. There is an issue (#2) reported on using some version of make. @linlynn provided the patch for that.

Summary: Summary - Decode SPI flash JEDEC ID to get SPI flash vendor name. - Support to decode SPI vendors: Winbond, Micron, Macronix. If unsupported JEDEC ID, returns "Unknown". Test Plan - It works on Bryce Canyon DVT type 5 system and check the behavior by curl command. --- 1. Winbond and Macronix: root@bmc:/tmp# cat spi0.0_vendor.dat EF4019 000000root@bmc:/tmp# root@bmc:/tmp# cat spi0.1_vendor.dat C22019 000000root@bmc:/tmp# { "Actions": [ "reboot" ], "Information": { "CPU Usage": "CPU: 23% usr 61% sys 0% nic 15% idle 0% io 0% irq 0% sirq", "Description": "FBTTN BMC", "MAC Addr": "24:8A:07:8D:6C:70", "Memory Usage": "Mem: 108148K used, 327636K free, 936K shrd, 0K buff, 58380K cached", "OpenBMC Version": "1.6", "Reset Reason": "User Initiated Reset or WDT Reset", "SPI0 Vendor": "Winbond", "SPI1 Vendor": "Macronix", "TPM FW version": "133.32", "TPM TCG version": "1.2", "Uptime": " 06:12:10 up 6 min, load average: 3.88, 1.62, 0.62\n", "kernel version": "4.1.15 #3 Tue Nov 7 14:46:04 CST 2017", "u-boot version": "U-Boot SPL 2016.07 fbttn-b14f557 (Nov 07 2017 - 11:08:27)\nU-Boot 2016.07 f }, "Resources": [] } 2. Micron and 'Unknown': root@bmc:/tmp# cat spi0.0_vendor.dat 20BB19 000000root@bmc:/tmp# root@bmc:/tmp# cat spi0.1_vendor.dat C42019 000000root@bmc:/tmp# { "Actions": [ "reboot" ], "Information": { "CPU Usage": "CPU: 0% usr 23% sys 0% nic 76% idle 0% io 0% irq 0% sirq", "Description": "FBTTN BMC", "MAC Addr": "24:8A:07:8D:6C:70", "Memory Usage": "Mem: 108040K used, 327744K free, 940K shrd, 0K buff, 58384K cached", "OpenBMC Version": "1.6", "Reset Reason": "User Initiated Reset or WDT Reset", "SPI0 Vendor": "Micron", "SPI1 Vendor": "Unknown", "TPM FW version": "133.32", "TPM TCG version": "1.2", "Uptime": " 06:24:51 up 19 min, load average: 3.61, 3.43, 2.24\n", "kernel version": "4.1.15 #3 Tue Nov 7 14:46:04 CST 2017", "u-boot version": "U-Boot SPL 2016.07 fbttn-b14f557 (Nov 07 2017 - 11:08:27)\nU-Boot 2016.07 f }, "Resources": [] } Reviewed By: amithash fbshipit-source-id: e118bc0

Summary: Summary - Add retry 3 times for GPIO assert and de-assert to make sure the GPIO status is correct. - Now in gpiod, assert and de-assert event is Mono Lake missing, SCC missing, and NIC is plugged out. Test Plan - It works on Bryce Canyon DVT type 5 system. - Follow the step to test and the test results are match with expectation. 1. In case the SCC is connected, the server will continue power-on as usual. 2. In case the SCC is not inserted when AC on, BMC log ASSERT SCC missing and the server will continue power-on as usual. 3. In case the SCC is hotplugged out (surprise removal), BMC log ASSERT SCC absence and turn off ML-12V. 4. In case the SCC is hotplugged in (surprise install), BMC log DEASSERT SCC absence and turn on ML-12V and then turn on ML-DC depending on on/off/lps power policy. 5. In case the Server is hotplugged out (surprise removal), BMC log ASSERT ML absence and turn off ML-12V and IOM-3V3. 6. In case the Server is hotplugged in (surprise install), BMC log DEASSERT ML absence and turn on ML-12V. 7. In case the Server is not inserted when AC on, BMC log ASSERT Server missing and turn off ML-12V and IOM-3V3. 8. In case the NIC is not inserted when AC on, BMC log ASSERT NIC is plugged out. Test Log - case #2: root@bmc:~# cat /var/log/messages | grep gpiod 2017-11-03T12:08:53.240000-07:00 bmc gpiod: ASSERT: SCC missing root@bmc:~# power-util server status Power status for fru 1 : ON - case #3: root@bmc:/tmp# cat /var/log/messages | grep gpiod bmc gpiod: ASSERT: SCC missing bmc gpiod: Powering Off Server due to SCC is absent. root@bmc:/tmp# power-util server status Power status for fru 1 : OFF (12V-OFF) - case #4: root@bmc:/tmp# cat /var/log/messages | grep gpiod bmc gpiod: DEASSERT: SCC missing bmc gpiod: Due to SCC were pushed in. Power On Server board 12V power and Power On Server by Power Restore Policy. bmc gpiod: FRU: 1, Server is powered on root@bmc:/tmp# power-util server status Power status for fru 1 : ON - case #5: root@bmc:/tmp# cat /var/log/messages | grep gpiod bmc gpiod: ASSERT: Mono Lake missing bmc gpiod: Powering Off Server due to server is absent. * Check ML-12V (active: high): root@bmc:/tmp# cat /sys/class/gpio/gpio119/value 0 * Check IOM-3V3 (active: high): root@bmc:/tmp# cat /sys/class/gpio/gpio215/value0 0 - case #6: root@bmc:/tmp# cat /var/log/messages | grep gpiod bmc gpiod: DEASSERT: Mono Lake missing bmc gpiod: Due to Server board were pushed in. Power On Server board 12V power. bmc gpiod: FRU: 1, Server is powered off root@bmc:/tmp# power-util server status Power status for fru 1 : OFF * Check ML-12V (active: high): root@bmc:/tmp# cat /sys/class/gpio/gpio119/value 1 * Check IOM-3V3 (active: high): root@bmc:/tmp# cat /sys/class/gpio/gpio215/value 0 - case #7: root@bmc:/tmp# cat /var/log/messages | grep gpiod bmc gpiod: ASSERT: Mono Lake missing * Check ML-12V (active: high): root@bmc:/tmp# cat /sys/class/gpio/gpio119/value 0 * Check IOM-3V3 (active: high): root@bmc:/tmp# cat /sys/class/gpio/gpio215/value 0 - case #8: root@bmc:/tmp# cat /var/log/messages | grep gpiod 2017-11-03T12:33:39.620000-07:00 bmc gpiod: ASSERT: NIC is plugged out Reviewed By: jmehta fbshipit-source-id: ec9f042

Summary: Summary - Move bios-util version from v0.1 to v0.2. - Add and modularize these features for project-specific: plat_info, pcie_config, pcie_port_config. - Select with bios-util supports feature by bios_board.py. Test Plan - It works on Bryce Canyon DVT type 5 system. --- 1. boot_order: (1) clear_CMOS: root@bmc:/tmp# bios-util server boot_order --clear_CMOS --get Clear CMOS Function: Disabled root@bmc:/tmp# bios-util server boot_order --clear_CMOS --enable root@bmc:/tmp# bios-util server boot_order --clear_CMOS --get Clear CMOS Function: Enabled root@bmc:/tmp# bios-util server boot_order --clear_CMOS --disable root@bmc:/tmp# bios-util server boot_order --clear_CMOS --get Clear CMOS Function: Disabled (2) force_boot_BIOS_setup: root@bmc:/tmp# bios-util server boot_order --force_boot_BIOS_setup --get Force Boot to BIOS Setup Function: Disabled root@bmc:/tmp# bios-util server boot_order --force_boot_BIOS_setup --enable root@bmc:/tmp# bios-util server boot_order --force_boot_BIOS_setup --get Force Boot to BIOS Setup Function: Enabled root@bmc:/tmp# bios-util server boot_order --force_boot_BIOS_setup --disable root@bmc:/tmp# bios-util server boot_order --force_boot_BIOS_setup --get Force Boot to BIOS Setup Function: Disabled (3) boot_order: root@bmc:/tmp# bios-util server boot_order --boot_order --get Boot Order: USB Device, IPv6 Network, SATA HDD, SATA-CDROM, Other Removable Device root@bmc:/tmp# cfg-util slot1_boot_order 810009020304 root@bmc:/tmp# bios-util server boot_order --boot_order --set 0 1 2 3 4 root@bmc:/tmp# bios-util server boot_order --boot_order --get Boot Order: USB Device, IPv4 Network, SATA HDD, SATA-CDROM, Other Removable Device root@bmc:/tmp# cfg-util slot1_boot_order 810001020304 root@bmc:/tmp# bios-util server boot_order --boot_order --disable root@bmc:/tmp# cfg-util slot1_boot_order 010001020304 root@bmc:/tmp# bios-util server boot_order --boot_order --set 0 9 2 3 4 root@bmc:/tmp# cfg-util slot1_boot_order 810009020304 2. postcode: root@bmc:/tmp# bios-util server postcode --get 2 3 6 1D 19 A1 A3 A3 A7 A9 A7 A7 A7 A8 A9 A9 A9 AA AA AA AE AF B0 B1 B4 B2 B3 B6 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B7 B8 B9 B9 BA B7 BB BC BF 33 32 4F 9A 78 68 70 79 91 92 94 94 94 94 94 94 95 96 97 98 9D 9C B4 B4 B4 B4 B4 B4 92 A0 A2 AD D9 AD D9 AD A0 84 AA 0 3. plat_info: root@bmc:/tmp# bios-util server plat_info --get Presense: Present Non Test Board SKU: Triton-Type 5B (Right sub-system) Slot Index: 1 4. pcie_config: root@bmc:/tmp# bios-util server pcie_config --get PCIe Configuration:Triton-Type 5 5. pcie_port_config: root@bmc:/tmp# bios-util server pcie_port_config --get * PCIe Port #3 is invalid and will be ignored. SCC IOC: Unknown flash1: Unknown flash2: Unknown * PCIe Port #1 is invalid and will be ignored. NIC: Unknown root@bmc:/tmp# cfg-util server_pcie_port_config 0000 root@bmc:/tmp# bios-util server pcie_port_config --set --disable scc_ioc root@bmc:/tmp# bios-util server pcie_port_config --set --disable flash1 root@bmc:/tmp# bios-util server pcie_port_config --set --disable flash2 root@bmc:/tmp# bios-util server pcie_port_config --set --disable nic root@bmc:/tmp# bios-util server pcie_port_config --get SCC IOC: Disabled flash1: Disabled flash2: Disabled NIC: Disabled root@bmc:/tmp# cfg-util server_pcie_port_config 838f root@bmc:/tmp# bios-util server pcie_port_config --set --enable scc_ioc root@bmc:/tmp# bios-util server pcie_port_config --set --enable flash1 root@bmc:/tmp# bios-util server pcie_port_config --set --enable flash2 root@bmc:/tmp# bios-util server pcie_port_config --set --enable nic root@bmc:/tmp# bios-util server pcie_port_config --get SCC IOC: Enabled flash1: Enabled flash2: Enabled NIC: Enabled root@bmc:/tmp# cfg-util server_pcie_port_config 8080 Reviewed By: benwei13 fbshipit-source-id: 73e3e43

Summary: 1. To keep LogUtilFileFormat compatible with standard RsyslogFileFormat; appending the bmc_version_tag to %msg% section. 2. Log all the syslog message to the remote syslog server 3. Log the mTerm logs (host console history) to remote syslog server Test Plan: Query for the logs for fbttn platform: [#1 verified] since the bmc_version_tag in %msg% [#2 verified] syslog message is based on the template LogUtilFileFormat [#3 verified] verified that syslog sends mTerm logs to remote server with tag 'oob_console' as 'local0.debug' Reviewed By: jmehta fbshipit-source-id: 580e7b0

Summary: Update the sequence of "setup-dhc6.sh" from 2 to 3 (runlevel 5) so fixup scripts (such as "eth0_mac_fixup.sh") can be placed at sequence 2 for yamp, which needs to be executed after "networking start" (sequence #1) but before "setup-dhc6.sh" (sequence #3). Test Plan: 1) "bitbake yamp-image" succeeded. 2) rebooted yamp-4.18 for 3 times and verified ipv6 link-local address is always derived from the correct MAC. 3) tested the patch on cmm: no issue found. Reviewed By: mikechoifb fbshipit-source-id: 0d05e26196

Summary: It was reported on Northdome that certain invocations of `fruid-util` could result in an error such as: ``` malloc(): invalid size(unsorted) ``` Looking at the glibc source code this appears to be a buffer-overrun resulting in corruption of the buddy information in the heap allocation. I visually inspected the code and found two instances where strings were not properly NUL-terminated. I then hacked at the executable to get it to compile on an x86-64 system so I could run the tool against an EEPROM capture that was reported to cause the problem. I enabled GCC's ASAN and it identified the following problem: ``` $ gcc recipes-lib/fruid/files/fruid.c recipes-core/fruid/files/fruid-util.c \ -Irecipes-lib/fruid/files -Irecipes-lib/ipmi/files \ -Irecipes-lib/obmc-pal/files -ljansson -O1 -g -fsanitize=address $ ./a.out slot1 --modify --CCD1 9KF8120U10147 5.bin ================================================================= ==166643==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000003cf at pc 0x55c4c24403db bp 0x7ffc2cb11cf0 sp 0x7ffc2cb11ce0 READ of size 1 at 0x6020000003cf thread T0 #0 0x55c4c24403da in rtrim recipes-core/fruid/files/fruid-util.c:70 #1 0x55c4c2440e7d in fruid_trim recipes-core/fruid/files/fruid-util.c:87 #2 0x55c4c2440e7d in get_fruid_info recipes-core/fruid/files/fruid-util.c:511 #3 0x55c4c2444ad7 in do_action recipes-core/fruid/files/fruid-util.c:1148 #4 0x55c4c2444fe3 in main recipes-core/fruid/files/fruid-util.c:1273 #5 0x7fd8bd86b7fc in __libc_start_main (/lib64/libc.so.6+0x237fc) #6 0x55c4c2436459 in _start (/home/apwillia/local/sync/fbopenbmc/common/a.out+0x7459) 0x6020000003cf is located 1 bytes to the left of 2-byte region [0x6020000003d0,0x6020000003d2) allocated by thread T0 here: #0 0x7fd8bdacd777 in __interceptor_malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libasan.so.6+0xb6777) #1 0x55c4c2436b4f in _fruid_area_field_read recipes-lib/fruid/files/fruid.c:192 AddressSanitizer: heap-buffer-overflow recipes-core/fruid/files/fruid-util.c:70 in rtrim ``` Through some additional debug I determined that the `chassis.custom2` field in this EEPROM was initialized with 0's. This causes `_fruid_area_field_read` to interpret the data as {TYPE_BINARY, len 0} for which it allocates a 1-byte NUL-terminated string. Later on the `rtrim` function does not correctly handle strings where `strlen` is 0 without causing corruption past the end of the string. Added a case to skip `rtrim` when the string is 0-bytes long. After this was resolved, ASAN identified another problem: ``` $ ./a.out slot1 --modify --CCD1 9KF8120U10147 5.bin ================================================================= ==170880==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000000110 at pc 0x7fa7c0d8481b bp 0x7fffe02a33c0 sp 0x7fffe02a2b68 WRITE of size 14 at 0x611000000110 thread T0 #0 0x7fa7c0d8481a in __interceptor_memcpy (/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libasan.so.6+0x3a81a) #1 0x55dd7892aced in memcpy /usr/include/bits/string_fortified.h:29 #2 0x55dd7892aced in fruid_modify recipes-lib/fruid/files/fruid.c:1852 #3 0x55dd7892fb2c in do_action recipes-core/fruid/files/fruid-util.c:1148 #4 0x55dd78930062 in main recipes-core/fruid/files/fruid-util.c:1278 #5 0x7fa7c0b9e7fc in __libc_start_main (/lib64/libc.so.6+0x237fc) #6 0x55dd78921459 in _start (/home/apwillia/local/sync/fbopenbmc/common/a.out+0x7459) 0x611000000110 is located 0 bytes to the right of 208-byte region [0x611000000040,0x611000000110) allocated by thread T0 here: #0 0x7fa7c0e00777 in __interceptor_malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libasan.so.6+0xb6777) #1 0x55dd78927e9d in fruid_modify recipes-lib/fruid/files/fruid.c:1618 ``` The source of this issue is found when adding a new optional field, such as `CCD1`, it can cause an entirely new section (ex. `chassis`) to be added with all of its optional fields becoming 1-byte type/len entries. In order to prevent a buffer overrun when creating the modified EEPROM image, we need to account for these additional optional fields. Over-estimate this size by adding an allocation for all optional fields in the entire image. Test Plan: Fix issues and confirm ASAN no longer reports problems. Reviewed By: amithash fbshipit-source-id: 6729ce2a43

Summary: The current write method goes in 4 steps. 1. disableRead 2. write request 3. wait for LSR assert. 4. enableRead 5. Read response Normally, a response would arrive after #4 thus, marking the transaction as successful. But occationally (1/10 times) the response arrives before #4 thus causing the device to completely miss the response -- resulting in a timeout. This change, replaces this with 1. Keeping read enabled throughout. 2. ignore LSR changes (Do not do #3). This change completely eliminates timeouts on wedge400+ with an FTDI USB device which do not need this sequencing. But we would still need this functionality for wedge100 where we use the native aspeed device (Pending a verification on wedge100. If it is not needed even on that platform, that functionality can be completely stripped.) Test Plan: On one SSH session, run `modbuscmd -t 300 -x 7 b50300000001` a thousand times and on a parallel SSH session run `modbuscmd -t 300 -x 7 b60300000001` a thousand times. Each iteration ensure we get the correct response and after the stress test ensure that the number of timeouts are moderate (<10). Reviewed By: garnermic fbshipit-source-id: 7846f2875cd32f402c766f5e2599bf4171ba41b3

tfangit closed this as completed Apr 14, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Beside CentOS 6.X , any other oS supported, how about Fedora, Ubuntu ?? #3

Beside CentOS 6.X , any other oS supported, how about Fedora, Ubuntu ?? #3

jwang3089 commented Mar 25, 2015

linlynn commented Mar 27, 2015

tfangit commented Apr 14, 2015

Beside CentOS 6.X , any other oS supported, how about Fedora, Ubuntu ?? #3

Beside CentOS 6.X , any other oS supported, how about Fedora, Ubuntu ?? #3

Comments

jwang3089 commented Mar 25, 2015

linlynn commented Mar 27, 2015

tfangit commented Apr 14, 2015