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)
-
Hi Simon,
On 8 July 2015 at 09:57, Peter Griffin peter.grif...@linaro.org 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
Hi,
On 16-07-15 01:17, Simon Glass wrote:
Hi,
On 15 July 2015 at 02:42, Wang Haikun haikun.w...@freescale.com 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
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
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 really help
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 or move them
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
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, IMHO.
Open
On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com 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
On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com 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
On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote:
Move to driver model pci for Intel queensbay/crownbay.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
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 bmeng...@gmail.com 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 bmeng...@gmail.com
---
Hi Bin,
On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com 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
On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com
---
include/linker_lists.h | 20 ++--
1 file changed, 10
On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
On 15 July 2015 at 02:23, Bin Meng bmeng...@gmail.com wrote:
Add a RTC node in the device tree to enable DM RTC support.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/dts/chromebook_link.dts| 1 +
On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
On 15 July 2015 at 02:23, Bin Meng bmeng...@gmail.com wrote:
IRQ 0 is reserved and should not be assigned to pci device.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/pci.c | 2 ++
1 file changed, 2 insertions(+)
On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
On 15 July 2015 at 02:23, Bin Meng bmeng...@gmail.com wrote:
We need walk through all functions within a PCI device and assign
their IRQs accordingly.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/pci.c
+Thierry
Hi Scott,
On 18 July 2015 at 11:42, Scott Wood scottw...@freescale.com wrote:
On Sat, 2015-07-18 at 08:36 -0600, Simon Glass wrote:
Hi Scott,
On 14 July 2015 at 12:16, Scott Wood scottw...@freescale.com wrote:
On Wed, 2015-07-15 at 01:08 +0900, Masahiro Yamada wrote:
This
Hi Peter,
On 19 July 2015 at 03:39, Peter Griffin peter.grif...@linaro.org wrote:
Hi Simon,
On 8 July 2015 at 09:57, Peter Griffin peter.grif...@linaro.org 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
Hi Simon,
On Mon, Jul 20, 2015 at 9:59 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com 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
On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
On 15 July 2015 at 02:23, Bin Meng bmeng...@gmail.com wrote:
Turn on cache on the pci option rom area to improve the performance.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/cpu.c | 27
On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
On 9 July 2015 at 20:38, Bin Meng bmeng...@gmail.com 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
On 9 July 2015 at 20:51, Bin Meng bmeng...@gmail.com 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
On 18 July 2015 at 14:49, Simon Glass s...@chromium.org wrote:
On 16 July 2015 at 20:43, Bin Meng bmeng...@gmail.com wrote:
The doc wrongly put sandbox in the '--fetch-arch' command. Remove it.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
tools/buildman/README | 4 ++--
1 file changed,
On 26 June 2015 at 05:56, Haikun Wang haikun.w...@freescale.com wrote:
From: Haikun Wang haikun.w...@freescale.com
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
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
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 more
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, Buildroot,
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
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...
We came
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've
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 borneo.anto...@gmail.com
To: Albert Aribaud albert.u.b...@aribaud.net
To: Tom Rini tr...@konsulko.com
To: Kamil Lulko re...@wp.pl
Cc:
On 5/11/2015 10:59 AM, Simon Glass wrote:
Hi,
On 10 May 2015 at 07:04, Jagan Teki jt...@openedev.com wrote:
On 8 May 2015 at 13:51, haikun.w...@freescale.com
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
On 7/7/2015 1:33 AM, Simon Glass wrote:
On 2 July 2015 at 03:12, Haikun Wang haikun.w...@freescale.com wrote:
Add error handler when write/erase flash fail.
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
drivers/mtd/spi/sf_dataflash.c | 30 ++
1 file
On 7/7/2015 1:33 AM, Simon Glass wrote:
Hi,
On 2 July 2015 at 03:12, Haikun Wang haikun.w...@freescale.com wrote:
Signed-off-by: Haikun Wang haikun.w...@freescale.com
Missing commit message. Doesn't this mean it will always do the verify?
---
drivers/mtd/spi/sf_dataflash.c | 2 --
1
On 7/2/2015 5:17 PM, Haikun Wang wrote:
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
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
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 table
On 7/7/2015 1:33 AM, Simon Glass wrote:
On 2 July 2015 at 03:12, Haikun Wang haikun.w...@freescale.com wrote:
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
drivers/mtd/spi/sf_dataflash.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
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
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 borneo.anto...@gmail.com
To: Albert Aribaud albert.u.b...@aribaud.net
To: Tom
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
builds for
41 matches
Mail list logo
