ish: Trim down the release branchstabilize-wristpin-14469.59.B-ishstabilize-voshyr-14637.B-ishstabilize-quickfix-14695.187.B-ishstabilize-quickfix-14695.124.B-ishstabilize-quickfix-14526.91.B-ishstabilize-14695.85.B-ishstabilize-14695.107.B-ishstabilize-14682.B-ishstabilize-14633.B-ishstabilize-14616.B-ishstabilize-14589.B-ishstabilize-14588.98.B-ishstabilize-14588.14.B-ishstabilize-14588.123.B-ishstabilize-14536.B-ishstabilize-14532.B-ishstabilize-14528.B-ishstabilize-14526.89.B-ishstabilize-14526.84.B-ishstabilize-14526.73.B-ishstabilize-14526.67.B-ishstabilize-14526.57.B-ishstabilize-14498.B-ishstabilize-14496.B-ishstabilize-14477.B-ishstabilize-14469.9.B-ishstabilize-14469.8.B-ishstabilize-14469.58.B-ishstabilize-14469.41.B-ishstabilize-14442.B-ishstabilize-14438.B-ishstabilize-14411.B-ishstabilize-14396.B-ishstabilize-14395.B-ishstabilize-14388.62.B-ishstabilize-14388.61.B-ishstabilize-14388.52.B-ishstabilize-14385.B-ishstabilize-14345.B-ishstabilize-14336.B-ishstabilize-14333.B-ishrelease-R99-14469.B-ishrelease-R98-14388.B-ishrelease-R102-14695.B-ishrelease-R101-14588.B-ishrelease-R100-14526.B-ishfirmware-cherry-14454.B-ishfirmware-brya-14505.B-ishfirmware-brya-14505.71.B-ishfactory-kukui-14374.B-ishfactory-guybrush-14600.B-ishfactory-cherry-14455.B-ishfactory-brya-14517.B-ish

In the interest of making long-term branch maintenance incur as little
technical debt on us as possible, we should not maintain any files on
the branch we are not actually using.

This has the added effect of making it extremely clear when merging CLs
from the main branch when changes have the possibility to affect us.

The follow-on CL adds a convenience script to actually pull updates from
the main branch and generate a CL for the update.

BUG=b:204206272
BRANCH=ish
TEST=make BOARD=arcada_ish && make BOARD=drallion_ish

Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I17e4694c38219b5a0823e0a3e55a28d1348f4b18
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3262038
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Tom Hughes <tomhughes@chromium.org>

1 files changed, 0 insertions, 53 deletions

diff --git a/docs/zephyr_init.md b/docs/zephyr_init.md
deleted file mode 100644
index 8822736efb..0000000000
--- a/docs/zephyr_init.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# Zephyr OS-based EC Initialization Order
-
-Zephyr provides Z_INIT_ENTRY_DEFINE() & the extend macro to install the initial
-function. The initialize flow for different levels would be like the following
-(not very detailed):
-*   architecture-specific initialization
-*   `PRE_KERNEL_1` level
-*   `PRE_KERNEL_2` level
-*   `POST_KERNEL` level
-*   `APPLICATION` level
-*   main()
-
-The kernel and driver initial functions separate into specific initialize
-levels. It couldn't put all initial functions in main() for the Zephyr OS-based
-EC. It is also hard to maintain those initial priority which separates into
-different files.
-
-This file defines some Zephyr OS-based EC initial priorities which have critical
-sequence requirement for initializing:
-
-## PRE_KERNEL_1
-*   Priority (0-9) - Reserved for system testability:
-
-    The highest priority could be used in zephyr. Don't use it when system
-    development. Buffer it for the following system development & testing.
-
-*   Priority (10-19) - Chip level system pre-initialization:
-
-    These priorities in this range are used for critical chip initialization,
-    including determining the reset cause and initializing the battery-backed
-    RAM driver. Most chip drivers should only be initialized after
-    `PLATFORM_EC_SYSTEM_PRE_INIT`.
-
-*   Priority (20) - PLATFORM_EC_SYSTEM_PRE_INIT:
-
-    At this initialization priority, the CROS system checks the reset cause and
-    initializing the system reset flags. Any chip level drivers related to
-    determining the reset type must be at a higher priority.
-
-*   TODO
-
-## PRE_KERNEL_2
-*   TODO
-
-## POST_KERNEL
-*   TODO
-
-## APPLICATION
-*   TODO
-
-## main()
-*   TODO
-*   Start the tasks.