Dear Kuo-Jung Su,
In message <1395813799-3672-7-git-send-email-dant...@gmail.com> you wrote:
> From: Kuo-Jung Su
>
> Faraday Virtual Machine (FVM) is a QEMU based emulator
> which is designed for early stage software development
> (i.e., IPL, SPL development).
...
> +ulong clk_get_rate(const cha
Dear Kuo-Jung Su,
In message <1395813799-3672-2-git-send-email-dant...@gmail.com> you wrote:
> From: Kuo-Jung Su
>
> Here is the list of verified cores:
>
> 1. FA606TE (ARMv5TE, no mmu)
> 2. FA626TE (ARMv5TE)
...
> diff --git a/include/configs/faraday-common.h
> b/include/configs/faraday-commo
2014-03-25 20:41 GMT+08:00 Albert ARIBAUD :
> Hi Kuo-Jung,
>
> On Thu, 20 Feb 2014 11:40:32 +0800, Kuo-Jung Su
> wrote:
>
>> From: Kuo-Jung Su
>>
>> These patches introduce Faraday A369 & Virtual SoC platform support.
>
> Except for patches 4/6 and 6/6 in which boards.cfg needed manual
> fixing (
From: Kuo-Jung Su
For the Faraday FTSDC021 (SDHCI) controller driver source is
sent out before the patches for Faraday Virtual Machine (FVM)
which actually uses this chip.
The header file (ftsdc021.h) has been accidentally removed
by commit: 3b98b57fa - include: delete unused header files
This
From: Kuo-Jung Su
Faraday FTPWMTMR010 is a simple APB device which supports
both timer and pwm functions.
Signed-off-by: Kuo-Jung Su
CC: Albert Aribaud
---
Changes for v11:
- Directly specify the timer object in
'arch/arm/cpu/faraday//Makefile'
instead of using CONFIG_FTPWMT
From: Kuo-Jung Su
These patches introduce Faraday A369 & Virtual SoC platform support.
Here are some public documents for your reference.
http://www.faraday-tech.com/html/Product/SoCPlatform/SoCreativeIII.htm
http://www.faraday-tech.com/html/documentation/index.html
There is also a QEMU
From: Kuo-Jung Su
Faraday Virtual Machine (FVM) is a QEMU based emulator
which is designed for early stage software development
(i.e., IPL, SPL development).
Please check the link bellow for details:
https://github.com/dantesu1218/qemu/blob/qemu-1.5.1/hw/arm/faraday_fvm.c
Signed-off-by: Kuo-Jun
From: Kuo-Jung Su
The A369 is an ARM CPU-based SoC with rich SoC features and
convenient FPGA link for building fast system prototyping
and mass production.
More information about this hardware can be found at:
http://www.faraday-tech.com/html/Product/SoCPlatform/SoCreativeIII.htm
Signed-off-by
From: Kuo-Jung Su
Faraday FTTMR010 is a simple APB device which supports
generic timer functions.
Signed-off-by: Kuo-Jung Su
CC: Albert Aribaud
---
Changes for v11:
- Directly specify the timer object in
'arch/arm/cpu/faraday//Makefile'
instead of using CONFIG_FTTMR010 in 'a
From: Kuo-Jung Su
Here is the list of verified cores:
1. FA606TE (ARMv5TE, no mmu)
2. FA626TE (ARMv5TE)
Signed-off-by: Kuo-Jung Su
CC: Albert Aribaud
---
Changes for v11:
- Nothing updates
Changes for v10:
- Merge [arm: add Faraday SoC helper files]
Changes for v9:
-
Hello Rommel,
This patch is abandoned. We are working on new set of patches.
We will send them upstream and in FSL SDK once ready.
Regards
Priyanka
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Rommel G Custodio
> Sent: W
Dear Priyanka Jain,
Priyanka Jain freescale.com> writes:
>
> Add support of 2-stage T1040QDS SPI bootloader using SPL framework.
> In this, PBL (hardware) initializes SRAM (256K) and copy SPL
> (192K) from SPI flash to SRAM and transfer control to SPL.
> This SPL bootloader furthur initializes
Dear Tom,
In message <20140325200435.GV16360@bill-the-cat> you wrote:
>
> But as Wolfgang's v4 shows, it's also not hard to just call
> clrsetbits_le32 directly. Arguably the cases where mask==1 we should
> just call setbits_le32 but that's not a big deal.
We would have to call setbits_le32() o
Dear Tom,
In message <20140325200420.GU16360@bill-the-cat> you wrote:
>
> With respect to danger / readability, no, either way is just as
> dangerous (or not dangerous) and it's still fairly dense code either
> way and fixing a problem with an incorrect shift value is the same
> effort.
The key
This patch adds support for the new PMC440 hardware revision 1.4.
The board now uses Micrel KSZ9031 phys.
Add missing i2c initialization before reading bootstrap eeprom.
Fix a couple of coding style issues.
Make local functions static.
Signed-off-by: Matthias Fuchs
---
board/esd/pmc440/pmc440
On 03/20/2014 04:13 PM, Dennis Gilmore wrote:
> some boards have used fdt_file while others have used fdtfile to
> define the name of the fdt file. If we do notget a fdtfile environment
> variable, additionally check for fdt_file.
Is this variable typically set by the user or by the default
enviro
On 03/21/2014 12:48 PM, Tom Rini wrote:
> On Thu, Mar 20, 2014 at 05:12:56PM -0500, Dennis Gilmore wrote:
>
>> Add documentation on how to setup a system to use the generic distro
>> configs and boot commands. This spells out what is needed to make a
>> system conformant, but does not limit the bo
On 03/21/2014 12:48 PM, Tom Rini wrote:
> On Thu, Mar 20, 2014 at 05:12:57PM -0500, Dennis Gilmore wrote:
>
>> As the next step in a generic config we are introducing a set of generic boot
>> paramaters. Depending on the hardwares configuration, booting from supported
>> hardware will be enabled,
On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> As the next step in a generic config we are introducing a set of generic boot
> paramaters. Depending on the hardwares configuration, booting from supported
> hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
>
> There is nothing to
On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> Add documentation on how to setup a system to use the generic distro
> configs and boot commands. This spells out what is needed to make a
> system conformant, but does not limit the board to only the defaults.
> diff --git a/doc/README.distro b/doc/
On Tue, Mar 25, 2014 at 05:54:10PM +0100, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <1395764855-23377-1-git-send-email-swar...@wwwdotorg.org> you
> wrote:
> >
> > +static inline void update_reg_mask_shift_val(u32 *reg, u32 mask, u32 shift,
> > +
On Tue, Mar 25, 2014 at 10:27:35AM -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> This removes a bunch of open-coded register IO, masking, and shifting.
> I would have squashed this into "ARM: tegra: pinctrl: remove duplication"
> except that keeping it a separate commit allows easier b
On 03/25/2014 01:09 PM, Wolfgang Denk wrote:
> From: Stephen Warren
>
> This removes a bunch of open-coded register IO, masking, and shifting.
> I would have squashed this into "ARM: tegra: pinctrl: remove duplication"
> except that keeping it a separate commit allows easier bisection of any
> is
On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote:
> Signed-off-by: Przemyslaw Marczak
Patch description? Why are these function useful on these platforms?
For completeness (I have no real ack power of Samsung platforms),
Acked-by: Stephen Warren
___
U
On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote:
> Changes:
> - randomly generate partition uuid if any is undefined and CONFIG_RAND_UUID
> is defined
> - print debug info about set/unset/generated uuid
> - update doc/README.gpt
>
> Update existing code to the new library functions.
The change
On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote:
> Those commands basis on implementation of random UUID generator version 4
> which is described in RFC4122. The same algorithm is used for generation
> both ids but string representation is different as below.
>
> char: 0914 19 24
On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote:
> This patch adds support to generate UUID (Universally Unique Identifier)
> in version 4 based on RFC4122, which is randomly.
>
> Source: https://www.ietf.org/rfc/rfc4122.txt
Some nits in the comments below, but otherwise:
Acked-by: Stephen Warre
On 03/25/2014 01:13 PM, Wolfgang Denk wrote:
> Dear Stephen,
>
> In message <1395769173-8143-1-git-send-email-swar...@wwwdotorg.org> you wrote:
>>
>> Jetson TK1 is an NVIDIA Tegra124 reference board, which shares much of
>> its design with Venice2.
> ...
>> +++ b/include/configs/jetson-tk1.h
>> @@
Dear Tom,
In message <5331bc48.7020...@wwwdotorg.org> Stephen Warren wrote:
> On 03/21/2014 12:28 PM, Stephen Warren wrote:
> > From: Stephen Warren
> >
> > This removes a bunch of open-coded register IO, masking, and shifting.
> > I would have squashed this into "ARM: tegra: pinctrl: remove dup
Dear Stephen,
In message <1395769173-8143-1-git-send-email-swar...@wwwdotorg.org> you wrote:
>
> Jetson TK1 is an NVIDIA Tegra124 reference board, which shares much of
> its design with Venice2.
...
> +++ b/include/configs/jetson-tk1.h
> @@ -0,0 +1,79 @@
> +/*
> + * (C) Copyright 2013-2014
> + *
On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote:
> Changes in lib/uuid.c to:
> - uuid_str_to_bin()
> - uuid_bin_to_str()
>
> New parameter is added to specify input/output string format in listed
> functions
> This change allows easy recognize which UUID type is or should be stored in
> given
>
From: Stephen Warren
This removes a bunch of open-coded register IO, masking, and shifting.
I would have squashed this into "ARM: tegra: pinctrl: remove duplication"
except that keeping it a separate commit allows easier bisection of any
issues that are introduced by this patch. I also wrote this
On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote:
> Changes:
> - move uuid<->string conversion functions into lib/uuid.c so they can be
> used by code outside part_efi.c.
> - rename uuid_string() to uuid_bin_to_str() for consistency with existing
> uuid_str_to_bin()
> - add an error return code
From: Stephen Warren
Jetson TK1 is an NVIDIA Tegra124 reference board, which shares much of
its design with Venice2.
Signed-off-by: Stephen Warren
---
This patch depends on my recent pinmux cleanup series.
arch/arm/dts/Makefile | 1 +
arch/arm/dts/tegra124-jetso
On 03/21/2014 12:28 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> This removes a bunch of open-coded register IO, masking, and shifting.
> I would have squashed this into "ARM: tegra: pinctrl: remove duplication"
> except that keeping it a separate commit allows easier bisection of any
> i
Dear Stephen Warren,
In message <5331b55b.7080...@wwwdotorg.org> you wrote:
>
> > No, please do not do that. Please use plain clrsetbits_le32() as is.
> > All these hidden shifts are (a) mostly unreadable and (b) sometimes
> > dangerous.
>
> Seriously, are you joking now?
No, I am not.
> I
Dear Stephen Warren,
In message <5331b4e4.5090...@wwwdotorg.org> you wrote:
>
> > Please do not invent new bit manipulation functions. Just use the
> > standard I/O accessors. And whenever possible, please remove pre-
> > existing functions.
> >
> > I've just recently sent patches to get rid of
On 03/25/2014 10:54 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <1395764855-23377-1-git-send-email-swar...@wwwdotorg.org> you
> wrote:
>>
>> +static inline void update_reg_mask_shift_val(u32 *reg, u32 mask, u32 shift,
>> + u32 val)
>> +{
On 03/25/2014 10:51 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <5331a6b6.8090...@wwwdotorg.org> you wrote:
>>
>>> Or perhaps update_reg_mask_shift_val()?
>>
>> Still, I can rename the function if you want; it certainly does make it
>> obvious. It's rather a long name though, bu
Dear Stephen Warren,
In message <1395764855-23377-1-git-send-email-swar...@wwwdotorg.org> you wrote:
>
> +static inline void update_reg_mask_shift_val(u32 *reg, u32 mask, u32 shift,
> + u32 val)
> +{
> + clrsetbits_le32(reg, mask << shift, val << shift
Dear Stephen Warren,
In message <5331a6b6.8090...@wwwdotorg.org> you wrote:
>
> > Or perhaps update_reg_mask_shift_val()?
>
> Still, I can rename the function if you want; it certainly does make it
> obvious. It's rather a long name though, but I guess wrapping the
> parameters isn't too bad.
Pl
On 03/25/2014 10:04 AM, Simon Glass wrote:
> On 25 March 2014 08:54, Stephen Warren wrote:
>> On 03/24/2014 08:27 PM, Simon Glass wrote:
>>> On 21 March 2014 11:28, Stephen Warren wrote:
This removes a bunch of open-coded register IO, masking, and shifting.
I would have squashed this in
From: Stephen Warren
This removes a bunch of open-coded register IO, masking, and shifting.
I would have squashed this into "ARM: tegra: pinctrl: remove duplication"
except that keeping it a separate commit allows easier bisection of any
issues that are introduced by this patch. I also wrote this
Hi Stephen,
On 25 March 2014 08:54, Stephen Warren wrote:
> On 03/24/2014 08:27 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On 21 March 2014 11:28, Stephen Warren wrote:
>>> From: Stephen Warren
>>>
>>> This removes a bunch of open-coded register IO, masking, and shifting.
>>> I would have squa
On 03/24/2014 08:27 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 21 March 2014 11:28, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> This removes a bunch of open-coded register IO, masking, and shifting.
>> I would have squashed this into "ARM: tegra: pinctrl: remove duplication"
>> except t
The only remaining user of the custom bit manipulation function sr32()
is arch/arm/cpu/armv7/omap3/clock.c, so make it a static function in
that file to prepare complete removal.
Signed-off-by: Wolfgang Denk
Cc: Tom Rini
Cc: Albert ARIBAUD
---
V2: fix checkpatch issues
arch/arm/cpu/armv7/oma
Replace the custom bit manipulation function sr32() by standard I/O
accessors. A major motivation for this cleanup was the fact, that a
number of calls of that function resulted in 32 bit wide shift
operations on u32 data, which according to the C-ISO/IEC-9899-Standard
provokes undefined behaviour
Replace the custom sr32() bit manipulation function in
arch/arm/cpu/armv7/omap3/board.c and board/ti/panda/panda.c
by standard I/O accessors.
Signed-off-by: Wolfgang Denk
Cc: Tom Rini
Cc: Albert ARIBAUD
---
V2: fix checkpatch issues
arch/arm/cpu/armv7/omap3/board.c | 4 ++--
board/ti/panda/pa
This patch series replaces the custom bit manipulation function sr32()
by standard I/O accessors. A major motivation for this cleanup was
the fact that a number of calls of that function resulted in 32 bit
wide shift operations on u32 data, which according to the C-ISO
IEC-9899-Standard provokes u
The only remaining user of the custom bit manipulation function sr32()
is arch/arm/cpu/armv7/omap3/clock.c, so make it a static function in
that file to prepare complete removal.
Signed-off-by: Wolfgang Denk
Cc: Tom Rini
Cc: Albert ARIBAUD
---
arch/arm/cpu/armv7/omap3/clock.c| 13
This patch series replaces the custom bit manipulation function sr32()
by standard I/O accessors. A major motivation for this cleanup was
the fact that a number of calls of that function resulted in 32 bit
wide shift operations on u32 data, which according to the C-ISO
IEC-9899-Standard provokes u
Replace the custom bit manipulation function sr32() by standard I/O
accessors. A major motivation for this cleanup was the fact, that a
number of calls of that function resulted in 32 bit wide shift
operations on u32 data, which according to the C-ISO/IEC-9899-Standard
provokes undefined behaviour
Replace the custom sr32() bit manipulation function in
arch/arm/cpu/armv7/omap3/board.c and board/ti/panda/panda.c
by standard I/O accessors.
Signed-off-by: Wolfgang Denk
Cc: Tom Rini
Cc: Albert ARIBAUD
---
arch/arm/cpu/armv7/omap3/board.c | 4 ++--
board/ti/panda/panda.c | 2 +-
2 f
Hi Kuo-Jung,
On Thu, 20 Feb 2014 11:40:32 +0800, Kuo-Jung Su
wrote:
> From: Kuo-Jung Su
>
> These patches introduce Faraday A369 & Virtual SoC platform support.
Except for patches 4/6 and 6/6 in which boards.cfg needed manual
fixing (due to commit 3fa67050), the series applies to current
u-bo
Hi Albert,
> Hi Lukasz,
>
> On Tue, 25 Mar 2014 09:55:45 +0100, Lukasz Majewski
> wrote:
>
> > Hi Albert,
> >
> > > Hi Lukasz, Tom,
> > >
> > >
> > > > Hi Tom,
> > > >
> > > > > On Tue, Mar 18, 2014 at 04:46:48PM +0100, Lukasz Majewski
> > > > > wrote:
> > > > >
> > > > > > After Kbuild in
Hello Tom,
On 03/25/2014 10:58 AM, Przemyslaw Marczak wrote:
New configs:
- CONFIG_LIB_RAND- to enable implementation of rand library in lib/rand.c
- CONFIG_LIB_HW_RAND - to enable hardware based implementations of lib rand
Other changes:
- add CONFIG_LIB_RAND to boards configs which needs
Hi Lukasz,
On Tue, 25 Mar 2014 09:55:45 +0100, Lukasz Majewski
wrote:
> Hi Albert,
>
> > Hi Lukasz, Tom,
> >
> >
> > > Hi Tom,
> > >
> > > > On Tue, Mar 18, 2014 at 04:46:48PM +0100, Lukasz Majewski wrote:
> > > >
> > > > > After Kbuild introduction, the CROSS_COMPILE environment
> > > > >
This patch adds implementation of rand library based on hardware random
number generator of security subsystem in Exynos SOC.
This library includes:
- srand() - used for seed hardware block
- rand() - returns random number
- rand_r() - the same as above with given seed
which depends on CONFIG_
This allows to use exynos random number generator by enabling configs:
- CONFIG_EXYNOS_ACE_SHA
- CONFIG_LIB_HW_RAND
Signed-off-by: Przemyslaw Marczak
Acked-by: Lukasz Majewski
cc: Piotr Wilczek
cc: Minkyu Kang
---
Changes v2:
- none
Changes v3:
- change config name CONFIG_RAND_HW_ACCEL to CO
Signed-off-by: Przemyslaw Marczak
Cc: Minkyu Kang
---
Changes v3:
- new commit - after separate changes from next commit
Changes v4:
- none
Changes v5:
- put base addresses in growing order
---
arch/arm/include/asm/arch-exynos/cpu.h | 8
1 file changed, 4 insertions(+), 4 deletions(-
New configs:
- CONFIG_LIB_RAND- to enable implementation of rand library in lib/rand.c
- CONFIG_LIB_HW_RAND - to enable hardware based implementations of lib rand
Other changes:
- add CONFIG_LIB_RAND to boards configs which needs rand()
- put only one rand.o dependency in lib/Makefile
CONFIG_
Hi Albert,
> Hi Lukasz, Tom,
>
>
> > Hi Tom,
> >
> > > On Tue, Mar 18, 2014 at 04:46:48PM +0100, Lukasz Majewski wrote:
> > >
> > > > After Kbuild introduction, the CROSS_COMPILE environment
> > > > variable has been set to some default value (prefix arm-linux-).
> > >
> > > Note that this is
Hello Minkyu,
On 03/25/2014 02:26 AM, Minkyu Kang wrote:
On 24/03/14 16:44, Przemyslaw Marczak wrote:
Hello Minkyu,
On 03/22/2014 04:18 PM, Minkyu Kang wrote:
Dear Przemyslaw Marczak,
On 21 March 2014 17:56, Przemyslaw Marczak wrote:
Signed-off-by: Przemyslaw Marczak
Cc: Minkyu Kang
-
63 matches
Mail list logo
