Flash-N-Go Boot– Release Notes

Content

Flash-N-Go Boot – Release Notes

Content

1Device description

2Change history

2.1Changes from version V10.0 to V11.0

2.2Changes from version V9.0 to V10.0

2.3Changes from version V8.0 to V9.0

2.4Changes from version V7.0 to V8.0

2.5Changes from version V6.0 to V7.0

2.6Changes from version V5.0 to V6.0

2.7Changes from version V4.0 to V5.0

2.8Changes from version V3.0 to V4.0

2.9Changes from version V2.0 to V3.0

2.10Changes from version V1.0 to V2.0

2.11Changes from version V0.1 to V1.0

2.12Changes from version V0.0 to V0.1

3Known restrictions in current version

4Test Devices

5Features List

5.1Serial Diagnostic Port

5.2Support for different RAM supply voltages

5.3SD-/MMC-Support

5.4Partition-/Filesystem Support

5.5Boot-Mode Support

5.6CFG-File Commands

5.7GF Versioning

6License

1Device description

BL Version/Milestone / V11.0r3603
Release Date / 11.05.2017
SupportedHardware / SANTARO x1/x2l/x2/x4 V1.0/V1.1/V1.1.1/V1.2
SANTOKA x1/x2l/x2/x4 V1.0/V1.1/V1.2/V1.2.1/V1.2.2
SANTINO x1/x2l V1.0/V1.1
SANTINO LT x1/x2l V1.0/V1.1
SDC-CSPU V1.0/V1.1/V1.2/V1.3
SANTvend V1.0/V1.1
HYDRA V1.0
Freescale Sabre SD i.MX6
Released by / Marc-Oliver Westerburg
Verified by / Nils Grimm
Common information / Regular production release supporting all Garz & Fricke i.MX6-based systems (some features still missing, though; see Known Restrictions).

2Change history

2.1Changes from version V10.0 to V11.0

  • Added support for detection board revisions 1.3 and 1.4 (# 22591)
  • Added support for SANTvend “Outdoor” and “Netzbetrieb” PFIDs (#22907)
  • Added support for SANTvend Rev. 1.1 boards with DDR3 RAM and PFUZE1000 PMIC (#22907)
  • Added support for 4 GB RAM (#7443)
  • Fixed support for FSL Sabre Board (#22942)
  • Added support for installation from local directory (instead of TFTP) (#21265)

2.2Changes from version V9.0 to V10.0

  • Renamed “Vending Touch” to “SANTvend” (#19661)
  • Added support for HYDRA platform (#20973)
  • Added initial support for i.MX6-Plus SoC-Versions (#20138)
  • Fixed DDR3 timing for MRW-commands (writing to DDR3 configuration registers) (#20155)
  • Enabled bank-interleaving in DRAM-controller for improved OS-performance; esp. video-playback (#21137)

2.3Changes from version V8.0 to V9.0

  • Added support for LPDDR2 RAM initialization (#16865)
  • Added support for VENDING-TOUCH platform (#16864)
  • Added very simple memory “dump”-command for debugging purposes (#17340)
  • Fixed L2 cache-flushing before jumping to OS-image (#17444)

2.4Changes from version V7.0 to V8.0

  • Added support for 1.35V DDR3L RAM supply voltage on all Garz & Fricke i.MX6 boards (#11726)
  • Added partial support for 16-Bit DDR3 RAM interface (#12557)
  • DQS-gating is still not working in 16-Bit mode (#13649)

2.5Changes from version V6.0 to V7.0

  • Added support for SANTINO/SANTINO LT platform (#11757)
  • Added support for Freescale Sabre SD platform (#7441)
  • Fixed size determination on non-zero-terminated files (#7439)
  • Fixed MBR and FAT extended partition detection (#7435)

2.6Changes from version V5.0 to V6.0

  • Added support for SANTOKA platform (#1118)
  • Added support for 32-Bit wide DRAM on multicore SoCs (#1111)
  • Added support for new “devtree”-command to make loading of Linux kernel device-tree easier (#1118)
  • Replaced pseudo-error messages from DRAM calibration functions with more useful, always present status outputs (#1111)
  • Added GPLv2 license to source-tree (#1038)

2.7Changes from version V4.0 to V5.0

  • Implemented working DDR3 RAM write-delay line calibration not working at all in previous version (#1082)
  • Fixed automatic DDR3 RAM calibration routines on devices with 64-bit RAM interface (#1083)
  • Finished proper DDR3 timing configuration on all devices (#1085)
  • Fixed bugs in “load”-commands, which in some cases failed silently in previous versions (#1100)
  • Added support for SDC-CSPU platform

2.8Changes from version V3.0 to V4.0

  • Enabled L2-Cache support (#1084)
  • Updated DRAM drive-strength and termination settings for improved signal quality and EMI compliance (#1033)
  • Improved test-functions to more closely resemble typical OS-environment allowing better error detection (#1093)

2.9Changes from version V2.0 to V3.0

  • Fixed I2C-configuration on SANTARO x1 (for boot-select script to work) (#1090)

2.10Changes from version V1.0 to V2.0

  • Added automatic RAM size detection. Due to available hardware currently only tested with 1 GB x 64 Bit on SANTARO x2/x4 and 512 MB x 32 Bit on SANTARO x1, but other RAM configurations should also work now (#1033)
  • Added support for SANTARO x1 using i.MX6Solo (#1039)
  • Added testbench and testram commands (#1033)
  • Added support for starting Flash-n-Go Boot directly via Freescale’s USB MfgTool (#1081)

2.11Changes from version V0.1 to V1.0

  • Added support for switching between different boot partitions (#1036)

2.12Changes from version V0.0 to V0.1

  • Initial implementation based on U-Boot 2009-08 (#1029, #1030)
  • Boot-partitions on eMMC are supported (#1041)
  • Name changed from internal project name to “Flash-N-Go Boot” / ”FNGBoot” (#1043)
  • Several performance improvements to get the SD-/MMC-load performance from initially ~1.5 MB/s to currently 9.0 – 12 MB/s depending on card/eMMC-speed. (refs #1035)

3Known restrictions in current version

  • Currently huge loads of debugging messages are output on the serial diag-port with no way of turning these off. Future releases will by default not output any messages to the serial port and provide a command to enable some debugging messages via its configuration file. (#7343)
  • Load performance from storage media is currently not optimized. Even with fast cards or the internal eMMC on SANTARO, which support significantly higher speeds, only at most about 14-16 MB/s load performance can be achieved currently. This will be improved in future releases (#7341).
  • Currently no verification of loaded images is supported. Future release will support optional MD5 checksums. (#7348)
  • DQS-Gating in DDR3 RAM-initialization is currently not working for 16-Bit RAM interface (#13649)

4Test Devices

Device(s):

S/N / Art.Nr. / Type / SoC / RAM / eMMC
1 / 01340156 / 900-2474R / SANTARO x1 V1.1 / i.MX6S / 1.50V 512MB DDR3 32B / 4GB JW808
2 / 01708201 / 900-3048R / SANTARO x4 V1.2 / i.MX6Q / 1.35V 1GB DDR3 64B / 4GB JWA57
3 / 01937126 / 900-3529R / SANTOKA x1 V1.2.1 / i.MX6S / 1.35V 1GB DDR3 32B / 4GB THGBM
4 / 01618696 / 900-2994R / SANTOKA x2l V1.0 / i.MX6DL / 1.50V 1GB DDR3 32B / 4GB JW808
5 / 01849570 / 900-3393R / SANTOKA x4P V1.2 / i.MX6QP / 1.35V 4GB DDR3 64B / 8GB JY995
6 / 01754645 / 900-3245R / SANTINO x1 V1.0 / i.MX6S / 1.35V 512MB DDR3 32B / 4GB JWA57
7 / 01910276 / 900-3361R / SANTINO-LT x1 V1.1 / i.MX6S / 1.35V 512MB DDR3 32B / 4GB JWA57
8 / 01569668 / 900-2844R / SDC-CSPU V1.0 / i.MX6D / 1.50V 1GB DDR3 64B / 4GB JW808
9 / 01887924 / 900-3420R / HYDRA V1.0 / 2 i.MX6Q / 1.35V 1GB/256MB DDR3 64/16B / 4GB JWA57
10 / 01825664 / 921-0315R / SANTvend V1.0 / i.MX6S / 1.20V 1GB LPDDR2 32B / 4GB JWA57
11 / 01947965 / 921-0357R / SANTvend V1.1 / i.MX6D / 1.35V 2GB DDR3 32B / 4GB JY976

Peer: Dell Vostro Intel Core i7-2600 @3.4 GHz, 8 GB RAM, RS-232 Null-Modem connection to test device(s)

5Features List

5.1Serial Diagnostic Port

Features

  • (intended) Completely disabled by default and for regular field use
  • (intended) Can be enabled via configuration file
  • Provides diagnostic information on the system and executed steps
  • Runs at 115200 baud, 8 bits, 1 stop-bit, no parity, no hand-shake

Performed Tests

Description / Dev / Version / Author / Status
Debugging output on serial port at 115200 baud, 8 bits, 1 stop, no parity, no hand-shake / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
Debugging output can be disabled via configuration file / all / V11.0r3603 / MOW / Not supported
Debugging output is completely quiet by default / all / V11.0r3603 / MOW / Not supported

Notes

  • None

Known Restrictions

  • Serial debug port will currently always output lots of debugging messages with no way of turning them off.

5.2Support for different RAM supply voltages

Features

  • Lower power-consumption with lower voltages
  • Lower SoC, RAM and board temperatures
  • Identical RAM- and system-performance no matter if 1.5V DDR3 or 1.35V DDR3L RAM is used.
  • Uses (fixed) 1.20V LPDDR2 RAM supply voltage on SANTvend Rev. 1.0
  • Uses (fixed) 1.35V DDR3L RAM supply voltage on SANTINO and SANTINO-LT
  • (Semi-)auto-detects DDR3L support via configuration resistor on other Garz & Fricke i.MX6-based boards and configures RAM either to 1.5V DDR3 or 1.35V DDR3L supply voltage.

Performed Tests

Description / Dev / Version / Author / Status
Check supply-voltage debugging output on fixed DDR3L board and measure 1.35V RAM supply-voltage on board / 2, 3, 5, 6, 7, 9, 11 / V11.0r3603 / MOW / Okay
Check supply-voltage debugging output on board which supports both RAM types equipped with 1.5V DDR3 RAM and measure RAM supply-voltage on board / 1, 4, 8 / V11.0r3603 / MOW / Okay
Check supply-voltage debugging output on fixed LPDDR2 board and measure 1.2V RAM supply-voltage on board / 10 / V11.0r3603 / MOW / Okay

Notes

  • Support for this feature depends on the hardware being used:
  • SANTvend Rev. 1.0: only 1.20V LPDDR2 (supported in initial designs already).
  • SANTvend Rev. 1.1: designed for and equipped with 1.35V DDR3L (but can be equipped with 1.5V DDR3 RAM).
  • SANTINO and SANTINO-LT: only 1.35V DDR3L (supported in initial designs already)
  • SANTARO: boards and revisions produced prior to Feb. 2016 may be equipped either with 1.5V-only DDR3 RAMs or RAMs, which support both 1.5V DDR3 and 1.35V DDR3L voltages. Only in production batches for SANTARO 1.2 starting Feb. 2016 with S/N 01794356 a mechanism for telling the equipped RAM-type apart by software has been introduced into series production, therefore boards produced earlier will be operated at 1.5V DDR3 supply voltage, only. Boards produced since Feb. 2016 will usually be equipped with 1.35V DDR3L supply voltage configuration.
  • SANTOKA Rev. 1.2 and newer and all HYDRA revisions are usually equipped with 1.35V DDR3L RAM. All revisions support and can be equipped with both DDR3 and DDR3L RAMs, though.
  • As of May 2017 SDC-CSPU is still equipped with 1.5V DDR3 RAM (but can be equipped with 1.35V DDR3L RAM, as well).
  • Support for this feature also requires OS support on boards that may be equipped with both types of RAM (SANTARO, SANTOKA, SDC-CSPU):
  • The following OS releases support both 1.35V DDR3L and 1.5V DDR3 configurations:
  • Linux Yocto Releases from 34.1 and newer
  • Linux Yocto-Jethro Releases from 1.0 and newer
  • FnG-System Releases from 8.0 using Yocto Kernel 35.0 or newer
  • All Windows Embedded Compact Releases
  • The following OS releases do only support 1.5V DDR3 configurations but no 1.35V DDR3L (may still be used with older FnG-Boot releases, though):
  • Linux Yocto Releases prior to 34.1
  • Linux PTXDist Releases up to and including 1.47.0 (support in newer releases is currently unplanned)
  • Android Releases up to and including 7.0 (support will be included in newer releases)
  • FnG-System Releases using older kernels than the Yocto 35.0 kernel, which includes all FnG-System Releases prior to 8.0.
  • If FnG-Boot 8.0 or newer is used on a device equipped with DDR3L but an OS is used, which doesn’t support 1.35V DDR3L, the RAM supply voltage will be reconfigured back to 1.5V during the OS boot process, which may cause stability issues.
  • In these cases please consider either upgrading your OS to a newer version, or down-grading FnG-Boot to v7.0, which can still be used safely on all platforms that have been changed to ship with DDR3L hardware.
  • To verify if your device is using 1.35V DDR3L RAM supply voltage, please check the two very first debugging messages FnG-Boot 8.0 and newer issue on the serial console.
  • The RAM supply voltage used has no impact on the system speed.
  • DDR3(L)-systems in all cases use either DDR3-800E or DDR3-1066G timings depending on the i.MX6 SoC-capabilities regardless of the RAM-voltage.
  • LPDDR2-systems always use LPDDR2-800 timings.

Known Restrictions

  • None

5.3SD-/MMC-Support

Features

  • Boots from internal eMMC
  • Boots from external SD-Cards (not officially supported on Garz & Fricke i.MX6-based devices)
  • Supports “native” speed of storage media up to
  • 50 MHz, 4 Bit SDR for SD-Cards
  • 52 MHz, 8 Bit DDR for eMMCs

Performed Tests

Description / Dev / Version / Author / Status
Tested storage media
4GB JW808 Micron MTFC4GLVEA-0M,
eMMC v4.41,8Bit,52MHz DDR / 1, 4, 8 / V11.0r3603 / MOW / Okay
4GB JWA57 Micron MTFC4GACAAAM-1M WT,
eMMC v4.51, 8Bit,52MHz DDR / 2, 6, 7, 9, 10 / V11.0r3603 / MOW / Okay
4GB JY976 Micron MTFC4GACAJCN-1M WT,
eMMC v5.0, 8Bit, 52MHz DDR / 11 / V11.0r3603 / MOW / Okay
8GB JY995 Micron MTFC8GAKAJCN-1M WT,
eMMC v5.0, 8Bit, 52MHz DDR / 5 / V11.0r3603 / MOW / Okay
4GB THGBM Toshiba THGBMDG5D1LBAIT,
eMMC v5.0, 8 Bit, 52MHz DDR / 3 / V11.0r3603 / MOW / Okay
1GB SD-Card, SanDisk, 4Bit, 25MHz / 2 / V11.0r3603 / MOW / Okay
2GB SD-Card, SanDisk Extreme III, 4Bit, 50MHz / 2 / V11.0r3603 / MOW / Okay
4GB SD-Card (not SDHC), Transcend 150x, 4Bit, 50MHz / 2 / V11.0r3603 / MOW / Okay
4GB SDHC-Card, SanDisk, Class 2, 4Bit, 25MHz / 2 / V11.0r3603 / MOW / Okay

Notes

  • None

Known Restrictions

  • While theoretically possible, booting from external SD-Cards is not officially supported on Garz & Fricke devices using i.MX6 SoCs and requires manual access to the PCB.

5.4Partition-/Filesystem Support

Features

  • Supports MBR partition tables with primary and extended partitions
  • Supports FAT12, FAT16 and FAT32 filesystems
  • Supports partitions/filesystems on eMMC boot partitions
  • Supports multiple FAT partitions on one device
  • Supports loading files from named partitions

Performed Tests

Description / Dev / Version / Author / Status
Find & load “boot.cfg” and “boot-alt.cfg” on single primary FAT partition / 2 / V11.0r3603 / MOW / Okay
Find & load “boot.cfg“ and “boot-alt.cfg” on eMMC with one primary FAT partition “CONFIG” and two extended partitions “DEF” and “ALT” / 2 / V11.0r3603 / MOW / Okay
Find & load “boot.cfg“ and “boot-alt.cfg” on eMMC with one primary FAT eMMC-boot-partition “CONFIG” and two primary user-data partitions “DEF” and “ALT” / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
Load test file from single primary FAT partition / 2 / V11.0r3603 / MOW / Okay
Load test file from “current” FAT partition on eMMC with one primary FAT partition “CONFIG” and two extended partitions “DEF” and “ALT” / 2 / V11.0r3603 / MOW / Okay
Load test file from “CONFIG” FAT partition on eMMC with one primary FAT partition “CONFIG” and two extended partitions “DEF” and “ALT” / 2 / V11.0r3603 / MOW / Okay
Load test file from “CONFIG” FAT partition on eMMC with one primary FAT eMMC-boot-partition “CONFIG” and two primary user-data partitions “DEF” and “ALT” / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay

Notes

  • None

Known Restrictions

  • FAT-Filesystems with clusters >= 16 KB not supported.

5.5Boot-Mode Support

Features

  • Supports switching between two boot-scripts via Boot-Mode button and via software

Performed Tests

Description / Dev / Version / Author / Status
Switch between “boot.cfg” and “boot-alt.cfg” on eMMC via Boot-Mode button / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
Switch between “boot.cfg” and “boot-alt.cfg” on eMMC via “bootselect”-script in OS / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay

Notes

  • None

Known Restrictions

  • None

5.6CFG-File Commands

Features

  • Supports loading of different kinds of image files via “load”-command
  • Raw binary images (for Windows-CE, Linux Kernel, Ramdisk, XML-Configuration files)
  • Android boot-images
  • U-Boot boot-images
  • Supports loading different Linux Device-Tree imagesdynamically at runtime depending on current platform actually used via the “devtree”-command.
  • Supports executing code via “exec”-command
  • Supports RAM-tests via “testram”-command
  • Supports performance benchmarks via “testbench”-command
  • (intended) Supports enabling debugging messages on serial console via “debug”-command

Performed Tests

Description / Dev / Version / Author / Status
Load and execute raw OS Image
Windows-CE/E-Boot image via load -b 0x10100000 nk.nb0, load -b 0x10040000 eboot.nb0, exec -b 0x10042000 "" / 2 / V11.0r3603 / MOW / Okay
Raw Linux kernel via load -b 0x10010000 zImage, exec -b 0x10010000 " console_suppressable=ttymxc0,115200 root=/dev/mmcblk0p3 rootfstype=ext4 xmlram=0x13000000 logo=0x13080000" / all / V11.0r3603 / MOW / Untested (not used by any G&F OS)
Load and execute U-Boot kernel image
Linux kernel via load linuximage.bin, exec "console_suppressable=ttymxc0,115200 root=/dev/mmcblk0p3 rootfstype=ext4 xmlram=0x13000000 logo=0x13080000" / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
Load and execute Android boot-image containing Ramdisk
Android boot-image via load -b 0x12000000 -p config config.xml –o, load boot.img, exec "xmlram=0x12000000" / 2 / V11.0r3603 / MOW / Okay
Load and execute Flash-n-Go Boot and Flash-n-Go System via USB using Freescale’s MfgTool / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
Load and execute Flash-n-Go Boot and Flash-n-Go System from eMMC / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
Execute test commands
testram -b 0x10000000 -l 0x20000000 -r2 / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
testram -s -b 0x10000000 -l 0x20000000 -r2 / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
testbench -b 0x10000000 -l 0x10000000 / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
testbench -s -b 0x10000000 -l 0x10000000 / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay
Load different Linux Device-Tree file depending on current platform
devtree -b 0x06:0x63:0x13000000 GUF-Yocto-25.0-r5411-7-SDC-CSPU-imx6-sdc-cspu.dtb / 8 / V11.0r3603 / MOW / Okay
devtree -b 0x07:0x63:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6q-santaro.dtb
devtree -b 0x05:0x63:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6q-santoka.dtb
devtree -b 0x07:0x61:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6dl-santaro.dtb
devtree -b 0x05:0x61:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6dl-santoka.dtb
devtree -b 0x04:0x61:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6dl-santino.dtb
devtree -b 0x03:0x61:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6dl-santino-lt.dtb
devtree -b 0x02:0x61:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6dl-santvend.dtb
devtree -b 0x01:0x63:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6q-hydra.dtb
devtree -b 0x00:0x63:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6q-hydra.dtb
devtree -b 0x0F:0x63:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6q-santvend.dtb
devtree -b 0x05:0x6301:0x13000000 GUF-Yocto-jethro-7.0-r7507-0-IMX6GUF-imx6qp-santoka.dtb / 1, 2, 3, 4, 5, 6, 7, 9, 10, 11 / V11.0r3603 / MOW / Okay

Notes

  • None

Known Restrictions

  • “debug”-command is parsed but otherwise currently not supported
  • Only U-Boot format Linux kernel images are supported. U-Boot format binaries with a ramdisk-image or images containing multiple sections are not supported
  • The ATAGs-address in Android boot-images is ignored. ATAGs are always passed in i.MX6x-internal SRAM, instead.
  • Due to the simple command-parser in Flash-n-Boot testram and testbench commands are onlypartially compatible to the RedBoot versions:
  • Base-address (-b) and length (-l) parameters are mandatory and must always be specified.
  • Number of cycles (-n) parameter for testram is mandatory and must always be specified, and not supported for testbench command (was never used at all in RedBoot)
  • Intensive test (-i) parameter for testram is not supported and hard-coded to “true” in Flash-n-Go Boot.
  • New SMP (-s) parameter allows running tests on SANTARO x2/x4 in SMP-mode with multiple active cores
  • Note: Bootscripts currently may contain only one single testram or testbench command and this must be the last command. (Other commands placed after testram/testbench will be ignored).
  • “devtree”-command requires platform- and SoC-IDs to be specified together with the load-address:
  • Supported platform IDs:
  • 0xf: SANTvend Netzbetrieb
  • 0x7: SANTARO
  • 0x6: SDC-CSPU
  • 0x5: SANTOKA
  • 0x4: SANTINO
  • 0x3: SANTINO LT
  • 0x2: SANTvend Outdoor
  • 0x1: HYDRA CPU 1
  • 0x0: HYDRA CPU 2
  • Supported SoC IDs:
  • 0x6300 / 0x63: i.MX6 Dual/Quad
  • 0x6301: i.MX6Dual/Quad-Plus
  • 0x6100 / 0x61: i.MX6 Single/DualLite

5.7GF Versioning

Features

  • The bootloader passes version information to the OS

Performed Tests

Description / Dev / Version / Author / Status
BL Version is passed via ATAG_REVISION to OS / 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 / V11.0r3603 / MOW / Okay

Notes

  • None

Known Restrictions

  • Unlike the RedBoot bootloader used on other Garz & Fricke devices, FnG-Boot does not pass information on the board serial-number to the OS via ATAGs.

6License

Flash-N-Go Boot is published under the GNU General Public License, Version 2

GNU GENERAL PUBLIC LICENSE

Version 2, June 1991

Copyright (C) 1989, 1991 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

PREAMBLE

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.