Alignment with kernel driver name & binding
introduced by https://patchwork.kernel.org/cover/10761943/
to use the final marketing name = STPMIC1.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Prepare file modification for kernel alignment and
rename driver to stpmic1.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
SW impact for Rev 1.2 of STPMIC1 in U-Boot:
Buck converters output voltage change for Buck1
=> Vdd min 0,725 to max 1,5V instead of 0.6V to 1.35V
(see STPMIC1 datasheet / chapter 5.3 Buck converters)
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Initialize the system configuration for basic boot
- update interconnect setting
- disable pull-down for boot pin
- enable High Speed Low Voltage Pad mode for SPI, SDMMC, ETH, QSPI
- activate I/O compensation
Done by SSBL = TF-A for trusted boot
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Update the memory layout to be aligned with other platform and avoid
overlap with 32MB Linux kernel (multiv7 image).
+ Kernel => 32MiB offset = 0xC2000000
and increase the bootm size to 32MiB
+ FDT => 64MiB offset = 0xc4000000
+ SCRIPT => 65Mib offset = 0xc4100000
+ PXESCRIPT => 66Mib offset = 0xc4200000
+ SPLASHIMAGE => 67Mib offset = 0xc4300000
+ RAMDISK => 68Mib offset = 0xc4400000
(not limited size)
In sources/boot/u-boot/doc/README.distro
+ kernel_addr_r: A size of 16MB for the kernel is likely adequate.
+ pxefile_addr_r: A size of 1MB for extlinux.conf is more than adequate.
+ fdt_addr_r: A size of 1MB for the FDT/DTB seems reasonable.
+ ramdisk_addr_r: It is recommended that this location be highest in RAM
out of fdt_addr_, kernel_addr_r, and ramdisk_addr_r,
so that the RAM disk can vary in size and use any
available RAM.
+ pxefile_addr_r: A size of 1MB for extlinux.conf is more than adequate.
+ scriptaddr: A size of 1MB for extlinux.conf is more than adequate.
For suggestions on memory locations for ARM systems, you must follow
the guidelines specified in Documentation/arm/Booting
in the Linux kernel tree.
And in sources/linux-stm32mp/Documentation/arm/Booting
The zImage may also be placed in system RAM and called there. The
kernel should be placed in the first 128MiB of RAM. It is recommended
that it is loaded above 32MiB in order to avoid the need to relocate
prior to decompression, which will make the boot process slightly
faster.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Clearly separate bootcmd for stm32mp1 board
(bootcmd_stm32mp) and preboot management.
That solve issue for fastboot continue command.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Cosmetic cleanup in mach-stm32mp Kconfig
- remove duplicated SPL_DRIVERS_MISC_SUPPORT
- update help for TARGET_STM32MP1
- set value for NR_DRAM_BANKS
- remove one comment as DEBUG_UART is deactivated by default
- include board Kconfig at the end of the file
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
- export the function get_bootmode() and reused it in spl code
- manage uart instance by alias (prepare v4.19 binding)
- solve issue on nand instance
- restore console for uart boot
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Set board name with the first dts compatible found in DT
code under CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
The result with DEVICE_TREE=stm32mp157c-ev1 is:
STM32MP> env print
board=stm32mp1
board_name=stm32mp157c-ev1
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Implement checkboard() function to display
- the boot chain used: basic or trusted
- the board compatible in device tree
- the board identifier and revision, saved in OTP59 for ST boards
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
As BSEC is secure aware, all register access need to be done
by TF-A for TRUSTED boot chain, when U-Boot is executed in
normal world.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add support of trusted boot, using TF-A as first stage bootloader,
The boot sequence is
BootRom >=> TF-A.stm32 (clock & DDR) >=> U-Boot.stm32
The TF-A monitor provides secure monitor with support of SMC
- proprietary to manage secure devices (BSEC for example)
- PSCI for power
The same device tree is used for STMicroelectronics boards with
basic boot and with trusted boot.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Currently enabling fsck on FAT16/FAT32 exposes that we have problems
with:
TestFsBasic.test_fs13[fat16]
TestFsBasic.test_fs11[fat32]
TestFsBasic.test_fs12[fat32]
TestFsBasic.test_fs13[fat32]
TestFsExt.test_fs_ext1[fat32]
TestFsExt.test_fs_ext2[fat32]
TestFsExt.test_fs_ext3[fat32]
TestFsExt.test_fs_ext4[fat32]
TestFsExt.test_fs_ext5[fat32]
TestFsExt.test_fs_ext6[fat32]
TestFsExt.test_fs_ext7[fat32]
TestFsExt.test_fs_ext8[fat32]
TestFsExt.test_fs_ext9[fat32]
TestMkdir.test_mkdir6[fat16]
TestMkdir.test_mkdir1[fat32]
TestMkdir.test_mkdir2[fat32]
TestMkdir.test_mkdir3[fat32]
TestMkdir.test_mkdir4[fat32]
TestMkdir.test_mkdir5[fat32]
TestMkdir.test_mkdir6[fat32]
TestUnlink.test_unlink1[fat16]
TestUnlink.test_unlink2[fat16]
TestUnlink.test_unlink3[fat16]
TestUnlink.test_unlink4[fat16]
TestUnlink.test_unlink5[fat16]
TestUnlink.test_unlink6[fat16]
TestUnlink.test_unlink7[fat16]
TestUnlink.test_unlink1[fat32]
TestUnlink.test_unlink2[fat32]
TestUnlink.test_unlink3[fat32]
TestUnlink.test_unlink4[fat32]
TestUnlink.test_unlink5[fat32]
TestUnlink.test_unlink6[fat32]
TestUnlink.test_unlink7[fat32]
This is because we don't update the "information sector" on FAT32.
While in the future we should resolve this problem and include that
feature, we should enable fsck for ext4 to ensure that things remain in
good shape there.
Signed-off-by: Tom Rini <trini@konsulko.com>
Ext4 allows for arbitrarily sized block group descriptors when 64-bit
addressing is enabled, which was previously not properly supported. This
patch dynamically allocates a chunk of memory of the correct size.
Signed-off-by: Benjamin Lim <jarsp.ctf@gmail.com>
Add option to the mmc rd test to check the duration of the
execution of the mmc read command. This allows intercepting
read performance regressions.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add test for 'mmc info' subcommand. This tests whether the card
information is obtained correctly and verifies the device, bus
speed, bus mode and bus width.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add test for 'mmc rescan' subcommand. This tests whether the
system can switch to a specific card and then rescan the card.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add separate test for 'mmc dev' subcommand. This tests whether
the system can switch to a specific card.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Factor out the 'mmc dev' call so it can be recycled by other tests.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
A FAT12/FAT16 root directory location is specified by a sector offset and
it might not start at a cluster boundary. It also resides before the
data area (before cluster 2).
However, the current code assumes that the root directory is located at
a beginning of a cluster, causing no files to be found if that is not
the case.
Since the FAT12/FAT16 root directory is located before the data area
and is not aligned to clusters, using unsigned cluster numbers to refer
to the root directory does not work well (the "cluster number" may be
negative, and even allowing it be signed would not make it properly
aligned).
Modify the code to not use the normal cluster numbering when referring to
the root directory of FAT12/FAT16 and instead use a cluster-sized
offsets counted from the root directory start sector.
This is a relatively common case as at least the filesystem formatter on
Win7 seems to create such filesystems by default on 2GB USB sticks when
"FAT" is selected (cluster size 64 sectors, rootdir size 32 sectors,
rootdir starts at half a cluster before cluster 2).
dosfstools mkfs.vfat does not seem to create affected filesystems.
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Reviewed-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Tested-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Hi,
when I try to load a sparse file via ext4load, I am getting the error message
'invalid extent'
After a deeper look in the code, it seems to be an issue in the function ext4fs_get_extent_block in fs/ext4/ext4_common.c:
The file starts with 1k of zeros. The blocksize is 1024. So the first extend block contains the following information:
eh_entries: 1
eh_depth: 1
ei_block 1
When the upper layer (ext4fs_read_file) asks for fileblock 0, we are running in the 'invalid extent' error message.
For me it seems, that the code is not prepared for handling a sparse block at the beginning of the file. The following change, solved my problem:
I am really not an expert in ext4 filesystems. Can somebody please have a look at this issue and give me a feedback, if I am totally wrong or not?
Test cases are:
1) basic link creation, verify it can be followed
2) chained links, verify it can be followed
3) replace exiting file a with a link, and a link with a link. verify it
can be followed
4) create a broken link, verify it can't be followed
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The command line is:
ln <interface> <dev[:part]> target linkname
Currently symbolic links are supported only in ext4 and only if the option
CMD_EXT4_WRITE is enabled.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Re-use the functions used to write/create a file, to support creation of a
symbolic link.
The difference with a regular file are small:
- The inode mode is flagged with S_IFLNK instead of S_IFREG
- The ext2_dirent's filetype is FILETYPE_SYMLINK instead of FILETYPE_REG
- Instead of storing the content of a file in allocated blocks, the path
to the target is stored. And if the target's path is short enough, no block
is allocated and the target's path is stored in ext2_inode.b.symlink
As with regulars files, if a file/symlink with the same name exits, it is
unlinked first and then re-created.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Fix ext4 env code]
Signed-off-by: Tom Rini <trini@konsulko.com>
There is no need to modify the buffer passed to ext4fs_write_file().
The memset() call is not required here and was likely copied from the
equivalent part of the ext4fs_read_file() function where we do need it.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
We need to make sure that file writes,file creation, etc. are properly
performed and do not corrupt the filesystem.
To help with this, introduce the assert_fs_integrity() function that
executes the appropriate fsck tool. It should be called at the end of any
test that modify the content/organization of the filesystem.
Currently only supports FATs and EXT4.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
If the metadata checksums are enabled, all write operations will fail.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
When a file contains extents, U-Boot currently reads extent-related data
for each block in the file, even if that data is located in the same
block each time. This significantly slows down loading of files that use
extents. Implement a very dumb cache to prevent repeatedly reading the
same block. Files with extents now load as fast as files without.
Note: There are many cases where read_allocated_block() is called. This
patch only addresses one of those places; all others still read redundant
data in any case they did before. This is a minimal patch to fix the
load command; other cases aren't fixed.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJcrEcDAAoJEB6zHgIOrC/I1dgH/3mHQNW8bqiNCJYcoVQdheHb
e06TqbWHNlOG/NilYybvdeF+LjeCqhX4PzyL/sdcyBf3D/tK4cVvHpZrQyjb2s6K
5IZSKJ+cZznmq6Hv7b//d30Azhx8bi8luxs60kkj+PF0xI1EyU3JteUqAs4Ooxd7
z+HdcRFuAaps6sy0+szB3fTw9HTGrhFvQuHasDGb2uahhpwGzu/P0RchIDksOdzH
3L4EOvgq8MZCiZ3ZtFWMWzQoCjcKf5Fuux41qar8gG/LrkWRfKG+LfWfZtTiTsjf
vC9bYWmdKtkSLFj1PWgLBfGxev5zwPUbqI2EP4OlagfNs3os5pVFCYV5NZ6ovdE=
=kMXf
-----END PGP SIGNATURE-----
Merge tag 'u-boot-atmel-2019.07-a' of git://git.denx.de/u-boot-atmel
First set of u-boot-atmel features and fixes for 2019.07 cycle
I've noticed that the first ethernet packet after PHY link establishment
is not tranferred correctly most of the time on my AT91SAM9G25 board.
Here I usually see a timeout of a few seconds, which is quite
annoying.
Adding a small delay (10ms in this case) after the link establishment
helps to solve this problem. With this patch applied, this timeout
on the first packet is not seen any more.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Wenyou Yang <wenyou.yang@atmel.com>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
SAM9X60 uses high and low drive strengths. To implement this, in
at91_pinctrl_mux_ops::set_drivestrength we need bit numbers of
drive strengths (1 for low, 2 for high), thus change the code to
allow the usage of drive strength bit numbers.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
The GARDENA smart Gateway boards are equipped with an Atmel / Microchip
AT91SAM9G25 SoC and with 128 MiB of RAM and 256 MiB of NAND storage.
This patch adds support for this board including SPL support. Therefore
the AT91Boostrap is not needed on this platform any more.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Andreas Bießmann <andreas@biessmann.org>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
