diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.JFFS2 | 3 | ||||
| -rw-r--r-- | doc/README.omap-reset-time | 20 | ||||
| -rw-r--r-- | doc/README.x86 | 24 | ||||
| -rw-r--r-- | doc/uImage.FIT/howto.txt | 21 | ||||
| -rw-r--r-- | doc/uImage.FIT/multi_spl.its | 89 |
5 files changed, 131 insertions, 26 deletions
diff --git a/doc/README.JFFS2 b/doc/README.JFFS2 index 604e5b9686..0245da0488 100644 --- a/doc/README.JFFS2 +++ b/doc/README.JFFS2 @@ -10,6 +10,9 @@ fsinfo - print information about file systems ls - list files in a directory chpart - change active partition +If you do now need the commands, you can enable the filesystem separately +with CONFIG_FS_JFFS2 and call the jffs2 functions yourself. + If you boot from a partition which is mounted writable, and you update your boot environment by replacing single files on that partition, you should also define CONFIG_SYS_JFFS2_SORT_FRAGMENTS. Scanning diff --git a/doc/README.omap-reset-time b/doc/README.omap-reset-time deleted file mode 100644 index 0c974bacae..0000000000 --- a/doc/README.omap-reset-time +++ /dev/null @@ -1,20 +0,0 @@ -README on how reset time on OMAPs should be calculated - -CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC: -Most OMAPs' provide a way to specify the time for -which the reset should be held low while the voltages -and Oscillator outputs stabilize. - -This time is mostly board and PMIC dependent. Hence the -boards are expected to specify a pre-computed time -using the above option, (the details on how to compute -the value are given below) without which a default time -as specified by CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC -is used. - -The value for CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC -can be computed using a summation of the below 3 parameters --1- Time taken by the Osciallator to stop and restart --2- PMIC OTP time --3- Voltage ramp time, which can be derived using the -PMIC slew rate and value of voltage ramp needed. diff --git a/doc/README.x86 b/doc/README.x86 index a38cc1bc6c..c69dc1c511 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1014,12 +1014,12 @@ compile ACPI DSDT table written in ASL format to AML format. You can get the compiler via "apt-get install iasl" if you are on Ubuntu or download the source from [17] to compile one by yourself. -Current ACPI support in U-Boot is not complete. More features will be added -in the future. The status as of today is: +Current ACPI support in U-Boot is basically complete. More optional features +can be added in the future. The status as of today is: * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables. * Support one static DSDT table only, compiled by Intel ACPI compiler. - * Support S0/S5, reboot and shutdown from OS. + * Support S0/S3/S4/S5, reboot and shutdown from OS. * Support booting a pre-installed Ubuntu distribution via 'zboot' command. * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with the help of SeaBIOS using legacy interface (non-UEFI mode). @@ -1027,9 +1027,6 @@ in the future. The status as of today is: of SeaBIOS using legacy interface (non-UEFI mode). * Support ACPI interrupts with SCI only. -Features not supported so far (to make it a complete ACPI solution): - * S3 (Suspend to RAM), S4 (Suspend to Disk). - Features that are optional: * Dynamic AML bytecodes insertion at run-time. We may need this to support SSDT table generation and DSDT fix up. @@ -1046,6 +1043,21 @@ command from the OS. For other platform boards, ACPI support status can be checked by examining their board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y. +The S3 sleeping state is a low wake latency sleeping state defined by ACPI +spec where all system context is lost except system memory. To test S3 resume +with a Linux kernel, simply run "echo mem > /sys/power/state" and kernel will +put the board to S3 state where the power is off. So when the power button is +pressed again, U-Boot runs as it does in cold boot and detects the sleeping +state via ACPI register to see if it is S3, if yes it means we are waking up. +U-Boot is responsible for restoring the machine state as it is before sleep. +When everything is done, U-Boot finds out the wakeup vector provided by OSes +and jump there. To determine whether ACPI S3 resume is supported, check to +see if CONFIG_HAVE_ACPI_RESUME is set for that specific board. + +Note for testing S3 resume with Windows, correct graphics driver must be +installed for your platform, otherwise you won't find "Sleep" option in +the "Power" submenu from the Windows start menu. + EFI Support ----------- U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. diff --git a/doc/uImage.FIT/howto.txt b/doc/uImage.FIT/howto.txt index 14e316f72c..2988a52aa1 100644 --- a/doc/uImage.FIT/howto.txt +++ b/doc/uImage.FIT/howto.txt @@ -44,6 +44,27 @@ image source file mkimage + dtc transfer to target + ---------------> image file --------------------> bootm image data file(s) +SPL usage +--------- + +The SPL can make use of the new image format as well, this traditionally +is used to ship multiple device tree files within one image. Code in the SPL +will choose the one matching the current board and append this to the +U-Boot proper binary to be automatically used up by it. +Aside from U-Boot proper and one device tree blob the SPL can load multiple, +arbitrary image files as well. These binaries should be specified in their +own subnode under the /images node, which should then be referenced from one or +multiple /configurations subnodes. The required images must be enumerated in +the "loadables" property as a list of strings. + +If a platform specific image source file (.its) is shipped with the U-Boot +source, it can be specified using the CONFIG_SPL_FIT_SOURCE Kconfig symbol. +In this case it will be automatically used by U-Boot's Makefile to generate +the image. +If a static source file is not flexible enough, CONFIG_SPL_FIT_GENERATOR +can point to a script which generates this image source file during +the build process. It gets passed a list of device tree files (taken from the +CONFIG_OF_LIST symbol). Example 1 -- old-style (non-FDT) kernel booting ----------------------------------------------- diff --git a/doc/uImage.FIT/multi_spl.its b/doc/uImage.FIT/multi_spl.its new file mode 100644 index 0000000000..e5551d42b7 --- /dev/null +++ b/doc/uImage.FIT/multi_spl.its @@ -0,0 +1,89 @@ +/dts-v1/; + +/* + * (Bogus) example FIT image description file demonstrating the usage + * of multiple images loaded by the SPL. + * Several binaries will be loaded at their respective load addresses. + * Finally the one image specifying an entry point will be entered by the SPL. + */ + +/ { + description = "multiple firmware blobs and U-Boot, loaded by SPL"; + #address-cells = <0x1>; + + images { + + uboot { + description = "U-Boot (64-bit)"; + type = "standalone"; + arch = "arm64"; + compression = "none"; + load = <0x4a000000>; + }; + + atf { + description = "ARM Trusted Firmware"; + type = "firmware"; + arch = "arm64"; + compression = "none"; + load = <0x18000>; + entry = <0x18000>; + }; + + mgmt-firmware { + description = "arisc management processor firmware"; + type = "firmware"; + arch = "or1k"; + compression = "none"; + load = <0x40000>; + }; + + fdt@1 { + description = "Pine64+ DT"; + type = "flat_dt"; + compression = "none"; + load = <0x4fa00000>; + arch = "arm64"; + }; + + fdt@2 { + description = "Pine64 DT"; + type = "flat_dt"; + compression = "none"; + load = <0x4fa00000>; + arch = "arm64"; + }; + + kernel { + description = "4.7-rc5 kernel"; + type = "kernel"; + compression = "none"; + load = <0x40080000>; + arch = "arm64"; + }; + + initrd { + description = "Debian installer initrd"; + type = "ramdisk"; + compression = "none"; + load = <0x4fe00000>; + arch = "arm64"; + }; + }; + + configurations { + default = "config@1"; + + config@1 { + description = "sun50i-a64-pine64-plus"; + loadables = "uboot", "atf", "kernel", "initrd"; + fdt = "fdt@1"; + }; + + config@2 { + description = "sun50i-a64-pine64"; + loadables = "uboot", "atf", "mgmt-firmware"; + fdt = "fdt@2"; + }; + }; +}; |