On 20 December 2014 at 19:27, Hans de Goede wrote:
> Hi All,
>
> There are 3 topics which I would like to cover in this mail:
>
> 1) Switching over to upstream u-boot for the linux-sunxi project
> 2) How to build upstream u-boot for use with linux-sunxi sunxi-3.4 kernels
> 3) Adding more boards to
On 21/12/2014 22:14, Nikolay Dimitrov wrote:
> Hi Iain,
>
> On 12/14/2014 04:51 PM, Iain Paton wrote:
>> Since the Riot & Mars boards are dev boards it's likely people will
>> want to
>> run standard distros on them. So replace the current boot scripts with
>> the
>> standard one from config_distr
On 18 December 2014 at 19:21, Jagannadha Sutradharudu Teki
wrote:
> This reverts commit 562f8df18da62ae02c4ace1e530451fe82c3312d.
>
> Never see the issue with N25Q128 flash without need of W#/Vpp signal
> during probe.
>
> Signed-off-by: Jagannadha Sutradharudu Teki
> Cc: Heiko Schocher
> ---
>
Hi Hans,
On Sat, Dec 20, 2014 at 7:29 PM, Hans de Goede wrote:
> Hi Ian, et al,
>
> Here is a v2 of the A23 patches which did not pass review in v1 (so not a
> resend of the whole set).
>
I just built a new u-boot for my Q8H tablet this morning against
289dcd4 sunxi: video: Set input sync ena
The intent of this series is to show the nasty problems introduced
by .
Simon and I are already discussing this in the following thread:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203954
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/198550/focus=205880
-
Commit 0d296c
CONFIG_USE_STDINT was introduced to use compiler-provided types for
fixed-width variables.
This must be consistent everywhere to avoid warnings/errors
including printf() and friends.
Assume the code below
uint32_t foo;
printf("foo= %x\n", foo);
If is included, uint32_t is defined by the co
These must be fixed to fix sandbox at least.
(Horrible things are happening on the other boards, of course.)
If we include , we do not know 64bit-types are defined
as "unsigned long long" or "unsigned long".
(As for my 64bit GCC, __UINT64_TYPE__ is "long unsigned int")
We cannot hard-code "%llx"
Hi Simon,
On Tue, 16 Dec 2014 21:38:34 -0700
Simon Glass wrote:
> Hi Masahiro,
>
> On 15 December 2014 at 18:38, Masahiro YAMADA
> wrote:
> >
> > Hi Simon,
> >
> >
> > 2014-12-16 3:38 GMT+09:00 Simon Glass :
> > > Hi Masahiro,
> > >
> > > On 15 December 2014 at 09:55, Masahiro YAMADA
> >
Hi Simon,
On Tue, 16 Dec 2014 21:44:00 -0700
Simon Glass wrote:
> Hi Masahiro,
>
> On 15 December 2014 at 18:47, Masahiro YAMADA
> wrote:
> > Simon,
> >
> >
> > 2014-12-02 5:06 GMT+09:00 Simon Glass :
> >> Hi Masahiro,
> >>
> >> On 26 November 2014 at 00:45, Masahiro Yamada
> >> wrote:
>
MMC of exynos5420 can select SPLL as source clock, so add to support
SPLL in exynos5420_get_mmc_clk(). It was tested on Odroid-XU3 board.
Signed-off-by: Joonyoung Shim
---
arch/arm/cpu/armv7/exynos/clock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b
Signed-off-by: Masahiro Yamada
---
configs/ph1_ld4_defconfig | 2 ++
configs/ph1_pro4_defconfig | 2 ++
configs/ph1_sld8_defconfig | 2 ++
3 files changed, 6 insertions(+)
diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig
index 2e9dd00..86b4b15 100644
--- a/configs/ph1_ld4_def
This commit adds on-chip I2C driver used on some old Panasonic
UniPhier SoCs.
Signed-off-by: Masahiro Yamada
---
drivers/i2c/Kconfig| 14 +++
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-uniphier.c | 225 +
3 files changed, 240 inserti
This commit adds on-chip I2C driver used on newer SoCs of Panasonic
UniPhier platform.
Signed-off-by: Masahiro Yamada
---
drivers/i2c/Kconfig | 8 +
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-uniphier-f.c | 355 +++
3 files changed,
Masahiro Yamada (4):
i2c: UniPhier: add driver for UniPhier i2c controller
i2c: UniPhier: add driver for UniPhier FIFO-builtin i2c controller
ARM: UniPhier: enable UniPhier I2C driver
ARM: UniPhier: enable CONFIG_I2C_EEPROM
configs/ph1_ld4_defconfig| 2 +
configs/ph1_pro4_defconf
Signed-off-by: Masahiro Yamada
---
To apply this commit, the following must be applied in advance:
http://patchwork.ozlabs.org/patch/422543/
include/configs/uniphier.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 5a53c50..
If is included, the definition of fixed-width types
are compiler-dependent.
For example, some compilers use "unsigned long" and some compilers
use "unsigned int" for 32bit width typedefs.
That means, we can no longer use hard-code "%x" or "%d"
to print 32bit-width variables.
We use printf() eve
Linux expects "unsigned long" has the same bit-width as the pointer,
i.e. the size of "unsigned long" is 4 on 32-bit compilers (ILP32)
and it is 8 on 64-bit compilers (LLP64).
It provides us the convenience in return of the limitation that
LP64 data model is not supported.
U-Boot used to follow Li
Commit 0d296cc2d3b (Provide option to avoid defining a custome version of
uintptr_t)
and commit 4166ecb247 (Add some standard headers external code might need)
made a horrible decision.
I raised a flag in the following threads:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203954
http:/
For the same reason as the last commit, keep the typedefs of
__s{8,16,32,64} and __u{8,16,32,64} compatible with other types.
Signed-off-by: Masahiro Yamada
Cc: Gabe Black
Cc: Simon Glass
Cc: Bill Richardson
Cc: Tom Rini
---
arch/arc/include/asm/types.h| 16
arch/ar
If CONFIG_USE_STDINT is defined, (u)int_{8,16,32,64}_t are provided
by . s{8,16,32,64}, u{8,16,32,64} must be consistent with them.
For example, some compilers define "uint32_t" as "unsigned long" and
some define it as "unsigned int". "u32" should have the compatible type
with "uint32_t".
We can
On 12/12/14 14:45, Hyungwon Hwang wrote:
> This is v11 of the patchset adding support Odroud XU3 board.
>
> link to the previous version:
> v2: https://www.mail-archive.com/u-boot@lists.denx.de/msg152275.html
> v3: https://www.mail-archive.com/u-boot%40lists.denx.de/msg152677.html
> v4: https://pa
Dear Sjoerd Simons,
On 06/12/14 05:01, Sjoerd Simons wrote:
> USB is a pretty common feature on exynos 5 board, so it seems sensible
> to configure it directly from exynos5-common. As a side-effect this
> makes USB available from u-boot on exynos 5420 based boards.
>
> While there enable support
On 06/12/14 02:12, Sjoerd Simons wrote:
> With current u-boot-samsung HEAD on a peach-pi the following error is printed:
> exynos_lcd_power_on: ps8625_init() failed
>
> Which is not surprising given that chip does not exist on these boards.
>
> Changes since v2:
> * Move the parade_init funct
On 06/12/14 05:46, Sjoerd Simons wrote:
> Since commit 4a271cb1b4ffdf330 (exynos: usb: Switch USB VBUS GPIOs to be
> device tree configured) it's not needed for the board specific files to
> turn on the VBUS GPIO by hand as that gets done based on device tree. So
> drop the redundant code from the
On 06/12/14 05:26, Sjoerd Simons wrote:
> Add samsung,vbus-gpio information for the XU3. This allows the usage of
> the EHCI controller on the XU3, which is connected to the SMSC LAN9514
> chip (usb hub + network).
>
> Signed-off-by: Sjoerd Simons
> ---
> Changes since v1:
> + Correct gpio numb
Hi Ye Li,
On Wed, Nov 5, 2014 at 6:33 AM, Li Ye-B37916 wrote:
>> Why not use power_init_board()?
>> It's dedicated and called at common/board_r.c.
>>
> Good suggestion, will change to use the power_init_board in v2.
Have you had a chance to send a v2 for this series?
I still don't see this pat
On Fri, 2014-12-19 at 18:10 +0100, Hans de Goede wrote:
> Add 2 helper functions to get strings, reps. ints from the options value
> returned by video_get_video_mode() / video_get_ctfb_res_modes().
I can't quite parse this, what is "reps. ints"?
Also, it's "separated" not "seperated" (throughout)
On Fri, 2014-12-19 at 18:10 +0100, Hans de Goede wrote:
> Switch from fb_videomode to ctfb_res_modes and use the predefined videotimings
> from videomodes.c, rather then defining our own.
>
> Signed-off-by: Hans de Goede
Acked-by: Ian Campbell
___
U
On Fri, 2014-12-19 at 18:10 +0100, Hans de Goede wrote:
> Add support for the standard video-mode environment variable using the
> videomodes.c video_get_ctfb_res_modes() helper function.
>
> This will allow users to specify the resolution e.g. :
>
> setenv video-mode sunxi:video-mode=1280x1024-2
On Fri, 2014-12-19 at 18:10 +0100, Hans de Goede wrote:
> Allow the user to specify hpd=0 as option in the video-mode env. variable,
> if hpd is set to 0 then the hdmi output will be brought up even if no cable
> is connected.
>
> Signed-off-by: Hans de Goede
Acked-by: Ian Campbell
__
Dear Masahiro Yamada,
In message <1419243363-11542-6-git-send-email-yamad...@jp.panasonic.com> you
wrote:
> These must be fixed to fix sandbox at least.
> (Horrible things are happening on the other boards, of course.)
>
> If we include , we do not know 64bit-types are defined
> as "unsigned lon
On Fri, 2014-12-19 at 18:10 +0100, Hans de Goede wrote:
> Add DDC & EDID support and use it to automatically select the native mode of
> the attached monitor. This can be disabled by adding edid=0 as option
> to the video-mode env. variable.
>
> Signed-off-by: Hans de Goede
Acked-by: Ian Campbel
On Sat, 2014-12-20 at 15:42 +0100, Hans de Goede wrote:
> So far we've been programming the hdmi-encoder to send out dvi data over the
> hdmi connector. This works well for most devices, including hdmi devices, but
> not all devices accept dvi data on a hdmi input.
>
> Add support for sending prop
On Sat, 2014-12-20 at 15:42 +0100, Hans de Goede wrote:
> Add a sunxi_hdmi_edid_get_block helper function, this is a preparation patch
> for adding support for parsing EDID extension blocks.
>
> Signed-off-by: Hans de Goede
Acked-by: Ian Campbell
__
Dear Masahiro,
In message <1419243363-11542-1-git-send-email-yamad...@jp.panasonic.com> you
wrote:
>
> Commit 0d296cc2d3b (Provide option to avoid defining a custome version of
> uintptr_t)
> and commit 4166ecb247 (Add some standard headers external code might need)
> made a horrible decision.
On Sat, 2014-12-20 at 15:42 +0100, Hans de Goede wrote:
> When using edid use CEA681 edid extension blocks to select between dvi and
> hdmi output formats, so that u-boot will automatically do the right thing.
>
> Signed-off-by: Hans de Goede
Acked-by: Ian Campbell
___
On Sat, 2014-12-20 at 15:42 +0100, Hans de Goede wrote:
> When using a hdmi powered hdmi to vga dongle, and cold booting a sunxi
> device, the hpd detect code would not see the dongle (until a warm reboot),
> because the dongle needs some time to boot.
>
> Testing has shown that this dongle needs
On Sat, 2014-12-20 at 15:42 +0100, Hans de Goede wrote:
> Add a write to the "unknown" (*) register to enable auto input sync, when
> initially adding sunxi hdmi output support this magic write from the android
> kernel code was missed, causing lcdc -> hdmi encoder sync problems.
>
> With this wri
On Sat, 2014-12-20 at 15:41 +0100, Hans de Goede wrote:
> Hi Anatolij & Ian,
>
> Here is a second series of sunxi video support improvments.
>
> Anatolij, can you please review the first patch of the series? You're input
> on the rest is welcome too of course :)
I've been through them and they l
On Sun, 2014-12-21 at 11:53 -0700, Simon Glass wrote:
> On 19 December 2014 at 20:41, Axel Lin wrote:
> > It does not make sense to make gpio_direction_input() return the gpio input
> > status. The return value of gpio_direction_input() is inconsistent if
> > CONFIG_DM_GPIO is defined.
> > And we
On Sat, 2014-12-20 at 12:29 +0100, Hans de Goede wrote:
> sun8i (A23) introduces a new bus for communicating with the pmic, the rsb,
> the rsb is also used to communicate with the pmic on the A80, and is
> documented in the A80 user manual.
>
> This commit adds support for this based on the rsb dr
On Sat, 2014-12-20 at 12:29 +0100, Hans de Goede wrote:
> Based on the register / dram_para headers from the Allwinner u-boot / linux
> sources + the init sequences from boot0.
>
> Signed-off-by: Hans de Goede
All my queries last time were on the defconfig, which is now split out,
so: Acked-by:
On Sat, 2014-12-20 at 12:29 +0100, Hans de Goede wrote:
> Now that we've sun8i dram-init support we can enable the SPL for sun8i boards.
>
> While at it also replace CONFIG_DEFAULT_DEVICE_TREE with CONFIG_FDTFILE,
> the former is for u-boot's own fdt usage, which we do not use (yet), the later
> s
Hi,
On 22-12-14 09:32, Michal Suchanek wrote:
On 20 December 2014 at 19:27, Hans de Goede wrote:
Hi All,
There are 3 topics which I would like to cover in this mail:
1) Switching over to upstream u-boot for the linux-sunxi project
2) How to build upstream u-boot for use with linux-sunxi sunx
Hi,
On 21-12-14 21:40, Emilio López wrote:
Sorry for the noise, I messed up and was using the Cubieboard config instead of the
Cubietruck one >.<
Seems to work fine other than this warning:
Error: dwmac.1c5 address ab:cd:ef:ab:cd:ef illegal value
Weird, try doing:
setenv ethaddr
sav
On Mon, 2014-12-22 at 14:53 +0100, Hans de Goede wrote:
> Or alternatively, nuke your environment so that you get the default
> one using:
>
> sudo dd if=/dev/zero of=/dev/sdc bs=1024 seek=544 count=256
You can do this with the env command from the u-boot cmdline too. I
forget the parameters, but
2014-12-22 20:59 GMT+08:00 Ian Campbell :
> On Sun, 2014-12-21 at 11:53 -0700, Simon Glass wrote:
>> On 19 December 2014 at 20:41, Axel Lin wrote:
>> > It does not make sense to make gpio_direction_input() return the gpio input
>> > status. The return value of gpio_direction_input() is inconsisten
On Fri, 2014-12-19 at 17:55 +0100, Hans de Goede wrote:
> Hi,
>
> On 18-12-14 20:12, Ian Campbell wrote:
> > On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote:
> >> The sun8i boot0 code fills the DRAM with a "random" pattern before
> >> comparing
> >> it at different offsets to do columns, e
On Mon, 22 Dec 2014 14:19:20 +
Ian Campbell wrote:
> On Fri, 2014-12-19 at 17:55 +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 18-12-14 20:12, Ian Campbell wrote:
> > > On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote:
> > >> The sun8i boot0 code fills the DRAM with a "random" pattern
On Mon, 2014-12-22 at 16:32 +0200, Siarhei Siamashka wrote:
> On Mon, 22 Dec 2014 14:19:20 +
> Ian Campbell wrote:
>
> > On Fri, 2014-12-19 at 17:55 +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 18-12-14 20:12, Ian Campbell wrote:
> > > > On Tue, 2014-12-16 at 21:31 +0100, Hans de Goe
On Mon, 22 Dec 2014 17:35:02 +0800
Chen-Yu Tsai wrote:
> Hi Hans,
>
> On Sat, Dec 20, 2014 at 7:29 PM, Hans de Goede wrote:
> > Hi Ian, et al,
> >
> > Here is a v2 of the A23 patches which did not pass review in v1 (so not a
> > resend of the whole set).
> >
>
> I just built a new u-boot for m
Hi,
On 22-12-14 15:19, Ian Campbell wrote:
On Fri, 2014-12-19 at 17:55 +0100, Hans de Goede wrote:
Hi,
On 18-12-14 20:12, Ian Campbell wrote:
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote:
The sun8i boot0 code fills the DRAM with a "random" pattern before comparing
it at different o
Hi,
On 22-12-14 13:35, Ian Campbell wrote:
On Fri, 2014-12-19 at 18:10 +0100, Hans de Goede wrote:
Add 2 helper functions to get strings, reps. ints from the options value
returned by video_get_video_mode() / video_get_ctfb_res_modes().
I can't quite parse this, what is "reps. ints"?
Oops s
Hi all,
Im using a Freescale QorIQ P1020 custom board, booting from serial NOR
flash (SPI), U-Boot 2014.10.
It was everything OK, then I enabled POST memory test in my config file:
#define CONFIG_POST CONFIG_SYS_POST_MEMORY
When booting, the output is:
-
U-Boot 2014.10-6-gc81dc6b
Dear Allan,
In message
you wrote:
>
> Im using a Freescale QorIQ P1020 custom board, booting from serial NOR
> flash (SPI), U-Boot 2014.10.
...
> Im afraid that this test is hiding another errors, because its testing
> the whole DDR range. And in post/tests.c the flag POST_ROM is set, but
I do
Hi Fabio,
On 11/21/2014 08:42 PM, Fabio Estevam wrote:
From: Fabio Estevam
When an invalid USDHC port is passed we should return -EINVAL instead of 0.
Also, return the error immediately on fsl_esdhc_initialize() failure.
Cc: Eric Benard
Signed-off-by: Fabio Estevam
---
board/embest/mx6bo
On Mon, Dec 22, 2014 at 2:32 PM, Nikolay Dimitrov wrote:
> Excuse me for the (very) late question, but just stumbled upon this
> patch.
>
> Isn't it possible to continue the initialization of the next ESDHC
> module when the current one fails?
If the initialization of any esdhc port failed, it m
Hi,
On 21-12-14 19:52, Simon Glass wrote:
Hi,
I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
Scrolling seems very slow though - is the L2 cache disabled perhaps?
I don't think so, but it could be, I think the scrolling code is just
very inefficient. Feel free to poke thin
On Mon, 22 Dec 2014 14:50:09 +0100
Hans de Goede wrote:
> Hi,
>
> On 22-12-14 09:32, Michal Suchanek wrote:
> > On 20 December 2014 at 19:27, Hans de Goede wrote:
> >> Hi All,
> >>
> >> There are 3 topics which I would like to cover in this mail:
> >>
> >> 1) Switching over to upstream u-boot f
On Mon, Dec 22, 2014 at 2:28 PM, Wolfgang Denk wrote:
> Dear Allan,
>
> In message
> you
> wrote:
>>
>> Im using a Freescale QorIQ P1020 custom board, booting from serial NOR
>> flash (SPI), U-Boot 2014.10.
> ...
>> Im afraid that this test is hiding another errors, because its testing
>> the w
Dear Masahiro,
On 15/12/2014 17:46, Masahiro YAMADA wrote:
This is a known (and unfortunate) problem.
The Linux m68k toolchains (as I am using) define size_t as "unsigned
int", whereas bare-metal m68k toolchains (as you are using) define
size_t as "unsigned long".
People often want to adjust
Hi Hua,
On 21 December 2014 at 13:45, Hua Yanghao wrote:
>
> Being a long time u-boot developer, this is the first time I'm trying
> to get some fix for the open source code back to mainline.
> If anything wrong during the process, please be gentle :-) Thank you.
>
> From 225c8f8f2af4cf6092260e5c
Hi Masahiro,
On 21 December 2014 at 19:49, Masahiro Yamada wrote:
> Hi Simon,
>
>
>
> On Fri, 19 Dec 2014 13:48:16 -0700
> Simon Glass wrote:
>
>> On 19 December 2014 at 06:39, Masahiro Yamada
>> wrote:
>> > Jagan,
>> >
>> > On Fri, 19 Dec 2014 18:43:37 +0530
>> > Jagan Teki wrote:
>> >
>> >>
From: Dennis Gilmore
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.
Signed-off-by: Dennis Gilmore
[swarren, added concept, user config,
From: James Doublesin
Need to provide PLL values for all possible input frequencies (19.2, 24,
25, 26MHz). Values provide are also optimized for jitter (needed
especially for PER PLL and DDR PLL).
Signed-off-by: James Doublesin
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 59
From: James Doublesin
Switch to using hardware leveling for certain parameters on the EMIF
rather than using precalculated values. Doing this also means we have a
common place now between am437x and am335x for setting
emif_sdram_ref_ctrl with a value for the correct delay length.
Tested-by: Fel
A switch statement fits better in this case,
specially considering we have a few extra
frequencies to use.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index
From: James Doublesin
The frequencies for 25MHz in dpll_per were out of spec for 25MHz,
correct.
Signed-off-by: James Doublesin
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx
DCDC1 is used as VDD_MPU in all known boards,
let's define all other valid voltages for that
rail so it can be used by our boards.
Signed-off-by: Felipe Balbi
---
include/power/tps65218.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/power/tps65218.h b/include/power/tps65218.h
i
This regulator is used with AM437x IDK to feed
VDD_MPU, without means to scale VDD_MPU we can't
support higher frequencies.
Signed-off-by: Felipe Balbi
---
drivers/power/pmic/Makefile| 1 +
drivers/power/pmic/pmic_tps62362.c | 47 ++
2 files changed,
Make sure that all OPPs are checked on
scale_vcores(). While at that also fix 600MHz
VDD_MPU voltage according to AM437x Data Manual
available at [1].
Table 5-3 on that document, lists all valid
voltages per frequency.
[1] http://www.ti.com/lit/ds/symlink/am4379.pdf
Signed-off-by: Felipe Balbi
AM43xx Industrial Development Kit is a new board
based on AM437x line of SoCs. Targetted at Industrial
Automation applications, it comes with EtherCAT, motor
control and other goodies.
Thanks to James Doublesin for all the help.
Cc: James Doublesin
Signed-off-by: Felipe Balbi
---
board/ti/am43
HI Bin,
On 19 December 2014 at 22:36, Bin Meng wrote:
>
> Hi Simon,
>
> On Sat, Dec 20, 2014 at 1:00 PM, Simon Glass wrote:
> > Hi Bin,
> >
> > On 19 December 2014 at 19:43, Bin Meng wrote:
> >> Hi Simon,
> >>
> >> On Sat, Dec 20, 2014 at 5:52 AM, Simon Glass wrote:
> >>> Hi BIn,
> >>>
> >>> O
Hi Hans,
On 22 December 2014 at 09:45, Hans de Goede wrote:
> Hi,
>
> On 21-12-14 19:52, Simon Glass wrote:
>>
>> Hi,
>>
>> I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
>>
>> Scrolling seems very slow though - is the L2 cache disabled perhaps?
>
>
> I don't think so, but it
Hi Masahiro,
On 22 December 2014 at 03:15, Masahiro Yamada wrote:
> The intent of this series is to show the nasty problems introduced
> by .
>
> Simon and I are already discussing this in the following thread:
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203954
> http://thread.gmane.
Hi Masahiro,
On 22 December 2014 at 03:16, Masahiro Yamada wrote:
> CONFIG_USE_STDINT was introduced to use compiler-provided types for
> fixed-width variables.
> This must be consistent everywhere to avoid warnings/errors
> including printf() and friends.
>
> Assume the code below
>
> uint32_t
Hi Masahiro,
On 22 December 2014 at 03:16, Masahiro Yamada wrote:
> These must be fixed to fix sandbox at least.
> (Horrible things are happening on the other boards, of course.)
>
> If we include , we do not know 64bit-types are defined
> as "unsigned long long" or "unsigned long".
> (As for my
Hi Masahiro,
On 22 December 2014 at 03:16, Masahiro Yamada wrote:
> If is included, the definition of fixed-width types
> are compiler-dependent.
>
> For example, some compilers use "unsigned long" and some compilers
> use "unsigned int" for 32bit width typedefs.
>
> That means, we can no longer
Hi Masahiro,
On 22 December 2014 at 03:30, Masahiro Yamada wrote:
> Hi Simon,
>
>
>
> On Tue, 16 Dec 2014 21:44:00 -0700
> Simon Glass wrote:
>
>> Hi Masahiro,
>>
>> On 15 December 2014 at 18:47, Masahiro YAMADA
>> wrote:
>> > Simon,
>> >
>> >
>> > 2014-12-02 5:06 GMT+09:00 Simon Glass :
>> >>
Hello, Pierre.
Could you please help me to understand why you used R1b with
MMC_CMD_WRITE_MULTIPLE_BLOCK in mmc_rpmb_request:
+ cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK;
+ cmd.cmdarg = 0;
+ cmd.resp_type = MMC_RSP_R1b;
Because according to the spec CMD25 has R1 response, als
Hi Masahiro,
On 22 December 2014 at 03:16, Masahiro Yamada wrote:
> Linux expects "unsigned long" has the same bit-width as the pointer,
> i.e. the size of "unsigned long" is 4 on 32-bit compilers (ILP32)
> and it is 8 on 64-bit compilers (LLP64).
> It provides us the convenience in return of the
Hello Jagan,
Am 22.12.2014 09:58, schrieb Jagan Teki:
On 18 December 2014 at 19:21, Jagannadha Sutradharudu Teki
wrote:
This reverts commit 562f8df18da62ae02c4ace1e530451fe82c3312d.
Never see the issue with N25Q128 flash without need of W#/Vpp signal
during probe.
Signed-off-by: Jagannadha S
Signed-off-by: Dirk Behme
---
tools/buildman/README | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index bfb2f18..0f8ea20 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -42,7 +42,7 @@ Theory of Op
Acked-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
On 12/22/2014 07:46 PM, Joonyoung Shim wrote:
> MMC of exynos5420 can select SPLL as source clock, so add to support
> SPLL in exynos5420_get_mmc_clk(). It was tested on Odroid-XU3 board.
>
> Signed-off-by: Joonyoung Shim
> ---
> arch/arm/cp
84 matches
Mail list logo