Use the %pap printf specifier to print physical addresses. The physical
address is passed by reference and hence avoids the need to play tricks
with the preprocessor to use the correct specifier.
Signed-off-by: Thierry Reding <treding@nvidia.com>
If 64-bit physical addresses support is enabled, make sure the sandox
defines the correct types for phys_addr_t and phys_size_t.
Signed-off-by: Thierry Reding <treding@nvidia.com>
When phys_addr_t printf specifier support was first introduced in commit
1eebd14b79 ("vsprintf: Add modifier for phys_addr_t"), it was enabled
only if CONFIG_CMD_NET was selected. Since physical addresses are not
unique to networking support it doesn't make sense to conditionally add
it in those cases only. Move support for it outside of the CMD_NET guard
so that the specifier is always supported.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
v2019.04-rc3 sandbox U-Boot fails to boot when compiled with
-fsanitize=address and linked against -lasan, reporting [1].
Git bisecting shows that the issue is contributed by v2019.01 commit
1678754f5e ("core: ofnode: Fix ofnode_get_addr_index function").
The root cause seems to be the mismatch between sizeof(u64) and
sizeof(fdt_size_t) on sandbox. Luckily, thanks to the fact that the
size argument of both of_get_address() and fdtdec_get_addr_size_fixed()
is optional, we can pass NULL in its place, avoiding the problem.
[1] Backtrace reported by ASAN (gcc 8.1.0):
$> ./u-boot -d arch/sandbox/dts/sandbox.dtb
[..]
Reviewed-by: Simon Glass <sjg@chromium.org>
=================================================================
==10998==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcc2331140 at pc 0x0000004eeeb0 bp 0x7ffcc2330f80 sp 0x7ffcc2330f70
WRITE of size 8 at 0x7ffcc2331140 thread T0
#0 0x4eeeaf in of_get_address drivers/core/of_addr.c:154
#1 0x4f7441 in ofnode_get_addr_index drivers/core/ofnode.c:263
#2 0x5b2a78 in sb_eth_ofdata_to_platdata drivers/net/sandbox.c:422
#3 0x4dccd8 in device_probe drivers/core/device.c:407
#4 0x753170 in eth_initialize net/eth-uclass.c:428
#5 0x47d9bf in initr_net common/board_r.c:557
#6 0x6bcfa7 in initcall_run_list lib/initcall.c:30
#7 0x47e1fe in board_init_r common/board_r.c:859
#8 0x4060e5 in main arch/sandbox/cpu/start.c:356
#9 0x7fb8d135482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#10 0x40a3a8 in _start (/path/to/u-boot/u-boot+0x40a3a8)
Address 0x7ffcc2331140 is located in stack of thread T0 at offset 32 in frame
#0 0x4f72b8 in ofnode_get_addr_index drivers/core/ofnode.c:255
This frame has 3 object(s):
[32, 36) 'size' <== Memory access at offset 32 partially overflows this variable
[96, 100) 'flags'
[160, 168) 'node'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow drivers/core/of_addr.c:154 in of_get_address
Shadow bytes around the buggy address:
0x10001845e1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001845e1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001845e1f0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x10001845e200: 04 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2
0x10001845e210: 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00
=>0x10001845e220: 00 00 00 00 f1 f1 f1 f1[04]f2 f2 f2 f2 f2 f2 f2
0x10001845e230: 04 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3
0x10001845e240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10001845e250: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 f3 f3 f3 f3
0x10001845e260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
0x10001845e270: f1 f1 00 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==10998==ABORTING
'To' list:
git log --since=1year drivers/core/ofnode.c | grep "\-by: .*@" | \
sed 's/.*-by: //' | sort | uniq -c | sort -rn
10 Simon Glass <sjg@chromium.org>
3 Mario Six <mario.six@gdsys.cc>
2 Martin Fuzzey <mfuzzey@parkeon.com>
2 Marek Vasut <marek.vasut+renesas@gmail.com>
1 Tom Rini <trini@konsulko.com>
1 Masahiro Yamada <yamada.masahiro@socionext.com>
1 Keerthy <j-keerthy@ti.com>
1 Jens Wiklander <jens.wiklander@linaro.org>
1 Bin Meng <bmeng.cn@gmail.com>
Fixes: 1678754f5e ("core: ofnode: Fix ofnode_get_addr_index function")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Change the function syscon_regmap_lookup_by_phandle()
introduced by commit 6c3af1f24e ("syscon: dm: Add a
new method to get a regmap from DTS") to have
Linux-compatible syscon API.
Same modification than commit e151a1c288 ("syscon: add
Linux-compatible syscon API") solves issue when the node
identified by the phandle has several compatibles and is
already bound to a dedicated driver.
See Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon
interface from platform devices").
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 6d29cc7dcf ("fdt: Fixup only valid memory banks") ended up
being merged twice, first as:
commit 6d29cc7dcf
Author: Thierry Reding <treding@nvidia.com>
AuthorDate: Tue Jan 30 11:34:17 2018 +0100
Commit: Simon Glass <sjg@chromium.org>
CommitDate: Sun Feb 18 12:53:38 2018 -0700
fdt: Fixup only valid memory banks
Memory banks with address 0 and size 0 are empty and should not be
passed to the OS via device tree.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
and later again, though this time it was v2:
commit ed5af03f9b
Author: Thierry Reding <treding@nvidia.com>
AuthorDate: Thu Feb 15 19:05:59 2018 +0100
Commit: Tom Rini <trini@konsulko.com>
CommitDate: Fri Feb 23 10:40:50 2018 -0500
fdt: Fixup only valid memory banks
Memory banks with address 0 and size 0 are empty and should not be
passed to the OS via device tree.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The second version was slightly different, so the main hunk of the patch
was applied twice. This isn't harmful because the code is idempotent,
but it's wasteful to run the same code twice.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some binding define child node gpio-controller without compatible property.
This patch avoid to bind the pinconfig uclass to these node.
For example, the binding for st,stm32-pinctrl
(./device-tree-bindings/pinctrl/st,stm32-pinctrl.txt) defines the GPIO
controller/bank node as sub-node of pincontrol (st,stm32f429-pinctrl)
but without compatible (as it is not mandatory).
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In case of system with several pin-controller device, probe the first
UCLASS_PINCTRL by seq number (defined by alias) to avoid race condition
with I2C PINCONTROL driver for GPIO expander (GPIO expander need I2C bus,
I2C driver need PINCONFIG).
Signed-off-by: Patrick DELAUNAY <patrick.delaunay@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
interrupt-parent property is removed already that's why there is no
reason to keep interrupts property if parent doesn't exist.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 5ff7768892.
As noted in the comment, the function pinctrl_decode_pin_config_dm()
only served as a temporary solution.
Since the function has no users anymore, we can remove it again.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We can remove the pre reloc property in SPL and TPL device-tree:
- u-boot,dm-pre-reloc
- u-boot,dm-spl
- u-boot,dm-tpl
As only the needed node are kept by fdtgrep (1st pass).
The associated function (XXX_pre_reloc) are simple for SPL/TPL:
return always true.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
The current documentation only covers how to chain-load U-Boot on a
Chromebook. Add more information about the other ways to use U-Boot on
Chromebooks.
In particular it is again possible to build it with Chromium OS
verified boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Enable TI K3 AM65x PSI-L, Ring Accelerator and UDMA drivers
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add DT node for MCU NAVSS its components to get DMA working on AM654
SoC.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Merge drivers/soc/keystone/ into drivers/soc/ti/
and convert CONFIG_TI_KEYSTONE_SERDES into Kconfig.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types.
The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
channels. Channels in the UDMA-P can be configured to be either Packet-Based or
Third-Party channels on a channel by channel basis.
The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet mode)
- MEM_TO_DEV (Packet mode)
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Add TI Communications Port Programming Interface (CPPI) 5
interface description and helpers
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There is one RINGACC module per NAVSS on TI AM65x SoCs.
The RINGACC converts constant-address read and write accesses to equivalent
read or write accesses to a circular data structure in memory. The RINGACC
eliminates the need for each DMA controller which needs to access ring
elements from having to know the current state of the ring (base address,
current offset). The DMA controller performs a read or write access to a
specific address range (which maps to the source interface on the RINGACC)
and the RINGACC replaces the address for the transaction with a new address
which corresponds to the head or tail element of the ring (head for reads,
tail for writes). Since the RINGACC maintains the state, multiple DMA
controllers or channels are allowed to coherently share the same rings as
applicable. The RINGACC is able to place data which is destined towards
software into cached memory directly.
Supported ring modes:
- Ring Mode
- Messaging Mode
- Credentials Mode
- Queue Manager Mode
TI-SCI integration:
Texas Instrument's System Control Interface (TI-SCI) Message Protocol now
has control over Ringacc module resources management (RM) and Rings
configuration.
The Ringacc driver manages Rings allocation by itself now and requests
TI-SCI firmware to allocate and configure specific Rings only. It's done
this way because, Linux driver implements two stage Rings allocation and
configuration (allocate ring and configure ring) while TI-SCI Message
Protocol supports only one combined operation (allocate+configure).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Texas Instruments' System Control Interface (TI-SCI) Message Protocol
abstracts management of NAVSS resources, like PSI-L pairing and
unpairing, UDMAP tx/rx/flow configuration and Rings.
This patch adds support for requesting and configuring such resources
from TI-SCI firmware.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
The chip_desc.enable field is used only for muxes, not for switches.
Document it and remove the unused values.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Heiko Schocher<hs@denx.de>
The Kconfig help has not been updated while adding PCA9547 and PCA9646.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Heiko Schocher<hs@denx.de>
The 'u-boot,i2c-transaction-bytes' device tree property provides
information regarding number of bytes transferred by a device in a
single transaction.
This change is necessary to avoid hanging devices after soft reset.
One notable example is communication with MC34708 device:
1. Reset when communicating with MC34708 via I2C.
2. The u-boot (after reboot -f) tries to setup the I2C and then calls
force_idle_bus. In the same time MC34708 still has some data to be sent
(as it transfers data in 24 bits chunks).
3. The force_idle_bus() is not able to make the bus idle as 8 SCL
clocks may be not enough to have the full transmission.
4. We end up with I2C inconsistency with MC34708.
This PMIC device requires 24+ SCL cycles to make finish any pending I2C
transmission.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
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>
On modern Allwinner SoCs (tested: H2+, A64, H5, H6) the BootROM can
actually load the SPL also from sector 256 (128KB) of an SD card or eMMC
chip. For more details, see [1].
In this case the boot source indicator (written at offset 0x28 of SRAM A1)
has bit 4 set, so it's 0x10 for SD card and 0x12 for eMMC.
Add those new values to the existing boot source check to allow booting
the SPL from those "high" disk offsets as well. For this to work, the
value of CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR needs to be adjusted,
for instance to 0x140 (right after the high SPL). Doing this dynamically
sounds desirable, but looks nasty to implement.
[1] https://groups.google.com/forum/#!topic/linux-sunxi/MaiijyaAFjk
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Most of the boards we support with H3/H5 enable DRAM on-die termination,
which is consistent with the high DRAM clocks that are used.
Make it the default (like it's done for other similar platforms) instead
of defining it in each defconfig.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Most H3/H5 boards we support have the DRAM ZQ value set to 3881979,
which is also consistent with the default set for the R40.
Make this value the default on H3/H5 instead of 123.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
A few sun8i platforms define specific default DRAM ZQ values, but they
are not taken in account because of MACH_SUN8I being used for the 123
default first.
Replace MACH_SUN8I with the list of platforms that don't have specific
DRAM ZQ values, to avoid overwriting the default for those that do.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Acked-by: Jagan Teki <jagan@openedev.com>
While the exact problem is not known, based on discussion between
Philipp Tomsich and André Przywara it is guessed that exit self-refresh
timing is not set with correct value. There may be implicit enter or
exit Self-Refresh anywhere as part of some training phase.
In ZynqMP register guide [1], which is close to the various
Allwinner DRAM controllers, tXSDLL is bits [14:8], while the non-DLL
tXS is bits [6:0]: Self refresh exit delay. So it could be safely
increased and it only affects the time after the self-refresh “exit”,
which happens only after (re-)initialisation.
There was no document for cpu in question so based on oscilloscope
readings [2][3] and observed result by comparing allwinner architecture.
So set it same as Allwinner H5 silicon.
Before this patch, failure rate of was 7%.
This was tested on A33 allwinner cpu, dual rank connection connected
with two MT41K512M16HA-125:A memory model. Memory is configured as DDR3
1.5V
And also this is tested in A33-OLinuXino dev board.
[1] https://www.xilinx.com/html_docs/registers/ug1087/ddrc___dramtmg8.html
[2] https://ibb.co/R70zmyS
[3] https://ibb.co/HVVCGQ8
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Shyam Saini <shyam.saini@amarulasolutions.com>
Acked-by: Jagan Teki <jagan@openedev.com>
The Pine64-LTS defconfig is missing the CONFIG_USB_OHCI_HCD symbol, as
this was added during the same time as this defconfig was merged.
USB 1.x devices like USB keyboards don't work due to this.
Add the symbol to the defconfig as all the other boards do.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@openedev.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>
