Hello Vagrant,
Am 19.07.2015 um 15:14 schrieb Vagrant Cascadian:
On 2015-07-19, Holger Levsen wrote:
All this said, if you send me patches, I will probably deploy them as I'm
very curious and more reproducibility efforts are good :-) We can can
always decide to remove or move them later.
I wi
Hi Simon, Albert.
2015-07-18 23:37 GMT+09:00 Simon Glass :
> +Hans
>
> Hi,
>
> On 13 July 2015 at 11:16, Albert ARIBAUD wrote:
>> Hello Masahiro,
>>
>> On Mon, 13 Jul 2015 20:42:15 +0900, Masahiro Yamada
>> wrote:
>>> 2015-07-13 19:55 GMT+09:00 Albert ARIBAUD :
>>> > Hello Masahiro,
>>> >
>>>
On 7/2/2015 5:17 PM, Haikun Wang wrote:
> Some old dataflash chips don't have device ID,
> we should identif them using bits in the flash status byte.
> Add a variable status_byte in struct flash_info,
> and assign correct value for above old chips.
> Add those chips to the supported flash chip tab
On 7/7/2015 1:33 AM, Simon Glass wrote:
> On 2 July 2015 at 03:12, Haikun Wang wrote:
>> Signed-off-by: Haikun Wang
>> ---
>> drivers/mtd/spi/sf_dataflash.c | 28 +---
>> 1 file changed, 17 insertions(+), 11 deletions(-)
>
> Missing commit message. Otherwise:
>
> Review
On 7/7/2015 1:33 AM, Simon Glass wrote:
> On 2 July 2015 at 03:12, Haikun Wang wrote:
>> Add error handler when write/erase flash fail.
>>
>> Signed-off-by: Haikun Wang
>> ---
>> drivers/mtd/spi/sf_dataflash.c | 30 ++
>> 1 file changed, 22 insertions(+), 8 deletion
On 7/7/2015 1:33 AM, Simon Glass wrote:
> Hi,
>
> On 2 July 2015 at 03:12, Haikun Wang wrote:
>> Signed-off-by: Haikun Wang
>
> Missing commit message. Doesn't this mean it will always do the verify?
>
>> ---
>> drivers/mtd/spi/sf_dataflash.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> dif
On 7/2/2015 5:17 PM, Haikun Wang wrote:
> Signed-off-by: Haikun Wang
> ---
> drivers/mtd/spi/sf_dataflash.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_dataflash.c b/drivers/mtd/spi/sf_dataflash.c
> index 3111f4f..f83f994 100644
> --- a/drivers/
On 5/11/2015 10:59 AM, Simon Glass wrote:
> Hi,
>
> On 10 May 2015 at 07:04, Jagan Teki wrote:
>> On 8 May 2015 at 13:51, haikun.w...@freescale.com
>> wrote:
>>> On 5/8/2015 1:53 PM, Jagan Teki wrote:
On 8 May 2015 at 08:14, haikun.w...@freescale.com
wrote:
> On 5/7/2015 7:44 PM, J
Hi Simon,
On Mon, Jul 20, 2015 at 9:59 AM, Simon Glass wrote:
> Hi Bin,
>
> On 18 July 2015 at 10:20, Bin Meng wrote:
>> In driver model, each pci bridge device has its own hose structure.
>> hose->first_busno points to the bridge device's device number, so
>> we should not substract hose->first
HI Masahiro,
In my fiddling with Rockchip in SPL I found that the current single
config is simple, but a little too limited. You discussed this briefly
with someone from Marvell also. At present we effectively have two
options:
1. decide for all boards that a uclass should be supported in SPL (an
Hi Hans,
I've been thinking about the USB unbinding code. I know that I agreed
to go with it, but in retrospect I think that was a mistake.
I believe we should separate out the unbinding and make it an option,
so that it is not required in order to use USB. In effect this makes
one of driver mode
Hi Peter,
On 19 July 2015 at 03:39, Peter Griffin wrote:
> Hi Simon,
>
>
>> On 8 July 2015 at 09:57, Peter Griffin wrote:
>> > This patch adds the glue code for hi6220 SoC which has 2x synopsis
>> > dw_mmc controllers. This will be used by the hikey board support
>> > in subsequent patches.
>> >
On 26 June 2015 at 05:56, Haikun Wang wrote:
> From: Haikun Wang
>
> Fix below build warnings on armv8,
> drivers/spi/fsl_dspi.c: In function ‘fsl_dspi_ofdata_to_platdata’:
> drivers/spi/fsl_dspi.c:667:2:
> warning: format ‘%x’ expects argument of type ‘unsigned int’,
> but argument 2 has
+Thierry
Hi Scott,
On 18 July 2015 at 11:42, Scott Wood wrote:
> On Sat, 2015-07-18 at 08:36 -0600, Simon Glass wrote:
>> Hi Scott,
>>
>> On 14 July 2015 at 12:16, Scott Wood wrote:
>> > On Wed, 2015-07-15 at 01:08 +0900, Masahiro Yamada wrote:
>> > > This series fixes bugs of libfdt.
>> > >
>>
On 18 July 2015 at 08:37, Simon Glass wrote:
> On 15 July 2015 at 02:23, Bin Meng wrote:
>> Add a RTC node in the device tree to enable DM RTC support.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> arch/x86/dts/chromebook_link.dts| 1 +
>> arch/x86/dts/chromebox_panther.dts | 1 +
>> arch/x86
On 18 July 2015 at 08:37, Simon Glass wrote:
> On 15 July 2015 at 02:23, Bin Meng wrote:
>> IRQ 0 is reserved and should not be assigned to pci device.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> arch/x86/cpu/pci.c | 2 ++
>> 1 file changed, 2 insertions(+)
>
> Acked-by: Simon Glass
Applied to
On 18 July 2015 at 08:37, Simon Glass wrote:
> On 15 July 2015 at 02:23, Bin Meng wrote:
>> We need walk through all functions within a PCI device and assign
>> their IRQs accordingly.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> arch/x86/cpu/pci.c | 27 +--
>> ar
On 18 July 2015 at 14:49, Simon Glass wrote:
> On 16 July 2015 at 20:43, Bin Meng wrote:
>> The doc wrongly put sandbox in the '--fetch-arch' command. Remove it.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> tools/buildman/README | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Ack
On 18 July 2015 at 08:37, Simon Glass wrote:
> On 15 July 2015 at 02:23, Bin Meng wrote:
>> Turn on cache on the pci option rom area to improve the performance.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> arch/x86/cpu/cpu.c | 27 ---
>> arch/x86/include/asm/mtrr.
On 18 July 2015 at 08:37, Simon Glass wrote:
> On 9 July 2015 at 20:38, Bin Meng wrote:
>> Some exceptions cause an error code to be saved on the current stack
>> after the EIP value. We should extract CS/EIP/EFLAGS from different
>> position on the stack based on the exception number.
>>
>> Sign
On 9 July 2015 at 20:51, Bin Meng wrote:
> Instead of using switch..case for architecture defined exceptions,
> simply unify the handling by printing a message of exception name,
> followed by registers dump then halt the CPU.
>
> With this unification, it also fixes the wrong exception numbers
>
On 18 July 2015 at 10:20, Bin Meng wrote:
> In dm_pci_hose_probe_bus(), pci_bus_find_devfn() is called with a bdf
> which includes a bus number, but it really should not as this routine
> only expects a device/function encoding.
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/pci/pci-uclass.c | 2
Hi Bin,
On 18 July 2015 at 10:20, Bin Meng wrote:
> In driver model, each pci bridge device has its own hose structure.
> hose->first_busno points to the bridge device's device number, so
> we should not substract hose->first_busno before programming the
> bridge device's primary/secondary/subord
On 18 July 2015 at 10:20, Bin Meng wrote:
> Move to driver model pci for Intel queensbay/crownbay.
>
> Signed-off-by: Bin Meng
>
> ---
>
> arch/x86/cpu/queensbay/Makefile | 1 -
> arch/x86/cpu/queensbay/tnc.c | 5 -
> arch/x86/cpu/queensbay/tnc_pci.c | 46
> --
On 18 July 2015 at 10:20, Bin Meng wrote:
> Currently pci_bus_read_config() and pci_bus_write_config() are
> called with bus number masked off in the parameter bdf, and bus
> number is supposed to be added back in the bridge driver's pci
> config read/write ops if the device is behind a pci bridge
On 18 July 2015 at 10:20, Bin Meng wrote:
> Commit aec241d "dm: pci: Use the correct hose when configuring devices"
> was an attempt to fix pci bridge device configuration, but unfortunately
> that does not work 100%. In pciauto_config_devices(), the fix tried to
> call pciauto_config_device() wit
On 18 July 2015 at 10:20, Bin Meng wrote:
> This corrects several typos in the comment block as well as some
> indentions and nits in the linker_lists.h.
>
> Signed-off-by: Bin Meng
> ---
>
> include/linker_lists.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
A
>>> I tried to find a way to download a file with wget or a similar tool, which
>>> would be used by a distribution builder (like Yocto, Buildroot, OpenWrt,
>>> ...).
>>
>> Why would any build environment use tarballs? can you not just
>> reference the git repository? This is much more efficient
Dear Wolfgang,
Am 15.07.2015 um 14:51 schrieb Wolfgang Denk:
> In message <593aef6c47f46446852b067021a273d6fbc78...@mucse037.lantiq.com> you
> wrote:
>>
>> I tried to find a way to download a file with wget or a similar tool, which
>> would be used by a distribution builder (like Yocto, Buildro
Le dimanche 19 juillet 2015 à 17:47 +0200, Holger Levsen a écrit :
> > There seem to be two solutions to this:
> > * Including a script (e.g. the one from coreboot) to build the toolchain
> > as part of the build process
> > * Using native builds with visualization on the servers that run the
> > b
Hi,
On Sonntag, 19. Juli 2015, Paul Kocialkowski wrote:
> > I *think* that actually makes u-boot build reproducibly with Debian's
> > reproducible builds toolchain when SOURCE_DATE_EPOCH is set, but I
> > haven't tested it fully. I might have missed some other sources of
> > non-determinism...
> W
Hi Paul,
On Sonntag, 19. Juli 2015, Paul Kocialkowski wrote:
> > sorry for the late reply.
>
> No problem, I haven't kept you or the list posted on this either.
>
> I got a chance to discuss the issue with Lunar during RMLL 2015 and we
> came up with a nice way of doing things, using SOURCE_DATE
Hi Paul,
sorry for the late reply.
On Samstag, 13. Juni 2015, Paul Kocialkowski wrote:
> > you've seen https://reproducible.debian.net/u-boot ?
> This seems very minimalistic, but it's good to see U-Boot was given some
> attention already!
:-)
> > but maybe you can explain why u-boot needs mo
Le dimanche 19 juillet 2015 à 06:14 -0700, Vagrant Cascadian a écrit :
> On 2015-07-19, Holger Levsen wrote:
> >> > All this said, if you send me patches, I will probably deploy them as I'm
> >> > very curious and more reproducibility efforts are good :-) We can can
> >> > always decide to remove o
> sorry for the late reply.
No problem, I haven't kept you or the list posted on this either.
I got a chance to discuss the issue with Lunar during RMLL 2015 and we
came up with a nice way of doing things, using SOURCE_DATE_EPOCH.
> On Samstag, 13. Juni 2015, Paul Kocialkowski wrote:
> > > you'
Mainline Linux kernel commit
338a6aaabc02fa63b70441dd0e1b70aea64673c6 (ARM: dts: Introduce
STM32F429 MCU) in arch/arm/boot/dts/stm32f429.dtsi
requires U-Boot to set system clock to 180 MHz.
Signed-off-by: Antonio Borneo
To: Albert Aribaud
To: Tom Rini
To: Kamil Lulko
Cc: u-boot@lists.denx.de
-
While most stm32f4 run at 168 MHz, stm32f429 can work till 180 MHz.
Add option to select 180 MHz through macro CONFIG_SYS_CLK_FREQ.
Signed-off-by: Antonio Borneo
To: Albert Aribaud
To: Tom Rini
To: Kamil Lulko
Cc: u-boot@lists.denx.de
---
arch/arm/cpu/armv7m/stm32f4/clock.c | 34 +
Read device unique ID and set environment variable "serial#".
Value would then be passed to kernel through DTB.
To read ID from DTB, kernel is required to have commit:
3f599875e5202986b350618a617527ab441bf206 (ARM: 8355/1: arch: Show
the serial number from devicetree in cpuinfo)
This commit is alr
On 2015-07-19, Holger Levsen wrote:
>> > All this said, if you send me patches, I will probably deploy them as I'm
>> > very curious and more reproducibility efforts are good :-) We can can
>> > always decide to remove or move them later.
>>
>> I wish to make all contributions upstream. What would
Hi,
On 16-07-15 01:17, Simon Glass wrote:
Hi,
On 15 July 2015 at 02:42, Wang Haikun wrote:
Hi Simon,
It seems that we don't update the source image name to u-boot-dtb.bin in
case of enabling CONFIG_OF_SEPARATE when generate u-boot-with-spl.bin file.
ifdef CONFIG_TPL
SPL_PAYLOAD := tpl/u-bo
Hi,
On 13-07-15 16:16, Bin Liu wrote:
Hi,
On 07/11/2015 08:04 AM, Hans de Goede wrote:
Hi,
On 10-07-15 17:31, Bin Liu wrote:
Hi,
On 07/10/2015 10:12 AM, Heiko Schocher wrote:
Hello Samuel,
Am 10.07.2015 um 16:50 schrieb Egli, Samuel:
Hi Hans,
-Original Message- From: Hans de Go
Hi Simon,
On 8 July 2015 at 09:57, Peter Griffin wrote:
> > This patch adds the glue code for hi6220 SoC which has 2x synopsis
> > dw_mmc controllers. This will be used by the hikey board support
> > in subsequent patches.
> >
> > Signed-off-by: Peter Griffin
> > ---
>
> Reviewed-by: Simon Glas
STM32F429 has a peculiar arrangement for flash sector size.
Starting at 0x0800, the sectors are (total flash size is 2M):
(4 x 16K) + (1 x 64K) + (7 x 128K) + (4 x 16K) + (1 x 64K) + (7 x 128K)
Current U-Boot code for STM32F429 uses the following flash layout:
- 0x0800 : U-Boot (256K)
- 0x
43 matches
Mail list logo
