| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was roughly achieved by the following shell script:
$ git ls-files |
grep '\.[ch]p*$' |
while read F; do EXT=${F##*.}; cat spdx.$EXT <(sed '/^\/\*$/,/^ \*\/$/d' $F) > ${F}.tmp; mv ${F}.tmp $F; done
With the following context:
$ cat spdx.c
// SPDX-License-Identifier: Apache-2.0
// Copyright (C) 2018 IBM Corp.
$ cat spdx.h
/* SPDX-License-Identifier: Apache-2.0 */
/* Copyright (C) 2018 IBM Corp. */
$ ls -l spdx.*
-rw-r--r-- 1 andrew andrew 71 Feb 27 12:02 spdx.c
lrwxrwxrwx 1 andrew andrew 6 Feb 27 12:02 spdx.cpp -> spdx.c
-rw-r--r-- 1 andrew andrew 77 Feb 27 12:02 spdx.h
lrwxrwxrwx 1 andrew andrew 6 Feb 27 12:02 spdx.hpp -> spdx.h
The `sed` invocation catches a lot of function documentation, so the
hunks were manually added to avoid removing information that we want to
keep.
Change-Id: I63e49ca2593aa0db0568c7a63bfdead388642e76
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous patch added a new return field in GET_MBOX_INFO called
"suggested timeout" to be used to provide a suggested maximum timeout
value to the host.
Add this to the return arguments of GET_MBOX_INFO.
Note that the host is free to ignore the value and the daemon can
leave this blank if it doesn't want to provide a timeout.
We hard code a milliseconds per megabyte value which was determined
to be approximately 8000 based on testing and is close to linear
as the access size changes. Testing was conducted on an Aspeed ast2500
on a Witherspoon with the dev-4.7 OpenBMC branch.
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: If24e41ebb1d9f03c2bdcca84819f9430fd3eeff6
|
| |
|
|
|
| |
Change-Id: I48ff8175a1e9f6f012e5bed4f7268c5e9b0745e0
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The window size and number command line parameters are used to control
the number of windows and the size of each of the windows in the window
cache which the reserved memory region is divided between.
Most people won't care about tuning these or just won't know what they
refer to. Additionally in the event we change how the window cache
works or allow a non-constant window size then the meaning of these
becomes unclear.
Daemon implementations may also choose to just not implement a cache so
making these required parameters may hurt portability.
Make the window size and number command line parameters optional rather
than required so that they can be largly ignored while people who really
care about tuning them can still do so.
The default for now is to have windows of size 1MB and to map the entire
reserved memory region. That is:
number of windows = size of memory region / size of windows
This means that the size of the reserved memory region can be reduced
and the daemon will adapt to this.
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: I7c7bbef6e5d31d1372ec3a755877cacc6c135cce
|
|
|
Version 2 of the mbox protocol contains a few changes such as:
- All sizes are in block size
- Adds an erase command
- Adds new response codes
- Adds new BMC events
- Open windows commands now take a size directive
Update the mailbox daemon to support version 2 of the protocol which
includes implementing all of the V2 functionality. Also entirely refactor
the mboxd.c code to make it more modular improving readability and
maintainability.
At the same time improve the functionality by adding:
- Multiple windows in the daemon (still only one active window) to cache
flash contents
- Implement a dbus interface to allow interaction with the daemon
- Handle sigterm and sigint and terminate cleanly
The previous implementation utilised the entire reserved memory region.
Update the daemon so that on the command line the number of windows and
the size of each which the reserved memory region will be split into can
be specified. The reserved memory region is then divided between the
windows, however there can still only be one "active" window at a time.
The daemon uses these windows to cache the flash contents meaning the
flash doesn't have to be copied when the host requests access assuming
the daemon already has a copy.
A dbus interface is added so that commands can be sent to the daemon to
control it's operation from the bmc. These include suspending and resuming
the daemon to synchronise flash access, telling the daemon to point the lpc
mapping back to flash and telling the daemon when the flash has been
modified out from under it.
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: I10be01a395c2bec437cf2c825fdd144580b60dbc
|
