Fix below warnings happening for xilinx_zynqmp_ep_defconfig
drivers/net/zynq_gem.c: In function ‘zynq_gem_init’:
drivers/net/zynq_gem.c:330:7: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
((u32)(priv->rxbuffers) +
^
In file included from drivers/net/zynq_gem.c:19:0:
drivers/net/zynq_gem.c:336:10: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
writel((u32)priv->rx_bd, ®s->rxqbase);
^
./arch/arm/include/asm/io.h:146:34: note: in definition of macro ‘writel’
#define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
^
drivers/net/zynq_gem.c: In function ‘zynq_gem_send’:
drivers/net/zynq_gem.c:399:9: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
writel((u32)priv->tx_bd, ®s->txqbase);
^
./arch/arm/include/asm/io.h:146:34: note: in definition of macro ‘writel’
#define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
^
drivers/net/zynq_gem.c:404:22: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
priv->tx_bd->addr = (u32)ptr;
^
drivers/net/zynq_gem.c:409:9: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
addr = (u32) ptr;
^
drivers/net/zynq_gem.c:414:9: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
addr = (u32)priv->rxbuffers;
^
drivers/net/zynq_gem.c: In function ‘zynq_gem_recv’:
drivers/net/zynq_gem.c:454:31: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
net_process_received_packet((u8 *)addr, frame_len);
^
drivers/net/zynq_gem.c: In function ‘zynq_gem_initialize’:
drivers/net/zynq_gem.c:533:35: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
priv->rx_bd = (struct emac_bd *)((u32)bd_space + BD_SEPRN_SPACE);
^
drivers/net/zynq_gem.c:533:16: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
priv->rx_bd = (struct emac_bd *)((u32)bd_space + BD_SEPRN_SPACE);
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Fix below compilation warings happening for hikey_defconfig
drivers/usb/eth/smsc95xx.c:698:56: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
debug("** %s(), len %d, buf %#x\n", __func__, length, (int)msg);
^
include/common.h:109:26: note: in definition of macro ‘debug_cond’
printf(pr_fmt(fmt), ##args); \
^
drivers/usb/eth/smsc95xx.c:698:2: note: in expansion of macro ‘debug’
debug("** %s(), len %d, buf %#x\n", __func__, length, (int)msg);
^
drivers/usb/eth/smsc95xx.c:718:2: warning: format ‘%u’ expects argument of
type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
debug("Tx: len = %u, actual = %u, err = %d\n",
^
drivers/usb/eth/smsc95xx.c: In function ‘smsc95xx_recv’:
drivers/usb/eth/smsc95xx.c:802:19: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
cur_buf_align = (int)buf_ptr - (int)recv_buf;
^
drivers/usb/eth/smsc95xx.c:802:34: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
cur_buf_align = (int)buf_ptr - (int)recv_buf;
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Fix below compilation warings happening for hikey_defconfig
drivers/mmc/dw_mmc.c: In function ‘dwmci_set_idma_desc’:
drivers/mmc/dw_mmc.c:43:20: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
desc->next_addr = (unsigned int)desc + sizeof(struct dwmci_idmac);
^
drivers/mmc/dw_mmc.c: In function ‘dwmci_prepare_data’:
drivers/mmc/dw_mmc.c:61:35: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
dwmci_writel(host, DWMCI_DBADDR, (unsigned int)cur_idmac);
^
drivers/mmc/dw_mmc.c:73:9: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
(u32)bounce_buffer + (i * PAGE_SIZE));
^
CC drivers/mmc/hi6220_dw_mmc.o
drivers/mmc/hi6220_dw_mmc.c: In function ‘hi6220_dwmci_add_port’:
drivers/mmc/hi6220_dw_mmc.c:51:17: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
host->ioaddr = (void *)regbase;
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Fix below compilation warnings-
drivers/gpio/hi6220_gpio.c: In function ‘hi6220_gpio_probe’:
drivers/gpio/hi6220_gpio.c:82:15: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
bank->base = (u8 *)plat->base;
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
short strings can be used in type parameter of gpt command
to replace the guid string for the types known by u-boot
partitions = name=boot,size=0x6bc00,type=data; \
name=root,size=0x7538ba00,type=linux;
gpt write mmc 0 $partitions
and they are also used to display the type of partition
in "part list" command
Partition Map for MMC device 0 -- Partition Type: EFI
Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00000022 0x0000037f "boot"
attrs: 0x0000000000000000
type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
type: data
guid: d117f98e-6f2c-d04b-a5b2-331a19f91cb2
2 0x00000380 0x003a9fdc "root"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
type: linux
guid: 25718777-d0ad-7443-9e60-02cb591c9737
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
code under flag CONFIG_PARTITION_TYPE_GUID
add parameter "type" to select partition type guid
example of use with gpt command :
partitions = uuid_disk=${uuid_gpt_disk}; \
name=boot,size=0x6bc00,uuid=${uuid_gpt_boot}; \
name=root,size=0x7538ba00,uuid=${uuid_gpt_root}, \
type=0fc63daf-8483-4772-8e79-3d69d8477de4;
gpt write mmc 0 $partitions
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
Previously, Linux used the same GUID for the data partitions as Windows
(Basic data partition: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7).
This created problems when dual-booting Linux and Windows in UEFI-GPT
Setup, so a new GUID (Linux filesystem data:
0FC63DAF-8483-4772-8E79-3D69D8477DE4) was defined jointly by GPT fdisk
and GNU Parted developers.
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
When converting between PCI bus and phys addresses, a two pass search
was introduced with preference to non-PCI_REGION_SYS_MEMORY regions.
See commit 2d43e873a2.
However, since PCI_REGION_MEM is defined as 0, the if statement was
always asserted true: ((flags & PCI_REGION_MEM) == PCI_REGION_MEM)
This patch uses PCI_REGION_TYPE bit to check if the region is
PCI_REGION_MEM: ((flags & PCI_REGION_TYPE) == PCI_REGION_MEM)
Signed-off-by: Cheng Gu <chenggu@marvell.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Condense these updates down to SPDX tags too while doing this. This is
a port of a1452a3771c4eb85bd779790b040efdc36f4274e from the Linux
Kernel.
Signed-off-by: Tom Rini <trini@konsulko.com>
On the BeagleBone these i2c1 pins are routed to the expanasion header, where
they can be defined as either pr1_usart0_Xxd/pwm0/spi0/i2c1, dont assume i2c1
Fixes: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/313894/1387696
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Reported-by: Matthijs van Duin <matthijsvanduin@gmail.com>
CC: Tom Rini <trini@konsulko.com>
The Cubietruck has a mini-USB connector that can be used to power up the
board and as an OTG connector.
Since we have already some USB host-only ports right beside this one,
enable it in gadget mode
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The A13-Olinuxino has a mini-USB connector that can be used to power up
the board and as an OTG connector.
Since we have already some USB host-only ports right beside this one,
enable it in gadget mode
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The Android sparse image format is currently supported through a file
called aboot, which isn't really such a great name, since the sparse image
format is only used for transferring data with fastboot.
Rename the file and header to a file called "sparse", which also makes it
consistent with the header defining the image structures.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Some devices might need to do some per-partition initialization
(ECC/Randomizer settings change for example) before actually accessing it.
Add some hooks before the write and erase operations to let the boards
define what they need to do if needed.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
So far the fastboot code was only supporting MMC-backed devices for its
flashing operations (flash and erase).
Add a storage backend for NAND-backed devices.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The fastboot client will split the sparse images into several chunks if the
image that it tries to flash is bigger than what the device can handle.
In such a case, the bootloader is supposed to retain the last offset to
which it wrote to, so that it can resume the writes at the right offset
when flashing the next chunk.
Retain the last offset we used, and use the session ID to know if we need
it or not.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The fastboot flash command that writes an image to a partition works in
several steps:
1 - Retrieve the maximum size the device can download through the
"max-download-size" variable
2 - Retrieve the partition type through the "partition-type:%s" variable,
that indicates whether or not the partition needs to be erased (even
though the fastboot client has minimal support for that)
3a - If the image is smaller than what the device can handle, send the image
and flash it.
3b - If the image is larger than what the device can handle, create a
sparse image, and split it in several chunks that would fit. Send the
chunk, flash it, repeat until we have no more data to send.
However, in the 3b case, the subsequent transfers have no particular
identifiers, the protocol just assumes that you would resume the writes
where you left it.
While doing so works well, it also means that flashing two subsequent
images on the same partition (for example because the user made a mistake)
would not work withouth flashing another partition or rebooting the board,
which is not really intuitive.
Since we have always the same pattern, we can however maintain a counter
that will be reset every time the client will retrieve max-download-size,
and incremented after each buffer will be flashed, that will allow us to
tell whether we should simply resume the flashing where we were, or start
back at the beginning of the partition.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The current sparse image parser relies heavily on the MMC layer, and
doesn't allow any other kind of storage medium to be used.
Rework the parser to support any kind of storage medium, as long as there
is an implementation for it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The functions and a few define to generate a fastboot message to be sent
back to the host were so far duplicated among the users.
Move them all to a common place.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
To check the alignment of the image blocks to the storage blocks, the
current code uses a convoluted syntax, while a simple mod also does the
work.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The chunk parsing code was duplicating a lot of code among the various
chunk types, while all of them could be covered by generic and simple
functions.
Refactor the current code to reuse as much code as possible and hopefully
make the chunk parsing loop more readable and concise.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The current sparse image format parser is quite tangled, with a lot of
code duplication.
Start refactoring it by moving the header parsing function to a function
of its own.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The current error message in get_part if CONFIG_MTDPARTS is disabled is
"offset is not a number" which is confusing and doesn't help at all.
Change that for something that might give a hint on what's going on.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Since we don't have for sure a valid IP-setup during
board_late_init(...) because it maybe allready stored in environment or
not, we cannot form a proper vxWorks bootline at this place.
So we move to the way, forming the bootline just before
executing/launching vxWorks. To do this we use the bootvx command
instead go.
We only have to form the "othbootargs" environment variable, the rest is
done pretty good by the "bootvx" commannd.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The 10m50 devboard becomes the new golden reference design of
Nios II Linux. So change README.nios2 to use 10m50 as template.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Acked-by: Marek Vasut <marex@denx.de>
Rename board nios2-generic to 3c120_devboard. Since nios2 is
converted to driver model and device tree control of u-boot,
the nios2-generic board directory is removed. We can rename
the board back to a real board name. Now the boards maintained
in u-boot mainline are the same as Linux kernel, namely 3c120
and 10m50.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Add 10m50 devboard support. It is based on the Golden Hardware
Reference Design (GHRD), available at,
http://rocketboards.org/foswiki/view/Documentation/
AlteraMAX1010M50RevCDevelopmentKitLinuxSetup
Though we supported only one nios2-generic board in the past. Now,
with the removal of the nios2-generic board dir, adding new nios2
boards to u-boot is easier than before. It should be helpful to
add those boards supported in Linux mainline. There are only two
such nios2 boards, the 3c120 devboard and 10m50 devboard. The
nios2-generic is actually 3c120, and should restore the name. The
10m50 is this one.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
The Modular Scatter-Gather DMA core is a new DMA core to work
with the Altera Triple-Speed Ethernet MegaCore. It replaces the
legacy Scatter-Gather Direct Memory Access (SG-DMA) controller
core. Please find details on the "Embedded Peripherals IP User
Guide" of Altera.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
Add priv ops to prepare msgdma support. These ops are dma type
specific.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
Move the sgdma wait from free_pkt to recv. This is the proper
place to wait recv sgdma done.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
Zap the altera_tse_initialize() prototypes, since it is converted
to driver model.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
Do not allocate rx buf in net.c, because altera_tse allocates
its own rx buf in driver. This can save 6KB memory.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Add Altera Generic Quad SPI Controller support. The controller
converts SPI NOR flash to parallel flash interface. So it is
not like other SPI flash, but rather like CFI flash.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Implement a Memory Technology Device (MTD) uclass. It should
include most flash drivers in the future. Though no uclass ops
are defined yet, the MTD ops could be used.
The NAND flash driver is based on MTD. The CFI flash and SPI
flash support MTD, too. It should make sense to convert them
to MTD uclass.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
The latest Linux can directly handle SMP operations for UniPhier SoCs
without any help of U-boot. Drop the relevant code from U-boot.
See commit b1e4006aeda8c8784029de17d47987c21ea75f6d ("ARM: uniphier:
rework SMP operations to use trampoline code") in Linux Kernel.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This makes USB3.0 available on new SoCs/boards.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The IRQ is not used in U-Boot, but this would be useful to sync
device trees between Linux and U-Boot.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now that we have solved the problems that prevented this feature from
being enabled, enable it everywhere.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This sets up a fine-grained page table, which is a requirement for
noncached_init() to operate correctly.
MMU setup code currently exists in a number of places:
- A version in the core ARMv8 support code that sets up page tables that
use very large block sizes that CONFIG_SYS_NONCACHED_MEMORY doesn't
support.
- Enhanced versions for fsl-lsch3 and zynmq that set up finer grained
page tables.
Ideally, rather than duplicating the MMU setup code yet again this patch
would instead consolidate all the different routines into the core ARMv8
code so that it supported all use-cases. However, this will require
significant effort since there appear to be a number of discrepancies[1]
between different versions of the code, and between the defines/values by
some copies of the MMU setup code use and the architectural MMU
documentation. Some reverse engineering will be required to determine the
intent of the current code.
[1] For example, in the core ARMv8 MMU setup code, three defines named
TCR_EL[123]_IPS_BITS exist, but only one of them sets the IPS field and
the others set a different field (T1SZ) in the page tables. As far as I
can tell so far, there should be no need to set different values per
exception level nor to modify the T1SZ field at all, since TTBR1 shouldn't
be enabled anyway. Another example is inconsistent values for *_VA_BITS
between the current core ARMv8 MMU setup code and the various SoC-
specific MMU setup code. Another example is that asm/armv8/mmu.h's value
for SECTION_SHIFT doesn't match asm/system.h's MMU_SECTION_SHIFT;
research is needed to determine which code relies on which of those
values and why, and whether fixing the incorrect value will cause any
regression.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
In order for noncached_init() to operate correctly, SoCs must set up a
custom page table with fine-grained (2MiB) sections, which can be
configured from noncached_init().
This is currently performed by arch/arm/cpu/armv8/{fsl-lsch3,zynqmp}/cpu.c
by cut/pasting and re-implementing mmu_setup, enable_caches(), etc. There
are some other reasons for the duplication there though, such as enabling
icache early, and enabling dcaching earlier with a different configuration.
This change makes mmu_setup() a weak implementation, so that the MMU setup
code can be replaced without having to duplicate other code that calls it.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
The implementation of noncached_init() uses define MMU_SECTION_SIZE.
Define this on ARM64.
Move the prototype of noncached_{init,alloc}() to a location that
doesn't depend on !defined(CONFIG_ARM64).
Note that noncached_init() calls mmu_set_region_dcache_behaviour() which
relies on something having set up translation tables with 2MB block size.
The core ARMv8 MMU setup code does not do this by default, but currently
relies on SoC specific MMU setup code. Be aware of this before enabling
this feature on your platform!
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ls1043ardb_nand_defconfig and ls1043ardb_sdcard_defconfig are missing
in the MAINTAINERS file, so add them for completeness.
Reported-by: Albert Aribaud <albert.u.boot@aribaud.net>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Prabhakar Kushwaha
Siarhei Siamashka
Patrick Delaunay
Cheng Gu
Tom Rini
robertcnelson@gmail.com
Maxime Ripard
Hannes Petermaier
Thomas Chou
Masahiro Yamada
Stephen Warren
Fabio Estevam