Code Monkey home page Code Monkey logo

u-bmc's Introduction

u-bmc

Build Status Go Report Card License

Description

u-bmc uses u-root to create a Linux OS distribution that is fully open-source.

u-bmc borrows and contributes to OpenBMC which has similar high-level goals. The main difference is that u-bmc chooses to challenge the industry status quo, e.g. where OpenBMC uses IPMI, u-bmc uses gRPC.

Attention

This project is currently undergoing some heavy maintenance. Don't use in production yet!

Demo

asciicast

Why?

BMC software has historically been known to be insecure. There is no inherent reason for that. u-bmc sets out to improve this by offering an alternative built on modern technologies.

Support

u-bmc is still in experimental stage and is currently only supporting BMCs based on ASPEED AST2400 and AST2500. Other BMC SOCs are planned, and if you want to contribute let us know.

Currently the supported boards are:

  • Open Compute Project: Quanta F06 Leopard DDR3
  • Aspeed AST2500 Evaluation Board

Planned boards are:

  • ASRock Rack PAUL
  • Nuvoton Poleg BMC NPCM7XX Evaluation Board
  • Open Compute Project: Quanta F20 Yosemite
  • Tyan Tempest CX S7106

Do you want to become a contributor of a board? Let us know!

Roadmap

To give you some sense of what we want to create:

  • All function exported over gRPC like:
    • Serial-over-LAN
    • Sensor data
    • iKVM
    • Updating BIOS
    • POST information
  • Implementation of OpenMetrics for Prometheus integration for sensors
  • Offer SSH server for on-platform debugging
    • Support SSH CA-signed certificates to avoid having to upload a bunch of certs
  • USB device emulation
    • Must have: USB storage from image
    • Cool to have: USB ethernet to host, replaces KCS IPMI interface.
    • Cool to have: USB graphics card + mouse + keyboard for KVM
  • Optional WebUI
    • Uses the same API as the gRPC client
    • optional so the BMC can stay lean without loosing functionality

Usage

Prerequisites:

u-bmc uses the Taskfile build system, install it using their official installation guide.

Packages needed:

  • go (at least 1.17)
  • gcc-arm-none-eabi (for arm32)
  • gcc-aarch64-linux-gnu (for arm64)
  • mtd-utils (for targets using flash)
  • erofs-utils (for targets using block devices)
  • fakeroot
  • flex
  • bison
  • device-tree-compiler
  • bc
  • libssl-dev
  • libelf-dev
  • qemu-kvm

Get them for 32bit via e.g.:

sudo apt install gcc-arm-none-eabi mtd-utils golang fakeroot flex bison device-tree-compiler bc libssl-dev libelf-dev qemu-kvm

We also need both u-bmc and u-root in our GOPATH so install them with:

GO111MODULE=off go get github.com/u-root/u-root
GO111MODULE=off go get github.com/u-root/u-bmc

Or use git clone:

mkdir $GOPATH/src/github.com/u-root
cd $GOPATH/src/github.com/u-root
git clone https://github.com/u-root/u-root
git clone https://github.com/u-root/u-bmc

Setup configuration:

# SSH ECDSA public keys does not work for now

cp ~/.ssh/*.pub config/ssh_keys.pub

# Agree to the terms of the configured ACME server
# By default it's just a toy ACME server so this is fine, but if you're
# using another ACME server like Let's Encrypt (LE) ensure you agree to their terms.
# For LE, you can find them at https://letsencrypt.org/repository/.

touch i_agree_to_the_acme_terms
task config:generate

Build image:

cp TARGET.tmpl TARGET

then uncomment the desired target platform e.g. qemu-virt-a72 in TARGET and run

task build

Since u-bmc uses signed binaries it is important that you back up the contents of build/boot/keys/ after building as u-bmc will only accept updates signed with these keys.

Simulator

Trying out u-bmc is easiest using the simulator. First select a Qemu target in the TARGET file then to launch it, run:

# Build Qemu target

task build

# Launch a local ACME server in one terminal

task pebble

# Launch the u-bmc simulator in another terminal

task virtual-bmc -- 64bit

# (Optional, run in another terminal) Launch a local emulated BIOS to produce some data on the UART
# Needs to have u-bmc simulator above running for it to attach correctly.

task virtual-host

When simulating the following TCP/IP ports are set up:

  • 6053/udp: u-bmc DNS
  • 6443/tcp: u-bmc gRPC
  • 9370/tcp: u-bmc OpenMetrics

When the u-bmc guest tries to access 10.0.2.100 a local service called ubmc-pebble is started which uses Let's Encrypt's pebble service to generate an HTTPS certificate. The CA used is located in config/sim-ca.crt.

You can interact with u-bmc running in the simulator by pressing Enter to get a shell or by using ubmcctl:

go install github.com/u-root/u-bmc/cmd/ubmcctl

# The root CA is regenerated every time pebble is started to prevent
# testing to accidentally become production

curl https://localhost:14000/root --cacert config/sim-pebble.crt > root.crt
echo '127.0.1.2	ubmc.example.com' | sudo tee -a /etc/hosts
SSL_CERT_FILE=root.crt ubmcctl -host ubmc.example.com:6443

If you restart pebble you need to update root.crt.

Testing

The easiest way to run all unit tests is to run task test.

To run the integration tests: task test.

If you're using a supported platform and want to try it on your hardware you can use socflash_x64 provided by ASPEED like this:

echo This is extremely likely to break things as u-bmc is still experimental
sudo ./socflash_x64 of=bmc-backup.img if=flash.img lpcport=0x2e option=glc

Uploading a new version

If you want to quickly upload a new build of u-bmc without updating the kernel, you can use SCP like this:

scp build/rootfs/bin/bb my-ubmc:/bb
scp build/rootfs/bin/bb.sig my-ubmc:/bb.sig
ssh my-ubmc

# Verify that bb is sane by executing /bb
/bb

# Should return:
# <timestmap> You need to specify which command to invoke.
# Exception: /bin/bb exited with 1
# [tty], line 1: /bin/bb

mv /bb /bin/bb
mv /bb.sig /bin/bb.sig

# Verify the signature before rebooting

gpgv /etc/u-bmc.pub /bin/bb.sig /bin/bb
sync
shutdown -r

Contributions

See CONTRIBUTING.md

Since this is an early experiment if this is at all interesting for you or your company, do reach out in our Slack channel:

u-bmc's People

Contributors

bluecmd avatar c0d3z3r0 avatar dependabot[bot] avatar hugelgupf avatar keno avatar mdlayher avatar mdr164 avatar orangecms avatar osresearch avatar rjoleary avatar shenki avatar walterchris avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

u-bmc's Issues

Leopard: Ensure production grade

Right now the power LED is turned on straight away, but it would be nice if it can blink fast when verifying the firmware to indicate that the machine should not be booted right now, and blink slow when the machine is off but ready to be powered on.

We also want to capture and output the post code

f20 works for one boot

First boot with the f20 build:

DRAM Init-DDR3                                                                  
CBR0-1234567012345670123456701234567                                            
CBR134Done                                                                      
                                                                                
                                                                                
U-Boot 2016.07-00036-g8b3fd4183a-dirty (Sep 10 2018 - 18:25:46 +0200)           
                                                                                
DRAM:  248 MiB                                                                  
WARNING: Caches not enabled                                                     
Flash: Unsupported SPI Flash!! 0x0019609d                                       
32 MiB                                                                          
Using default environment                                                       
                                                                                
In:    serial                                                                   
Out:   serial                                                                   
Err:   serial                                                                   
Net:   aspeednic#0                                                              
Error: aspeednic#0 address not set.                                             
                                                                                
Hit any key to stop autoboot:  0                                                
ubi0: attaching mtd1                                                            
ubi0: scanning is finished                                                      
                                                                                
. done                                                                          
\       

This hangs after a few thousand spinners and done messages. Second boot produces:

DRAM Init-DDR3                                                                  
CBR0-1234567012345670123456701234567                                            
CBR134Done                                                                      
                                                                                
                                                                                
U-Boot 2016.07-00036-g8b3fd4183a-dirty (Sep 10 2018 - 18:25:46 +0200)           
                                                                                
DRAM:  248 MiB                                                                  
WARNING: Caches not enabled                                                     
Flash: Unsupported SPI Flash!! 0x0019609d                                       
32 MiB                                                                          
Using default environment                                                       
                                                                                
In:    serial                                                                   
Out:   serial                                                                   
Err:   serial                                                                   
Net:   aspeednic#0                                                              
Error: aspeednic#0 address not set.                                             
                                                                                
Hit any key to stop autoboot:  0                                                
ubi0: attaching mtd1                                                            
ubi0: scanning is finished                                                      
                                                                                
. done                                                                          
\                                                                               
(a few hundred spinners)                                           
ubi0: attached mtd1 (name "mtd=1", size 31 MiB)                                 
ubi0: PEB size: 65536 bytes (64 KiB), LEB size: 65408 bytes                     
ubi0: min./max. I/O unit sizes: 1/1, sub-page size 1                            
ubi0: VID header offset: 64 (aligned 64), data offset: 128                      
ubi0: good PEBs: 504, bad PEBs: 0, corrupted PEBs: 0                            
ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128              
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 97
1138040                                                                         
ubi0: available PEBs: 16, total reserved PEBs: 488, PEBs reserved for bad PEB ha
ndling: 0                                                                       
Loading file 'u-boot.boot.img' to addr 0x40000000...                            
Done                                                                            
## Executing script at 40000000                                                 
Loading file 'u-boot.env' to addr 0x40000000...                                 
Done                                                                            
## Info: input data size = 31706 = 0x7BDA                                       
Loading file 'f06c-leopard-ddr3.dtb' to addr 0x40000000...                      
Done                                                                            
Loading file 'zImage' to addr 0x40008000...                                     
Done                                                                            
Kernel image @ 0x40008000 [ 0x000000 - 0x24e408 ]                               
## Flattened Device Tree blob at 40000000                                       
   Booting using the fdt blob at 0x40000000                                     
   Loading Device Tree to 4f387000, end 4f38fa7b ... OK                         
                                                                                
Starting kernel ...                                                             
                                                                                
[    0.000000] Booting Linux on physical CPU 0x0                                
[    0.000000] Linux version 4.18.5-ubmc (bluecmd@bluecmd) (gcc version 6.3.1 20
170620 (15:6.3.1+svn253039-1)) #14 Fri Sep 14 11:38:36 CEST 2018

This makes it all the way to Linux and the interactive shell. Subsequent boots fail to produce any serial output at all.

Link flaps on NC-SI when the host is booting

Right now, and in other BMCs as well, the link flaps when the power state changes for the host.

There might be nothing we can do about that, but we should have a look to be sure that's the case.

Support the NPCM750 EVB

Nuvoton has graciously provided an evaluation board to port u-bmc to. It will serve as a good second SoC to target to make source the abstractions hold (or most likely will cause some refactors).

As this will likely shake the API this is a pre 1.0 thing.

DHCPv4

dhclient used to be a bit broken, but we want to run it in process anyway.

Implement DHCPv4 and set hostname accordingly.

Pad with 0xFF instead of 0x00

Since the flash chips are 0xFF in their erased state it is faster if the empty parts of the ROM are filled with all ones rather than all zeros.

gRPC reflection broken

There is a weird gRPC issue that I have not debugged much that is possibly related to vendoring. Essentially grpc_cli is no longer able to call any methods, claiming that there is no proto definition.

Sadly I did not save a long but it appears to be reproducible enough.

Will add more details as I get them

BMC firmware validation / Secure boot

Given that we're targeting specific platforms this is going to be optional and not useful for everyone.

However, it should be possible to create something that's reasonably secure by default.

The idea so far is to:

  • Ensure the BMC SPI flash has a protectable region that is volatile.
    Volatile is to prevent bricking, but the locking also needs to be persistent until power reset without any other option to unlock. For the Leopards I have access to that means replacing the SPI flashes with something like MT25QL256ABA (or even MT25QL512ABB for a nice upgrade).

  • Make u-boot verify Linux kernel, make the Linux kernel verify /init
    U-boot can already do this using signatures, and Linux can be made to do it using a initramfs.
    This would still allow for persistence for files around the /init - but not modifications of /init (bbin/bb) itself.

There are some interesting open issues that needs to be solved.

  1. Need to disable LPC super-duper access (iLPC2AHB) during this time and ASAP on power-up to reduce the timing window for attacks on that. Given that this is on power-on we should be good as the host system does not boot automatically.
  2. U-boot upgrades. How will they work?

Make fails on ssh_keys.go

~/go/src/github.com/u-root/u-bmc: make
make -C cmd/uinit ssh_keys.go
make[1]: Entering directory '/home/hudson/go/src/github.com/u-root/u-bmc/cmd/uinit'
make[1]: *** No rule to make target 'ssh_keys.go'.  Stop.
make[1]: Leaving directory '/home/hudson/go/src/github.com/u-root/u-bmc/cmd/uinit'
Makefile:78: recipe for target 'initramfs.cpio' failed
make: *** [initramfs.cpio] Error 2

There is no Makefile in cmd/uinit

DHCPv6

DHCPv6 will be nice for IPv6 only deployments.

While IPv6 can utilize RA for stateless configuration, we need to get a hostname for the TLS certificate.

Something is amiss with vendoring

This is when it's building the busybox:

cmds/uinit/grpc.go:40:36: cannot use g (type *"google.golang.org/grpc".Server) as type *"github.com/u-root/u-bmc/vendor/google.golang.org/grpc".Server in argument to bmc.RegisterManagementServiceServer
, exit status 2

Looks like a vendoring issue.

Submit Leopard kernel patches upstream

They ASPEED kernel maintainer eagerly awaits your device tree patch. Ping me on irc if you need help making a kernel submission.

If you have other patches you're using then we should either get them upstream, or in the openbmc tree if they are not yet ready.

Implement fan controller

Being able to set the fans in the console and using RPC would make the hardware much nicer to be around.

For the initial work, just setting a value between 0-100% for duty cycle should be enough. Then a PID controller can be added at a later stage.

Submit Leopard device tree upstream (dup)

They ASPEED kernel maintainer eagerly awaits your patch. Ping me on irc if you need help making a kernel submission.

If you have other patches you're using then we should either get them upstream, or in the openbmc tree if they are not yet ready.

Optional USB subsystem

Some users want USB devices and network connectivity (mainly when using stock BIOS) and some do not. Both sides of the camp have good arguments.

I'd like to support a "u-bmc +usb" type of build where the USB support is compiled in, and one where the USB controller etc. is disabled. Interestingly this has implications not only in code, but also in the .dts file.

Persistent RTC across reboots

The ast2400 has an RTC built-in that is not battery backed up, but using it to carry time across restarts would be a nice reliability addition to allow less RPC downtime on reboots.

Console streaming

Right now the console streaming is very basic.

  1. Buffered history is needed.

  2. It would be nice if multiple connections are supported and that the RPC becomes indempotemt with some form of timestamp as the identifier.

  3. The same stream would be nice to have for the console output and maybe klog for the BMC itself, instead of having the /tmp/u-bmc.log file.

RTC

There is an RTC somewhere on the server.

  1. Find what it is, and on which bus it is on
  2. Enable it in the device tree

Figure out automated regression/integration testing

I'm not sure how we want to do this.

The options I've been thinking about are:

  • Compile time redirection to use mocks.
    This is essentially unit tests, and we should do them anyway.

  • Using QEMU.
    QEMU is very limited when it comes to the ast2400 and creating a pseudo platform for it risks missing a lot of things.

  • Using gVisor.
    A lot of work and forces us to re-implement the ast2400 in gVisor.

  • Hardware
    Hardware is the best option, but it's slow to work with. Nonetheless it seems like the most promising candidate right now.

When the u-boot console issue has been solved and we can verify that NC-SI works in u-boot, then it should be possible to netboot from u-boot. That should be fast enough for on-demand testing in some fashion.

System comes up without GPIOs

This has happened twice. This particular one was after a power-cycle:

/# cat /tmp/u-bmc.log 
1970/01/01 00:00:05 Loading system configuration
1970/01/01 00:00:06 Starting debug SSH server
1970/01/01 00:00:06 Initialize system hardware
1970/01/01 00:00:06 Setting up Network Controller Sideband Interface (NC-SI) for eth0
1970/01/01 00:00:06 Starting GPIO drivers
1970/01/01 00:00:06 Starting fan system
1970/01/01 00:00:06 Configuring fan 0 for 20%
1970/01/01 00:00:06 Configuring fan 1 for 20%
1970/01/01 00:00:06 Configuring host UART console /dev/ttyS2 @ 57600 baud
1970/01/01 00:00:06 Starting gRPC interface
1970/01/01 00:00:06 Starting local shell

Reboot worked to restore functionality.

Restore MAC from NC-SI

On bootup u-bmc should read MAC address from NC-SI OEM commands and configure the interface accordingly.

Hack-mode

Right now we compile everything and require a reflash every time something changes.

Given that u-root has a compilation mode for on the fly builds, investigate if it's possible to use that to be able to modify the source on the device to shorten the development iterations.

Fix host bootup

Right now when doing power on this is the sequence that u-bmc goes through:

1970/01/01 00:10:09 CPLD_CLK                       output driving high
1970/01/01 00:10:09 CPLD_CLK                       output driving low
1970/01/01 00:10:10 CPLD_CLK                       output driving high
1970/01/01 00:10:10 CPLD_CLK                       output driving low
1970/01/01 00:10:11 CPLD_CLK                       output driving high
1970/01/01 00:10:11 CPLD_CLK                       output driving low
1970/01/01 00:10:12 BMC_PWR_BTN_OUT_N              output driving low
1970/01/01 00:10:12 CPLD_CLK                       output driving high
1970/01/01 00:10:12 SLP_S3_N                       input became high
1970/01/01 00:10:12 GPIOG3/SGPSI1                  input became high
1970/01/01 00:10:12 GPION3/PWM3/VPIG3              input became high
1970/01/01 00:10:12 CPU0_PROCHOT_N                 input became high
1970/01/01 00:10:12 CPU1_PROCHOT_N                 input became high
1970/01/01 00:10:12 GPIOB1/SALT2                   input became high
1970/01/01 00:10:12 GPIOD6/SD2CD#                  input became high
1970/01/01 00:10:12 CPU_CATERR_N                   input became high
1970/01/01 00:10:12 CPLD_CLK                       output driving low
1970/01/01 00:10:12 GPIOB4/LPCRST#                 input became high
1970/01/01 00:10:12 PCH_PWR_OK                     input became high
1970/01/01 00:10:12 SYS_PWR_OK                     input became high
1970/01/01 00:10:12 GPIOG6/FLBUSY#                 input became high
1970/01/01 00:10:12 GPIOH0/ROMD8/NCTS6             became output
1970/01/01 00:10:12 GPIOH1/ROMD9/NDCD6             became output
1970/01/01 00:10:12 GPIOH2/ROMD10/NDSR6            became output
1970/01/01 00:10:12 GPIOH3/ROMD11/NRI6             became output
1970/01/01 00:10:12 GPIOH4/ROMD12/NDTR6            became output
1970/01/01 00:10:12 GPIOH5/ROMD13/NRTS6            became output
1970/01/01 00:10:12 GPIOH6/ROMD14/TXD6             became output
1970/01/01 00:10:12 GPIOH7/ROMD15/RXD6             became output
1970/01/01 00:10:12 GPIOH0/ROMD8/NCTS6             output driving high
1970/01/01 00:10:12 GPIOH1/ROMD9/NDCD6             output driving high
1970/01/01 00:10:12 GPIOH2/ROMD10/NDSR6            output driving high
1970/01/01 00:10:12 GPIOH3/ROMD11/NRI6             output driving high
1970/01/01 00:10:12 GPIOH4/ROMD12/NDTR6            output driving high
1970/01/01 00:10:12 GPIOH5/ROMD13/NRTS6            output driving high
1970/01/01 00:10:12 GPIOH6/ROMD14/TXD6             output driving high
1970/01/01 00:10:12 GPIOH7/ROMD15/RXD6             output driving high
1970/01/01 00:10:13 GPIOH1/ROMD9/NDCD6             output driving low
1970/01/01 00:10:13 GPIOH2/ROMD10/NDSR6            output driving low
1970/01/01 00:10:13 GPIOH5/ROMD13/NRTS6            output driving low
1970/01/01 00:10:13 GPIOH6/ROMD14/TXD6             output driving low
1970/01/01 00:10:13 GPIOH7/ROMD15/RXD6             output driving low
1970/01/01 00:10:13 BMC_PWR_BTN_OUT_N              output driving high
1970/01/01 00:10:13 CPLD_CLK                       output driving high
1970/01/01 00:10:13 CPLD_CLK                       output driving low
1970/01/01 00:10:14 CPLD_CLK                       output driving high
1970/01/01 00:10:14 CPLD_CLK                       output driving low
1970/01/01 00:10:15 CPLD_CLK                       output driving high
1970/01/01 00:10:15 CPLD_CLK                       output driving low
1970/01/01 00:10:16 CPLD_CLK                       output driving high
1970/01/01 00:10:16 CPLD_CLK                       output driving low

CPLD_CLK is a local modification that pulses GPIOB0 at 1Hz, not sure if that is needed yet.

As can be seen at:

1970/01/01 00:10:12 GPIOH0/ROMD8/NCTS6             became output

the kernel responds to something, maybe the LPCRST# change, and reconfigures stuff. That's most likely not what we want, and could be an issue.

SCU states:

SCU70: 4208c512 SCU80: 00000000 SCU84: 00fff0c0 SCU88: 01000000 SCU8C: 000000ff SCU90: 003fa000 SCU94: 00000000```

In-process sshd

To control lifetime and better adoption of ssh, I think moving the sshd to an in-process routine would be beneficial.

That could potentially help adding visibility for issues like u-root/u-root#957

Split NCSI netlink functionality into own package

Hello again!

I had previously suggested that we split the NCSI netlink interaction code into its own package to enable further reuse in the Go ecosystem. I'd be happy to do the work and also write some tests (with genltest package) to lock in its behavior.

For now this could live under "u-bmc/pkg/ncsinl" or similar. I suggest the "nl" suffix because, if I understand, NCSI functionality can be manipulated with specially crafted Ethernet frames as well. I don't know how this all ties together.

Let me know if you'd like me to work on this! Thanks again.

i2cwatcher

Like gpiowatcher, i2cwatcher would snoop the BMC CPU to figure out what devices are being talked to, dump commands, replies, etc. to the extent where possible.

This would be useful in mapping undocumented motherboards.

Watchdog heartbeat and reset

Sometimes we get weird lockups in u-boot. Those should of course be fixed, but it would be really nice with a watchdog that just resets the CPU in case where it happens as well as some sort of exported counter on when that has happened.

Flaky bootup on initial boot

I've seen this live but now also in the integration tests (which is excellent).
The full bootlog looks like this:

qemu-system-arm: Aspeed iBT has no chardev backend

DRAM Init-DDR3
CBR0-1357135713571357
CBR134Done


U-Boot 2016.07-00038-gc7a5629a1c (Oct 02 2018 - 21:27:29 +0000)

DRAM:  240 MiB
WARNING: Caches not enabled
Flash: 32 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   aspeednic#0
Error: aspeednic#0 address not set.

Hit any key to stop autoboot:  0 
ubi0: attaching mtd1
ubi0: scanning is finished

. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done
|
. done

Then nothing. The CPU hangs.

The easiest thing here is probably figuring out why u-boot wants to "fix" the filesystem in the first place, that would significantly speed up the initial boot after installation as well.

BIOS flashing

Support flashing image to BIOS flash, simple as that.

Implementation is going to be a bit tricky maybe. I'd like to investigate doing BIOS flashing when the host is on, and only giving it control of the flash when it is in the BIOS, and as a soon as it is done reading it don't have it own the BIOS anymore. That will most likely break user-mode BIOS flashing/dumping however.

Still, the BMC is the one that should own the chip, and restricting the host from updating it can be a good thing as well.

OpenMetrics exporter

Link in the https://github.com/prometheus/client_golang library and export metrics.

I've allocated 9370 in https://github.com/prometheus/prometheus/wiki/Default-port-allocations.
It is also free in the IANA port assignment list it seems, if we want to get really serious about it.

Some metrics that I'm thinking that is needed:

  • BMC system load
  • BMC memory usage
  • BMC NC-SI state (low-prio)
  • BMC uptime
  • BMC network stats
  • Host power state
  • Host prochot/memhot/caterr/...
  • Debug board present
  • Mezzanine card present
  • BIOS selected
  • Fan speed
  • Fan percentage output
  • All the various sensors (pending sensor work)
  • SKU ID (Read from GPIO)
  • FRU IDs (I2C?)
  • BIOS version (maybe? Is going to be messy)
  • POST code

A lot of things in the list is doable straight away.

Fix reset state on Leopard

After a power cycle the UART does not come back up.
Network works though, so debugging it should be straight forward.

Investigate what registers need to be twiddled to make that work.

HTTPS for gRPC

Currently it's all plaintext over port 80.

This should be switch to 443 and using HTTPS.

Generating a self-signed certificate + key and storing it in /etc/ is a good first step. Dealing with CA and certificate SANs and such is going to be annoying, so let's not do that right now.

PressButton should block

Right now it returns as soon as the button has started to be pressed. It seems less surprising if it blocks for the duration of the press.

Readability feedback

As discussed in person, here are a bunch of thoughts regarding readability improvements from a quick glance at the code:

  • A bunch of places in the code panic. They should either return an error, or — typically only for testing — follow the must* naming convention, e.g. mustOpenHostMemory. The same holds for log.Fatal, which also terminates the process, which is probably not desirable, especially as the code grows to fulfill more functions.
  • The syscall package in the standard library is frozen in favor of the golang.org/x/sys/unix. While you might not have a specific reason to use the x/sys/unix package yet (or maybe some constants you’re currently defining are to be found there?), it might be good style to start using it for consistency as the code grows.
  • Currently, flags are defined all over the place. Ideally, flags would only be defined in the main package, which should pass the flag values to the rest of the code. Otherwise, flags will be a hindrance to testing, might conflict, etc.
  • optionally, you might consider replacing some of the Makefiles with “go generate” instructions
  • For testing, it’s not idiomatic to pass *testing.T around. Instead, compare actual and expected state, return a diff, and call t.Errorf (or t.Fatalf) in your test if the diff is non-empty.

This list might not be exhaustive, but that’s what I could find right now :)

Hope that helps!

BIOS chip selection

The Leopard has 2 BIOS flashes. Being able to select which one to use is good.

  • Should it be persistent? Or should it be a one time thing?
  • Should it be controllable externally? Holding power while pressing reset or something like that?
  • If the BIOS fails for too long, should it switch over automatically? Probably not, better handled by an external rollout manager.

Upgrade U-boot

We're using OpenBMC's u-boot which is based on 2016. This means that there is no chance that we can upstream any u-boot modifications we would like to do.

u-boot mainline does not support AST24xx series so that would have to be ported, but the good thing is that it's not that much stuff we require from the CPU - so it could maybe be not that hard.

Still, collecting all the contributor material and making sure it's all licensed properly etc is going to be a time sink.

Support different sized flashes

Right now u-bmc assumes 32MB flash. When putting in a 64MB flash u-boot correctly determined the size:

U-Boot 2016.07-00038-gc7a5629a1c (Sep 30 2018 - 22:40:21 +0200)

DRAM:  120 MiB
WARNING: Caches not enabled
Flash: 64 MiB
Using default environment

But the kernel was a bit more certain it was 32MB still:

[    1.567855] aspeed-smc 1e620000.flash-controller: Using 50 MHz SPI frequency
[    1.582237] aspeed-smc 1e620000.flash-controller: n25q512ax3 (65536 Kbytes)
[    1.596190] aspeed-smc 1e620000.flash-controller: CE0 window [ 0x20000000 - 0x24000000 ] 64MB
[    1.613363] aspeed-smc 1e620000.flash-controller: CE1 window [ 0x24000000 - 0x26000000 ] 32MB
[    1.630430] aspeed-smc 1e620000.flash-controller: read control register: 203b0641
[    2.192007] 2 fixed-partitions partitions found on MTD device bmc
[    2.204200] Creating 2 MTD partitions on "bmc":
[    2.213280] 0x000000000000-0x000000080000 : "u-boot"
[    2.228836] 0x000000080000-0x000002000000 : "ubi"

~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 04000000 00010000 "bmc"
mtd1: 00080000 00010000 "u-boot"
mtd2: 01f80000 00010000 "ubi"

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.