GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/src/cpu/Makefile.inc

52 lines
1.9 KiB
PHP
Raw Normal View History

buildsystem: Make CPU microcode updating more configurable This patch aims to improve the microcode in CBFS handling that was brought by the last patches from Stefan and the Chromium team. Choices in Kconfig - 1) Generate microcode from tree (default) - 2) Include external microcode file - 3) Do not put microcode in CBFS The idea is to give the user full control over including non-free blobs in the final ROM image. MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode is handled by a special class, cpu_microcode, as such: cpu_microcode-y += microcode_file.c MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is needed by intel microcode updating. Once all intel cpus are converted to cbfs updating, this variable can go away. These files are then compiled and assembled into a binary CBFS file. The advantage of doing it this way versus the current method is that 1) The rule is CPU-agnostic 2) Gives user more control over if and how to include microcode blobs 3) The rules for building the microcode binary are kept in src/cpu/Makefile.inc, and thus would not clobber the other makefiles, which are already overloaded and very difficult to navigate. Change-Id: I38d0c9851691aa112e93031860e94895857ebb76 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/1245 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-07-20 07:11:21 +02:00
################################################################################
## Subdirectories
################################################################################
cpu: Add initial support for Allwinner A10 SoC Add minimal support needed to get a bootblock capable of initialising a serial console. Change-Id: I50dd85544549baf9c5ea0aa3b4296972136c02a4 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/4549 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-12-14 03:44:48 +01:00
subdirs-y += allwinner
This now builds. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4537 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-12 17:56:17 +02:00
subdirs-y += amd
Add initial support for DMP Vortex86EX CPU. Change-Id: I74de250c69a57109362be1b2f00c0b4aa24a64e8 Signed-off-by: Andrew Wu <arw@dmp.com.tw> Reviewed-on: http://review.coreboot.org/3473 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-19 12:55:08 +02:00
subdirs-y += dmp
armv7: Add emulation/qemu-armv7 board. To simplify testing ARM implementation, we need a QEMU configuration for ARM. The qemu-armv7 provides serial output, CBFS simulation, and full boot path (bootblock, romstage, ramstage) to verify the boot loader functionality. To run with QEMU: export QEMU_AUDIO_DRV=none qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom Verified to boot until ramstage loaded successfully by QEMU v1.0.50. Change-Id: I1f23ffaf408199811a0756236821c7e0f2a85004 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2354 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-11 17:07:38 +01:00
subdirs-y += armltd
imgtec/danube: Add support for ImgTec Danube SoC Add build infrastructure and basic support code for the ImgTec Danube SoC. This support is sufficient to run on a simulator. BUG=chrome-os-partner:31438 TEST=none yet Change-Id: I59e36589765bf06b075fd4850215a0ef71246bb1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 881278d7fbb8e6803bc8f6f9e84c64640b097401 Original-Change-Id: Ia7ed7288b13085db7ff37b5ad75d978b6137f958 Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com> Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/207974 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8762 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-06-14 01:08:02 +02:00
subdirs-y += imgtec
Kconfig! Works on Kontron, qemu, and serengeti. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> tested on abuild only. Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-12 17:00:51 +02:00
subdirs-y += intel
beaglebone: initial Kconfig and Makefiles Initial structure of Beaglebone port Change-Id: Ia255ab207f424dcd525990cdc0d74953e012c087 Signed-off-by: David Hendricks <dhendrix@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3279 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-26 16:15:57 +02:00
subdirs-y += ti
Kconfig! Works on Kontron, qemu, and serengeti. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> tested on abuild only. Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-12 17:00:51 +02:00
subdirs-y += via
x86: add cache-as-ram migration option There are some boards that do a significant amount of work after cache-as-ram is torn down but before ramstage is loaded. For example, using vboot to verify the ramstage is one such operation. However, there are pieces of code that are executed that reference global variables that are linked in the cache-as-ram region. If those variables are referenced after cache-as-ram is torn down then the values observed will most likely be incorrect. Therefore provide a Kconfig option to select cache-as-ram migration to memory using cbmem. This option is named CAR_MIGRATION. When enabled, the address of cache-as-ram variables may be obtained dynamically. Additionally, when cache-as-ram migration occurs the cache-as-ram data region for global variables is copied into cbmem. There are also automatic callbacks for other modules to perform their own migration, if necessary. Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3232 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-10 07:33:32 +02:00
subdirs-y += x86
qemu: add x86 cpu This patch adds a qemu x86 cpu chip. It has no initialization function as this isn't needed on virtual hardware. A virtual machine can have pretty much any CPU: qemu emulates a wide range of x86 CPUs (try 'qemu -cpu ? for a list), also with 'qemu -cpu host' the guest will see a cpu which is (almost) identical to the one on the host machine. So I've added X86_VENDOR_ANY as wildcard match for the cpu_table. Change-Id: Ib01210694b09702e41ed806f31d0033e840a863f Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-on: http://review.coreboot.org/3344 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-31 09:23:26 +02:00
subdirs-$(CONFIG_CPU_QEMU_X86) += qemu-x86
buildsystem: Make CPU microcode updating more configurable This patch aims to improve the microcode in CBFS handling that was brought by the last patches from Stefan and the Chromium team. Choices in Kconfig - 1) Generate microcode from tree (default) - 2) Include external microcode file - 3) Do not put microcode in CBFS The idea is to give the user full control over including non-free blobs in the final ROM image. MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode is handled by a special class, cpu_microcode, as such: cpu_microcode-y += microcode_file.c MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is needed by intel microcode updating. Once all intel cpus are converted to cbfs updating, this variable can go away. These files are then compiled and assembled into a binary CBFS file. The advantage of doing it this way versus the current method is that 1) The rule is CPU-agnostic 2) Gives user more control over if and how to include microcode blobs 3) The rules for building the microcode binary are kept in src/cpu/Makefile.inc, and thus would not clobber the other makefiles, which are already overloaded and very difficult to navigate. Change-Id: I38d0c9851691aa112e93031860e94895857ebb76 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/1245 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-07-20 07:11:21 +02:00
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
$(eval $(call create_class_compiler,cpu_microcode,x86_32))
buildsystem: Make CPU microcode updating more configurable This patch aims to improve the microcode in CBFS handling that was brought by the last patches from Stefan and the Chromium team. Choices in Kconfig - 1) Generate microcode from tree (default) - 2) Include external microcode file - 3) Do not put microcode in CBFS The idea is to give the user full control over including non-free blobs in the final ROM image. MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode is handled by a special class, cpu_microcode, as such: cpu_microcode-y += microcode_file.c MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is needed by intel microcode updating. Once all intel cpus are converted to cbfs updating, this variable can go away. These files are then compiled and assembled into a binary CBFS file. The advantage of doing it this way versus the current method is that 1) The rule is CPU-agnostic 2) Gives user more control over if and how to include microcode blobs 3) The rules for building the microcode binary are kept in src/cpu/Makefile.inc, and thus would not clobber the other makefiles, which are already overloaded and very difficult to navigate. Change-Id: I38d0c9851691aa112e93031860e94895857ebb76 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/1245 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-07-20 07:11:21 +02:00
################################################################################
## Rules for building the microcode blob in CBFS
################################################################################
# External microcode file, or are we generating one ?
ifeq ($(CONFIG_CPU_MICROCODE_CBFS_EXTERNAL), y)
cpu: Add CPU microcode file to cbfs with 16-byte alignment On x86 there is a 16-byte alignment requirement for the addresses containing the CPU microcode. The cbfs files containing the microcode are used in memory-mapped fashion when loading new mircocode. Therefore, the data payload's address/offset of a cbfs file in flash dictates the resulting alignment. Fix this by processing the CPU microcode cbfs file separately as it uses $(CBFSTOOL) to find the proper location within the provided rom image. Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3663 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-11 23:36:37 +02:00
cpu_ucode_cbfs_file = $(call strip_quotes,$(CONFIG_CPU_MICROCODE_FILE))
cbfs_include_ucode = y
Fix microcode selection code The ARM CPUs we know of don't have CPU microcode updates, so don't show the selection in Kconfig. Also simplify (and fix) the microcode selection in the Makefile that would try to include microcode even though none is available. Change-Id: I502d9b48d4449c1a759b5e90478ad37eef866406 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2540 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-02-27 20:24:11 +01:00
endif
ifeq ($(CONFIG_CPU_MICROCODE_CBFS_GENERATE), y)
cpu: Add CPU microcode file to cbfs with 16-byte alignment On x86 there is a 16-byte alignment requirement for the addresses containing the CPU microcode. The cbfs files containing the microcode are used in memory-mapped fashion when loading new mircocode. Therefore, the data payload's address/offset of a cbfs file in flash dictates the resulting alignment. Fix this by processing the CPU microcode cbfs file separately as it uses $(CBFSTOOL) to find the proper location within the provided rom image. Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3663 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-11 23:36:37 +02:00
cpu_ucode_cbfs_file = $(obj)/cpu_microcode_blob.bin
cbfs_include_ucode = y
buildsystem: Make CPU microcode updating more configurable This patch aims to improve the microcode in CBFS handling that was brought by the last patches from Stefan and the Chromium team. Choices in Kconfig - 1) Generate microcode from tree (default) - 2) Include external microcode file - 3) Do not put microcode in CBFS The idea is to give the user full control over including non-free blobs in the final ROM image. MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode is handled by a special class, cpu_microcode, as such: cpu_microcode-y += microcode_file.c MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is needed by intel microcode updating. Once all intel cpus are converted to cbfs updating, this variable can go away. These files are then compiled and assembled into a binary CBFS file. The advantage of doing it this way versus the current method is that 1) The rule is CPU-agnostic 2) Gives user more control over if and how to include microcode blobs 3) The rules for building the microcode binary are kept in src/cpu/Makefile.inc, and thus would not clobber the other makefiles, which are already overloaded and very difficult to navigate. Change-Id: I38d0c9851691aa112e93031860e94895857ebb76 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/1245 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-07-20 07:11:21 +02:00
endif
cpu: microcode: Use microcode stored in binary format Using a copiler to compile something that's already a binary is pretty stupid. Now that Stefan converted most microcode in blobs to a plain binary, use the binary version. Change-Id: Iecf1f0cdf7bbeb7a61f46a0cd984ba341af787ce Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/11607 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-10 07:38:06 +02:00
# We just mash all microcode binaries together into one binary to rule them all.
# This approach assumes that the microcode binaries are properly padded, and
# their headers specify the correct size. This works fairly well on isolatied
# updates, such as Intel and some AMD microcode, but won't work very well if the
# updates are wrapped in a container, like AMD's microcode update container. If
# there is only one microcode binary (i.e. one container), then we don't have
# this issue, and this rule will continue to work.
$(obj)/cpu_microcode_blob.bin: $$(cpu_microcode_bins)
armv7/Makefile.inc, cpu/Makefile.inc: align output of printf Fix whitespace. Change-Id: I9e28b819d685851a84cee6c5a71458e07d0ec808 Signed-off-by: Daniele Forsi <dforsi@gmail.com> Reviewed-on: http://review.coreboot.org/6577 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-08-10 15:18:42 +02:00
@printf " MICROCODE $(subst $(obj)/,,$(@))\n"
cpu: microcode: Use microcode stored in binary format Using a copiler to compile something that's already a binary is pretty stupid. Now that Stefan converted most microcode in blobs to a plain binary, use the binary version. Change-Id: Iecf1f0cdf7bbeb7a61f46a0cd984ba341af787ce Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/11607 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-10 07:38:06 +02:00
@echo $(cpu_microcode_bins)
cat $+ > $@
cpu: Add CPU microcode file to cbfs with 16-byte alignment On x86 there is a 16-byte alignment requirement for the addresses containing the CPU microcode. The cbfs files containing the microcode are used in memory-mapped fashion when loading new mircocode. Therefore, the data payload's address/offset of a cbfs file in flash dictates the resulting alignment. Fix this by processing the CPU microcode cbfs file separately as it uses $(CBFSTOOL) to find the proper location within the provided rom image. Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3663 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-11 23:36:37 +02:00
microcode: Unify rules to add microcode to CBFS once again Now that cbfstool supports file alignment, we can use the conveniently available <filename>-align handler, and remove the need to have a separate rule in src/Makefile.inc just for adding the microcode. We can also get rid of the layering violation of having the CONFIG_PLATFORM_USES_FSP1_0 symbol in a generic src/cpu/ makefile. Note that we still have a layering violation by the use of the CONFIG_CPU_MICROCODE_CBFS_LOC symbol, but this one is acceptable for the time being. Change-Id: Id2f8c15d250a0c75300d0a870284cac0c68a311b Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/11526 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-07 09:35:55 +02:00
cbfs-files-$(cbfs_include_ucode) += cpu_microcode_blob.bin
cpu_microcode_blob.bin-file := $(cpu_ucode_cbfs_file)
cpu_microcode_blob.bin-type := microcode
ifneq ($(CONFIG_CPU_MICROCODE_CBFS_LOC),)
cpu_microcode_blob.bin-position := $(CONFIG_CPU_MICROCODE_CBFS_LOC)
cpu: Add CPU microcode file to cbfs with 16-byte alignment On x86 there is a 16-byte alignment requirement for the addresses containing the CPU microcode. The cbfs files containing the microcode are used in memory-mapped fashion when loading new mircocode. Therefore, the data payload's address/offset of a cbfs file in flash dictates the resulting alignment. Fix this by processing the CPU microcode cbfs file separately as it uses $(CBFSTOOL) to find the proper location within the provided rom image. Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3663 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-11 23:36:37 +02:00
else
microcode: Unify rules to add microcode to CBFS once again Now that cbfstool supports file alignment, we can use the conveniently available <filename>-align handler, and remove the need to have a separate rule in src/Makefile.inc just for adding the microcode. We can also get rid of the layering violation of having the CONFIG_PLATFORM_USES_FSP1_0 symbol in a generic src/cpu/ makefile. Note that we still have a layering violation by the use of the CONFIG_CPU_MICROCODE_CBFS_LOC symbol, but this one is acceptable for the time being. Change-Id: Id2f8c15d250a0c75300d0a870284cac0c68a311b Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/11526 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-07 09:35:55 +02:00
cpu_microcode_blob.bin-align := 16
cpu: Add CPU microcode file to cbfs with 16-byte alignment On x86 there is a 16-byte alignment requirement for the addresses containing the CPU microcode. The cbfs files containing the microcode are used in memory-mapped fashion when loading new mircocode. Therefore, the data payload's address/offset of a cbfs file in flash dictates the resulting alignment. Fix this by processing the CPU microcode cbfs file separately as it uses $(CBFSTOOL) to find the proper location within the provided rom image. Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3663 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-11 23:36:37 +02:00
endif