These constants are scattered around the various interface
implementations and should be in one place. This will also clean up
the u-boot side when ec_commands.h is copied there.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link, spring, pit; test 'ectool hello'
Change-Id: Ib1425db00ec8220538d8c5c65107ac9548009516
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60810
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for the TI BQ24715 smart battery charger.
It provides the system power while limiting the battery
charge limit based system power needs.
This code is based off of the bq24725 code, however there
is one change (aside from the min/max) to fit into the
current charging state machine. The charging voltage
setting is cached to provide the illusion of it being 0V
which the hardware does not allow.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=Used on a board containing this charger.
Change-Id: I59af88fba6bf740e7caff72c9ed27eaf721758c4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60804
This is necessary to support larger packet sizes for host protocol
ver.3. The host previously didn't have any way to know how big a
packet the EC could accept / respond with (except on LPC, where the
size is determined by the I/O window).
BUG=chrome-os-partner:20257
BRANCH=none
TEST='ectool protoinfo' returns good info; on link,
Protocol info:
protocol versions: 2 3
max request: 256 bytes
max response: 256 bytes
flags: 0x00000000
and on pit,
Protocol info:
protocol versions: 2 3
max request: 544 bytes
max response: 544 bytes
flags: 0x00000001
Change-Id: Ic1e3831d9b4a96ffbf365c0d09b6023472de39a9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60703
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Version 1 of EC_CMD_FLASH_WRITE will use as big a write as possible given
the available command parameter space. Falls back to 64 byte writes on old
platforms.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=Copy burn_my_ec onto a link and run it. Write size should be 64 bytes
for the first half of the update (since the old EC doesn't support ver.1
of the write command) and 240 bytes for the second half of the update.
Change-Id: I5900de3a5700d7c82a2e0c3cf9921b7ced1c0343
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60511
Bitfields are now in registers.h where they belong.
BUG=chrome-os-partner:20529
BRANCH=none
TEST='crosec test' from u-boot still works
Change-Id: I726550a32b61111c906c1b10c628c5e47eff74fb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60179
The maximum packet length for LPC is limited by the I/O space window
size. But that's not the case for SPI or LPC. Rename LPC constant
before adding a SPI constant.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link
Change-Id: I088327a11eff18d401c773db953700a36f9c1bb4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59959
Explicitly use enum for dma_channel, instead of ints (since channel is
1-based in the docs and 0-based in the enum). Add enum values for
other channels like USART.
Use volatile structs instead of typecasting through REG32().
Other assorted code cleanup.
Remove DMA2 partial support, since neither STM32F100R8 nor STM32L151x
has hardware support for it and it cluttered the code.
No functional changes.
BUG=chrome-os-partner:20485
BRANCH=none
TEST=from pit root shell, 'ectool version' still works
Change-Id: Ifdd62fb287c608a684ba8fa16934dfcab83ee609
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59949
Power LED PWM now uses the same functions as the hardware timer.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=Suspend system. Power button LED pulses smoothly still.
Change-Id: Ib5ca6655d815462baaf68600ad14c4c0c680a6af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59838
Clean up timer initialization code to be more general, so that we can
use timer 9 for the LSB on STM32L. Then use timer 4 for the watchdog
helper.
BUG=chrome-os-partner:18781
BRANCH=none
TEST=From EC console:
timerinfo -> current time still counts up properly
waitms 2000 -> prints watchdog info before rebooting
Change-Id: Ib0ba496b0eadb93756dcd1841857546910baf2a9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59612
Reviewed-by: Simon Glass <sjg@chromium.org>
This lets us force the EC to return various error codes, so that we can be
sure we're seeing them.
BUG=chromium:242706
BRANCH=none
TEST=none
Trigger various errors like so:
ectool test 0 14
ectool test 1 14
ectool test 5 14
ectool test 8 14
ectool test 0 33
Change-Id: Ia951cd7afacdcce6c8ec7d35d3bfb5b113dea694
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59327
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This will fix EC flash commands on pit, once the host side (u-boot and
cros_ec driver) are upgraded to match.
This change is backwards-compatible the EC still supports the existing
version 2 protocols for talking to existing AP/kernel/ectool.
Once the AP-side supports version 3 for SPI (and existing systems are
upgraded), we will remove older SPI support since we haven't shipped a
product which uses SPI.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=disable cros_ec driver support in ectool; 'ectool hello' works on link
And with an old ectool which predates this CL, 'ectool hello' also works.
On pit, from u-boot prompt, 'crosec test' and 'crosec version' work, and
keyboard works.
Change-Id: I01f193e316e9aa442fe50d632dc8a4681723e282
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58908
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
This will be used often, so let's move it to test_util.c.
BUG=chrome-os-partner:19235
TEST=Pass flash test.
BRANCH=None
Change-Id: I2f685f657f8742c2b29e3b9c88ba01daacf982f8
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58793
By 'make coverage', lcov is used to generate test coverage report in
HTML format stored in coverage_rpt folder.
BUG=chrome-os-partner:19235
TEST=Generate a report.
BRANCH=None
Change-Id: I44142eaaeb897cf09179764781120370920144cd
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58203
It's not used by the host command module or handlers, so shouldn't be exposed to them.
BUG=chrome-os-partner:20185
BRANCH=none
TEST='ectool hello' still works
Change-Id: I0122bd9ef33e71afab7e5cc035fb3b9d220334c6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58632
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The flags are specific to the LPC interface and not used by the host
command module, so shouldn't be present at that level.
BUG=chrome-os-partner:20185
BRANCH=none
TEST='ectool hello' still works
Change-Id: I6b2c3208fc398ea40d9e7cc7bf5ec206b3e317d8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58631
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
GPIO_HI_Z was a bit misleading (it's high impedance by default, but it's
actually an output not an input), but when we added GPIO_HI_Z_OPEN to mean
"open-drain output, pulled low by default", it got too confusing.
This renames those macros to:
#define GPIO_ODR_HIGH (GPIO_OUTPUT | GPIO_OPEN_DRAIN | GPIO_HIGH)
#define GPIO_ODR_LOW (GPIO_OUTPUT | GPIO_OPEN_DRAIN | GPIO_LOW)
BUG=chrome-os-partner:18788
BRANCH=none
TEST=none
No functional change, just renaming some macros. If it compiles, it should
be unchanged in behavior.
Change-Id: Ic84d7be8531f2b240a8eca4f6cfe5291ebd2d5ef
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58596
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds the BQ24738 smart battery charger, and a placeholder for the Falco
battery pack. I don't have either documentation or a battery to use to test,
so the battery pack stuff is just a guess (see crosbug.com/p/20142).
BUG=chrome-os-partner:20098
BRANCH=none
TEST=none
Well, if you like, from the EC console, run "charger". It should say
something like this:
> charger
Name : bq24738
Option: 1111100100010010 (0xf912)
Man id: 0x0040
Dev id: 0x000f
V_batt: 0 (1024 - 19200, 16)
I_batt: 0 ( 128 - 8128, 64)
I_in : 3968 ( 128 - 8064, 128)
>
But since I don't have either a battery or a spec, I had to guess at the
battery configuration. To test the charger, we kind of need a battery.
Change-Id: I6e63d6b5aa8be4ba15e2c427d2e86364ef6251b3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58466
Sometimes initialization may fail due to bad I2C bus status. Let's allow
for maximum 3 tries of initialization 500ms apart from previous attempt.
BUG=chrome-os-partner:20020
TEST=Boot and check device type detection still works.
BRANCH=spring
Change-Id: I6ccedf77c92c4b6014ca24c7a63534316eaa7b6a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58071
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently, we need to have #ifdefs everywhere watchdog_reload() is
called. With this fix we don't.
Also don't bother including unused hardware timer watchdog code if the
watchdog isn't defined.
No change when CONFIG_WATCHDOG is defined (which it is for all normal builds).
BUG=chrome-os-partner:20056
BRANCH=none
TEST=build all platforms with CONFIG_WATCHDOG commented out in config.h
Change-Id: Id3ce33af1a497eda127a4892e13651d9d2534d92
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58094
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds the initial support for Slippy's battery. The data I have is
unclear and incomplete, so this is NOT the final form. It seems to work
right now, and hasn't caught fire or anything, but it will need futher
tweaks.
BUG=chrome-os-partner:19976
BRANCH=none
TEST=manual (and watch it!)
Connect the EC console and watch what happens. You should see the battery
charging, discharging, etc. Keep an eye on it, though, and never leave it
unattended when on AC - we don't have the full data sheets available yet.
Change-Id: Id9bf93dc04a1399a9cdbc2156b3fac74be62038f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57814
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is very similar to the BQ24725. There are just enough differences to
require a separate file.
BUG=chrome-os-partner:19976
BRANCH=none
TEST=none
Nothing to test until it's enabled.
Change-Id: I3247fcfde93ac75f5f9790acadc7feca28038608
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57811
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is preparation for the common userspace EC interface. If/when that
appears, this will be ready.
BUG=chromium:239197
BRANCH=all
TEST=manual
Build, install, run it. Shouldn't be any change.
Change-Id: I9fa78515ec5443ba659f10a66bbaadcb7f4802b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56131
The WAKE# pin was being driven low when the power button was
pressed and no other events were occuring. This causes a PCIE
wake event to be observed on the host. This is incorrect. Therefore
only assert the WAKE# pin when any other event but the power button
has occured.
The implementation introduces a board-specific callback,
board_process_wake_events(), which handles the specific logic
for the wake events.
BUG=chrome-os-partner:19810
BRANCH=None
TEST=Manual. Both power button wakeup and lid events were tested. The
presence of PCIE Wake no longer exists for S5->S0 transitions.
Change-Id: If1311ccc36629b04d2d9e021c3e103e379836a3a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56970
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The firmware defines had two almost-identical sets. Coalesce into one
consistent set.
Link had 256 KB flash, but only allowed 2 80KB images. Future
LM4-based platforms (slippy/peppy/falco/etc) will now use the entire
flash, with RO=124KB, pstate=4KB, RW=128KB. This matches what the
STM32 platforms do, where pstate is contiguous with the RO firmware.
No functional change to STM32-based platforms.
BUG=chrome-os-partner:19176
BRANCH=none
TEST=build all platforms and dump_fmap ec.bin.
- stm32-based platforms should report RO=61440@0, RW=65536@0x10000
- link should report RO=81920@0, RW=81920@0x14000
- slippy should report RO=129024@0, RW=131072@0x20000
Change-Id: I20b1d95c16250d9a5d228ead06eef03d96548823
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56655
This adds the option to specify which LED to control as well as the
ability to query the supported LED color on the board.
BUG=chrome-os-partner:19745
TEST=On Spring:
- ectool led 0 query -> See the max value for R, G, Y is 0x80.
- ectool led 1 query -> See error message.
- ectool led 0 yellow -> See LED turns yellow.
- ectool led 0 green=0x40 red=0x40 -> See green and red lit up.
- ectool led 0 auto -> See LED turns off (without charger.)
BRANCH=spring
Change-Id: Ibdde2f7450122f59383dad1030a0a2a985386f73
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56877
Haswell devices have EC control of the WWAN power rail.
Expose a new wireless switch enable flag for this under
the existing wirless enable command.
This change also abstracts the wireless enable function
to call a per-board handler so the different boards can
do the right thing based on their GPIO setup.
The haswell boards will switch WLAN radio and WWAN power
rails based on the switch inputs. These boards do not have
EC control of bluetooth radio/rail power.
WLAN (power and radio) still defaults to enabled. Disabling
with ectool will turn off the radio but keep the power enabled
in order to prevent the PCIe device from disappearing.
WWAN (power) still defaults to disabled. Disabling with
ectool will turn off the power rail.
BUG=chrome-os-partner:19871
BRANCH=none
TEST=manual: boot on slippy
DEFAULT:
> ectool gpioget pp3300_wlan_en
GPIO pp3300_wlan_en = 1
> ectool gpioget wlan_off_l
GPIO wlan_off_l = 1
> ectool gpioget pp3300_lte_en
GPIO pp3300_lte_en = 0
ENABLE WWAN:
> ectool wireless 0x7
Success.
> ectool gpioget pp3300_lte_en
GPIO pp3300_lte_en = 1
DISABLE WLAN (radio):
> ectool wireless 0x7
Success.
> ectool gpioget pp3300_wlan_en
GPIO pp3300_wlan_en = 1
> ectool gpioget wlan_off_l
GPIO wlan_off_l = 0
Change-Id: I6f760b8cf5ab47d8f7f0dd8cd4d3e6563464043e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57215
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This provides a way to control LED color with ectool. We can either set
the color or switch back to automatic control.
BUG=chrome-os-partner:19745
TEST=ectool led red -> LED turns red.
ectool led green -> LED turns green.
Unplug charger -> LED turns off.
ectool led green -> LED turns of and shows green.
ectool led auto -> LED back to normal.
BRANCH=spring
Change-Id: I0b455f34cea448660fe44a5fecaac1cb084f8144
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56721
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Write protect signal naming is now consistent across boards.
New CONFIG_WP_ACTIVE_HIGH is present on systems where the write
protect signal is active-high (e.g. Link). This will be used in the
next CL, which moves flash_get_protect() to flash_common.c
BUG=chrome-os-partner:15613
BRANCH=none
TEST=flashinfo properly reports WP signal status
Change-Id: I502ab033c3eb36661cc3ee97320874b3fbf6fc0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56087
Reviewed-by: Vic Yang <victoryang@chromium.org>
Persistent state is needed by all platforms to hold the
protect-ro-at-boot flag. STM32F100 and LM4 implementations were
near-identical, and are now common code (with one #ifdef to handle the
single place where they weren't).
STM32L doesn't use pstate yet, but it'll need to. I can't simply
store the protect-ro-at-boot flag inside the WRP registers themselves
because they're still writable in EC-RW. The change to STM32L to use
pstate is coming next.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=build pit, link, spring; on link and spring, do
- flashinfo -> (no flags)
- enable WP (via screw or dut-control)
- flashinfo -> wp_gpio_asserted
- flashwp enable
- flashinfo -> wp_gpio_asserted ro_at_boot
- flashwp now
- flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now)
- flashwp disable -> fails
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- reboot ap-off
- flashinfo -> wp_gpio_asserted ro_at_boot ro_now
- disable WP (via screw or dut-control)
- reboot
- flashinfo -> ro_at_boot
- flashwp disable
- flashinfo -> (no flags)
(Note that on Spring you'll need to 'forceen on' before enabling WP,
or the console will be disabled once you enable ro_at_boot and reboot.)
Change-Id: I415388b98ec8bf1d149803aaaa7fe8c7f3076c36
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56064
This adds support for write protecting the RO code at boot, and the
entire flash on demand.
Implementation if WP# is not asserted is currently a little different
than STM32F and LM4; RO is still protected at boot if ro_at_boot, but
can be unprotected and the change will commit on the next reboot.
This saves the bank of flash which we use for pstate on LM4 and
STM32F. I think I can use one of the unused option bits (WRP2 bit 0)
to hold the RO-at-boot flag, in which case I can more closely match
the behavior of the other chips, but I'd like to do that (or give up
and implement pstate) in a separate CL so it's clearer what I'm doing.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=manual
- flashinfo -> (no flags)
- enable WP (via screw or dut-control)
- flashinfo -> wp_gpio_asserted
- flashwp enable
- flashinfo -> wp_gpio_asserted ro_at_boot
- flashwp now
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- flashwp disable -> fails
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- flasherase 0x1fc00 0x400 -> fails
- reboot
- flashinfo -> wp_gpio_asserted ro_at_boot ro_now
- flasherase 0xfc00 0x400 -> fails
- flasherase 0x1fc00 0x400 -> succeeds
- disable WP (via screw or dut-control)
- reboot
- flashinfo -> ro_at_boot ro_now
- flashwp disable
- flashinfo -> ro_now
- reboot
- flashinfo -> (no flags)
- flasherase 0xfc00 0x400 -> succeeds
- flasherase 0x1fc00 0x400 -> succeeds
Change-Id: Id1b6b099a44a1985a5ab9387feb882a8f26e3aa1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55594
The gpio pin used for RCIN# should be configured as open drain as the
rail is pulled up by a non-EC rail. Driving it high would leak power.
The current GPIO_HI_Z macro uses GPIO_HIGH as the default state.
However, it has been found that this actually drives the pin to ground.
It is still unclear how Link works or doesn't.
BUG=chrome-os-partner:19355
BRANCH=none
TEST=manual: boot on slippy without RCIN# causing reset and
the 'apreset warm' EC command works as expected.
Change-Id: I71425075f8d77b3d7e576a59fc24f823790e2655
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56269
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
For Spring, the charging time can be quite long and TPS65090 ends up in
timeout state and stops charging. Let's put charge state machine back to
re-init so that the device continues charging after checking charging
condition is good.
BUG=chrome-os-partner:19405
TEST=Pass charger test
BRANCH=spring
Change-Id: I838741e7283eb31ed76cf3979dbad7f070947aea
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55720
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The current lm4 pwm module was using board-specific
pins during this configuration. Move the implementation
of configure_fan_gpios() to the board-specific files
so that the pin configuration policy isn't a part of the
common infrastructure.
BUG=chrome-os-partner:19504
BRANCH=none
TEST=successfully booted slippy with backlight turning on in OS.
Change-Id: I325f1ac4639b4a78d8b860df7a8b688ca385b71b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51471
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When system is locked, the console is disabled. However, we need console
for debugging and testing. This CL uses a bit from back-up register to
indicate if the console should always be enabled. (This bit is currently
used by fake WP, which is removed in this CL.) With this, we can set
this bit with console command 'forceen 1' to ensure console is never
disabled.
To prevent device shipped in this state, the chip name is postfixed with
'-unsafe' so that the device is not able to pass HWID check.
BUG=chrome-os-partner:19293
TEST=Manual
BRANCH=spring
Change-Id: I88556e973ca542c1bdc27ba64988718291e01a26
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Several test utility macros have been duplicated across tests. Let's put
them in a single place.
BUG=chrome-os-partner:19236
TEST='make runtests', 'BOARD=spring make tests'
BRANCH=None
Change-Id: Ib0c9f829715425cc23e33b8ef456b17dfadab13c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50513
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On 64-bit platform, arrays should be aligned to 8 bytes. Also, change
the order of host_command fields so that it's packed on both 32-bit and
64-bit platforms.
BUG=chrome-os-partner:19257
TEST=Pass all tests. Print out and check the content of host commands.
BRANCH=None
Change-Id: I350a903bc11562d6d205c402548942f8967b75a5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50467
Perviously we use uint32_t for this, but this doesn't compile for 64-bit
environment (and likely doesn't for 16-bit either.) Use uintptr_t so that
we don't get size mismatch errors.
BUG=chrome-os-partner:19257
TEST=Run host emulated tests
BRANCH=None
Change-Id: I3cd66a745fa171c41a5f142514284ec106586acb
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50358
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is the first version of pthread-based RTOS emulator. With this, we
will be able to test high-level modules entirely on the host machine.
BUG=chrome-os-partner:19325
TEST='make runtests' and see tests passing.
BRANCH=None
Change-Id: I1f5fcd76aa84bdb46c7d35c5e60ae5d92fd3a319
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49954
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
