Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New system overlay technique #8

Closed
causten opened this issue Apr 8, 2015 · 2 comments
Closed

New system overlay technique #8

causten opened this issue Apr 8, 2015 · 2 comments

Comments

@causten
Copy link

causten commented Apr 8, 2015

I noticed you have wedge specific changes in the meta-aspeed directories...
i.e. 0000-u-boot-aspeed-064.patch directs uboot to print to UART3...

define CONFIG_ASPEED_COM 0x1e784000

i.e. 0000-linux-openbmc.patch disables the LPC

If I was to create a new system that uses UART1 and needs LPC from the Aspeed (i.e. slice) I was first thinking it should be meta-openbmc/meta-company/meta-slice, but that would pick up wedge specific changes for meta-aspeed.

What is your expectation for patch management and directory layout?
@tfangit
Copy link
Contributor

tfangit commented Apr 14, 2015

Ideally, board specific changes are in meta-openbmc/meta-company/meta-board. It is achievable but adding difficulty for development and maintenance, specially, in u-boot and kernel. Both u-boot and kernel already have great mechanism to support different boards/HWs. We would like leverage such mechanism, which means, HW/boards specific changes will be in SoC layer.

u-boot has board layers, currently, we re-used the ast2400 board layer for wedge development. That won't work for different boards. We will need to create separate directory for each different boards.

In kernel, we created separate configuration for wedge, wedge_defconfig. Then, use '#ifdef CONFIG_WEDGE' for wedge specific changes. However, we want to limit usage of '#ifdef' in source code. For example, for the code to enable/disable LPC, I would prefer to having a macro like CONFIG_ASPEED_ENABLE_LPC used in the source code, then each different HW defconfig has that macro defined or not depending on board specific design.

@causten
Copy link
Author

causten commented Apr 15, 2015

Sounds good, I'll get you some changes that adhere to the concepts. Employing the _defconfig more fits with our thoughts too

@causten causten closed this as completed Apr 15, 2015
facebook-github-bot pushed a commit that referenced this issue Nov 14, 2017
@jmehta @facebook-github-bot
fbttn: retry for GPIO assert and de-assert in gpiod
a29f33c 
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
facebook-github-bot pushed a commit that referenced this issue Apr 4, 2022
@binhuang00 @facebook-github-bot
systemd-networkd settings for Churchillmono (#8)
22e8ce6 
Summary:
Systemd network daemon settings for Cisco Churchillmono.

The systemd-networkd consists of configuring the eth0 and eth0.4088 interfaces. Ping to external server and internal host works with this interface setup respectively. dhcp-client added in the packages is used for eth0 to get an address automatically. Please note, the VENDOR_SERIAL is left without any change as things worked. We can change it if you would like to replace it with another string.

X-link: facebookexternal/openbmc.cisco#8

Test Plan:
external and internal ping (Assuming Marvell switch is programmed with the right firmware)

UT:
The external pings were working as expected (IPv4 and IPv6). We have some issues configuring the XR with IPv6, so internal ipv6 test hasn't been done yet (Should work when configured correctly).
[Ping_test_BMC.txt](https://github.com/facebookexternal/openbmc.cisco/files/8352726/Ping_test_BMC.txt)

Reviewed By: joancaneus, tao-ren

fbshipit-source-id: 246fb6eb2bbd0c57ada2f363a0ca560eae815833
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tfangit @causten