sama5
product family:
By programming BSC_CR register, we can bypass some steps in above sequence.
Note need a reset to make BSC_CR effective. And BSC_CR will be restored to factory value if power is removed.
wget -c https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz
tar -xf arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz export CROSS_COMPILE=`pwd`/arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-or
tar -xf arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz export CROSS_COMPILE=arm-none-linux-gnueabihf- export PATH=$PATH:/YOUR/PATH/TO/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-linux-gnueabihf/bin/
export PATH=${PATH/':/YOUR/PATH/TO/arm-gnu-toolchain-VERSION-x86_64-arm-none-linux-gnueabihf/bin/'/}
ls -l `which sh` /bin/sh -> dash sudo dpkg-reconfigure dash #Select "no" when you're asked [...] ls -l `which sh` /bin/sh -> bash
$ git clone https://github.com/linux4sam/at91bootstrap.git Cloning into 'at91bootstrap'... remote: Enumerating objects: 17621, done. remote: Counting objects: 100% (3324/3324), done. remote: Compressing objects: 100% (1029/1029), done. remote: Total 17621 (delta 2465), reused 3102 (delta 2285), pack-reused 14297 Receiving objects: 100% (17621/17621), 5.65 MiB | 4.65 MiB/s, done. Resolving deltas: 100% (13459/13459), done. $ cd at91bootstrap/
configs
folder which contains several default configuration files: sam9x60ekqspi_uboot_defconfig sam9x60eksd_uboot_defconfig sam9x60eknf_uboot_defconfigTips:
qspi
means to read quad-SPI serial flash, sd
means to read mmc card, nf
means to read nand flash$ make mrproper $ make sam9x60eksd_uboot_defconfigIf the configuring process is successful, the .config file can be found at AT91Bootstrap root directory.
$ make menuconfigNow, in the menuconfig dialog, you can easily add or remove some features to/from AT91Bootstrap as the same way as kernel configuration.
<Exit>
with arrows and press this button hitting the Enter
key to exit from this screen.
$ makeIf the building process is successful, the final .bin image is build/binaries/at91bootstrap.bin.
make menuconfigYou will see a screen similar with the following:
Load and launch next software
This is the most used purpose of a bootloader. The bootloader should initialize the device (the MPU), and the required peripherals to copy the next software stage from non-volatile media (NVM) to the external RAM (DRAM) and then launch the next piece of software. In other words, load a software image from external media to RAM then, depending on the type of software, prepare the required boot parameters, and finally jump to the entry point of this software in RAM. Alternatively, if XIP is enabled, execute the software in place.
Launch externally loaded software
This is a mode that asks the bootloader to only initialize the MPU and have other external tools load the software into memory, and then launch them. It is equivalent with the previous step with the mention of skipping the copy of next software image from NVM to DRAM. This is available because in some cases we cannot copy the software from external media to RAM. Then, we can skip copying any software image from external media to RAM. In this mode, we expect the required images and boot parameters to be present in RAM already. For instance they will have been loaded by a debugger via JTAG, or by the SAM-BA boot assistant. Jump directly to the entry point of the software in RAM.
Configure and stop
This mode is similar with the previous with the difference that the bootloader will no longer copy the next software image and as well do not jump to any address after configuration is done. This mode can be used for debugging, for the user to connect with a hardware probe (JTAG) to take control of the MPU once the bootloader configures the MPU correctly. The bootloader will : configure essential peripherals. Do not not load any image. Once the system is configured, trigger a breakpoint, and enter an infinite loop. Wait there until a debugger takes control. Resort to the debugger (attached via JTAG) for taking control and possibly loading/running a software application. In order to load code into DRAM from a debugger, a bootloader is required to configure the clocks, PIOs, and memory correctly. Selecting this option builds a bootstrap image that can be used for this purpose.
h
on the menuconfig interface to check the exact numbers. In the screenshot below an example is visible.
DRAM part number
This allows one to use the configuration tailored for a specific DRAM chip, selectable by part number (manufacturer and model ).
JEDEC profile
With this method, one can choose the JEDEC recommended configuration and timings for specific DRAM family , like DDR2, DDR3, etc. These are the failsafe timings recommended by JEDEC and should work with all DRAM parts that are compliant with JEDEC specification.
Customized timings
This method allows complete custom configuration of all the parameters and timings of the DRAM interface.
defconfig
make savedefconfigOnce this is done, a file named
defconfig
will be created and this can be added to the configs/
directory and sent as a patch for inclusion in AT91Bootstrap mainline.
# sama5d3_xplained # 4 bit pmecc in 512 byte sector, one page has 4 sectors, spare size: 64, ecc offset: 36 setenv pmecc_header 0xc0902405 # sama5d4 xplained # 8 bit pmecc in 512 byte sector, one page has 8 sectors, spare size: 224, ecc offset: 120 setenv pmecc_header 0xc1e04e07The ROM code expects this header written in NAND Flash, before the actual boot.bin file. AT91Bootstrap has a pmecc header generator that can prepend the boot.bin file with the expected pmecc header. Thus, you can write the boot.bin directly with any tool to the nand flash, once you used this script to prepend the pmecc header. If you do not have the pmecc header prepended to the binary, it will be automatically prepended to the binary by SAM-BA, when you write the boot.bin using the
writeboot
command from the nandflash
applet.
setenv load_addr 22000000 # load_addr started by pmecc header setenv load_addr_bootstrap 220000d0 # load_addr + 0xd0 setenv load_addr_bootstrap_vector 220000e4 # load_addr + 0xd0 + 0x14 setenv erase_bootstrap 'nand erase 0 10000' # erase first 64k nand. setenv mmc_bootstrap_file 'boot.bin' # at91bootstrap file name in mmc card setenv load_mmc_bootstrap 'mw.b ${load_addr} 0xff 0x10000; mw.l ${load_addr} ${pmecc_header} 0x34; fatload mmc 0 ${load_addr_bootstrap} ${mmc_bootstrap_file};' setenv flash_bootstrap_from_mmc 'run erase_bootstrap; run load_mmc_bootstrap; mw.l ${load_addr_bootstrap_vector} ${filesize}; nand write ${load_addr} 0 0x10000;' setenv tftp_bootstrap_file 'u-boot/boot.bin' # at91bootstrap file name in tftp server folder setenv load_tftp_bootstrap 'mw.b ${load_addr} 0xff 0x10000; mw.l ${load_addr} ${pmecc_header} 0x34;tftp ${load_addr_bootstrap} ${tftp_bootstrap_file};' setenv flash_bootstrap_from_tftp 'run erase_bootstrap; run load_tftp_bootstrap; mw.l ${load_addr_bootstrap_vector} ${filesize}; nand write ${load_addr} 0 0x10000;'
run flash_bootstrap_from_tftp
or run flash_bootstrap_from_mmc
$ make savedefconfig
Then you will have a saved 'defconfig' file that can be placed into
configs/ directory, after you rename it according to the rule described
in chapter 3.
The configuration file can be send as a patch for review to the github pull-request facility directly.
You should be able to do the above steps without requiring to write any actual C code.
However your board may require specific 'board quirks', as some boards do. In this case you will have to implement your quirk into AT91Bootstrap and send this board quirk as a separate patch. Board quirks include for example: resetting of certain devices on the board, reconfiguring specific I/O pins, or blocking the TWI access on some busses.
Maintainers:
Li Bin bin.li at microchip dot com
Nicolas Ferre nicolas.ferre at microchip dot com
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
Microchip and others, are registered trademarks or trademarks of Microchip Technology Inc. and its subsidiaries.
Arm® and others are registered trademarks or trademarks of Arm Limited (or its affiliates). Other terms and product names may be trademarks of others.
Ideas, requests, contributions ? Connect to LinksToCommunities page.