summaryrefslogtreecommitdiff
path: root/zephyr/Kconfig
blob: 313566625b5aa1acc797c6da906aecdc5d4e6a65 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
# Copyright 2020 The Chromium OS Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.

rsource "app/Kconfig"
rsource "drivers/Kconfig"

if ZTEST

config HAS_TEST_TASKS
	bool "Whether or not this test includes custom tasks"
	help
	  This enables custom tasks for tests. When set to 'y', the file
	  "shimmed_test_tasks.h" will be included and is expected to set
	  CROS_EC_TASK_LIST.

endif # ZTEST

menuconfig PLATFORM_EC
	bool "Chromium OS EC shim"
	imply PRINTK
	imply SHELL
	help
	  The platform/ec Zephyr module allows some code from the
	  existing Chromium OS EC project to be "shimmed" into Zephyr. With
	  this it is possible to use the existing code base within Zephyr.

	  Once we manage to get a platform fully running with Zephyr we will
	  progressively upstream components and turn off the shim for each
	  one until eventually all code is on the Zephyr side.

if PLATFORM_EC

rsource "Kconfig.adc"
rsource "Kconfig.battery"
rsource "Kconfig.console"
rsource "Kconfig.header"
rsource "Kconfig.keyboard"
rsource "Kconfig.led"
rsource "Kconfig.powerseq"
rsource "Kconfig.motionsense"
rsource "Kconfig.tasks"
rsource "Kconfig.temperature"
rsource "Kconfig.usbc"

# Define PLATFORM_EC_... options to enable EC features. Each Kconfig should be
# matched by a line in zephyr/shim/include/config_chip.h which #defines the
# corresponding EC CONFIG if this Kconfig is enabled.
#
# Please keep these in alphabetical order

config PLATFORM_EC_ACPI
	bool "Enable the ACPI module"
	default y if AP_X86 && PLATFORM_EC_ESPI
	help
	  Enable shimming the ACPI handler, which will handle the Host data from
	  the ACPI I/O port for X86 AP.

config PLATFORM_EC_BACKLIGHT_LID
	bool "Control the display backlight based on the lid switch"
	depends on PLATFORM_EC_HOSTCMD
	default y
	help
	  Support controlling the display backlight based on the state of the
	  lid switch. The EC will disable the backlight when the lid is closed.

	  This option enables the EC_CMD_SWITCH_ENABLE_BKLIGHT host command,
	  which allows the AP to override the backlight setting until the next
	  change in the lid state.

config PLATFORM_EC_HOSTCMD_GET_UPTIME_INFO
	bool "Host command: EC_CMD_GET_UPTIME_INFO"
	default PLATFORM_EC_HOSTCMD
	help
	  Enable the EC_CMD_GET_UPTIME_INFO host command which reports the time
	  the EC has been powered up, the number of AP resets, an optional log
	  of AP-reset events and some flags.

config PLATFORM_EC_AP_RESET_LOG
	bool "Enable the Application Processor reset log"
	depends on PLATFORM_EC_HOSTCMD_GET_UPTIME_INFO
	default y if PLATFORM_EC_POWERSEQ
	help
	  Enable logging of AP reset events. This information is provided in
	  response to the EC_CMD_GET_UPTIME_INFO host command.

config PLATFORM_EC_BOARD_RESET_AFTER_POWER_ON
	bool "Work around H1 reset issue"
	default y
	help
	  Enable this if H1 resets the EC after power-on. This is needed so the EC
	  can delay its start-up until the reset happens. Without this option
	  the EC starts up, performs some amount of processing and then gets a
	  reset that it is not expecting.

config PLATFORM_EC_BRINGUP
	bool "Enable early bringup debugging features"
	help
	  Enable the CONFIG_BRINGUP platform/ec configuration option,
	  turning on a variety of miscellaneous early bringup
	  debugging features.

	  These features include:
	  - The device will not power on when the EC starts.  The
	    power button will need to be pressed, or the "powerbtn"
	    command issued.
	  - Enable power signal logging, showing relative timestamps
	    for each power signal change.
	  - And more!  You can search the codebase for CONFIG_BRINGUP
            to see all of the features this flag will toggle.

config PLATFORM_EC_VBOOT
	bool "Enable Chromium OS verified boot"
	default y if !SOC_POSIX
	help
	  Enables Early Firmware Selection v2 (EFS2) verified boot. When booting
	  a Chromium OS image we're actually packing both an RO image and an RW
	  image into flash. The RO image is loaded first. EFS2 runs at boot and
	  verifies the integrity of the RW image by sending a hash of the image
	  to the Google Security Chip (GSC). Once the GSC verifies the hash,
	  EFS2 calls sysjump and reboot the EC using the RW image.

config PLATFORM_EC_BOARD_VERSION
	bool "Support the notion of board version"
	default y
	help
	  Enable support for a board version, used to distinguish different
	  revisions of the same base design. Each board goes through a number
	  of development phases on the way to launch. Sometimes different boards
	  have different quirks and this version number can provide a way for
	  the EC to handle several board versions, avoiding the problem of
	  having to flash different images to different board versions.

if PLATFORM_EC_BOARD_VERSION

choice "Version source"
	prompt "Select the source of the version number"
	help
	  This allow selection of the source of the board version number
	  information. Several options are available, but BOARD_VERSION_CBI is
	  preferred for new boards, so long as the hardware supports it (i.e.
	  has an EEPROM).

config PLATFORM_EC_BOARD_VERSION_CBI
	bool "Chromium OS Board Info (CBI)"
	depends on PLATFORM_EC_CBI
	help
	  Choose this if the board version comes from Chromium Board Info
	  within the EEPROM. This is the recommended approach and is used on
	  newer boards. The version information is written into the EEPROM as
	  part of the factory process.

config PLATFORM_EC_BOARD_VERSION_GPIO
	bool "Strapping GPIOs"
	help
	  Choose this if the board version is encoded with three GPIO signals
	  (GPIO_BOARD_VERSION1, GPIO_BOARD_VERSION2 and GPIO_BOARD_VERSION3)
	  forming the 3-digit binary number. GPIO_BOARD_VERSION1 is the LSB.
	  This provides 8 possible combinations.

	  The GPIOs should have external pull-up/pull-down resistors installed
	  at the factory to select the correct value.

config PLATFORM_EC_BOARD_VERSION_CUSTOM
	bool "Custom board-specific algortihm"
	help
	  Choose this if none of the standard methods is available and you must
	  perform special logic to find the board version. If this is chosen,
	  then the system code will call board_get_version() to find out the
	  version, so you should implement this function in your board code.

endchoice

endif # PLATFORM_EC_BOARD_VERSION

config PLATFORM_EC_CBI
	bool "CBI EEPROM support"
	depends on PLATFORM_EC_I2C
	help
	  Enables various Chromium OS Board Info (CBI) accessors as well as
	  host and console commands. CBI is a means for accessing information
	  about a board, typically written during the factory process.

	  One must specify both I2C_PORT_EEPROM and I2C_ADDR_EEPROM_FLAGS to the
	  CBI EEPROM's i2c port and 7-bit i2c address.

	  See here for information on CBI:

	  https://chromium.googlesource.com/chromiumos/docs/+/master/design_docs/cros_board_info.md

config PLATFORM_EC_CHIPSET_RESET_HOOK
	bool "Provide a hook for when the AP resets"
	default y
	help
	  Enables support for the HOOK_CHIPSET_RESET hook. This can be used by
	  code that needs to run before a programmatic reset actually happens.
	  Note that these hooks don't run with a cold reset, only when the AP
	  decides to reset itself.

	  You can declare a hook like this:

	     DECLARE_HOOK(HOOK_CHIPSET_RESET, do_something, HOOK_PRIO_DEFAULT);

	  Then do_something() will be called just before the reset happens.

config PLATFORM_EC_CONSOLE_CMD_MEM
	bool "Console command: md, rw"
	default y
	help
	  Enable memory related console commands.

	     md - dump memory values
	     rw - read or write in memory

if PLATFORM_EC_CONSOLE_CMD_MEM

config PLATFORM_EC_CONSOLE_CMD_MD
	bool "Console command: md"
	default y
	help
	  Enable the "md" command. This dumps memory value from a specified
	  address, optionally specifying the format.

	  Example:
	     md 0x64000000 10

	     64000000: 2a3b4d5e 030054e1 07000000 09297110
	     64000010: 00000010 03db4f00 03db5000 00000100
	     64000020: 00000000 00000000

config PLATFORM_EC_CONSOLE_CMD_RW
	bool "Console command: rw"
	default y
	help
	  Enable the "rw" command. This Read or write in memory optionally
	  specifying the size.

	  Example:
	     rw 0x64000000

	     read 0x64000000 = 0x2a3b4d5e

endif # PLATFORM_EC_CONSOLE_CMD_MEM

config PLATFORM_EC_DEBUG_ASSERT
	bool "Enable assertion failures"
	default y
	help
	  Assertion failures are used to flag conditions which should not occur
	  and thus indicate the software is unable to continue execution. This
	  option can be disabled so that the assert() macro becomes a NOP. In
	  this case, execution will continue but the results are unpredictable.

	  Messages are of the form:

	     ASSERTION FAILURE '<expr>' in function() at file:line

	  Note: There is also ASSERT() which is an alias of assert(), used in
	  host code where cstdlib is used.

choice "Behaviour on assertion failure"
	prompt "Select behaviour on assertion failure"
	help
	  This selects the action taken when the board hits an assertion
	  failure in the code. This should not happen in normal operation,
	  but can appear during development when the code is not yet fully
	  tested.

config PLATFORM_EC_DEBUG_ASSERT_REBOOTS
	bool "Reboot"
	help
	  Prints a message and reboot if an assert() macro fails at runtime.
	  If PLATFORM_EC_SOFTWARE_PANIC is enabled then the information is
	  written to the panic log before rebooting.

config PLATFORM_EC_DEBUG_ASSERT_BREAKPOINT
	bool "Generate a breakpoint"
	help
	  Immediately hits a breakpoint instruction (without printing a message)
	  so that a connected JTAG debugger can be used to debug the problem
	  from there. If there is no debugger connected then the breakpoint
	  instruction will cause the board to reboot immediately.

endchoice # "Behaviour on assertion failure"

config PLATFORM_EC_DEBUG_ASSERT_BRIEF
	bool "Use brief assertion-failure messages"
	depends on PLATFORM_EC_DEBUG_ASSERT_REBOOTS
	help
	  Normally the assertion-failure messages include the expression that
	  failed and the function name where the failure occurred. These are
	  both stored as strings and can add a lot to the size of the image,
	  since they are generated for every call to assert(). Use this option
	  to drop them so that only the file and line number are shown.

	  This option is of course not available with
	  PLATFORM_EC_DEBUG_ASSERT_BREAKPOINT, since that does not print a
	  message at all.

menuconfig PLATFORM_EC_ESPI
	bool "eSPI"
	depends on ESPI && AP
	default y
	help
	  Enable the Enhanced Serial Peripheral Interface (eSPI) shim layer.
	  eSPI supports a shared physical connection between several on-board
	  devices, similar to SPI. It adds a few optional signals and a protocol
	  layer to provide independent 'channels' for each device to communicate
	  over.

	  eSPI is the replacement for LPC (Low-Pin-Count bus).

	  See here for information about eSPI:

	  https://www.intel.com/content/dam/support/us/en/documents/software/chipset-software/327432-004_espi_base_specification_rev1.0_cb.pdf

if PLATFORM_EC_ESPI

config PLATFORM_EC_ESPI_VW_SLP_S3
	bool "SLP_S3 is an eSPI virtual wire instead of a GPIO"
	help
	  For power sequencing, use an eSPI virtual wire instead of
	  defining GPIO_PCH_SLP_S3 in gpio_map.h.

config PLATFORM_EC_ESPI_VW_SLP_S4
	bool "SLP_S4 is an eSPI virtual wire instead of a GPIO"
	help
	  For power sequencing, use an eSPI virtual wire instead of
	  defining GPIO_PCH_SLP_S4 in gpio_map.h.

endif # PLATFORM_EC_ESPI

config PLATFORM_EC_EXTPOWER_GPIO
	bool "GPIO-based external power detection"
	depends on PLATFORM_EC_HOOKS && PLATFORM_EC_HOSTCMD
	help
	  Enable shimming the extpower_gpio module, which provides
	  GPIO-based external power presence detection features.  The
	  project should define a GPIO pin named GPIO_AC_PRESENT, with
	  extpower_interrupt configured as the handler in gpio_map.h.

config PLATFORM_EC_FLASH
	bool "Enable flash support"
	default y if FLASH_SIZE > 0
	help
	  Enables access to the device's flash through a simple API. With
	  this is it possible for the EC to update its flash while running,
	  e.g. to support auto-update. Various write-protection features are
	  also provided.

if PLATFORM_EC_FLASH

config PLATFORM_EC_SPI_FLASH_REGS
	bool "Enable SPI flash registers"
	default y
	help
	  Enables flash registers for SPI flash (both internal and external).
	  When enabled, two new functions will become available: (1) a function
	  to compute the block write protection range from a set of status
	  registers, and (2) the inverse function to set the status registers
	  based on the desired protection offset/length.

config PLATFORM_EC_PROTECTED_STORAGE_OFF
	hex "Position of the RO image in Flash memory"
	default 0x0
	help
	  Sets the position in flash memory where the RO image begins. This is
	  the address that will be used to start copying the image into RAM.

config PLATFORM_EC_PROTECTED_STORAGE_SIZE
	hex "Size of the RO image in Flash memory"
	default 0x40000
	help
	  The total size of the RO image in flash memory. This will dictate the
	  ending position of the RO image being copied into RAM when combined
	  with PLATFORM_EC_PROTECTED_STORAGE_OFF.

config PLATFORM_EC_WRITABLE_STORAGE_OFF
	hex "Position of the RW image in Flash memory"
	default 0x40000
	help
	  Sets the position in flash memory where the RW image begins. This is
	  the address that will be used to start copying the image into RAM.

config PLATFORM_EC_WRITABLE_STORAGE_SIZE
	hex "Size of the RW image in Flash memory"
	default 0x40000
	help
	  The total size of the RW image in flash memory. This will dictate the
	  ending position of the RW image being copied into RAM when combined
	  with PLATFORM_EC_WRITABLE_STORAGE_OFF.

config PLATFORM_EC_CONSOLE_CMD_CHARGEN
	bool "Console command: chargen"
	depends on UART_INTERRUPT_DRIVEN
	help
	  Enables the "chargen" console command, which sends a continuous
	  stream of characters to the EC console.

	  This allows to create tests which validate console output by
	  verifying that no characters in the received sequence were lost.

config PLATFORM_EC_CONSOLE_CMD_FLASH
	bool "Console commands: flasherase, flashread, flashwp, flashwrite"
	default y
	help
	  Enables various console commands:

	     flasherase - erase flash region
	     flashread - read from flash to memory
	     flashwp - change write-protection settings
	     flashwrite - write memory to flash

config PLATFORM_EC_CONSOLE_CMD_SYSJUMP
	bool "Console command: sysjump"
	default y
	help
	  Enables the sysjump console command used for testing and verifying
	  that we're able to jump between images. Normally, in an EC build,
	  there will exist 2 images (sometimes more): read-only (RO) and
	  read-write (RW). This console command allows us to manually jump
	  between the various images (or even to a random starting address) by
	  copying the image data from flash to ram, then jumping to the image's
	  entry point.

config PLATFORM_EC_EXTERNAL_STORAGE
	bool "Flash is stored external to the EC"
	default y if SOC_FAMILY_NPCX
	help
	  This indicates that the EC's flash is stored separately and is it
	  not possible execute directly from it. Code must be loaded from
	  the flash into internal SRAM before it can be executed. It is still
	  possible to read and write the flash.

config PLATFORM_EC_MAPPED_STORAGE
	bool "Flash is mapped into the EC's address space"
	default y if SOC_FAMILY_NPCX
	help
	  This indicates that the EC's flash is directly mapped into
	  its address space. This makes it easier to read and write the flash.
	  If this is not defined, the flash driver must implement
	  flash_physical_read().

endif # PLATFORM_EC_FLASH

config PLATFORM_EC_FPU
	bool "Support floating point"
	depends on FPU && CPU_CORTEX_M && !NEWLIB_LIBC
	default y
	help
	  This enables support for floating point. This is generally already
	  provided in Zephyr, but the EC side expects a few functions to be
	  available which are not available with Zephyr's minimal lib: sqrtf()
	  and fabsf(). Enabling this options defines them.

	  For now this is only supported on Cortex-M4.

config PLATFORM_EC_HOOKS
	bool "Hooks and deferred compatibility shim"
	default y
	help
	  Enable translation of DECLARE_DEFERRED() and hook_call_deferred()
	  to Zephyr's work queues, along with a compatible DECLARE_HOOK
	  implementation.

	  This option is needed by many features in the EC. Disabling it will
	  likely cause build errors.

config PLATFORM_EC_I2C
	bool "I2C shim"
	default n if ARCH_POSIX
	default y
	help
	  Enable compilation of the EC i2c module. Once enabled, it will be
	  possible to make calls using the old platform/ec i2c APIs defined
	  in include/i2c.h and implemented in common/i2c_master.c. Doing so
	  should make shimming other platform/ec modules which rely on i2c
	  communication "just work" without requiring any further code changes.

menuconfig PLATFORM_EC_HOSTCMD
	bool "Host commands"
	default n if ARCH_POSIX
	default y if AP
	select HAS_TASK_HOSTCMD
	help
	  Enable the host commands shim in platform/ec. This handles
	  communication with the AP. The AP sends a command to the EC and it
	  responds when able. An interrupt can be used to indicate to the AP
	  that the EC has something for it.

config PLATFORM_EC_LID_SWITCH
	bool "Lid switch"
	help
	  Enable shimming the lid switch implementation and related
	  commands in platform/ec. The lid switch can affect power-on
	  behaviour. For example, when the lid is opened, the device may
	  automatically power on.

	  This requires a GPIO named GPIO_LID_OPEN to be defined in gpio_map.h.

config PLATFORM_EC_MKBP_EVENT
    bool "MKBP event"
    help
      Enable this to support MKBP event. MKBP event is used not only
      for matrix keyboard but also for other many events like button,
      switch, fingerprint, and etc.

      This requires a MKBP event delivery method(GPIO, HOST_EVENT, and etc)

if PLATFORM_EC_MKBP_EVENT

choice
    prompt "MKBP delivery method"
    default PLATFORM_EC_MKBP_USE_GPIO
    help
      Select MKBP delivery method

config PLATFORM_EC_MKBP_USE_GPIO
    bool "Use GPIO"
    help
      Select to send MKBP events via GPIO. You should define GPIO_EC_INT_L
      in gpio_map.h as output from the EC. The GPIO is used to indicate an
      event is ready for serving by the AP.

config PLATFORM_EC_MKBP_USE_HOST_EVENT
    bool "Use host event"
    help
      Select to send MKBP events via host event.

config PLATFORM_EC_MKBP_USE_GPIO_AND_HOST_EVENT
    bool "Use GPIO and host event"
    help
      MKBP events are notified by using both a GPIO and a host event.

      You should use this if you are using a GPIO to notify the AP of an MKBP
      event, and you need an MKBP event to wake the AP in suspend and the
      AP cannot wake from the GPIO.  Since you are using both a GPIO and
      a hostevent for the notification, make sure that the S0 hostevent mask
      does NOT include MKBP events.  Otherwise, you will have multiple
      consumers for a single event. However, make sure to configure the
      host event *sleep* mask in coreboot to include MKBP events. In order to
      prevent all MKBP events from waking the AP, use
      CONFIG_MKBP_EVENT_WAKEUP_MASK to filter the events.

config PLATFORM_EC_MKBP_USE_CUSTOM
    bool "Use custom method"
    help
      Select to send MKBP events using custom method. You need to define
      mkbp_set_host_active_via_custom() which is called when there's a MKBP event
      to be sent. for more about the function, refer to mkbp_event.h.

endchoice

endif # PLATFORM_EC_MKBP_EVENT

config PLATFORM_EC_PANIC
	bool "Panic output"
	default y
	help
	  Enable support for collecting and reporting panic information,
	  caused by exceptions in the EC. This can be the result of a watchdog
	  firing, a division by zero, unaligned access, stack overflow or
	  assertion failure.

	  The panic information is made available to the AP via the
	  EC_CMD_GET_PANIC_INFO host command and a 'panicinfo' console command

config PLATFORM_EC_MPU
	bool "Support Memory-Protection Unit (MPU)"
	depends on CPU_CORTEX_M && CPU_HAS_MPU
	default y
	help
	  This enables support a Memory-Protection Unit which can limit access
	  to certain areas of memory. This can be used to protect code or data
	  from being written to improve security or to find bugs.

	  It causes any code in the iram.text section to be protected when
	  system jump is disabled (see system_disable_jump()). It also stops
	  execution of the image that is not currently being executed (read-only
	  or read-write). If internal storage is used, this is achieved by not
	  allowing code execution in that area. For external storage, it
	  disallows loading any code into RAM.

if PLATFORM_EC_PANIC

config PLATFORM_EC_SOFTWARE_PANIC
	bool "Software panic"
	default y
	help
	  Sometimes the EC has bugs that are provoked by unexpected events.
	  This enables storing a panic log and halt the system for
	  software-related reasons, such as stack overflow or assertion
	  failure.

config PLATFORM_EC_CONSOLE_CMD_CRASH
	bool "Console command: crash"
	default y
	help
	  For testing purposes it is useful to be able to generation exceptions
	  to check that the panic reporting is working correctly. The enables
	  the 'crash' command which supports generating various exceptions,
	  selected by its parameter:

	     assert              - assertion failure (ASSERT() macro)
	     divzero             - division by zero
	     udivzero            - division of unsigned value by zero
	     stack (if enabled)  - stack overflow
	     unaligned           - unaligned access (e.g. word load from 0x123)
	     watchdog            - watchdog timer fired
	     hang                - infinite loop in the EC code

config PLATFORM_EC_STACKOVERFLOW
	bool "Console command: crash stack"
	depends on PLATFORM_EC_CONSOLE_CMD_CRASH
	default y
	help
	  This enables the 'stack' parameter for the 'crash' command. This
	  causes a stack overflow by recursing repeatedly while task switching.
	  This can be used to check that stack-overflow detection is working
	  as expected.

endif # PLATFORM_EC_PANIC

config PLATFORM_EC_PORT80
	bool "Port 80 support"
	default y if AP_X86 && PLATFORM_EC_POWERSEQ
	help
	  Enable the port80 module, a way to report progress of the AP's boot
	  sequence, assuming that the EC can detect these writes on the I/O
	  bus. The EC buffers calls to port_80_write() and occasionally prints
	  a message when there are new writes.

	  See here for more information:

	  https://en.wikipedia.org/wiki/Power-on_self-test#Progress_and_error_reporting

config PLATFORM_EC_POWER_BUTTON
	bool "Power-button support"
	depends on PLATFORM_EC_HOSTCMD
	help
	  Enable shimming the power button implementation and related
	  commands in platform/ec.  This is used to implement the Chromium OS
	  shutdown sequence.

	  This requires a GPIO named GPIO_POWER_BUTTON_L in gpio_map.h.

config PLATFORM_EC_PWM
	bool "PWM (Pulse Width Modulation) module"
	help
	  Enable the PWM (Pulse Width Modulation) module. This module is used to
	  support variable brightness LEDs, backlight controls, and
	  variable-speed fans.

config PLATFORM_EC_RTC
	bool "Real-time clock (RTC)"
	default y
	help
	  Enable support for a real-time clock. Typically this is available
	  on-chip in the EC. It provides a way to track the passage of time
	  in terms of second and minutes. Once set, and provided that it has a
	  suitable power source, it should be able to keep reasonably accurate
	  time over a period of days and weeks.

	  The starting EC clock is typically set by the AP, since it has access
	  to the outside world and can often obtain the current time when
	  desired.

if PLATFORM_EC_RTC

config PLATFORM_EC_CONSOLE_CMD_RTC
	bool "Console command: rtc"
	default y
	help
	  This command allows getting and setting the current RTC value. The
	  value is in seconds since the Epoch (midnight on 1/1/70). You can
	  convert this to a human date on the command line with 'date -u -d @n'
	  where n is the numeric value. To convert a time to seconds, use:

	     date -d '1970-01-01 UTC + n seconds'

config PLATFORM_EC_CONSOLE_CMD_RTC_ALARM
	bool "Console command: rtc_alarm"
	depends on PLATFORM_EC_CONSOLE_CMD_RTC
	default y
	help
	  This command supports setting a real-time-clock (RTC) alarm that
	  causes an interrupt when the timer reaches that point. To set the
	  alarm:

	     rtc <sec> [<usec>]

	  where:
	    <sec> is the number of seconds since the epoch
	    <usec> is the optional number of microseconds (fractional seconds)

config PLATFORM_EC_HOSTCMD_RTC
	bool "Host command: EC_CMD_RTC_GET_VALUE etc."
	depends on PLATFORM_EC_HOSTCMD
	default y
	help
	  Enables support for EC_CMD_RTC_GET_VALUE, EC_CMD_RTC_SET_VALUE,
	  EC_CMD_RTC_GET_ALARM and EC_CMD_RTC_SET_ALARM which colectively allow
	  the AP to control the EC's real-time-clock. The AP typically makes
	  use of the EC's RTC to avoid needing a discrete RTC chip on the board.

endif # PLATFORM_EC_RTC

choice "SHA256 method"
	prompt "Select method to use for computing SHA256 hashes"
	help
	  The verified boot mechanism requests the hash of the entire read-write
	  portion of the EC image. This is typically done using a hashing block
	  in the EC, so that it is as fast as possible. A fallback software
	  algorithm is available if needed.

config PLATFORM_EC_SHA256_SW
	bool "Compute SHA256 in software"
	help
	  Enable this if your EC chip does not support hardware-accelerated
	  SHA256 computation. This enables the software algorithm which is
	  quite slow but will work in a pinch.

config PLATFORM_EC_SHA256_HW_ACCELERATE
	bool "Compute SHA256 in hardware"
	help
	  Enable this if your EC chip supports hardware-accelerated SHA256
	  computation. This is faster than running the algorithm in software,
	  so is desirable.

	  The chip support must implement the functions in sha256.h

endchoice # SHA256 method

config PLATFORM_EC_CONSOLE_CMD_SHMEM
	bool "Console command: shmem"
	default y
	help
	  This command prints basic information about the EC shared memory,
	  located at the top of RAM, above all RAM symbols: total size, bytes
	  used and the maximum number of bytes that have been used since
	  the EC started running.

config PLATFORM_EC_SWITCH
	bool "Memory mapped switches"
	depends on PLATFORM_EC_HOSTCMD
	default y
	help
	  Enable the reporting of the platform switches state to the AP using
	  memory mapped storage provided by the host command interface.

	  The platform switches include:
	    LID open
	    power button pressed
	    write protect disabled
	    recovery switch

          This also enables the "mmapinfo" console command to report the current
          state of all switches.

config PLATFORM_EC_THROTTLE_AP
	bool "CPU throttling"
	default y if PLATFORM_EC_POWERSEQ
	help
	  Enable throttling the CPU based on the temperature sensors. When they
	  detect that the CPU is getting too hot, the CPU is throttled to
	  a lower speed. This reduce the CPU's power output and eventually
	  results in a lower temperature.

if PLATFORM_EC_THROTTLE_AP

# TODO(b/177676794): Add the CONFIG_THROTTLE_AP_ON_... options

config PLATFORM_EC_CHIPSET_CAN_THROTTLE
	bool "CPU can support throttling"
	default y
	help
	  Indicates that the SoC supports throttling. This means that a
	  chipset_throttle_cpu() function is provided by the chipset, to be
	  called to set the throttle state. The typical implementation asserts
	  GPIO_CPU_PROCHOT, to make the CPU slow down.

config PLATFORM_EC_CONSOLE_CMD_APTHROTTLE
	bool "Console command: apthrottle"
	default y
	help
	  This command shows the current status of AP throttling. Both soft
	  (type 0) and hard (type 1) throttling are supported. Soft throttling
	  is typically controlled by the AP via a host event. Hard throttling
	  typically uses the PROCHOT (Processor Hot) signal on x86 CPUs.

	  Example output:

	     AP throttling type 0 is off (0x00000000)
	     AP throttling type 1 is off (0x00000000)

endif # PLATFORM_EC_THROTTLE_AP

menuconfig PLATFORM_EC_TIMER
	bool "Timer module"
	default y
	help
	  Enable compilation of the EC timer module. This provides support for
	  delays, getting the current time and setting alarms.

	  This option is needed by many features in the EC. Disabling it will
	  likely cause build errors.

if PLATFORM_EC_TIMER

config PLATFORM_EC_CONSOLE_CMD_GETTIME
	bool "Console command: gettime"
	default y
	help
	  Enable the "gettime" command. This shows the current time (in
	  microseconds since boot) in both hex and in decimal converted to
	  seconds. For example:

	     Time: 0x0000000002706a62 = 40.921698 s


config PLATFORM_EC_CONSOLE_CMD_TIMERINFO
	bool "Console command: timerinfo"
	default y
	help
	  Enable the "timerinfo" command which shows the current time (in
	  microseconds and seconds since boot), the deadline (next time the EC
	  needs to wake up) and a list of active timers along with when they
	  will next fire.

	  Example:

	    Time:     0x0000000002706a62 us,   40.921698 s
	    Deadline: 0x000000000270774d ->    0.003307 s from now
	    Active timers:
	      Tsk  1  0x000000000271db8f ->    0.094509
	      Tsk  4  0x00000000027396b3 ->    0.207953
	      Tsk 13  0x00000000027133a1 ->    0.051519


config PLATFORM_EC_CONSOLE_CMD_WAITMS
	bool "Console command: waitms"
	default y
	help
	  Enable the "waitms" command. This waits for a given number of
	  milliseconds. For example:

	    waitms 100

	  waits for 100ms. Note that long waits can introduce problems since
	  it stops the EC from executing its normal tasks. For example, a
	  two-second wait can cause the EC to reset.

endif # PLATFORM_EC_TIMER

config PLATFORM_EC_VBOOT_HASH
	bool "Host command: EC_CMD_VBOOT_HASH"
	depends on PLATFORM_EC_HOSTCMD
	default y
	help
	  Allows the AP to request hashing functions from the EC.

	  Verified boot can update the EC's read/write code when it detects
	  that it is an incorrect version. It detects this by asking the EC to
	  hash itself. If the hash is incorrect, new code is write to the EC's
	  read/write area.

config PLATFORM_EC_VSTORE
	bool "Secure temporary storage for verified boot"
	default y
	help
	  Enable support for storing a block of data received from the AP so it
	  can be read back later by the AP. This is helpful since the AP may
	  reboot or resume and want the data early in its start-up before it
	  has access to SDRAM.

	  There are a fixed number of slots and each can hold a fixed amount of
	  data (EC_VSTORE_SLOT_SIZE bytes). Once a slot is written it is locked
	  and cannot be written again unless explicitly unlocked.

	  Stored data is preserved when the EC moved from RO to RW.

config PLATFORM_EC_VSTORE_SLOT_COUNT
	int "Number of slots"
	depends on PLATFORM_EC_VSTORE
	default 1
	help
	  Set the number of slots available in the verified-boot store. The
	  number required depends on the AP firmware. Typically the vstore is
	  used only for recording a hash of the read-write AP firmware for
	  checking on resume. For this, one slot is enough.

config PLATFORM_EC_SYSTEM_UNLOCKED
	bool "System unlocked: allow dangerous commands while in development"
	default y if PLATFORM_EC_BRINGUP
	help
	  System should remain unlocked even if write protect is enabled.

	  NOTE: This should ONLY be defined during bringup, and should never be
	  defined on a shipping / released platform.

	  When defined, CBI allows ectool to reprogram all the fields.
	  Normally, it refuses to change certain fields. (e.g. board version,
	  OEM ID)

	  Also, this enables PD in RO for TCPMv2.

menuconfig PLATFORM_EC_WATCHDOG
	bool "watchdog"
	depends on WATCHDOG
	default y
	help
	  Enable the watchdog functionality. The watchdog timer will reboot the
	  system if the hook task (which is the lowest-priority task on the
	  system) gets starved for CPU time and isn't able to fire its
	  HOOK_TICK event.

if PLATFORM_EC_WATCHDOG

config PLATFORM_EC_WATCHDOG_PERIOD_MS
	int "Watchdog timeout in ms"
	default 1600
	help
	  Set the timeout of the watchdog timer. The watchdog timer reboots
	  the system if no one reloads the watchdog timer before the timeout.
	  The interval between reloads of the watchdog timer should be less than
	  half of the watchdog period.

endif # PLATFORM_EC_WATCHDOG

endif # PLATFORM_EC