Hi,
On 03-03-16 17:54, Hendrik wrote:
Hello Hans,
Thank you very much for your message. The PIO program reported
'PE6<0><0><1><1>' for both U-Boots but changing the configuration's
CONFIG_AXP_ALDO3_VOLT and CONFIG_AXP_ALDO4_VOLT back to 2800 did indeed solve the problem. I can run
U-Boot 201
From: Alban Bedel
The init simply hardcoded the i2c bus and address to those used on
jetson. Extend the init function to take the bus number and device
address as parameter. As only jetson is using this code for now just
fix this single use of the function.
Signed-off-by: Alban Bedel
Reviewed-b
Add support for platforms based on the Meerkat COM module. Includes support
for the minimal reference platform called Kein Baseboard, which in fact is
sufficient to run most existing Meerkat carriers.
Signed-off-by: Julian Scheel
---
Changes in v3:
- Remove bad as3722 gpio manipulations on pcie
Hi,
Le mardi 01 mars 2016 à 06:27 -0700, Simon Glass a écrit :
> On 1 March 2016 at 01:10, Paul Kocialkowski wrote:
> > Hi,
> > Le lundi 29 février 2016 à 19:03 -0700, Simon Glass a écrit :
> > > On 29 February 2016 at 03:15, Lukasz Majewski
> > > wrote:
> > > > > I was told some time ago that a
CONFIG_PINCTRL_UNIPHIER is more suitable than CONFIG_ARCH_UNIPHIER
to guard the drivers/pinctrl/uniphier directory.
The current CONFIG_PINCTRL_UNIPHIER_CORE is a bit long, so rename it
into CONFIG_PINCTRL_UNIPHIER.
Signed-off-by: Masahiro Yamada
---
drivers/pinctrl/Makefile | 2 +-
d
While IECTRL is disabled, input signals are pulled-down internally.
If pin-muxing is set up first, glitch signals (Low to High transition)
might be input to hardware blocks.
Bad case scenario:
[1] The hardware block is already running before pinctrl is handled.
(the reset is de-asserted by defa
The build fails if compiled with CONFIG_CMD_DDRMPHY_DUMP=y since commit
46abfcc99e04 ("ARM: uniphier: rework struct uniphier_board_data").
Fixes: 46abfcc99e04 ("ARM: uniphier: rework struct uniphier_board_data")
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/dram/cmd_ddrmphy.c | 18 +
- Make comment 'one-liners' truly one line
- Drop some CFI verbage and definitions
* NOR Support needs to be added with current conventions
Signed-off-by: Derald D. Woods
---
include/configs/am3517_evm.h | 255 +++
1 file changed, 111 insertions(+), 144
Select 8-bit BCH ecc-scheme with s/w based error correction
- OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
Signed-off-by: Derald D. Woods
---
include/configs/am3517_evm.h | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/include/configs/am3517_evm.h b/include/con
Signed-off-by: Derald D. Woods
---
configs/am3517_evm_defconfig | 2 +
include/configs/am3517_evm.h | 102 +++
2 files changed, 66 insertions(+), 38 deletions(-)
diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index cde84fe..c769
This patch series updates NAND support for the LogicPD AM3517 EVM/EXP
development boards and their corresponding System On Modules.
OMAP3: am3517_evm: Use BCH8 ECC for NAND
OMAP3: am3517_evm: Replace JFFS2 with UBI/UBIFS on NAND
OMAP3: am3517_evm: Misc. comment and option cleanup
In order to execute an EFI application, we need to bridge the gap between
U-Boot's notion of executing images and EFI's notion of doing the same.
The best path forward IMHO here is to stick completely to the way U-Boot
deals with payloads. You manually load them using whatever method to RAM
and th
Now that everything's in place, let's add myself as the maintainer for
the efi payload support.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d447ea..32f97b2 100644
--- a/MAINTAI
Now that we have nice table driven page table creating code that gives
us everything we need, move to that.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Move mmu tables into board file
---
arch/arm/cpu/armv8/zynqmp/cpu.c | 217 +---
include/configs/xilin
We have a nice framework around image fils to prepare a device tree
for OS execution. That one patches in missing device tree nodes and
fixes up the memory range bits.
We need to call that one from the EFI boot path too to get all those
nice fixups. This patch adds the call.
Signed-off-by: Alexan
The commonly defined environment variable to determine the device tree
file name is called fdtfile rather than fdt_name. Replace all occurences
of fdt_name with fdtfile.
Signed-off-by: Alexander Graf
---
include/config_distro_bootcmd.h | 4 ++--
include/configs/hikey.h | 2 +-
incl
EFI payloads can query for the device they were booted from. Because
we have a disconnect between loading binaries and running binaries,
we passed in a dummy device path so far.
Unfortunately that breaks grub2's logic to find its configuration
file from the same device it was booted from.
This pa
To preserve all cover letter knowledge of the status on UEFI payload
support, let's add some sections to README.efi.
Signed-off-by: Alexander Graf
v3 -> v4:
- Add section about config options
- s/10kb/10KB/
---
doc/README.efi | 83 +-
Now that we have all the bits and pieces ready for EFI payload loading
support, hook them up in Makefiles and KConfigs so that we can build.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
Tested-by: Simon Glass
---
v1 -> v2:
- Move to GPLv2+
- Default to y
v2 -> v3:
- Add mem
The idea to generate our pages tables from an array of memory ranges
is very sound. However, instead of hard coding the code to create up
to 2 levels of 64k granule page tables, we really should just create
normal 4k page tables that allow us to set caching attributes on 2M
or 4k level later on.
S
UEFI defines a simple boot protocol for removable media. There we should look
at the EFI (first GPT FAT) partition and search for /efi/boot/bootXXX.efi with
XXX being different between different platforms (x86, x64, arm, aa64, ...).
This patch implements a simple version of that protocol for the d
After booting has finished, EFI allows firmware to still interact with the OS
using the "runtime services". These callbacks live in a separate address space,
since they are available long after U-Boot has been overwritten by the OS.
This patch adds enough framework for arbitrary code inside of U-B
Our current arm64 exception handlers all panic and never return to the
exception triggering code.
But if any handler wanted to continue execution after fixups, it would
need help from the exception handling code to restore all registers.
This patch implements that help. With this code, exception
A EFI applications usually want to access storage devices to load data from.
This patch adds support for EFI disk interfaces. It loops through all block
storage interfaces known to U-Boot and creates an EFI object for each existing
one. EFI applications can then through these objects call U-Boot's
When an EFI application runs, it has access to a few descriptor and callback
tables to instruct the EFI compliant firmware to do things for it. The bulk
of those interfaces are "boot time services". They handle all object management,
and memory allocation.
This patch adds support for the boot time
There are 2 ways an EFI payload could return into u-boot:
- Callback function
- Exception
While in EFI payload mode, r9 is owned by the payload and may not contain
a valid pointer to gd, so we need to fix it up. We do that properly for the
payload to callback path already.
This patch also ad
There are 2 ways an EFI payload could return into u-boot:
- Callback function
- Exception
While in EFI payload mode, x18 is owned by the payload and may not contain
a valid pointer to gd, so we need to fix it up. We do that properly for the
payload to callback path already.
This patch also a
The EFI API header is great, but missing a good chunk of function prototype,
GUID defines and enum declarations.
This patch extends it to cover more of the EFI API. It's still not 100%
complete, but sufficient enough for our EFI payload interface.
Signed-off-by: Alexander Graf
Reviewed-by: Simon
EFI uses the PE binary format for its application images. Add support to EFI PE
binaries as well as all necessary bits for the "EFI image loader" interfaces.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
Tested-by: Simon Glass
---
v1 -> v2:
- move memory allocation to separate pat
Now that we have an easy way to describe memory regions and enable the MMU,
there really shouldn't be anything holding people back from running with
caches enabled on AArch64. To make sure people catch early if they're missing
on the caching fun, give them a compile error.
Signed-off-by: Alexander
By now the code to only have a single page table level with 64k page
size and 42 bit address space is no longer used by any board in tree,
so we can safely remove it.
To clean up code, move the layerscape mmu code to the new defines,
removing redundant field definitions.
Signed-off-by: Alexander
Based on the memory map we can determine a lot of hard coded fields of
TCR, like the maximum VA and max PA we want to support. Calculate those
dynamically to reduce the chance for pit falls.
Signed-off-by: Alexander Graf
---
arch/arm/cpu/armv8/cache_v8.c| 59 +
We have a pretty nice and generic interface to ask for a specific block
device. However, that one is still based around the magic notion that
we know the driver name.
In order to be able to write fully generic disk access code, expose the
currently internal list to other source files so that they
The MMU range table can vary depending on things we may only find
out at runtime. While the very simple ThunderX variant does not
change, other boards will, so move the definition from a static
entry in a header file to the board file.
Signed-off-by: Alexander Graf
---
arch/arm/cpu/armv8/cache_v
This is my (now very late) Christmas present for my openSUSE friends :).
U-Boot is a great project for embedded devices. However, convincing
everyone involved that only for "a few oddball ARM devices" we need to
support different configuration formats from grub2 when all other platforms
(PPC, Syst
Now that we have nice table driven page table creating code that gives
us everything we need, move to that.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Move mmu tables into .c file
---
arch/arm/mach-tegra/arm64-mmu.c | 132 +-
include/configs/tegra210
One of the basic EFI interfaces is the console interface. Using it an EFI
application can interface with the user. This patch implements an EFI console
interface using getc() and putc().
Today, we only implement text based consoles. We also convert the EFI Unicode
characters to UTF-8 on the fly, h
The EFI loader needs to maintain views of memory - general system memory
windows as well as used locations inside those and potential runtime service
MMIO windows.
To manage all of these, add a few helpers that maintain an internal
representation of the map the similar to how the EFI API later on
When enable dcache on HiKey, we're running into MMC command timeouts
because our retry loop is now faster than the eMMC (or an external SD
card) can answer.
Increase the retry count to the same as the timeout value for status
reports.
The real fix is obviously to not base this whole thing on a cy
The hikey runs with dcache disabled today. There really should be no reason
not to use caches on AArch64, so let's add MMU definitions and enable the
dcache.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Move tables to .c file
---
board/hisilicon/hikey/hikey.c | 21 +
in
There's no good excuse for running with caches disabled on AArch64,
so let's just move the vexpress64 target to enable the MMU and run
with caches on.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Move tables to .c file
---
board/armltd/vexpress64/vexpress64.c | 21 +
in
When running in EL1, AArch64 knows two page table maps. One with addresses
that start with all zeros (TTBR0) and one with addresses that start with all
ones (TTBR1).
In U-Boot we don't care about the high up maps, so just disable them to ensure
we don't walk an invalid page table by accident.
Rep
On 3 March 2016 at 15:07, Marek Vasut wrote:
>> On 3 March 2016 at 14:42, Marek Vasut wrote:
>>> On 03/03/2016 11:27 PM, George Broz wrote:
Hi Marek,
>>>
>>> Hi!
>>>
Yes - would love to be using the SPL from 2016.01 for the Terasic board,
but it does not seem to be working for me
On Thu, Mar 3, 2016 at 4:56 AM, Peng Fan wrote:
> If including MX7D in CONFIG_SYS_EXTRA_OPTIONS, CONFIG_ROM_UNIFIED_SECTIONS
> will not effect.So move MX7D to Kconfig entry from CONFIG_SYS_EXTRA_OPTIONS
> to
> "select MX7D" to boards using i.MX7 Dual.
>
> Signed-off-by: Peng Fan
> Cc: Stefano B
On Thu, Mar 3, 2016 at 4:56 AM, Peng Fan wrote:
> If including MX6SX in CONFIG_SYS_EXTRA_OPTIONS, CONFIG_ROM_UNIFIED_SECTIONS
> will not effect.So move MX6SX to Kconfig entry from CONFIG_SYS_EXTRA_OPTIONS
> to
> "select MX6SX" to boards using i.MX6 SoloX.
>
> Signed-off-by: Peng Fan
Don't you w
On 03/03/2016 11:00 PM, George Broz wrote:
> On 3 March 2016 at 06:51, Marek Vasut wrote:
>> On 03/03/2016 03:48 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 03/02/2016 05:24 PM, Marek Vasut wrote:
Well, that's our usual USB/QSPI cache issue that's tormenting your soul.
CCing Chin ;-)
On 3 March 2016 at 06:51, Marek Vasut wrote:
> On 03/03/2016 03:48 PM, Dinh Nguyen wrote:
>>
>>
>> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>>>
>>> Well, that's our usual USB/QSPI cache issue that's tormenting your soul.
>>> CCing Chin ;-)
>>>
>>> Does the issue by any chance magically disappear
On 2 March 2016 at 23:11, Phil Reid wrote:
> On 3/03/2016 2:49 PM, George Broz wrote:
>>
>> On 1 March 2016 at 19:49, Phil Reid wrote:
>>>
>>> On 2/03/2016 10:40 AM, George Broz wrote:
>>>
Sorry for the delayed response - got called away, but am back to this
now. I patched
socfpga_
On 02/29/2016 04:26 AM, Jagan Teki wrote:
> Hi York,
>
> On 27 February 2016 at 02:14, york sun wrote:
>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>>> Hi York,
>>>
>>> On 15 February 2016 at 02:16, Jagan Teki wrote:
Compared to previous patch series this series adds spi-nor
core with
On 03/03/2016 04:57 PM, Stefan Roese wrote:
> This patch makes the following changes to the SR1500 board port:
>
> - Update defconfig to support SPI NOR (use make savedefconfig).
> - Increase SPI speed to a maximum of 100MHz for faster system
> bootup.
> - Change environment location, so that it
On 03/03/2016 04:57 PM, Stefan Roese wrote:
> This patch makes it possible that boards can define a board-specific env
> size. This is used by the SR1500 SoCFPGA board port.
>
> Signed-off-by: Stefan Roese
> Cc: Chin Liang See
> Cc: Dinh Nguyen
> Cc: Marek Vasut
> ---
> include/configs/socfpg
On 03/02/2016 06:30 PM, Yao Yuan wrote:
> On 03/03/2016 12:52 AM, York Sun wrote:
>> On 03/02/2016 02:41 AM, Yuan Yao wrote:
>>> From: Yuan Yao
>>>
>>> This patch adds QSPI boot support for LS2080AQDS board.
>>> The QSPI boot image need to be programmed into the QSPI flash first.
>>> Then the boot
On 03/02/2016 06:28 PM, Yao Yuan wrote:
> On 03/03/2016 12:52 AM, York Sun wrote:
>> On 03/02/2016 02:41 AM, Yuan Yao wrote:
>>> From: Yuan Yao
>>>
>>> If we want to access QSPI flash when boot from NAND,
>>
>> Is this "either this or that" choice? Is there any limitation after
>> configuring pin
On 03/02/2016 05:25 PM, Simon Glass wrote:
Hi Stephen,
On 29 February 2016 at 16:39, Stephen Warren wrote:
On 02/25/2016 09:00 PM, Simon Glass wrote:
Don't try to run commands when not supported.
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
+int board_run_command(
Hello Hans,
Thank you very much for your message. The PIO program reported
'PE6<0><0><1><1>' for both U-Boots but changing the configuration's
CONFIG_AXP_ALDO3_VOLT and CONFIG_AXP_ALDO4_VOLT back to 2800 did indeed
solve the problem. I can run U-Boot 2016.01 now and control PE6 properly.
LDO
This patch makes the following changes to the SR1500 board port:
- Update defconfig to support SPI NOR (use make savedefconfig).
- Increase SPI speed to a maximum of 100MHz for faster system
bootup.
- Change environment location, so that its not between SPL and
main U-Boot. This way the combin
This patch makes it possible that boards can define a board-specific env
size. This is used by the SR1500 SoCFPGA board port.
Signed-off-by: Stefan Roese
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Marek Vasut
---
include/configs/socfpga_common.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Mar 2, 2016 9:13 AM, "Alexander Graf" wrote:
>
>
>
> > Am 02.03.2016 um 12:29 schrieb Adam Ford :
> >
> >> On Tue, Mar 1, 2016 at 6:01 PM, Alexander Graf wrote:
> >>
> >>
> >>> On 02.03.16 00:23, Adam Ford wrote:
> >>> A few boards still use ns16550_platdata structures, but assume the
structur
On 2 March 2016 at 23:11, Phil Reid wrote:
> On 3/03/2016 2:49 PM, George Broz wrote:
>>
>> On 1 March 2016 at 19:49, Phil Reid wrote:
>>>
>>> On 2/03/2016 10:40 AM, George Broz wrote:
>>>
Sorry for the delayed response - got called away, but am back to this
now. I patched
socfpga_
On 03/03/2016 03:48 PM, Dinh Nguyen wrote:
>
>
> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>>
>> Well, that's our usual USB/QSPI cache issue that's tormenting your soul.
>> CCing Chin ;-)
>>
>> Does the issue by any chance magically disappear if you apply this patch:
>>
>> diff --git a/arch/arm/
On 03/02/2016 05:24 PM, Marek Vasut wrote:
>
> Well, that's our usual USB/QSPI cache issue that's tormenting your soul.
> CCing Chin ;-)
>
> Does the issue by any chance magically disappear if you apply this patch:
>
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
On 03/03/2016 12:11 PM, Sriram Dash wrote:
>
>
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Thursday, March 03, 2016 3:29 PM
>> To: Sriram Dash ; u-boot@lists.denx.de
>> Cc: york sun ; Ramneek Mehresh
>> ; Rajesh Bhagat
>> Subject: Re: [PATCH v3 2/3] board:f
On 03/03/2016 12:10 PM, Sriram Dash wrote:
>
>
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Thursday, March 03, 2016 3:26 PM
>> To: Sriram Dash ; u-boot@lists.denx.de
>> Cc: york sun ; Ramneek Mehresh
>> ; Rajesh Bhagat ; Tom
>> Rini
>> Subject: Re: [PATCH v
On 03/03/2016 12:51 PM, Stefan Roese wrote:
> Hi Chin Liang,
>
> On 02.03.2016 13:24, Chin Liang See wrote:
>>> On 01.03.2016 14:38, Chin Liang See wrote:
On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
> On 01.03.2016 07:53, Chin Liang See wrote:
>> On Mon, 2016-02-29 at 23:55
Hi Chin Liang,
On 02.03.2016 13:24, Chin Liang See wrote:
>> On 01.03.2016 14:38, Chin Liang See wrote:
>>> On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
On 01.03.2016 07:53, Chin Liang See wrote:
> On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
>> On 02/24/2016 09:59
>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Thursday, March 03, 2016 3:26 PM
>To: Sriram Dash ; u-boot@lists.denx.de
>Cc: york sun ; Ramneek Mehresh
>; Rajesh Bhagat ; Tom
>Rini
>Subject: Re: [PATCH v3 1/3] board:freescale:common: Move device-tree fixup
>framewor
>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Thursday, March 03, 2016 3:29 PM
>To: Sriram Dash ; u-boot@lists.denx.de
>Cc: york sun ; Ramneek Mehresh
>; Rajesh Bhagat
>Subject: Re: [PATCH v3 2/3] board:freescale:usb: Remove code duplication for
>fdt_usb_get_node_t
>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Thursday, March 03, 2016 3:33 PM
>To: Sriram Dash ; u-boot@lists.denx.de
>Cc: york sun ; Ramneek Mehresh
>; Rajesh Bhagat
>Subject: Re: [PATCH v3 3/3] board:freescale:usb: Add device-tree fixup support
>for
>xhci contr
On 03/03/2016 09:32 AM, Sriram Dash wrote:
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Wednesday, March 02, 2016 3:55 AM
>> To: Sriram Dash ; u-boot@lists.denx.de
>> Cc: york sun ; Ramneek Mehresh
>> ; Rajesh Bhagat
>> Subject: Re: [PATCH v3 3/3] board:freesc
On 03/03/2016 09:30 AM, Sriram Dash wrote:
>
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Wednesday, March 02, 2016 3:57 AM
>> To: Sriram Dash ; u-boot@lists.denx.de
>> Cc: york sun ; Ramneek Mehresh
>> ; Rajesh Bhagat
>> Subject: Re: [PATCH v3 2/3] board:fre
On 03/03/2016 09:29 AM, Sriram Dash wrote:
>
>
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Wednesday, March 02, 2016 3:43 AM
>> To: Sriram Dash ; u-boot@lists.denx.de
>> Cc: york sun ; Ramneek Mehresh
>> ; Rajesh Bhagat ; Tom
>> Rini
>> Subject: Re: [PATCH
On 03/03/2016 07:55 AM, George Broz wrote:
> On 2 March 2016 at 14:54, Dinh Nguyen wrote:
>
>>> socfpga_common.h and re-built the project. I picked up
>>> spl/u-boot-spl-dtb.sfp and
>>> u-boot-dtb.img and transferred them to the SD card with:
>>>
>>> dd if=u-boot-spl-dtb.sfp of=/dev/sdf3 bs=64k s
>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Wednesday, March 02, 2016 3:43 AM
>To: Sriram Dash ; u-boot@lists.denx.de
>Cc: york sun ; Ramneek Mehresh
>; Rajesh Bhagat ; Tom
>Rini
>Subject: Re: [PATCH v3 1/3] board:freescale:common: Move device-tree fixup
>framewo
>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Wednesday, March 02, 2016 3:57 AM
>To: Sriram Dash ; u-boot@lists.denx.de
>Cc: york sun ; Ramneek Mehresh
>; Rajesh Bhagat
>Subject: Re: [PATCH v3 2/3] board:freescale:usb: Remove code duplication for
>fdt_usb_get_node_t
>-Original Message-
>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Wednesday, March 02, 2016 3:55 AM
>To: Sriram Dash ; u-boot@lists.denx.de
>Cc: york sun ; Ramneek Mehresh
>; Rajesh Bhagat
>Subject: Re: [PATCH v3 3/3] board:freescale:usb: Add device-tree fixup support
>for
>xhci contro
These cyg_ prototypes are not referenced anywhere in current mainline
U-Boot. So lets remove them.
Signed-off-by: Stefan Roese
---
include/crc.h | 26 --
1 file changed, 26 deletions(-)
diff --git a/include/crc.h b/include/crc.h
index b0031b2..111cb4a 100644
--- a/includ
The original name of this function is unclear. This patch renames this
CRC16 function to crc16_ccitt() matching its name with its
implementation.
To make the usage of this function more flexible, lets add the CRC start
value as parameter to this function. This way it can be used by other
functions
lib/crc16.c is changed to match the common U-Boot coding-style.
Signed-off-by: Stefan Roese
---
lib/crc16.c | 81 ++---
1 file changed, 40 insertions(+), 41 deletions(-)
diff --git a/lib/crc16.c b/lib/crc16.c
index c63fde9..57e46f8 100644
Hi,
On 02-03-16 17:54, Hendrik wrote:
I am trying to get an Olimex A20-SOM running but I am experiencing strange
problems on some of the GPIO pins on the device.
We are using (amongst others) pin PE6 as GPIO output but somehow there seems
to be a change between U-Boot 2015.10 and 2016.01 in
If including MX7D in CONFIG_SYS_EXTRA_OPTIONS, CONFIG_ROM_UNIFIED_SECTIONS
will not effect.So move MX7D to Kconfig entry from CONFIG_SYS_EXTRA_OPTIONS to
"select MX7D" to boards using i.MX7 Dual.
Signed-off-by: Peng Fan
Cc: Stefano Babic
Cc: Fabio Estevam
---
arch/arm/cpu/armv7/mx7/Kconfig |
If including MX6SX in CONFIG_SYS_EXTRA_OPTIONS, CONFIG_ROM_UNIFIED_SECTIONS
will not effect.So move MX6SX to Kconfig entry from CONFIG_SYS_EXTRA_OPTIONS to
"select MX6SX" to boards using i.MX6 SoloX.
Signed-off-by: Peng Fan
Cc: Stefano Babic
Cc: Fabio Estevam
---
arch/arm/cpu/armv7/mx6/Kconfig
81 matches
Mail list logo
