Re: [U-Boot] [PATCH] test:dfu: Add test script for testing DFU regression
Hi Simon,
Hi Lukasz,
On 22 May 2014 00:43, Lukasz Majewski l.majew...@samsung.com wrote:
This commit adds test script for testing if any commit has
introduced regression to the DFU.
It uses md5 to test if sent and received file is correct.
The test detailed description is available at DESCRIPTION.TXT file.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
test/dfu/DESCRIPTION.TXT| 27 ++
This sounds like an important and useful test, but I have a few
comments (coming from someone with little knowledge of dfu)
Would README be a better name?
I think it will be better.
test/dfu/dfu_gadget_test.sh | 86
+++ 2 files changed, 113
insertions(+) create mode 100644 test/dfu/DESCRIPTION.TXT
create mode 100755 test/dfu/dfu_gadget_test.sh
diff --git a/test/dfu/DESCRIPTION.TXT b/test/dfu/DESCRIPTION.TXT
new file mode 100644
index 000..48da06b
--- /dev/null
+++ b/test/dfu/DESCRIPTION.TXT
@@ -0,0 +1,27 @@
+DFU TEST CASE DESCRIPTION:
+
+For running test script one needs to create:
+./log and ./bkp
+
+One also need to generate with dd following files:
+
+dat_*
+
+(e.g. dat_127B.img dat_128B.img dat_129B.img dat_33M.img
dat_4095B.img +dat_4096B.img dat_4097B.img dat_63B.img
dat_64B.img dat_65B.img +dat_960.img dat_97M.img)
How do you do that?
I generate them with using dd if=/dev/urandom of=/dev/null bs=XX
count=YY
Generation of those test images can be easily scripted.
Is this intended for use with a particular board?
No. Those values shall be applicable to all boards which use DFU. For
example, since DFU uses the 64B as packet size, it is important to test
+1/-1 size. With those tests one can also test UDC driver for
regression.
Other file sizes (like 33MiB or 97MiB) are picked randomly to check if
transferring large or very large files work.
I think you are missing some info here.
+
+The size is only important (so if=/dev/urandom), especially corner
cases of +DFU EP0's size of packet (64B). This is very helpful for
fixing UDC driver +regressions.
+
+Moreover on a target device the dfu_alt_info env variable should
be extended +to have dfu_test.bin fat 0 6; \ entry [1].
What is [1] ?
[1] is the entry: dfu_test.bin fat 0 6;, which should be added to the
dfu_alt_info environment variable to define one special alt setting
for testing purposes.
+One can use fat, ext4 or any other supported file system.
+
+As a prerequisite one must also create proper partition with file
system on it. +
+Example usage:
+./dfu_gadget_test.sh 11
+
+where 11 is the mumber of alt setting corresponding to entry [1].
\ No newline at end of file
I'm really none-the-wiser as to how this works - I think you need to
add a bit more detail.
Ok.
In short - the parameter which the script ./dfu_gadget_test.sh accepts
is 11 (therefore we must type ./dfu_gadget_test.sh 11
diff --git a/test/dfu/dfu_gadget_test.sh
b/test/dfu/dfu_gadget_test.sh new file mode 100755
index 000..ebde2ff
--- /dev/null
+++ b/test/dfu/dfu_gadget_test.sh
@@ -0,0 +1,86 @@
+#! /bin/bash
+set -e # any command return not equal to zero
+clear
+
+DIR=./
+SUFFIX=img
+RCV_DIR=rcv/
+LOG_FILE=./log/log-`date +%d-%m-%Y_%H-%M-%S`
+
+cleanup () {
+rm -rf $RCV_DIR
+}
+
+die () {
+ printf\33[31m FAILED \33[0m \n
Perhaps define $RED or whatever at the top and use those here?
Good point, thanks.
+ cleanup
+ exit 1
+}
+
+calculate_md5sum () {
+MD5SUM=`md5sum $1`
+MD5SUM=`echo $MD5SUM | cut -d ' ' -f1`
+echo md5sum:$MD5SUM
+}
+
+dfu_test_file () {
I suggest putting the argument in a variable here, instead of using $1
throughout the function.
OK.
+printf
\33[32m=
\33[0m\n
+printf File:\33[32m %s \33[0m\n $1
+
+# dfu-util -D $1 -a $TARGET_ALT_SETTING /dev/null 21
Remove this line?
Yes, agree. This line seems like a remain after testing.
+dfu-util -D $1 -a $TARGET_ALT_SETTING $LOG_FILE 21 || die
$? +
+echo -n TX:
+calculate_md5sum $1
+
+MD5_TX=$MD5SUM
+
+N_FILE=$DIR$RCV_DIR${1:2}_rcv
+
+# dfu-util -U $N_FILE -a $TARGET_ALT_SETTING /dev/null 21
And again
OK.
+dfu-util -U $N_FILE -a $TARGET_ALT_SETTING $LOG_FILE 21
|| die $? +
+echo -n RX:
+calculate_md5sum $N_FILE
+MD5_RX=$MD5SUM
+
+if [ $MD5_TX == $MD5_RX ]
+ then
+ printf\33[32m --- OK \33[0m \n
+ else
outdent
+ printf\33[31m --- FAILED \33[0m \n
+ cleanup
+ exit 1
+fi
+
+#echo $N_FILE
+}
+
+printf
\33[32m=
\33[0m\n +echo DFU EP0
Re: [U-Boot] Standalone application issue.
Dear Wolfgang, Thank you very much. As per your request, I executed the following mkimage command: mkimage -A arm -O u-boot -T standalone -C none -a 0x0c10 -e 0x0c10 -n Hello World -d hello_world.bin Hello.img Than, I transferred to the board using uboot loadb (followed by the kermit send command) and then launched the bootm ARNDALE5250 # bootm 0x43E0 ## Booting kernel from Legacy Image at 43e0 ... Image Name: Hello World Image Type: ARM U-Boot Standalone Program (uncompressed) Data Size:594 Bytes = 594 Bytes Load Address: 0c10 Entry Point: 0c10 Verifying Checksum ... OK Loading Standalone Program ... OK OK Still, the program hangs at the above giving no sign of life. Please note I am using the arndale 5250 board, am I missing something? Can I try to write the hello world standalone into the microSD? what are dd parameters shall I use (e.g. seek)? Many thanks and best regards. -- View this message in context: http://u-boot.10912.n7.nabble.com/Standalone-application-issue-tp180515p180701.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/12] exynos5: support tps65090 pmic
Dear Simon, On 23/05/14 02:27, Simon Glass wrote: Hi Minkyu, On 21 May 2014 15:20, Minkyu Kang mk7.k...@samsung.com wrote: On 22/05/14 03:58, Simon Glass wrote: Hi Minkyu, On 21 May 2014 00:05, Minkyu Kang mk7.k...@samsung.com wrote: On 20/05/14 20:47, Simon Glass wrote: Hi Minkyu, On 15 May 2014 00:51, Minkyu Kang mk7.k...@samsung.com wrote: On 03/04/14 08:24, Simon Glass wrote: From: Aaron Durbin adur...@chromium.org The TSP65090 is a PMIC on some exynos5 boards. The init function is called for the TPS65090 pmic. If that device is not a part of the device tree (returns -ENODEV) then continue. Otherwise return a failure. Signed-off-by: Aaron Durbin adur...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v2: - Move code to exynos5-dt.c - Fix comment style - Add #ifdef around tps65090 code board/samsung/smdk5250/exynos5-dt.c | 13 + 1 file changed, 13 insertions(+) diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 1a64b9b..2c1cf8a 100644 --- a/board/samsung/smdk5250/exynos5-dt.c +++ b/board/samsung/smdk5250/exynos5-dt.c @@ -20,6 +20,7 @@ #include asm/arch/sromc.h #include power/pmic.h #include power/max77686_pmic.h +#include power/tps65090_pmic.h #include tmu.h DECLARE_GLOBAL_DATA_PTR; @@ -164,7 +165,19 @@ int exynos_power_init(void) #ifdef CONFIG_POWER_MAX77686 ret = max77686_init(); + if (ret) + return ret; #endif +#ifdef CONFIG_POWER_TPS65090 + /* + * The TPS65090 may not be in the device tree. If so, it is not + * an error. Then, how we can initialise the tps65090? It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip. then I think, it's an error. Why you said, it is not an error? I may be misunderstanding your question, but I'll try to answer what I think you are asking. The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = disabled property in the node). The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc. Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also. The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes. The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c. Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic. I totally understood what you assert. But I can't agree with you. Do you think if we collect all features at exynos5-dt.h then it can be generic? even if some boards doesn't have the device? I think no. It just wrong definition. We should separate exynos5 generic features and board specific features. + ret = tps65090_init(); + if (ret == 0 || ret == -ENODEV) + return 0; At here.. whatever, the error is an error. If you got NODEV then should return it, because that board does not have device. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] xilinx-u-boot:- NAND: no devices available
I am trying to run FALCON MODE on zynq-microzed board. I am following README-falcon.But when i run `nand read 8200 kernel` command, i get this error.. no devices available And when i run u-boot it shows.. ** NAND: zynq_nand_init: Unable detect NAND based on MIO settings ZYNQ NAND init failed ** **Here are messages from my u-boot.** U-Boot 2014.01 (May 26 2014 - 11:19:45) I2C: ready Memory: ECC disabled DRAM: 1 GiB **NAND: zynq_nand_init: Unable detect NAND based on MIO settings ZYNQ NAND init failed** 0 MiB MMC: zynq_sdhci: 0 SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Gem.e000b000 Hit any key to stop autoboot: 0 zynq-uboot nand read 8200 kernel **no devices available** zynq-uboot I have to use nand command, so please tell me how can i resolve this problem. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone application issue.
Dear mazen.e, In message 1401086047300-180701.p...@n7.nabble.com you wrote: mkimage -A arm -O u-boot -T standalone -C none -a 0x0c10 -e 0x0c10 -n Hello World -d hello_world.bin Hello.img ... ARNDALE5250 # bootm 0x43E0 ## Booting kernel from Legacy Image at 43e0 ... Image Name: Hello World Image Type: ARM U-Boot Standalone Program (uncompressed) Data Size:594 Bytes = 594 Bytes Load Address: 0c10 Entry Point: 0c10 Verifying Checksum ... OK Loading Standalone Program ... OK OK This looks OK to me. Still, the program hangs at the above giving no sign of life. Well, then I guess you should attach a JTAG debugger and have a closer look where it is hanging, and why. Can I try to write the hello world standalone into the microSD? what are dd parameters shall I use (e.g. seek)? That would not change anything, I think. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A complex system that works is invariably found to have evolved from a simple system that worked. - John Gall, _Systemantics_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pxa310 SDHC support.
Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? Thank you very much. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pxa310 SDHC support.
Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? Thank you very much. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone application issue.
Thanks Wolfgang, I will do and post the result. Many thanks. -- View this message in context: http://u-boot.10912.n7.nabble.com/Standalone-application-issue-tp180515p180707.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fwd: xilinx-u-boot:- NAND: no devices available
-- Forwarded message -- From: Uzair Zaidi uzair.a...@gmail.com Date: Mon, May 26, 2014 at 1:05 PM Subject: xilinx-u-boot:- NAND: no devices available To: U-Boot@lists.denx.de I am trying to run FALCON MODE on zynq-microzed board. I am following README-falcon.But when i run `nand read 8200 kernel` command, i get this error.. no devices available And when i run u-boot it shows.. ** NAND: zynq_nand_init: Unable detect NAND based on MIO settings ZYNQ NAND init failed ** **Here are messages from my u-boot.** U-Boot 2014.01 (May 26 2014 - 11:19:45) I2C: ready Memory: ECC disabled DRAM: 1 GiB **NAND: zynq_nand_init: Unable detect NAND based on MIO settings ZYNQ NAND init failed** 0 MiB MMC: zynq_sdhci: 0 SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Gem.e000b000 Hit any key to stop autoboot: 0 zynq-uboot nand read 8200 kernel **no devices available** zynq-uboot I have to use nand command, so please tell me how can i resolve this problem. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone application issue.
Hello, On zo, 2014-05-25 at 23:34 -0700, mazen.e wrote: ARNDALE5250 # bootm 0x43E0 ## Booting kernel from Legacy Image at 43e0 ... Image Name: Hello World Image Type: ARM U-Boot Standalone Program (uncompressed) Data Size:594 Bytes = 594 Bytes Load Address: 0c10 Entry Point: 0c10 Verifying Checksum ... OK Loading Standalone Program ... OK OK which version of u-boot are you using and where did you compile the hello_world example from? Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mkimage: path behavior for FIT images
Hi Simon, On Sat, May 24, 2014 at 3:58 AM, Simon Glass s...@chromium.org wrote: Hi Yegor, On 20 May 2014 20:59, Yegor Yefremov yegorsli...@googlemail.com wrote: I have following folder structure: board/kernel_fdt.its output/images/zImage The kernel.its has following path for the zImage: data = /incbin/(output/images/zImage); When I invoke mkimage like this, it complains, that output/images/zImage doesn't exist: mkimage -f board/kernel_fdt.its output/images/kernel_fdt.itb in other words it seems to take zImage's relative path starting from board, where kernel_fdt.its is located. Is it a desired behavior and how can I override it, so that root will be set to the mkimage invocation path? You could put ../output/... in there perhaps. Your workaround is working. Thanks. I just wanted to know, if it was a desired behavior. Can it be the dtc is invoked from board/ and this is the cause of such behavior? Yegor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
Hi Wolfgang, Darwin, On Thu, 15 May 2014 21:19:57 +0200, Wolfgang Denk w...@denx.de wrote: Setting CONFIG_SYS_TEXT_BASE to something like 0x8820 is extremly fishy. If you want to add some header data to your image, you should not shift the text segment, but rather include your header in the start of the text segment. Or keep it completely separate, without messing with CONFIG_SYS_TEXT_BASE. Back to the origin of the discussion and patch: Darwin, can you describe the actual technical difficulty which caused you to you write and submitting this patch? Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pxa310 SDHC support.
On Monday, May 26, 2014 at 09:51:58 AM, aking_jin wrote: Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? It is well possible that the driver is broken on PXA3xx . Note that mainline U- Boot doesn't really support PXA3xx . Are you working on PXA3xx support for mainline U-Boot ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH v2 2/4] lib, rbtree: resync with Linux-3.14
On Monday, May 26, 2014 at 07:32:22 AM, Heiko Schocher wrote: Hello Marek, Am 24.05.2014 12:30, schrieb Marek Vasut: On Thursday, May 22, 2014 at 12:43:06 PM, Heiko Schocher wrote: resync with linux: commit 455c6fdbd219161bd09b1165f11699d6d73de11c Author: Linus Torvaldstorva...@linux-foundation.org Date: Sun Mar 30 20:40:15 2014 -0700 Linux 3.14 Needed for the MTD/UBI/UBIFS resync Signed-off-by: Heiko Schocherh...@denx.de Cc: Marek Vasutma...@denx.de Cc: Sergey Lapinsla...@ossfans.org Cc: Scott Woodscottw...@freescale.com Did you just copy the files over or did you change anything in them? If you changed anything, I'd say that should go into some compat header so there's a minimum amount of changes compared to the mainline linux code. Just copied the file from Linux, changed the license file header, and add: +#define __UBOOT__ #include linux/rbtree_augmented.h +#ifndef __UBOOT__ #include linux/export.h +#else +#include ubi_uboot.h +#endif so, that should be ok. Thanks for clarifying, I suppose that might need to be in the commit message though , so once we decide to do resync again, we'd know what the code looked like compared to 3.14 . Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] xilinx-u-boot:- NAND: no devices available
On 05/26/2014 09:35 AM, Uzair Zaidi wrote: I am trying to run FALCON MODE on zynq-microzed board. I am following README-falcon.But when i run `nand read 8200 kernel` command, i get this error.. no devices available And when i run u-boot it shows.. ** NAND: zynq_nand_init: Unable detect NAND based on MIO settings ZYNQ NAND init failed ** **Here are messages from my u-boot.** U-Boot 2014.01 (May 26 2014 - 11:19:45) I2C: ready Memory: ECC disabled DRAM: 1 GiB **NAND: zynq_nand_init: Unable detect NAND based on MIO settings There is no NAND driver for zynq in mainline u-boot that's why please use xilinx forums for this type of questions. But based on this message you can simple identify where the problem is. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pxa310 SDHC support.
Hi, Marek On 2014/5/26 Mon 16:59, Marek Vasut wrote: On Monday, May 26, 2014 at 09:51:58 AM, aking_jin wrote: Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? It is well possible that the driver is broken on PXA3xx . Note that mainline U- Boot doesn't really support PXA3xx . Are you working on PXA3xx support for mainline U-Boot ? I'm looking for support for pxa310 MMC SDHC . In the PXA310 SPEC: The MMC module is based on the standards outlined in the MultiMediaCard System Specification Version 3.3.1. The SD module manages one SD or SDIO card based on the standards outlined in the SD Memory Card Specification Version 1.10 and SDIO Card Specification Version 1.0 I'm doubting if the controller support SDHC (SD 2.0) ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pxa310 SDHC support.
Hi, Marek On 2014/5/26 Mon 16:59, Marek Vasut wrote: On Monday, May 26, 2014 at 09:51:58 AM, aking_jin wrote: Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? It is well possible that the driver is broken on PXA3xx . Note that mainline U- Boot doesn't really support PXA3xx . Are you working on PXA3xx support for mainline U-Boot ? I'm looking for support for pxa310 MMC SDHC . In the PXA310 SPEC: The MMC module is based on the standards outlined in the MultiMediaCard System Specification Version 3.3.1. The SD module manages one SD or SDIO card based on the standards outlined in the SD Memory Card Specification Version 1.10 and SDIO Card Specification Version 1.0 I'm doubting if the controller support SDHC (SD 2.0) ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] boards.cfg: fix a configuration error of ep8248 board again
make ep8248_config fails with an error like this: $ make ep8248_config make: *** [ep8248_config] Error 1 Its cause is that there are two entries for ep8248. The first is around line 661 of boards.cfg. (as Active) The second appears around line 1242. (as Orphan) This bug was originally introduced by commit e7e90901 and I fixed it by commit 8ad5d45e. (Refer to git-log of commit 8ad5d45e) But this bug was re-introduced by commit 05d134b0 because the custodian made a mistake when he resolved a merge conflict. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Heiko Schocher h...@denx.de Cc: Kim Phillips kim.phill...@linaro.org --- boards.cfg | 1 - 1 file changed, 1 deletion(-) diff --git a/boards.cfg b/boards.cfg index 221b7f8..0a0871b 100644 --- a/boards.cfg +++ b/boards.cfg @@ -658,7 +658,6 @@ Active powerpc mpc8260- - cpu86 Active powerpc mpc8260- - cpu86 CPU86_ROMBOOT CPU86:BOOT_ROM Wolfgang Denk w...@denx.de Active powerpc mpc8260- - cpu87 CPU87 - - Active powerpc mpc8260- - cpu87 CPU87_ROMBOOT CPU87:BOOT_ROM - -Active powerpc mpc8260- - ep8248 ep8248- Yuli Barcohen y...@arabellasw.com Active powerpc mpc8260- - iphase4539 IPHASE4539- Wolfgang Grandegger w...@denx.de Active powerpc mpc8260- - muas3001 muas3001 - Heiko Schocher h...@denx.de Active powerpc mpc8260- - muas3001 muas3001_dev muas3001:MUAS_DEV_BOARD Heiko Schocher h...@denx.de -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: fix a build error with CONFIG_USE_IRQ
Commit 41623c91 moved exception handling to arch/arm/lib/vectors.S, breaking CONFIG_USE_IRQ feature. If CONFIG_USE_IRQ is enabled, undefined reference error occurs. arch/arm/lib/built-in.o: In function `interrupt_init': arch/arm/lib/interrupts.c:37: undefined reference to `IRQ_STACK_START' arch/arm/lib/interrupts.c:37: undefined reference to `FIQ_STACK_START' make: *** [u-boot] Error 1 Because arch/arm/lib/vectors.S includes references to CONFIG_SYS_DV_NOR_BOOT_CFG and CONFIG_USE_IRQ, it must include config.h. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- arch/arm/lib/vectors.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index d68cc47..fad00da 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -13,6 +13,8 @@ * SPDX-License-Identifier:GPL-2.0+ */ +#include config.h + /* * * -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] fat: Define MAX_CLUSTSIZE only if not defined in config
Define the MAX_CLUSTSIZE to default of 65536 only if CONFIG_FS_FAT_MAX_CLUSTSIZE is not defined in board specific config file. Also please define your own MAX_CLUSTSIZE value if CONFIG_FS_FAT_MAX_CLUSTSIZE is defined. This option has been provided to save memory in some memory constrained cases. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com --- Changes in v2: -Defined CONFIG_FS_FAT_MAX_CLUSTSIZE and documented as per review comment. README|7 +++ include/fat.h |2 ++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/README b/README index 5f89552..0d947cb 100644 --- a/README +++ b/README @@ -1613,6 +1613,13 @@ CBFS (Coreboot Filesystem) support filesystem. Available commands are cbfsinit, cbfsinfo, cbfsls and cbfsload. +- FAT(File Allocation Table) filesystem write/read buffer size: + CONFIG_FS_FAT_MAX_CLUSTSIZE + + If this macro is not defined then the default MAX_CLUSTSIZE + is defined with 65536 else specify your own MAX_CLUSTSSIZE + value. + - Keyboard Support: CONFIG_ISA_KEYBOARD diff --git a/include/fat.h b/include/fat.h index 81d9790..8b67851 100644 --- a/include/fat.h +++ b/include/fat.h @@ -18,7 +18,9 @@ #define VFAT_MAXSEQ9 /* Up to 9 of 13 2-byte UTF-16 entries */ #define PREFETCH_BLOCKS2 +#ifndef CONFIG_FS_FAT_MAX_CLUSTSIZE #define MAX_CLUSTSIZE 65536 +#endif #define DIRENTSPERBLOCK(mydata-sect_size / sizeof(dir_entry)) #define DIRENTSPERCLUST((mydata-clust_size * mydata-sect_size) / \ sizeof(dir_entry)) -- 1.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Standalone application issue.
Hi, I am using the u-boot-arndale from https://github.com/virtualopensystems/u-boot-arndale and I am using the arm-linux-gnueabi- Linaro toolchain for compilation? I also tried u-boot-linaro-2013.03.01 but the issue persist? any suggestion please? Many thanks. -- View this message in context: http://u-boot.10912.n7.nabble.com/Standalone-application-issue-tp180515p180720.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Some powerpc cfgs fail to build on v2014.04
Hi, Are all boards supposed to build fine in v2014.04 release? I'm running ./MAKEALL -a powerpc and get build failure for 9 boards: Boards with errors: 9 ( ep8248 MPC8572DS MPC8572DS_36BIT PMC440 dlvision-10g io iocon neo ep8248 ) ep8248 -- /home/lab/dev/uboot/Makefile:501: *** System not configured - see README. Stop. make: *** [sub-make] Error 2 MPC8572DS - powerpc-none-eabi-ld.bfd: section .bootpg loaded at [e000,e4d3] overlaps section .u_boot_list loaded at [efffee98,e737] powerpc-none-eabi-ld.bfd: u-boot: section .bootpg lma 0xe000 adjusted to 0xe738 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 MPC8572DS_36BIT --- powerpc-none-eabi-ld.bfd: section .bootpg loaded at [e000,e4d3] overlaps section .data loaded at [efff74e0,e7ab] powerpc-none-eabi-ld.bfd: section .resetvec loaded at [effc,efff] overlaps section .u_boot_list loaded at [e7ac,f04b] powerpc-none-eabi-ld.bfd: u-boot: section .bootpg lma 0xe000 adjusted to 0xe7ac powerpc-none-eabi-ld.bfd: u-boot: section .u_boot_list lma 0xe7ac adjusted to 0xec80 powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xeffc adjusted to 0xf520 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 PMC440 -- /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o): In function `__eabi': /home/lab/dev/gcc/build-powerpc-none-eabi/gcc-4.8.1/powerpc-none-eabi/nof/libgcc/../../../../../sources/gcc-4.8.1/libgcc/config/rs6000/eabi.S:221: undefined reference to `__init' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x8): undefined reference to `__SDATA_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0xc): undefined reference to `__SBSS_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x14): undefined reference to `__SDATA2_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x18): undefined reference to `__SBSS2_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x1c): undefined reference to `__GOT_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x28): undefined reference to `__GOT_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x2c): undefined reference to `__GOT2_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x30): undefined reference to `__GOT2_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x34): undefined reference to `__FIXUP_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x38): undefined reference to `__FIXUP_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x3c): undefined reference to `__CTOR_LIST__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x40): undefined reference to `__CTOR_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x44): undefined reference to `__DTOR_LIST__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x48): undefined reference to `__DTOR_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x4c): undefined reference to `__EXCEPT_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x50): undefined reference to `__EXCEPT_END__' make[3]: *** [examples/api/demo] Error 1 make[2]: *** [examples/api] Error 2 make[1]: *** [examples] Error 2 make: *** [sub-make] Error 2 dlvision-10g powerpc-none-eabi-ld.bfd: section .resetvec loaded at [fffc,] overlaps section .data loaded at [df18,0001047b] powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xfffc adjusted to 0x1047c powerpc-none-eabi-ld.bfd: u-boot: section .u_boot_list lma 0x1047c adjusted to 0x10480 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 io -- powerpc-none-eabi-ld.bfd: section .resetvec loaded at [fffc,] overlaps section .u_boot_list loaded at [fa4c,0001024f] powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xfffc adjusted to 0x10250 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 iocon - powerpc-none-eabi-ld.bfd: section .resetvec loaded at [fffc,] overlaps section .data loaded at [ef24,000116db] powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xfffc adjusted to 0x116dc powerpc-none-eabi-ld.bfd: u-boot: section .u_boot_list lma 0x116dc adjusted to 0x116e0 make[1]:
Re: [U-Boot] pxa310 SDHC support.
On Monday, May 26, 2014 at 12:28:49 PM, aking_jin wrote: Hi, Marek On 2014/5/26 Mon 16:59, Marek Vasut wrote: On Monday, May 26, 2014 at 09:51:58 AM, aking_jin wrote: Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? It is well possible that the driver is broken on PXA3xx . Note that mainline U- Boot doesn't really support PXA3xx . Are you working on PXA3xx support for mainline U-Boot ? I'm looking for support for pxa310 MMC SDHC . In the PXA310 SPEC: The MMC module is based on the standards outlined in the MultiMediaCard System Specification Version 3.3.1. The SD module manages one SD or SDIO card based on the standards outlined in the SD Memory Card Specification Version 1.10 and SDIO Card Specification Version 1.0 I'm doubting if the controller support SDHC (SD 2.0) ? The PXA27x controller works even with SDXC , that is tested. I suspect there might be some change in the PXA3xx controller, but I don't really know for sure. You'd have to check. Also, you didn't really answer my question with regards to porting U-Boot above. If you do that, use latest mainline, not 2014.01 . Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Some powerpc cfgs fail to build on v2014.04
Hi Vasili, On Mon, 26 May 2014 13:51:52 +0300 Vasili Galka vvv...@gmail.com wrote: Hi, Are all boards supposed to build fine in v2014.04 release? I'm running ./MAKEALL -a powerpc and get build failure for 9 boards: Boards with errors: 9 ( ep8248 MPC8572DS MPC8572DS_36BIT PMC440 dlvision-10g io iocon neo ep8248 ) ep8248 -- /home/lab/dev/uboot/Makefile:501: *** System not configured - see README. Stop. make: *** [sub-make] Error 2 I've posted a patch to fix ep8248. Check http://patchwork.ozlabs.org/patch/352483/ BTW, I fixed it by commit 8ad5d45e. But now it is broken again. I am wondering how many times I have to post the same patch to fix this board. MPC8572DS - powerpc-none-eabi-ld.bfd: section .bootpg loaded at [e000,e4d3] overlaps section .u_boot_list loaded at [efffee98,e737] powerpc-none-eabi-ld.bfd: u-boot: section .bootpg lma 0xe000 adjusted to 0xe738 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 MPC8572DS_36BIT --- powerpc-none-eabi-ld.bfd: section .bootpg loaded at [e000,e4d3] overlaps section .data loaded at [efff74e0,e7ab] powerpc-none-eabi-ld.bfd: section .resetvec loaded at [effc,efff] overlaps section .u_boot_list loaded at [e7ac,f04b] powerpc-none-eabi-ld.bfd: u-boot: section .bootpg lma 0xe000 adjusted to 0xe7ac powerpc-none-eabi-ld.bfd: u-boot: section .u_boot_list lma 0xe7ac adjusted to 0xec80 powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xeffc adjusted to 0xf520 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 PMC440 -- /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o): In function `__eabi': /home/lab/dev/gcc/build-powerpc-none-eabi/gcc-4.8.1/powerpc-none-eabi/nof/libgcc/../../../../../sources/gcc-4.8.1/libgcc/config/rs6000/eabi.S:221: undefined reference to `__init' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x8): undefined reference to `__SDATA_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0xc): undefined reference to `__SBSS_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x14): undefined reference to `__SDATA2_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x18): undefined reference to `__SBSS2_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x1c): undefined reference to `__GOT_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x28): undefined reference to `__GOT_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x2c): undefined reference to `__GOT2_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x30): undefined reference to `__GOT2_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x34): undefined reference to `__FIXUP_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x38): undefined reference to `__FIXUP_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x3c): undefined reference to `__CTOR_LIST__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x40): undefined reference to `__CTOR_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x44): undefined reference to `__DTOR_LIST__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x48): undefined reference to `__DTOR_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x4c): undefined reference to `__EXCEPT_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x50): undefined reference to `__EXCEPT_END__' make[3]: *** [examples/api/demo] Error 1 make[2]: *** [examples/api] Error 2 make[1]: *** [examples] Error 2 make: *** [sub-make] Error 2 dlvision-10g powerpc-none-eabi-ld.bfd: section .resetvec loaded at [fffc,] overlaps section .data loaded at [df18,0001047b] powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xfffc adjusted to 0x1047c powerpc-none-eabi-ld.bfd: u-boot: section .u_boot_list lma 0x1047c adjusted to 0x10480 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 io -- powerpc-none-eabi-ld.bfd: section .resetvec loaded at [fffc,] overlaps section .u_boot_list loaded at [fa4c,0001024f] powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xfffc adjusted to 0x10250
Re: [U-Boot] [PATCH v2] fat: Define MAX_CLUSTSIZE only if not defined in config
On 05/26/2014 12:29 PM, Siva Durga Prasad Paladugu wrote: Define the MAX_CLUSTSIZE to default of 65536 only if CONFIG_FS_FAT_MAX_CLUSTSIZE is not defined in board specific config file. Also please define your own MAX_CLUSTSIZE value if CONFIG_FS_FAT_MAX_CLUSTSIZE is defined. This option has been provided to save memory in some memory constrained cases. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com --- Changes in v2: -Defined CONFIG_FS_FAT_MAX_CLUSTSIZE and documented as per review comment. README|7 +++ include/fat.h |2 ++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/README b/README index 5f89552..0d947cb 100644 --- a/README +++ b/README @@ -1613,6 +1613,13 @@ CBFS (Coreboot Filesystem) support filesystem. Available commands are cbfsinit, cbfsinfo, cbfsls and cbfsload. +- FAT(File Allocation Table) filesystem write/read buffer size: + CONFIG_FS_FAT_MAX_CLUSTSIZE + + If this macro is not defined then the default MAX_CLUSTSIZE + is defined with 65536 else specify your own MAX_CLUSTSSIZE + value. + - Keyboard Support: CONFIG_ISA_KEYBOARD diff --git a/include/fat.h b/include/fat.h index 81d9790..8b67851 100644 --- a/include/fat.h +++ b/include/fat.h @@ -18,7 +18,9 @@ #define VFAT_MAXSEQ 9 /* Up to 9 of 13 2-byte UTF-16 entries */ #define PREFETCH_BLOCKS 2 +#ifndef CONFIG_FS_FAT_MAX_CLUSTSIZE #define MAX_CLUSTSIZE65536 +#endif #define DIRENTSPERBLOCK (mydata-sect_size / sizeof(dir_entry)) #define DIRENTSPERCLUST ((mydata-clust_size * mydata-sect_size) / \ sizeof(dir_entry)) CONFIG_FS_FAT_MAX_CLUSTSIZE is not used anywhere. This should be the solution. #ifndef CONFIG_FS_FAT_MAX_CLUSTSIZE #define CONFIG_FS_FAT_MAX_CLUSTSIZE 65536 #endif #define MAX_CLUSTSIZE CONFIG_FS_FAT_MAX_CLUSTSIZE Please send v3. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pxa310 SDHC support.
On 5/26/2014 Monday 6:56 PM, Marek Vasut wrote: On Monday, May 26, 2014 at 12:28:49 PM, aking_jin wrote: Hi, Marek On 2014/5/26 Mon 16:59, Marek Vasut wrote: On Monday, May 26, 2014 at 09:51:58 AM, aking_jin wrote: Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? It is well possible that the driver is broken on PXA3xx . Note that mainline U- Boot doesn't really support PXA3xx . Are you working on PXA3xx support for mainline U-Boot ? I'm looking for support for pxa310 MMC SDHC . In the PXA310 SPEC: The MMC module is based on the standards outlined in the MultiMediaCard System Specification Version 3.3.1. The SD module manages one SD or SDIO card based on the standards outlined in the SD Memory Card Specification Version 1.10 and SDIO Card Specification Version 1.0 I'm doubting if the controller support SDHC (SD 2.0) ? The PXA27x controller works even with SDXC , that is tested. I suspect there might be some change in the PXA3xx controller, but I don't really know for sure. You'd have to check. Thank you for your answer. are you using SD mode or SPI Mode? which version are you using? Also, you didn't really answer my question with regards to porting U-Boot above. If you do that, use latest mainline, not 2014.01 . I just have to add SD support for my board, It's emergency. sorry for that. Best regards, Marek Vasut -- Best Regards aking_jin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pxa310 SDHC support.
On 5/26/2014 Monday 6:56 PM, Marek Vasut wrote: On Monday, May 26, 2014 at 12:28:49 PM, aking_jin wrote: Hi, Marek On 2014/5/26 Mon 16:59, Marek Vasut wrote: On Monday, May 26, 2014 at 09:51:58 AM, aking_jin wrote: Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? It is well possible that the driver is broken on PXA3xx . Note that mainline U- Boot doesn't really support PXA3xx . Are you working on PXA3xx support for mainline U-Boot ? I'm looking for support for pxa310 MMC SDHC . In the PXA310 SPEC: The MMC module is based on the standards outlined in the MultiMediaCard System Specification Version 3.3.1. The SD module manages one SD or SDIO card based on the standards outlined in the SD Memory Card Specification Version 1.10 and SDIO Card Specification Version 1.0 I'm doubting if the controller support SDHC (SD 2.0) ? The PXA27x controller works even with SDXC , that is tested. I suspect there might be some change in the PXA3xx controller, but I don't really know for sure. You'd have to check. Thank you for your answer. are you using SD mode or SPI Mode? which version are you using? Also, you didn't really answer my question with regards to porting U-Boot above. If you do that, use latest mainline, not 2014.01 . I just have to add SD support for my board, It's emergency. sorry for that. Best regards, Marek Vasut -- Best Regards aking_jin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Some powerpc cfgs fail to build on v2014.04
Hi Masahiro, On Mon, May 26, 2014 at 2:28 PM, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Vasili, On Mon, 26 May 2014 13:51:52 +0300 Vasili Galka vvv...@gmail.com wrote: Hi, Are all boards supposed to build fine in v2014.04 release? I'm running ./MAKEALL -a powerpc and get build failure for 9 boards: Boards with errors: 9 ( ep8248 MPC8572DS MPC8572DS_36BIT PMC440 dlvision-10g io iocon neo ep8248 ) ep8248 -- /home/lab/dev/uboot/Makefile:501: *** System not configured - see README. Stop. make: *** [sub-make] Error 2 I've posted a patch to fix ep8248. Check http://patchwork.ozlabs.org/patch/352483/ BTW, I fixed it by commit 8ad5d45e. But now it is broken again. I am wondering how many times I have to post the same patch to fix this board. MPC8572DS - powerpc-none-eabi-ld.bfd: section .bootpg loaded at [e000,e4d3] overlaps section .u_boot_list loaded at [efffee98,e737] powerpc-none-eabi-ld.bfd: u-boot: section .bootpg lma 0xe000 adjusted to 0xe738 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 MPC8572DS_36BIT --- powerpc-none-eabi-ld.bfd: section .bootpg loaded at [e000,e4d3] overlaps section .data loaded at [efff74e0,e7ab] powerpc-none-eabi-ld.bfd: section .resetvec loaded at [effc,efff] overlaps section .u_boot_list loaded at [e7ac,f04b] powerpc-none-eabi-ld.bfd: u-boot: section .bootpg lma 0xe000 adjusted to 0xe7ac powerpc-none-eabi-ld.bfd: u-boot: section .u_boot_list lma 0xe7ac adjusted to 0xec80 powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xeffc adjusted to 0xf520 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 PMC440 -- /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o): In function `__eabi': /home/lab/dev/gcc/build-powerpc-none-eabi/gcc-4.8.1/powerpc-none-eabi/nof/libgcc/../../../../../sources/gcc-4.8.1/libgcc/config/rs6000/eabi.S:221: undefined reference to `__init' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x8): undefined reference to `__SDATA_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0xc): undefined reference to `__SBSS_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x14): undefined reference to `__SDATA2_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x18): undefined reference to `__SBSS2_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x1c): undefined reference to `__GOT_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x28): undefined reference to `__GOT_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x2c): undefined reference to `__GOT2_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x30): undefined reference to `__GOT2_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x34): undefined reference to `__FIXUP_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x38): undefined reference to `__FIXUP_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x3c): undefined reference to `__CTOR_LIST__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x40): undefined reference to `__CTOR_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x44): undefined reference to `__DTOR_LIST__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x48): undefined reference to `__DTOR_END__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x4c): undefined reference to `__EXCEPT_START__' /usr/powerpc-none-eabi/lib/gcc/powerpc-none-eabi/4.8.1/nof/libgcc.a(eabi.o):(.got2+0x50): undefined reference to `__EXCEPT_END__' make[3]: *** [examples/api/demo] Error 1 make[2]: *** [examples/api] Error 2 make[1]: *** [examples] Error 2 make: *** [sub-make] Error 2 dlvision-10g powerpc-none-eabi-ld.bfd: section .resetvec loaded at [fffc,] overlaps section .data loaded at [df18,0001047b] powerpc-none-eabi-ld.bfd: u-boot: section .resetvec lma 0xfffc adjusted to 0x1047c powerpc-none-eabi-ld.bfd: u-boot: section .u_boot_list lma 0x1047c adjusted to 0x10480 make[1]: *** [u-boot] Error 1 make: *** [sub-make] Error 2 io -- powerpc-none-eabi-ld.bfd: section .resetvec loaded at [fffc,] overlaps section .u_boot_list loaded at [fa4c,0001024f]
Re: [U-Boot] pxa310 SDHC support.
On Monday, May 26, 2014 at 01:54:54 PM, aking wrote: [...] Also, you didn't really answer my question with regards to porting U-Boot above. If you do that, use latest mainline, not 2014.01 . I just have to add SD support for my board, It's emergency. sorry for that. Can you please fix your mailer so that I am not receiving every email from you twice with 10-minutes delay between that ? Thanks Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pxa310 SDHC support.
On Monday, May 26, 2014 at 01:48:14 PM, aking wrote: On 5/26/2014 Monday 6:56 PM, Marek Vasut wrote: On Monday, May 26, 2014 at 12:28:49 PM, aking_jin wrote: Hi, Marek On 2014/5/26 Mon 16:59, Marek Vasut wrote: On Monday, May 26, 2014 at 09:51:58 AM, aking_jin wrote: Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? It is well possible that the driver is broken on PXA3xx . Note that mainline U- Boot doesn't really support PXA3xx . Are you working on PXA3xx support for mainline U-Boot ? I'm looking for support for pxa310 MMC SDHC . In the PXA310 SPEC: The MMC module is based on the standards outlined in the MultiMediaCard System Specification Version 3.3.1. The SD module manages one SD or SDIO card based on the standards outlined in the SD Memory Card Specification Version 1.10 and SDIO Card Specification Version 1.0 I'm doubting if the controller support SDHC (SD 2.0) ? The PXA27x controller works even with SDXC , that is tested. I suspect there might be some change in the PXA3xx controller, but I don't really know for sure. You'd have to check. Thank you for your answer. are you using SD mode or SPI Mode? which version are you using? I believe the pxa_mmc_gen.c is what needs to be used. There is no other PXA MMC driver in U-Boot mainline. I now noticed it has some basic monahans (pxa3xx) support too. Also, you didn't really answer my question with regards to porting U-Boot above. If you do that, use latest mainline, not 2014.01 . I just have to add SD support for my board, It's emergency. sorry for that. Hmmm. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
hi Wolfgang, I am will glad to share my understanding. Dear David, In message 0579e649-f359-415b-a8ed-e1d4267f8...@phytium.com.cn you wrote: And if any text base alignment is less than the image's maximum alignment requirement, the load will fail, and then we likely scratch our heads and set the CONFIG_SYS_TEXT_BASE alignment higher until it works. Whatever CONFIG_SYS_TEXT_BASE is the alignment will be ok if the relocated address satisfy the align requirement. So CONFIG_SYS_TEXT_BASE could be any value(compiler maybe require the text base aligned with 0x20), just make relocated address has the same offset. There is a point which has not been answered yet, wnd which I really would like to understand. maybe you could be so kind and try to explain it to me? I wonder if the use of the ardp instruction by the compiler can be influenced or maybe even prevent for specific code parts, for example by specific compiler options? For example, there is a number of PIC/PIE-related compiler options - would these have any influence here? I did not find any options that can prevent the use of adrp. I wonder how adrp would work in any code that is supposed to be position-independent? In my understanding, with adrp the program is still relocatable except that the text base should be 4KB aligned or the relocated address has the same offset with text base. Darwin want CONFIG_SYS_TEXT_BASE to be not 4KB aligned, so the relocated address should be offsetted in the same manner. Position-independent code is usually page aligned, so gcc-aarch64 implicitly apply the restriction of text base. Actually, u-boot for aarch64 apply another align requirement that is interrupt vector. The interrupt vector should be 2KB aligned. So, even without adrp CONFIG_SYS_TEXT_BASE should be 2KB aligned yet or relocated with the same offset, otherwise bug exist. Best regards, David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Exynos5420: Introduce support for the Peach-Pit board
Hi Simon, Hi Akshay, On 21 May 2014 23:23, Akshay Saraswat aksha...@samsung.com wrote: While the Exynos5420 chip is used in both Smdk5420 and in the Peach-Pit line of devices, there could be other boards using the same chip, so a common configuration file is being added (exynos5420.h) as well as two common device tree files (exynos54xx.dtsi exynos5420.dtsi). The peach board as declared in boards.cfg is a copy of smdk5420 declaration. The configuration files are similar, but define different default device trees, console serial ports and prompts. The device tree files for smdk5420 and peach-pit inherit from the same common file. Signed-off-by: Vadim Bendebury vben...@chromium.org Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org This looks good to me. I think you might have an extra space in the last column of your boards.cfg addition, and CONFIG_CHROMEOS_PEACH might not be needed. Will fix these in the next version. But I can't get pit to boot with these patches - it hangs in SPL. Do you know what is going on? For me, these patches are working fine. I have tested them over three different pit boards. I am not sure what could be wrong. I will try over more of those boards, if I witness something like this I will update. 9276cf9 (HEAD, try-pit) Exynos5420: DMC: Add software read leveling 7706877 DMC: exynos5420: Gate CLKM to when reading PHY_CON13 0bc31a0 Exynos5420: Remove code for enabling read leveling cc36404 Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init 4544c39 Exynos: Make sure ps_hold gets set in the SPL f08ba9d Exynos5420: Let macros be used for exynos5420 5620192 Exynos5420: Introduce support for the Peach-Pit board 73e3bea (samsung/master) ARM: exynos5420: removed undefined gpio structure Regards, Simon Regards, Akshay Saraswat ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Prevent a buffer overflow in mkimage when signing with SHA256
Due to the FIT_MAX_HASH_LEN constant not having been updated
to support SHA256 signatures one will always see a buffer
overflow in fit_image_process_hash when signing images that
use this larger hash. This is exposed by vboot_test.sh.
Signed-off-by: Michael van der Westhuizen mich...@smart-africa.com
---
Changes in v2:
* Use the HASH_MAX_DIGEST_SIZE constant from hash.h for the
FIT_MAX_HASH_LEN.
* Hide use of struct lmb behind USE_HOSTCC being undefined.
include/image.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/image.h b/include/image.h
index 1886168..cbbdf26 100644
--- a/include/image.h
+++ b/include/image.h
@@ -45,6 +45,8 @@ struct lmb;
#endif /* USE_HOSTCC */
#if defined(CONFIG_FIT)
+#include command.h
+#include hash.h
#include libfdt.h
#include fdt_support.h
# ifdef CONFIG_SPL_BUILD
@@ -328,7 +330,7 @@ typedef struct bootm_headers {
#define BOOTM_STATE_OS_GO (0x0400)
int state;
-#ifdef CONFIG_LMB
+#if defined(CONFIG_LMB) !defined(USE_HOSTCC)
struct lmb lmb; /* for memory mgmt */
#endif
} bootm_headers_t;
@@ -703,7 +705,7 @@ int bootz_setup(ulong image, ulong *start, ulong *end);
#define FIT_FDT_PROP fdt
#define FIT_DEFAULT_PROP default
-#define FIT_MAX_HASH_LEN 20 /* max(crc32_len(4), sha1_len(20)) */
+#define FIT_MAX_HASH_LEN HASH_MAX_DIGEST_SIZE
/* cmdline argument format parsing */
int fit_parse_conf(const char *spec, ulong addr_curr,
--
2.0.0.rc4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] Exynos5420: Remove code for enabling read leveling
Hi Simon, Hi Akshay, On 21 May 2014 23:33, Akshay Saraswat aksha...@samsung.com wrote: This patch intends to remove all code which enables hardware read leveling. All characterization environments may not cope up with h/w read leveling enabled, hence, we need to disable this. Also, disabling h/w read leveling improves the MIF LVcc value (LVcc value is the value at which DDR will fail to work properly). Improving LVcc means we have enough voltage margin for MIF. When h/w leveling is enabled, we have almost zero volatge margin. Signed-off-by: Alim Akhtar alim.akh...@samsung.com Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org Does this mean that the read_leveling_enable structure member is not used? Yes, we don't use read_leveling_enable structure member anymore but I think it's good to keep it because if we update this file in future for next version of SoCs, we may need it. Regards, Simon Regards, Akshay Saraswat ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos: Make sure ps_hold gets set in the SPL
Hi Simon, On 22 May 2014 01:53, Akshay Saraswat aksha...@samsung.com wrote: From: Doug Anderson diand...@chromium.org Setting ps_hold ought to be one of the first things we do when we first boot up. If we wait until the main u-boot runs we won't set it in time and the PMIC may power us back off. Moving ps_hold setup into the generic power_init() which should contain code that's currently duplicated in the board_power_init() of several boards. Signed-off-by: Doug Anderson diand...@chromium.org Signed-off-by: Akshay Saraswat aksha...@samsung.com --- arch/arm/cpu/armv7/exynos/lowlevel_init.c | 6 +- arch/arm/cpu/armv7/exynos/power.c | 14 ++ arch/arm/include/asm/arch-exynos/power.h | 8 3 files changed, 27 insertions(+), 1 deletion(-) Acked-by: Simon Glass s...@chromium.org Also see http://patchwork.ozlabs.org/patch/350693/ but your patch is better. Shall we keep this one then ? Regards, Simon Regards, Akshay Saraswat ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/2] Introduction of new board Peach-Pit
This board is based on Exynos5420 and is similar to SMDK5420 board. Adding new and refactoring existing DT and config files to support both SMDK5420 and Peach-Pit. Changes since v1: - Added Acked-by. Changes since v2: - Changed order of the patches because 2/2 alone results in compiler errors and has dependency over patch 1/2. - Removed CONFIG_CHROMEOS_PEACH. Akshay Saraswat (2): Exynos5420: Let macros be used for exynos5420 Exynos5420: Introduce support for the Peach-Pit board arch/arm/cpu/armv7/exynos/exynos5_setup.h | 6 +- arch/arm/dts/Makefile | 3 +- arch/arm/dts/exynos5420-peach-pit.dts | 127 + arch/arm/dts/exynos5420-smdk5420.dts | 23 + arch/arm/dts/exynos5420.dtsi | 70 -- arch/arm/dts/exynos54xx.dtsi | 151 ++ boards.cfg| 1 + include/configs/exynos5420.h | 46 + include/configs/peach-pit.h | 27 ++ include/configs/smdk5420.h| 49 ++ 10 files changed, 367 insertions(+), 136 deletions(-) create mode 100644 arch/arm/dts/exynos5420-peach-pit.dts delete mode 100644 arch/arm/dts/exynos5420.dtsi create mode 100644 arch/arm/dts/exynos54xx.dtsi create mode 100644 include/configs/exynos5420.h create mode 100644 include/configs/peach-pit.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] Exynos5420: Introduce support for the Peach-Pit board
While the Exynos5420 chip is used in both Smdk5420 and in the Peach-Pit
line of devices, there could be other boards using the same chip, so a
common configuration file is being added (exynos5420.h) as well
as two common device tree files (exynos54xx.dtsi exynos5420.dtsi).
The peach board as declared in boards.cfg is a copy of smdk5420
declaration. The configuration files are similar, but define different
default device trees, console serial ports and prompts.
The device tree files for smdk5420 and peach-pit inherit from the same
common file.
Signed-off-by: Vadim Bendebury vben...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v2:
- Removed CONFIG_CHROMEOS_PEACH.
Changes since v1:
- Added Acked-by.
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/exynos5420-peach-pit.dts | 127
arch/arm/dts/exynos5420-smdk5420.dts | 23 +-
arch/arm/dts/exynos5420.dtsi | 70
arch/arm/dts/exynos54xx.dtsi | 151 ++
boards.cfg| 1 +
include/configs/exynos5420.h | 46 +++
include/configs/peach-pit.h | 25 ++
include/configs/smdk5420.h| 49 ++-
9 files changed, 362 insertions(+), 133 deletions(-)
create mode 100644 arch/arm/dts/exynos5420-peach-pit.dts
delete mode 100644 arch/arm/dts/exynos5420.dtsi
create mode 100644 arch/arm/dts/exynos54xx.dtsi
create mode 100644 include/configs/exynos5420.h
create mode 100644 include/configs/peach-pit.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5554615..933a464 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -6,7 +6,8 @@ dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
exynos5250-smdk5250.dtb \
- exynos5420-smdk5420.dtb
+ exynos5420-smdk5420.dtb \
+ exynos5420-peach-pit.dtb
dtb-$(CONFIG_MX6) += imx6q-sabreauto.dtb
dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
diff --git a/arch/arm/dts/exynos5420-peach-pit.dts
b/arch/arm/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..8d148af
--- /dev/null
+++ b/arch/arm/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,127 @@
+/*
+ * SAMSUNG/GOOGLE Peach-Pit board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ exynos54xx.dtsi
+
+/ {
+ model = Samsung/Google Peach Pit board based on Exynos5420;
+
+ compatible = google,pit-rev#, google,pit,
+ google,peach, samsung,exynos5420, samsung,exynos5;
+
+ config {
+ google,bad-wake-gpios = gpio 0x56 0; /* gpx0-6 */
+ hwid = PIT TEST A-A 7848;
+ lazy-init = 1;
+ };
+
+ aliases {
+ serial0 = /serial@12C3;
+ console = /serial@12C3;
+ pmic = /i2c@12ca;
+ };
+
+ dmc {
+ mem-manuf = samsung;
+ mem-type = ddr3;
+ clock-frequency = 8;
+ arm-frequency = 17;
+ };
+
+ tmu@1006 {
+ samsung,min-temp= 25;
+ samsung,max-temp= 125;
+ samsung,start-warning = 95;
+ samsung,start-tripping = 105;
+ samsung,hw-tripping = 110;
+ samsung,efuse-min-value = 40;
+ samsung,efuse-value = 55;
+ samsung,efuse-max-value = 100;
+ samsung,slope = 274761730;
+ samsung,dc-value= 25;
+ };
+
+ /* MAX77802 is on i2c bus 4 */
+ i2c@12ca {
+ clock-frequency = 40;
+ power-regulator@9 {
+ compatible = maxim,max77802-pmic;
+ reg = 0x9;
+ };
+ };
+
+ i2c@12cd { /* i2c7 */
+ clock-frequency = 10;
+ soundcodec@20 {
+ reg = 0x20;
+ compatible = maxim,max98090-codec;
+ };
+ };
+
+sound@383 {
+samsung,codec-type = max98090;
+};
+
+ i2c@12e1 { /* i2c9 */
+ clock-frequency = 40;
+tpm@20 {
+compatible = infineon,slb9645-tpm;
+reg = 0x20;
+ };
+ };
+
+ spi@12d3 { /* spi1 */
+ spi-max-frequency = 5000;
+ firmware_storage_spi: flash@0 {
+ reg = 0;
+
+ /*
+* A region for the kernel to store a panic event
+* which the firmware will add to the
[U-Boot] [PATCH v3 1/2] Exynos5420: Let macros be used for exynos5420
Macros defined in exynos5_setup.h specific to SMDK5420 are required for Peach-Pit too. Hence, replacing CONFIG_SMDK5420 with CONFIG_EXYNOS5420 to enable these macros for all the boards based on Exynos5420. Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes since v1: - Added Acked-by. arch/arm/cpu/armv7/exynos/exynos5_setup.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h b/arch/arm/cpu/armv7/exynos/exynos5_setup.h index 53b0ace..db8ea86 100644 --- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h +++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h @@ -431,10 +431,10 @@ /* * Definitions that differ with SoC's. - * Below is the part defining macros for smdk5250. - * Else part introduces macros for smdk5420. + * Below is the part defining macros for Exynos5250. + * Else part introduces macros for Exynos5420. */ -#ifndef CONFIG_SMDK5420 +#ifndef CONFIG_EXYNOS5420 /* APLL_CON1 */ #define APLL_CON1_VAL (0x00203800) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] Exynos5: Update dmc init
This patch series intends to add few changes with respect to ddr3 init function definition and read leveling. Changes since v1: - Added Acked-by in patches 1/4, 2/4 and 3/4. - Removing only mem_iv_size argument now in patch 1/4. - Modified commit-msg for patch 4/4. - Fixed few nits in patch 4/4. Akshay Saraswat (3): Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init Exynos5420: Remove code for enabling read leveling Exynos5420: DMC: Add software read leveling Doug Anderson (1): DMC: exynos5420: Gate CLKM to when reading PHY_CON13 arch/arm/cpu/armv7/exynos/dmc_common.c|2 +- arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 369 ++--- arch/arm/cpu/armv7/exynos/exynos5_setup.h | 14 +- arch/arm/include/asm/arch-exynos/dmc.h|3 + arch/arm/include/asm/arch-exynos/power.h |4 +- 5 files changed, 297 insertions(+), 95 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting armv8 kernel on uboot
hi Tom, On Thu, May 22, 2014 at 10:26:17PM +0800, feng...@phytium.com.cn wrote: Hi , I have added mmc driver into the vexpress64 board file for uboot and tested it on FVP base model. I tried booting a kernel on that but it is aborting with the following message: Final value for argc=3 Loading Kernel Image ... OK kernel loaded at 0x0008, end = 0x00827024 using: FDT reserving fdt memory region: addr=8000 size=1 ## initrd_high = 0x, copy_to_ram = 1 ramdisk load start = 0x, ramdisk load end = 0x ## device tree at 90008000 ... 9000a850 (len=22609 [0x5851]) Loading Device Tree to 9fffa000, end 9850 ... OK Initial value for argc=3 Final value for argc=3 ## Transferring control to Linux (at address 8)... Starting kernel ... Synchronous Abort handler, esr 0x0200 ELR: 8 LR: fff90fc8 x0 : 9fffa000 x1 : 1c09 x2 : 1c09 x3 : 0020 x4 : fff6b834 x5 : x6 : fff6bb40 x7 : ffd0 x8 : 000f x9 : 7ff8e000 x10: fffb7188 x11: x12: 6000 x13: 0004 x14: 0003 x15: fffc7c20 x16: x17: x18: fff6beb8 x19: 0008 x20: fffc7a70 x21: x22: x23: fff6d8d8 x24: x25: fffc2630 x26: x27: 80008000 x28: x29: fff6bb40 Can anyone please provide the procedure on how to boot the kernel with u-boot on armv8 models ? I always use mkimage converting kernel to uImage and booting it. It works fine. Wish this help you. Which version of the model are you using and which kernel tree? Thanks! The model is the most recent FVP from linaro website and the kernel is a very old one. But mkimage has nothing to do with the kernel. uImage produced by mkimage is correctly loaded by u-boot for aarch64. I will make a test with the most recently kernel and give you feedback. Best regards, David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] fat: Define MAX_CLUSTSIZE using CONFIG_FS_FAT_MAX_CLUSTSIZE
Define the MAX_CLUSTSIZE to default of 65536 only if CONFIG_FS_FAT_MAX_CLUSTSIZE is not defined. This option has been provided to save memory in some memory constrained cases. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com --- Changes in v3: -Used CONFIG_FS_FAT_MAX_CLUSTSIZE to define MAX_CLUSTSIZE as per review comment. Changes in v2: -Defined CONFIG_FS_FAT_MAX_CLUSTSIZE and documented as per review comment. README|6 ++ include/fat.h |6 +- 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/README b/README index 5f89552..2f2aba3 100644 --- a/README +++ b/README @@ -1613,6 +1613,12 @@ CBFS (Coreboot Filesystem) support filesystem. Available commands are cbfsinit, cbfsinfo, cbfsls and cbfsload. +- FAT(File Allocation Table) filesystem cluster size: + CONFIG_FS_FAT_MAX_CLUSTSIZE + + Define the max cluster size for fat operations else + a default value of 65536 will be defined. + - Keyboard Support: CONFIG_ISA_KEYBOARD diff --git a/include/fat.h b/include/fat.h index 81d9790..63cf787 100644 --- a/include/fat.h +++ b/include/fat.h @@ -18,7 +18,11 @@ #define VFAT_MAXSEQ9 /* Up to 9 of 13 2-byte UTF-16 entries */ #define PREFETCH_BLOCKS2 -#define MAX_CLUSTSIZE 65536 +#ifndef CONFIG_FS_FAT_MAX_CLUSTSIZE +#define CONFIG_FS_FAT_MAX_CLUSTSIZE 65536 +#endif +#define MAX_CLUSTSIZE CONFIG_FS_FAT_MAX_CLUSTSIZE + #define DIRENTSPERBLOCK(mydata-sect_size / sizeof(dir_entry)) #define DIRENTSPERCLUST((mydata-clust_size * mydata-sect_size) / \ sizeof(dir_entry)) -- 1.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init
Passing fewer arguments is better and mem_iv_size is never
used. Let's keep only one argument and make it cleaner.
Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Acked-by.
- Removing only mem_iv_size argument now.
arch/arm/cpu/armv7/exynos/dmc_common.c| 2 +-
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 7 ++-
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 9 ++---
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_common.c
b/arch/arm/cpu/armv7/exynos/dmc_common.c
index cca925e..9b6ee69 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_common.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_common.c
@@ -162,7 +162,7 @@ void mem_ctrl_init(int reset)
/* If there are any other memory variant, add their init call below */
if (param-mem_type == DDR_MODE_DDR3) {
- ret = ddr3_mem_ctrl_init(mem, param-mem_iv_size, reset);
+ ret = ddr3_mem_ctrl_init(mem, reset);
if (ret) {
/* will hang if failed to init memory control */
while (1)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 487e6f4..4481ab4 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -28,8 +28,7 @@ static void reset_phy_ctrl(void)
writel(DDR3PHY_CTRL_PHY_RESET, clk-lpddr3phy_ctrl);
}
-int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned long mem_iv_size,
- int reset)
+int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
{
unsigned int val;
struct exynos5_phy_control *phy0_ctrl, *phy1_ctrl;
@@ -221,8 +220,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned
long mem_iv_size,
#endif
#ifdef CONFIG_EXYNOS5420
-int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned long mem_iv_size,
- int reset)
+int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
{
struct exynos5420_clock *clk =
(struct exynos5420_clock *)samsung_get_base_clock();
@@ -244,7 +242,6 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned
long mem_iv_size,
tzasc0 = (struct exynos5420_tzasc *)samsung_get_base_dmc_tzasc();
tzasc1 = (struct exynos5420_tzasc *)(samsung_get_base_dmc_tzasc()
+ DMC_OFFSET);
-
/* Enable PAUSE for DREX */
setbits_le32(clk-pause, ENABLE_BIT);
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index db8ea86..4542bd1 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -890,16 +890,11 @@ enum {
/*
* Memory variant specific initialization code for DDR3
*
- * @param mem Memory timings for this memory type.
- * @param mem_iv_size Memory interleaving size is a configurable parameter
- * which the DMC uses to decide how to split a memory
- * chunk into smaller chunks to support concurrent
- * accesses; may vary across boards.
+ * @param mem Memory timings for this memory type.
* @param reset Reset DDR PHY during initialization.
* @return 0 if ok, SETUP_ERR_... if there is a problem
*/
-int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned long mem_iv_size,
- int reset);
+int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset);
/* Memory variant specific initialization code for LPDDR3 */
void lpddr3_mem_ctrl_init(void);
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] Exynos5420: Remove code for enabling read leveling
This patch intends to remove all code which enables hardware read
leveling. All characterization environments may not cope up with
h/w read leveling enabled, so we must disable this.
Also, disabling h/w read leveling improves the MIF LVcc value
(LVcc value is the value at which DDR will fail to work properly).
Improving LVcc means we have enough voltage margin for MIF.
When h/w leveling is enabled, we have almost zero volatge margin.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Acked-by.
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 71 ---
1 file changed, 71 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 4481ab4..1d6048c 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -519,77 +519,6 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
drex1-directcmd);
}
- if (mem-read_leveling_enable) {
- /* Set Read DQ Calibration */
- val = (0x3 DIRECT_CMD_BANK_SHIFT) | 0x4;
- for (chip = 0; chip mem-chips_to_configure; chip++) {
- writel(val | (chip DIRECT_CMD_CHIP_SHIFT),
- drex0-directcmd);
- writel(val | (chip DIRECT_CMD_CHIP_SHIFT),
- drex1-directcmd);
- }
-
- val = readl(phy0_ctrl-phy_con1);
- val |= READ_LEVELLING_DDR3;
- writel(val, phy0_ctrl-phy_con1);
- val = readl(phy1_ctrl-phy_con1);
- val |= READ_LEVELLING_DDR3;
- writel(val, phy1_ctrl-phy_con1);
-
- val = readl(phy0_ctrl-phy_con2);
- val |= (RDLVL_EN | RDLVL_INCR_ADJ);
- writel(val, phy0_ctrl-phy_con2);
- val = readl(phy1_ctrl-phy_con2);
- val |= (RDLVL_EN | RDLVL_INCR_ADJ);
- writel(val, phy1_ctrl-phy_con2);
-
- setbits_le32(drex0-rdlvl_config,
-CTRL_RDLVL_DATA_ENABLE);
- i = TIMEOUT;
- while (((readl(drex0-phystatus) RDLVL_COMPLETE_CHO)
-!= RDLVL_COMPLETE_CHO) (i 0)) {
- /*
-* TODO(waihong): Comment on how long this take
-* to timeout
-*/
- sdelay(100);
- i--;
- }
- if (!i)
- return SETUP_ERR_RDLV_COMPLETE_TIMEOUT;
-
- clrbits_le32(drex0-rdlvl_config,
-CTRL_RDLVL_DATA_ENABLE);
- setbits_le32(drex1-rdlvl_config,
-CTRL_RDLVL_DATA_ENABLE);
- i = TIMEOUT;
- while (((readl(drex1-phystatus) RDLVL_COMPLETE_CHO)
-!= RDLVL_COMPLETE_CHO) (i 0)) {
- /*
-* TODO(waihong): Comment on how long this take
-* to timeout
-*/
- sdelay(100);
- i--;
- }
- if (!i)
- return SETUP_ERR_RDLV_COMPLETE_TIMEOUT;
-
- clrbits_le32(drex1-rdlvl_config,
-CTRL_RDLVL_DATA_ENABLE);
-
- val = (0x3 DIRECT_CMD_BANK_SHIFT);
- for (chip = 0; chip mem-chips_to_configure; chip++) {
- writel(val | (chip DIRECT_CMD_CHIP_SHIFT),
- drex0-directcmd);
- writel(val | (chip DIRECT_CMD_CHIP_SHIFT),
- drex1-directcmd);
- }
-
- update_reset_dll(drex0-phycontrol0, DDR_MODE_DDR3);
- update_reset_dll(drex1-phycontrol0, DDR_MODE_DDR3);
- }
-
/* Common Settings for Leveling */
val = PHY_CON12_RESET_VAL;
writel((val + n_lock_w_phy0), phy0_ctrl-phy_con12);
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] DMC: exynos5420: Gate CLKM to when reading PHY_CON13
From: Doug Anderson diand...@chromium.org
From experiments it appears that PHY_CON13 is glitchy if we sample it
when CLKM is running. If we stop CLKM when sampling it the glitches
all go away, so we'll do that as per Samsung suggestion.
We also check the is it locked bits of PHY_CON13 and loop until they
show the the value sampled actually represents a locked value. It
doesn't appear that the glitching and is it locked are related, but
it seems wise to wait until the PHY tells us the value is good before
we use it. In practice we will not loop more than a couple times (and
usually won't loop at all).
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Acked-by.
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 43 +++
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 1 +
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 1d6048c..13003b8 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -230,6 +230,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
struct exynos5420_dmc *drex0, *drex1;
struct exynos5420_tzasc *tzasc0, *tzasc1;
uint32_t val, n_lock_r, n_lock_w_phy0, n_lock_w_phy1;
+ uint32_t lock0_info, lock1_info;
int chip;
int i;
@@ -391,7 +392,41 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
*/
dmc_config_mrs(mem, drex0-directcmd);
dmc_config_mrs(mem, drex1-directcmd);
- } else {
+ }
+
+ /*
+* Get PHY_CON13 from both phys. Gate CLKM around reading since
+* PHY_CON13 is glitchy when CLKM is running. We're paranoid and
+* wait until we get a fine lock, though a coarse lock is probably
+* OK (we only use the coarse numbers below). We try to gate the
+* clock for as short a time as possible in case SDRAM is somehow
+* sensitive. sdelay(10) in the loop is arbitrary to make sure
+* there is some time for PHY_CON13 to get updated. In practice
+* no delay appears to be needed.
+*/
+ val = readl(clk-gate_bus_cdrex);
+ while (true) {
+ writel(val ~0x1, clk-gate_bus_cdrex);
+ lock0_info = readl(phy0_ctrl-phy_con13);
+ writel(val, clk-gate_bus_cdrex);
+
+ if ((lock0_info CTRL_FINE_LOCKED) == CTRL_FINE_LOCKED)
+ break;
+
+ sdelay(10);
+ }
+ while (true) {
+ writel(val ~0x2, clk-gate_bus_cdrex);
+ lock1_info = readl(phy1_ctrl-phy_con13);
+ writel(val, clk-gate_bus_cdrex);
+
+ if ((lock1_info CTRL_FINE_LOCKED) == CTRL_FINE_LOCKED)
+ break;
+
+ sdelay(10);
+ }
+
+ if (!reset) {
/*
* During Suspend-Resume S/W-Reset, as soon as PMU releases
* pad retention, CKE goes high. This causes memory contents
@@ -442,15 +477,13 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
val |= (RDLVL_PASS_ADJ_VAL RDLVL_PASS_ADJ_OFFSET);
writel(val, phy1_ctrl-phy_con1);
- n_lock_r = readl(phy0_ctrl-phy_con13);
- n_lock_w_phy0 = (n_lock_r CTRL_LOCK_COARSE_MASK) 2;
+ n_lock_w_phy0 = (lock0_info CTRL_LOCK_COARSE_MASK) 2;
n_lock_r = readl(phy0_ctrl-phy_con12);
n_lock_r = ~CTRL_DLL_ON;
n_lock_r |= n_lock_w_phy0;
writel(n_lock_r, phy0_ctrl-phy_con12);
- n_lock_r = readl(phy1_ctrl-phy_con13);
- n_lock_w_phy1 = (n_lock_r CTRL_LOCK_COARSE_MASK) 2;
+ n_lock_w_phy1 = (lock1_info CTRL_LOCK_COARSE_MASK) 2;
n_lock_r = readl(phy1_ctrl-phy_con12);
n_lock_r = ~CTRL_DLL_ON;
n_lock_r |= n_lock_w_phy1;
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index 4542bd1..583be27 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -284,6 +284,7 @@
#define CTRL_DLL_ON(1 5)
#define CTRL_FORCE_MASK(0x7F 8)
#define CTRL_LOCK_COARSE_MASK (0x7F 10)
+#define CTRL_FINE_LOCKED 0x7
#define CTRL_OFFSETD_RESET_VAL 0x8
#define CTRL_OFFSETD_VAL 0x7F
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] Exynos5420: DMC: Add software read leveling
Sometimes Read DQ and DQS are not in phase. Since, this
phase shift differs from board to board, we need to
calibrate it at DRAM init phase, that's read DQ calibration.
This patch adds SW Read DQ calibration routine to compensate
this skew.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v1:
- Added Acked-by.
- Changed TIMEOUT to TIMEOUT_US.
- Replaced 0x2000 with CONFIG_SYS_SDRAM_BASE.
- Removed TRUE and FALSE macros.
- Fixed few typos and nits.
arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 250 +-
arch/arm/cpu/armv7/exynos/exynos5_setup.h | 5 +-
arch/arm/include/asm/arch-exynos/dmc.h| 3 +
arch/arm/include/asm/arch-exynos/power.h | 4 +-
4 files changed, 255 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
index 13003b8..b86dd2d 100644
--- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
+++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
@@ -6,6 +6,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#include common.h
#include config.h
#include asm/io.h
#include asm/arch/clock.h
@@ -16,7 +17,11 @@
#include exynos5_setup.h
#include clock_init.h
-#define TIMEOUT1
+#define TIMEOUT_US 1
+#define NUM_BYTE_LANES 4
+#define DEFAULT_DQS8
+#define DEFAULT_DQS_X4 (DEFAULT_DQS 24) || (DEFAULT_DQS 16) \
+ || (DEFAULT_DQS 8) || (DEFAULT_DQS 0)
#ifdef CONFIG_EXYNOS5250
static void reset_phy_ctrl(void)
@@ -176,7 +181,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
writel(val, phy1_ctrl-phy_con1);
writel(CTRL_RDLVL_GATE_ENABLE, dmc-rdlvl_config);
- i = TIMEOUT;
+ i = TIMEOUT_US;
while ((readl(dmc-phystatus)
(RDLVL_COMPLETE_CHO | RDLVL_COMPLETE_CH1)) !=
(RDLVL_COMPLETE_CHO | RDLVL_COMPLETE_CH1) i 0) {
@@ -220,6 +225,219 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, int reset)
#endif
#ifdef CONFIG_EXYNOS5420
+/**
+ * RAM address to use in the test.
+ *
+ * We'll use 4 words at this address and 4 at this address + 0x80 (Ares
+ * interleaves channels every 128 bytes). This will allow us to evaluate all
of
+ * the chips in a 1 chip per channel (2GB) system and half the chips in a 2
+ * chip per channel (4GB) system. We can't test the 2nd chip since we need to
+ * do tests before the 2nd chip is enabled. Looking at the 2nd chip isn't
+ * critical because the 1st and 2nd chip have very similar timings (they'd
+ * better have similar timings, since there's only a single adjustment that is
+ * shared by both chips).
+ */
+const unsigned int test_addr = CONFIG_SYS_SDRAM_BASE;
+
+/* Test pattern with which RAM will be tested */
+static const unsigned int test_pattern[] = {
+ 0x5a5a5a5a,
+ 0xa5a5a5a5,
+ 0xf0f0f0f0,
+ 0x0f0f0f0f,
+};
+
+/**
+ * This function is a test vector for sw read leveling,
+ * it compares the read data with the written data.
+ *
+ * @param ch DMC channel number
+ * @param byte_lanewhich DQS byte offset,
+ * possible values are 0,1,2,3
+ * @return TRUE if memory was good, FALSE if not.
+ */
+static bool dmc_valid_window_test_vector(int ch, int byte_lane)
+{
+ unsigned int read_data;
+ unsigned int mask;
+ int i;
+
+ mask = 0xFF (8 * byte_lane);
+
+ for (i = 0; i ARRAY_SIZE(test_pattern); i++) {
+ read_data = readl(test_addr + i * 4 + ch * 0x80);
+ if ((read_data mask) != (test_pattern[i] mask))
+ return false;
+ }
+
+ return true;
+}
+
+/**
+ * This function returns current read offset value.
+ *
+ * @param phy_ctrl pointer to the current phy controller
+ */
+static unsigned int dmc_get_read_offset_value(struct exynos5420_phy_control
+ *phy_ctrl)
+{
+ return readl(phy_ctrl-phy_con4);
+}
+
+/**
+ * This function performs resync, so that slave DLL is updated.
+ *
+ * @param phy_ctrl pointer to the current phy controller
+ */
+static void ddr_phy_set_do_resync(struct exynos5420_phy_control *phy_ctrl)
+{
+ setbits_le32(phy_ctrl-phy_con10, PHY_CON10_CTRL_OFFSETR3);
+ clrbits_le32(phy_ctrl-phy_con10, PHY_CON10_CTRL_OFFSETR3);
+}
+
+/**
+ * This function sets read offset value register with 'offset'.
+ *
+ * ...we also call call ddr_phy_set_do_resync().
+ *
+ * @param phy_ctrl pointer to the current phy controller
+ * @param offset offset to read DQS
+ */
+static void dmc_set_read_offset_value(struct exynos5420_phy_control *phy_ctrl,
+ unsigned int offset)
+{
+ writel(offset, phy_ctrl-phy_con4);
+
[U-Boot] [PATCH v2] Exynos: Make sure ps_hold gets set in the SPL
From: Doug Anderson diand...@chromium.org
Setting ps_hold ought to be one of the first things we do when we
first boot up. If we wait until the main u-boot runs we won't set it
in time and the PMIC may power us back off.
Moving ps_hold setup into the generic power_init() which
should contain code that's currently duplicated in the
board_power_init() of several boards.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Acked-by.
arch/arm/cpu/armv7/exynos/lowlevel_init.c |6 +-
arch/arm/cpu/armv7/exynos/power.c | 14 ++
arch/arm/include/asm/arch-exynos/power.h |8
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
index 11fe5b8..ed966bc 100644
--- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
+++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
@@ -39,6 +39,7 @@ enum {
DO_CLOCKS = 1 1,
DO_MEM_RESET= 1 2,
DO_UART = 1 3,
+ DO_POWER= 1 4,
};
int do_lowlevel_init(void)
@@ -60,9 +61,12 @@ int do_lowlevel_init(void)
break;
default:
/* This is a normal boot (not a wake from sleep) */
- actions = DO_CLOCKS | DO_MEM_RESET;
+ actions = DO_CLOCKS | DO_MEM_RESET | DO_POWER;
}
+ if (actions DO_POWER)
+ power_init();
+
if (actions DO_CLOCKS) {
system_clock_init();
mem_ctrl_init(actions DO_MEM_RESET);
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 563abd7..8999fb9 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -112,6 +112,12 @@ static void exynos5_set_ps_hold_ctrl(void)
EXYNOS_PS_HOLD_CONTROL_DATA_HIGH);
}
+/*
+ * Set ps_hold data driving value high
+ * This enables the machine to stay powered on
+ * after the initial power-on condition goes away
+ * (e.g. power button).
+ */
void set_ps_hold_ctrl(void)
{
if (cpu_is_exynos5())
@@ -196,3 +202,11 @@ void power_exit_wakeup(void)
else
exynos4_power_exit_wakeup();
}
+
+int power_init(void)
+{
+ /* Assert PS_HOLD to indicate that we're up and running */
+ set_ps_hold_ctrl();
+
+ return 0;
+}
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index bcef43f..7957169 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -1726,4 +1726,12 @@ uint32_t get_reset_status(void);
/* Read the resume function and call it */
void power_exit_wakeup(void);
+
+/**
+ * SoC level power init
+ *
+ * @return Return 0 if ok, else -1
+ */
+int power_init(void);
+
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pxa310 SDHC support.
On 5/26/2014 Monday 8:10 PM, Marek Vasut wrote: On Monday, May 26, 2014 at 01:48:14 PM, aking wrote: On 5/26/2014 Monday 6:56 PM, Marek Vasut wrote: On Monday, May 26, 2014 at 12:28:49 PM, aking_jin wrote: Hi, Marek On 2014/5/26 Mon 16:59, Marek Vasut wrote: On Monday, May 26, 2014 at 09:51:58 AM, aking_jin wrote: Hi, marek I've seen on the Internet that pxa310 support SDHC up to 32GB, but I'm using u-boot 2014.01, It could initialize OK. Device: PXA MMC Manufacturer ID: 3 OEM: 5344 Name: SS08G Tran Speed: 2600 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 7.4 GiB Bus Width: 4-bit It shows time out while reading block . Is there any particular process should be add? It is well possible that the driver is broken on PXA3xx . Note that mainline U- Boot doesn't really support PXA3xx . Are you working on PXA3xx support for mainline U-Boot ? I'm looking for support for pxa310 MMC SDHC . In the PXA310 SPEC: The MMC module is based on the standards outlined in the MultiMediaCard System Specification Version 3.3.1. The SD module manages one SD or SDIO card based on the standards outlined in the SD Memory Card Specification Version 1.10 and SDIO Card Specification Version 1.0 I'm doubting if the controller support SDHC (SD 2.0) ? The PXA27x controller works even with SDXC , that is tested. I suspect there might be some change in the PXA3xx controller, but I don't really know for sure. You'd have to check. Thank you for your answer. are you using SD mode or SPI Mode? which version are you using? I believe the pxa_mmc_gen.c is what needs to be used. There is no other PXA MMC driver in U-Boot mainline. I now noticed it has some basic monahans (pxa3xx) support too. Could you give out a log with MACRO CONFIG_MMC_TRACE on your pxa27x device ? any initialize ,read ,write, erase operation? Sorry for disturb you. Also, you didn't really answer my question with regards to porting U-Boot above. If you do that, use latest mainline, not 2014.01 . I just have to add SD support for my board, It's emergency. sorry for that. Hmmm. Best regards, Marek Vasut -- Best Regards aking_jin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Implement generalised RSA public exponents for verified boot
Remove the verified boot limitation that only allows a single
RSA public exponent of 65537 (F4). This allows use with existing
PKI infrastructure, and has been tested with HSM-based PKI.
Change the configuration OF tree format to store the RSA public
exponent as a 64 bit integer and implement backward compatibility
for verified boot configuration trees without this extra field.
Parameterise vboot_test.sh to test different public exponents and
do a drive-by fix to get vboot_test.sh working again.
Mathematics and other hard work by Andrew Bott.
Tested with the following public exponents: 3, 5, 17, 257, 39981,
50457, 65537 and 4294967297.
Signed-off-by: Andrew Bott andrew.b...@ipaccess.com
Signed-off-by: Andrew Wishart andrew.wish...@ipaccess.com
Signed-off-by: Neil Piercy neil.pie...@ipaccess.com
Signed-off-by: Michael van der Westhuizen mich...@smart-africa.com
---
doc/uImage.FIT/signature.txt | 4 +-
include/rsa.h| 1 +
lib/rsa/rsa-sign.c | 56 +++-
lib/rsa/rsa-verify.c | 88 +---
test/vboot/vboot_test.sh | 11 +-
5 files changed, 151 insertions(+), 9 deletions(-)
diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index 9502037..cc314a3 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -66,7 +66,8 @@ Creating an RSA key and certificate
---
To create a new public key, size 2048 bits:
-$ openssl genrsa -F4 -out keys/dev.key 2048
+$ openssl genpkey -algorithm RSA -out keys/dev.key \
+-pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
To create a certificate for this:
@@ -159,6 +160,7 @@ For RSA the following are mandatory:
- rsa,num-bits: Number of key bits (e.g. 2048)
- rsa,modulus: Modulus (N) as a big-endian multi-word integer
+- rsa,exponent: Public exponent (E) as a 64 bit unsigned integer
- rsa,r-squared: (2^num-bits)^2 as a big-endian multi-word integer
- rsa,n0-inverse: -1 / modulus[0] mod 2^32
diff --git a/include/rsa.h b/include/rsa.h
index a5680ab..b84d82a 100644
--- a/include/rsa.h
+++ b/include/rsa.h
@@ -27,6 +27,7 @@ struct rsa_public_key {
uint32_t n0inv; /* -1 / modulus[0] mod 2^32 */
uint32_t *modulus; /* modulus as little endian array */
uint32_t *rr; /* R^2 as little endian array */
+ uint64_t exponent; /* public exponent */
};
#if IMAGE_ENABLE_SIGN
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index ca8c120..f20ae28 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -261,9 +261,56 @@ err_priv:
}
/*
+ * rsa_get_e(): - Get the public exponent from an RSA public key
+ */
+static int rsa_get_e(RSA *key, uint64_t *e)
+{
+ int ret;
+ BIGNUM *bn_te;
+ uint64_t te;
+
+ ret = -1;
+ bn_te = NULL;
+
+ if (!e)
+ goto cleanup;
+
+ if (BN_num_bits(key-e) 64)
+ goto cleanup;
+
+ *e = BN_get_word(key-e);
+
+ if (BN_num_bits(key-e) 33) {
+ ret = 0;
+ goto cleanup;
+ }
+
+ bn_te = BN_dup(key-e);
+ if (!bn_te)
+ goto cleanup;
+
+ if (!BN_rshift(bn_te, bn_te, 32))
+ goto cleanup;
+
+ if (!BN_mask_bits(bn_te, 32))
+ goto cleanup;
+
+ te = BN_get_word(bn_te);
+ te = 32;
+ *e |= te;
+ ret = 0;
+
+cleanup:
+ if (bn_te)
+ BN_free(bn_te);
+
+ return ret;
+}
+
+/*
* rsa_get_params(): - Get the important parameters of an RSA public key
*/
-int rsa_get_params(RSA *key, uint32_t *n0_invp, BIGNUM **modulusp,
+int rsa_get_params(RSA *key, uint64_t *e, uint32_t *n0_invp, BIGNUM **modulusp,
BIGNUM **r_squaredp)
{
BIGNUM *big1, *big2, *big32, *big2_32;
@@ -286,6 +333,9 @@ int rsa_get_params(RSA *key, uint32_t *n0_invp,
BIGNUM **modulusp,
return -ENOMEM;
}
+ if (0 != rsa_get_e(key, e))
+ ret = -1;
+
if (!BN_copy(n, key-n) || !BN_set_word(big1, 1L) ||
!BN_set_word(big2, 2L) || !BN_set_word(big32, 32L))
ret = -1;
@@ -386,6 +436,7 @@ static int fdt_add_bignum(void *blob, int noffset,
const char *prop_name,
int rsa_add_verify_data(struct image_sign_info *info, void *keydest)
{
BIGNUM *modulus, *r_squared;
+ uint64_t e;
uint32_t n0_inv;
int parent, node;
char name[100];
@@ -397,7 +448,7 @@ int rsa_add_verify_data(struct image_sign_info
*info, void *keydest)
ret = rsa_get_pub_key(info-keydir, info-keyname, rsa);
if (ret)
return ret;
- ret = rsa_get_params(rsa, n0_inv, modulus, r_squared);
+ ret = rsa_get_params(rsa, e, n0_inv, modulus, r_squared);
if (ret)
return ret;
bits = BN_num_bits(modulus);
@@ -431,6 +482,7 @@ int rsa_add_verify_data(struct image_sign_info
*info, void *keydest)
info-keyname);
ret |= fdt_setprop_u32(keydest, node, rsa,num-bits, bits);
ret |= fdt_setprop_u32(keydest, node, rsa,n0-inverse, n0_inv);
+ ret |= fdt_setprop_u64(keydest, node, rsa,exponent, e);
ret |= fdt_add_bignum(keydest, node, rsa,modulus, modulus, bits);
ret |= fdt_add_bignum(keydest, node, rsa,r-squared, r_squared, bits);
ret |= fdt_setprop_string(keydest, node, FIT_ALGO_PROP,
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
Re: [U-Boot] pxa310 SDHC support.
On Monday, May 26, 2014 at 03:55:58 PM, aking wrote: [...] The PXA27x controller works even with SDXC , that is tested. I suspect there might be some change in the PXA3xx controller, but I don't really know for sure. You'd have to check. Thank you for your answer. are you using SD mode or SPI Mode? which version are you using? I believe the pxa_mmc_gen.c is what needs to be used. There is no other PXA MMC driver in U-Boot mainline. I now noticed it has some basic monahans (pxa3xx) support too. Could you give out a log with MACRO CONFIG_MMC_TRACE on your pxa27x device ? any initialize ,read ,write, erase operation? Sorry for disturb you. No, I cannot, sorry. I don't have the PXA27x device handy. +CC panto, he might have an idea how to debug it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] env_eeprom: Assign default environment during board_init_f
Assign default environment and set env valid during board_init_f
before relocation as the actual environment will be read from eeprom
later.
Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
---
Changes in v2:
-Handled the same in redundant env case also
as per review comment.
common/env_eeprom.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/common/env_eeprom.c b/common/env_eeprom.c
index 490ac73..905d39a 100644
--- a/common/env_eeprom.c
+++ b/common/env_eeprom.c
@@ -147,6 +147,7 @@ int saveenv(void)
#ifdef CONFIG_ENV_OFFSET_REDUND
int env_init(void)
{
+#ifdef ENV_IS_EMBEDDED
ulong len, crc[2], crc_tmp;
unsigned int off, off_env[2];
uchar buf[64], flags[2];
@@ -212,12 +213,16 @@ int env_init(void)
gd-env_addr = off_env[1] + offsetof(env_t, data);
else if (gd-env_valid == 1)
gd-env_addr = off_env[0] + offsetof(env_t, data);
-
+#else
+ gd-env_addr = (ulong)default_environment[0];
+ gd-env_valid = 1;
+#endif
return 0;
}
#else
int env_init(void)
{
+#ifdef ENV_IS_EMBEDDED
ulong crc, len, new;
unsigned off;
uchar buf[64];
@@ -250,7 +255,10 @@ int env_init(void)
gd-env_addr= 0;
gd-env_valid = 0;
}
-
+#else
+ gd-env_addr = (ulong)default_environment[0];
+ gd-env_valid = 1;
+#endif
return 0;
}
#endif
--
1.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
Dear David, In message cbdd3537-16f3-41c8-9929-6c30f56c3...@phytium.com.cn you wrote: I am will glad to share my understanding. Thanks. I wonder how adrp would work in any code that is supposed to be position-independent? In my understanding, with adrp the program is still relocatable except that the text base should be 4KB aligned or the relocated address has the same offset with text base. Darwin want CONFIG_SYS_TEXT_BASE to be not 4KB aligned, so the relocated address should be offsetted in the same manner. We should be careful here to use precise terms. CONFIG_SYS_TEXT_BASE is just the start address of the text segment, and if I understand correctly, it is NOT required that this is in any way aligned to a 4 KB boundary - we have to keep in mind here that the start of the text segment is not the same as the start address of the code; it can be the same, but often it is not - often other blocks of date preceed the actual program code (things like HRCW [hard reset configuration word], or strings with ID information etc., exception vector tables and/or code, etc.). Position-independent code is usually page aligned, so gcc-aarch64 implicitly apply the restriction of text base. Actually, u-boot for aarch64 apply another align requirement that is interrupt vector. The interrupt vector should be 2KB aligned. So, even without adrp CONFIG_SYS_TEXT_BASE should be 2KB aligned yet or relocated with the same offset, otherwise bug exist. CONFIG_SYS_TEXT_BASE is just one number here, and it cannot be considered alone. We must also include into our considerations the linker script, because this is where actually alignments are enforced. I think we do not need to add specific code to deal with these alignment requireents. It should be sufficient to implement these in the aarch64 linker script. This also applies for the alignment of the exception vector table. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You don't have to stay up nights to succeed; you have to stay awake days. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Implement generalised RSA public exponents for verified boot
From: Michael van der Westhuizen mich...@smart-africa.com
Remove the verified boot limitation that only allows a single
RSA public exponent of 65537 (F4). This allows use with existing
PKI infrastructure, and has been tested with HSM-based PKI.
Change the configuration OF tree format to store the RSA public
exponent as a 64 bit integer and implement backward compatibility
for verified boot configuration trees without this extra field.
Parameterise vboot_test.sh to test different public exponents and
do a drive-by fix to get vboot_test.sh working again.
Mathematics and other hard work by Andrew Bott.
Tested with the following public exponents: 3, 5, 17, 257, 39981,
50457, 65537 and 4294967297.
Signed-off-by: Andrew Bott andrew.b...@ipaccess.com
Signed-off-by: Andrew Wishart andrew.wish...@ipaccess.com
Signed-off-by: Neil Piercy neil.pie...@ipaccess.com
Signed-off-by: Michael van der Westhuizen mich...@smart-africa.com
---
Changes for v2:
- None. Resend to address line wrapping issues.
doc/uImage.FIT/signature.txt | 4 +-
include/rsa.h| 1 +
lib/rsa/rsa-sign.c | 56 +++-
lib/rsa/rsa-verify.c | 88 +---
test/vboot/vboot_test.sh | 11 +-
5 files changed, 151 insertions(+), 9 deletions(-)
diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index 9502037..cc314a3 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -66,7 +66,8 @@ Creating an RSA key and certificate
---
To create a new public key, size 2048 bits:
-$ openssl genrsa -F4 -out keys/dev.key 2048
+$ openssl genpkey -algorithm RSA -out keys/dev.key \
+-pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
To create a certificate for this:
@@ -159,6 +160,7 @@ For RSA the following are mandatory:
- rsa,num-bits: Number of key bits (e.g. 2048)
- rsa,modulus: Modulus (N) as a big-endian multi-word integer
+- rsa,exponent: Public exponent (E) as a 64 bit unsigned integer
- rsa,r-squared: (2^num-bits)^2 as a big-endian multi-word integer
- rsa,n0-inverse: -1 / modulus[0] mod 2^32
diff --git a/include/rsa.h b/include/rsa.h
index a5680ab..b84d82a 100644
--- a/include/rsa.h
+++ b/include/rsa.h
@@ -27,6 +27,7 @@ struct rsa_public_key {
uint32_t n0inv; /* -1 / modulus[0] mod 2^32 */
uint32_t *modulus; /* modulus as little endian array */
uint32_t *rr; /* R^2 as little endian array */
+ uint64_t exponent; /* public exponent */
};
#if IMAGE_ENABLE_SIGN
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index ca8c120..f20ae28 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -261,9 +261,56 @@ err_priv:
}
/*
+ * rsa_get_e(): - Get the public exponent from an RSA public key
+ */
+static int rsa_get_e(RSA *key, uint64_t *e)
+{
+ int ret;
+ BIGNUM *bn_te;
+ uint64_t te;
+
+ ret = -1;
+ bn_te = NULL;
+
+ if (!e)
+ goto cleanup;
+
+ if (BN_num_bits(key-e) 64)
+ goto cleanup;
+
+ *e = BN_get_word(key-e);
+
+ if (BN_num_bits(key-e) 33) {
+ ret = 0;
+ goto cleanup;
+ }
+
+ bn_te = BN_dup(key-e);
+ if (!bn_te)
+ goto cleanup;
+
+ if (!BN_rshift(bn_te, bn_te, 32))
+ goto cleanup;
+
+ if (!BN_mask_bits(bn_te, 32))
+ goto cleanup;
+
+ te = BN_get_word(bn_te);
+ te = 32;
+ *e |= te;
+ ret = 0;
+
+cleanup:
+ if (bn_te)
+ BN_free(bn_te);
+
+ return ret;
+}
+
+/*
* rsa_get_params(): - Get the important parameters of an RSA public key
*/
-int rsa_get_params(RSA *key, uint32_t *n0_invp, BIGNUM **modulusp,
+int rsa_get_params(RSA *key, uint64_t *e, uint32_t *n0_invp, BIGNUM **modulusp,
BIGNUM **r_squaredp)
{
BIGNUM *big1, *big2, *big32, *big2_32;
@@ -286,6 +333,9 @@ int rsa_get_params(RSA *key, uint32_t *n0_invp, BIGNUM
**modulusp,
return -ENOMEM;
}
+ if (0 != rsa_get_e(key, e))
+ ret = -1;
+
if (!BN_copy(n, key-n) || !BN_set_word(big1, 1L) ||
!BN_set_word(big2, 2L) || !BN_set_word(big32, 32L))
ret = -1;
@@ -386,6 +436,7 @@ static int fdt_add_bignum(void *blob, int noffset, const
char *prop_name,
int rsa_add_verify_data(struct image_sign_info *info, void *keydest)
{
BIGNUM *modulus, *r_squared;
+ uint64_t e;
uint32_t n0_inv;
int parent, node;
char name[100];
@@ -397,7 +448,7 @@ int rsa_add_verify_data(struct image_sign_info *info, void
*keydest)
ret = rsa_get_pub_key(info-keydir, info-keyname, rsa);
if (ret)
return ret;
- ret = rsa_get_params(rsa, n0_inv, modulus, r_squared);
+ ret = rsa_get_params(rsa, e, n0_inv, modulus, r_squared);
if (ret)
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
Hi Albert, The previous stage bootloader (which I had no control over) wanted it's header to be aligned to a 512 byte MMC block boundary, presumably since this allowed DMA operations without copy/shifting. At the same time, I didn't want to hack a header into start.S because I didn't want to carry another downstream patch. So I investigated if I could shift u-boot's base address as a feature that would allow an aligned header to be used without the start.S patch. I know that a custom header patch to start.S would work, and that a header plus padding will also work. But I found out that you can align the base on certain smaller offsets if you keep the relocation offset at nice boundaries like 0x1000 and if the relocation offset is a multiple of the maximum alignment requirements of the image. The original patch I submitted didn't handle an end condition properly, was ARM64-specific (wasn't tested on other architectures), and because the patch was NAK'd, I didn't bother to submit a v2 patch and consider the idea to be dead. I'm happy to abandon the patch. I hope this helps. Best regards, Darwin On 14-05-26 02:50 AM, Albert ARIBAUD wrote: Hi Wolfgang, Darwin, On Thu, 15 May 2014 21:19:57 +0200, Wolfgang Denk w...@denx.de wrote: Setting CONFIG_SYS_TEXT_BASE to something like 0x8820 is extremly fishy. If you want to add some header data to your image, you should not shift the text segment, but rather include your header in the start of the text segment. Or keep it completely separate, without messing with CONFIG_SYS_TEXT_BASE. Back to the origin of the discussion and patch: Darwin, can you describe the actual technical difficulty which caused you to you write and submitting this patch? Best regards, Wolfgang Denk Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] EFI Partition handling
This series focusses on the EFI Partition handling and provides: - fixes to endianness issues - cleanup of the lbaint_t handling - cleanup of a type that requires u64 - improved clarification of the code by cleaning up the casting - verified support of CONFIG_SYS_64BIT_LBA Also, added new feature: - get_partition_info_efi_by_name(): find a partition entry by name Tested on ARMv7 and ARMv8. (not tested on Big Endian...) Steve Rae (3): disk: part_efi: resolve endianness issues disk: part_efi: clarify lbaint_t usage disk: part_efi: add get_partition_info_efi_by_name() disk/part_dos.c| 5 ++-- disk/part_efi.c| 73 +++--- fs/fat/fat_write.c | 2 +- include/part.h | 11 4 files changed, 62 insertions(+), 29 deletions(-) -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] disk: part_efi: add get_partition_info_efi_by_name()
Add function to find a GPT table entry by name.
Tested on little endian ARMv7 and ARMv8 configurations
Signed-off-by: Steve Rae s...@broadcom.com
---
disk/part_efi.c | 21 -
include/part.h | 11 +++
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 78a3782..612f092 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -181,7 +181,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, int
part,
UUID_STR_FORMAT_GUID);
#endif
- debug(%s: start 0x LBAF , size 0x LBAF , name %s, __func__,
+ debug(%s: start 0x LBAF , size 0x LBAF , name %s\n, __func__,
info-start, info-size, info-name);
/* Remember to free pte */
@@ -189,6 +189,25 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc,
int part,
return 0;
}
+int get_partition_info_efi_by_name(block_dev_desc_t *dev_desc,
+ const char *name, disk_partition_t *info)
+{
+ int ret;
+ int i;
+ for (i = 1; i GPT_ENTRY_NUMBERS; i++) {
+ ret = get_partition_info_efi(dev_desc, i, info);
+ if (ret != 0) {
+ /* no more entries in table */
+ return -1;
+ }
+ if (strcmp(name, (const char *)info-name) == 0) {
+ /* matched */
+ return 0;
+ }
+ }
+ return -2;
+}
+
int test_part_efi(block_dev_desc_t * dev_desc)
{
ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc-blksz);
diff --git a/include/part.h b/include/part.h
index f2c8c64..a496a4a 100644
--- a/include/part.h
+++ b/include/part.h
@@ -180,6 +180,17 @@ int test_part_amiga (block_dev_desc_t *dev_desc);
#include part_efi.h
/* disk/part_efi.c */
int get_partition_info_efi (block_dev_desc_t * dev_desc, int part,
disk_partition_t *info);
+/**
+ * get_partition_info_efi_by_name() - Find the specified GPT partition table
entry
+ *
+ * @param dev_desc - block device descriptor
+ * @param gpt_name - the specified table entry name
+ * @param info - returns the disk partition info
+ *
+ * @return - '0' on match, '-1' on no match, otherwise error
+ */
+int get_partition_info_efi_by_name(block_dev_desc_t *dev_desc,
+ const char *name, disk_partition_t *info);
void print_part_efi (block_dev_desc_t *dev_desc);
int test_part_efi (block_dev_desc_t *dev_desc);
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] disk: part_efi: clarify lbaint_t usage
- update the comments regarding lbaint_t usage
- cleanup casting of values related to the lbaint_t type
- cleanup of a type that requires a u64
Tested on little endian ARMv7 and ARMv8 configurations
Signed-off-by: Steve Rae s...@broadcom.com
---
disk/part_dos.c| 5 +++--
disk/part_efi.c| 51 ++-
fs/fat/fat_write.c | 2 +-
3 files changed, 30 insertions(+), 28 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 05c3933..b0c3af5 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -199,8 +199,9 @@ static int get_partition_info_extended (block_dev_desc_t
*dev_desc, int ext_part
(part_num == which_part)
(is_extended(pt-sys_ind) == 0)) {
info-blksz = 512;
- info-start = ext_part_sector + le32_to_int
(pt-start4);
- info-size = le32_to_int (pt-size4);
+ info-start = (lbaint_t)(ext_part_sector +
+ le32_to_int(pt-start4));
+ info-size = (lbaint_t)le32_to_int(pt-size4);
switch(dev_desc-if_type) {
case IF_TYPE_IDE:
case IF_TYPE_SATA:
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 8c89740..78a3782 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -6,13 +6,9 @@
*/
/*
- * Problems with CONFIG_SYS_64BIT_LBA:
- *
- * struct disk_partition.start in include/part.h is sized as ulong.
- * When CONFIG_SYS_64BIT_LBA is activated, lbaint_t changes from ulong to
uint64_t.
- * For now, it is cast back to ulong at assignment.
- *
- * This limits the maximum size of addressable storage to 2 Terra Bytes
+ * NOTE:
+ * when CONFIG_SYS_64BIT_LBA is not defined, lbaint_t is 32 bits; this
+ * limits the maximum size of addressable storage to 2 Terra Bytes
*/
#include asm/unaligned.h
#include common.h
@@ -43,8 +39,8 @@ static inline u32 efi_crc32(const void *buf, u32 len)
static int pmbr_part_valid(struct partition *part);
static int is_pmbr_valid(legacy_mbr * mbr);
-static int is_gpt_valid(block_dev_desc_t * dev_desc, unsigned long long lba,
- gpt_header * pgpt_head, gpt_entry ** pgpt_pte);
+static int is_gpt_valid(block_dev_desc_t *dev_desc, u64 lba,
+ gpt_header *pgpt_head, gpt_entry **pgpt_pte);
static gpt_entry *alloc_read_gpt_entries(block_dev_desc_t * dev_desc,
gpt_header * pgpt_head);
static int is_pte_valid(gpt_entry * pte);
@@ -169,10 +165,10 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc,
int part,
return -1;
}
- /* The ulong casting limits the maximum disk size to 2 TB */
- info-start = (u64)le64_to_cpu(gpt_pte[part - 1].starting_lba);
+ /* The 'lbaint_t' casting may limit the maximum disk size to 2 TB */
+ info-start = (lbaint_t)le64_to_cpu(gpt_pte[part - 1].starting_lba);
/* The ending LBA is inclusive, to calculate size, add 1 to it */
- info-size = ((u64)le64_to_cpu(gpt_pte[part - 1].ending_lba) + 1)
+ info-size = (lbaint_t)le64_to_cpu(gpt_pte[part - 1].ending_lba) + 1
- info-start;
info-blksz = dev_desc-blksz;
@@ -279,12 +275,14 @@ int write_gpt_table(block_dev_desc_t *dev_desc,
gpt_h-header_crc32 = cpu_to_le32(calc_crc32);
if (dev_desc-block_write(dev_desc-dev,
- le32_to_cpu(gpt_h-last_usable_lba) + 1,
+ (lbaint_t)le64_to_cpu(gpt_h-last_usable_lba)
+ + 1,
pte_blk_cnt, gpt_e) != pte_blk_cnt)
goto err;
if (dev_desc-block_write(dev_desc-dev,
- le32_to_cpu(gpt_h-my_lba), 1, gpt_h) != 1)
+ (lbaint_t)le64_to_cpu(gpt_h-my_lba), 1,
+ gpt_h) != 1)
goto err;
debug(GPT successfully written to block device!\n);
@@ -298,9 +296,10 @@ int write_gpt_table(block_dev_desc_t *dev_desc,
int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
disk_partition_t *partitions, int parts)
{
- u32 offset = (u32)le32_to_cpu(gpt_h-first_usable_lba);
- ulong start;
- u32 last_usable_lba = (u32)le32_to_cpu(gpt_h-last_usable_lba);
+ lbaint_t offset = (lbaint_t)le64_to_cpu(gpt_h-first_usable_lba);
+ lbaint_t start;
+ lbaint_t last_usable_lba = (lbaint_t)
+ le64_to_cpu(gpt_h-last_usable_lba);
int i, k;
size_t efiname_len, dosname_len;
#ifdef CONFIG_PARTITION_UUIDS
@@ -364,7 +363,8 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
gpt_e[i].partition_name[k] =
(efi_char16_t)(partitions[i].name[k]);
- debug(%s:
[U-Boot] [PATCH 1/3] disk: part_efi: resolve endianness issues
Tested on little endian ARMv7 and ARMv8 configurations
Signed-off-by: Steve Rae s...@broadcom.com
---
disk/part_efi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index c74b7b9..8c89740 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -279,7 +279,7 @@ int write_gpt_table(block_dev_desc_t *dev_desc,
gpt_h-header_crc32 = cpu_to_le32(calc_crc32);
if (dev_desc-block_write(dev_desc-dev,
- le32_to_cpu(gpt_h-last_usable_lba + 1),
+ le32_to_cpu(gpt_h-last_usable_lba) + 1,
pte_blk_cnt, gpt_e) != pte_blk_cnt)
goto err;
@@ -300,6 +300,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
{
u32 offset = (u32)le32_to_cpu(gpt_h-first_usable_lba);
ulong start;
+ u32 last_usable_lba = (u32)le32_to_cpu(gpt_h-last_usable_lba);
int i, k;
size_t efiname_len, dosname_len;
#ifdef CONFIG_PARTITION_UUIDS
@@ -321,7 +322,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
gpt_e[i].starting_lba = cpu_to_le64(offset);
offset += partitions[i].size;
}
- if (offset = gpt_h-last_usable_lba) {
+ if (offset = last_usable_lba) {
printf(Partitions layout exceds disk size\n);
return -1;
}
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] atngw100mkii: add missing CONFIG_SYS_TEXT_BASE
Dear Andreas Bießmann, Andreas Bießmann andreas.de...@googlemail.com writes: Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Masahiro Yamada yamad...@jp.panasonic.com --- include/configs/atngw100mkii.h |1 + 1 file changed, 1 insertion(+) applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i2c: kona: Resolve Kona I2C driver issue
- i2c mw command hangs (with some compilers)
Signed-off-by: Steve Rae s...@broadcom.com
---
drivers/i2c/kona_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/kona_i2c.c b/drivers/i2c/kona_i2c.c
index 0b1715a..5eab338 100644
--- a/drivers/i2c/kona_i2c.c
+++ b/drivers/i2c/kona_i2c.c
@@ -663,7 +663,7 @@ static int kona_i2c_read(struct i2c_adapter *adap, uchar
chip, uint addr,
static int kona_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr,
int alen, uchar *buffer, int len)
{
- struct i2c_msg msg[0];
+ struct i2c_msg msg[1];
unsigned char msgbuf0[64];
unsigned int i;
struct bcm_kona_i2c_dev *dev = kona_get_dev(adap);
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-avr32/master - u-boot/master
Dear Tom Rini, Please pull the following changes from u-boot-avr32/master into u-boot/master. The following changes since commit 9665fa8f9e1488209d5e01d0792c243e0a220c5a: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-05-24 06:34:08 -0400) are available in the git repository at: git://git.denx.de/u-boot-avr32.git master for you to fetch changes up to 024cd74174a7ee11e71a430395d9f8ae334fec43: atngw100mkii: add missing CONFIG_SYS_TEXT_BASE (2014-05-26 21:23:54 +0200) Andreas Bießmann (1): atngw100mkii: add missing CONFIG_SYS_TEXT_BASE include/configs/atngw100mkii.h |1 + 1 file changed, 1 insertion(+) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: free allocated memory on initialization errors
Cleanup to balance malloc/free calls.
Signed-off-by: Darwin Rambo dra...@broadcom.com
Reviewed-by: Steve Rae s...@broadcom.com
---
drivers/mmc/kona_sdhci.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/kona_sdhci.c b/drivers/mmc/kona_sdhci.c
index 77e42c8..f804f4c 100644
--- a/drivers/mmc/kona_sdhci.c
+++ b/drivers/mmc/kona_sdhci.c
@@ -113,16 +113,20 @@ int kona_sdhci_init(int dev_index, u32 min_clk, u32
quirks)
__func__, dev_index);
ret = -EINVAL;
}
- if (ret)
+ if (ret) {
+ free(host);
return ret;
+ }
host-name = kona-sdhci;
host-ioaddr = reg_base;
host-quirks = quirks;
host-host_caps = MMC_MODE_HC;
- if (init_kona_mmc_core(host))
+ if (init_kona_mmc_core(host)) {
+ free(host);
return -EINVAL;
+ }
if (quirks SDHCI_QUIRK_REG32_RW)
host-version = sdhci_readl(host, SDHCI_HOST_VERSION - 2) 16;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] macb: make checkpatch clean
This also renames the CONFIG_SYS_MACB_xx defines. They are used just local and
therefore don't need the CONFIG_SYS_ prefix.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
drivers/net/macb.c | 56 +++-
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 781a272..750331d 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -40,11 +40,11 @@
#include macb.h
-#define CONFIG_SYS_MACB_RX_BUFFER_SIZE 4096
-#define CONFIG_SYS_MACB_RX_RING_SIZE (CONFIG_SYS_MACB_RX_BUFFER_SIZE
/ 128)
-#define CONFIG_SYS_MACB_TX_RING_SIZE 16
-#define CONFIG_SYS_MACB_TX_TIMEOUT 1000
-#define CONFIG_SYS_MACB_AUTONEG_TIMEOUT500
+#define MACB_RX_BUFFER_SIZE4096
+#define MACB_RX_RING_SIZE (MACB_RX_BUFFER_SIZE / 128)
+#define MACB_TX_RING_SIZE 16
+#define MACB_TX_TIMEOUT1000
+#define MACB_AUTONEG_TIMEOUT 500
struct macb_dma_desc {
u32 addr;
@@ -170,7 +170,7 @@ int macb_miiphy_read(const char *devname, u8 phy_adr, u8
reg, u16 *value)
struct eth_device *dev = eth_get_dev_by_name(devname);
struct macb_device *macb = to_macb(dev);
- if ( macb-phy_addr != phy_adr )
+ if (macb-phy_addr != phy_adr)
return -1;
arch_get_mdio_control(devname);
@@ -184,7 +184,7 @@ int macb_miiphy_write(const char *devname, u8 phy_adr, u8
reg, u16 value)
struct eth_device *dev = eth_get_dev_by_name(devname);
struct macb_device *macb = to_macb(dev);
- if ( macb-phy_addr != phy_adr )
+ if (macb-phy_addr != phy_adr)
return -1;
arch_get_mdio_control(devname);
@@ -208,11 +208,12 @@ static int macb_send(struct eth_device *netdev, void
*packet, int length)
ctrl = length TXBUF_FRMLEN_MASK;
ctrl |= TXBUF_FRAME_END;
- if (tx_head == (CONFIG_SYS_MACB_TX_RING_SIZE - 1)) {
+ if (tx_head == (MACB_TX_RING_SIZE - 1)) {
ctrl |= TXBUF_WRAP;
macb-tx_head = 0;
- } else
+ } else {
macb-tx_head++;
+ }
macb-tx_ring[tx_head].ctrl = ctrl;
macb-tx_ring[tx_head].addr = paddr;
@@ -223,7 +224,7 @@ static int macb_send(struct eth_device *netdev, void
*packet, int length)
* I guess this is necessary because the networking core may
* re-use the transmit buffer as soon as we return...
*/
- for (i = 0; i = CONFIG_SYS_MACB_TX_TIMEOUT; i++) {
+ for (i = 0; i = MACB_TX_TIMEOUT; i++) {
barrier();
ctrl = macb-tx_ring[tx_head].ctrl;
if (ctrl TXBUF_USED)
@@ -233,7 +234,7 @@ static int macb_send(struct eth_device *netdev, void
*packet, int length)
dma_unmap_single(packet, length, paddr);
- if (i = CONFIG_SYS_MACB_TX_TIMEOUT) {
+ if (i = MACB_TX_TIMEOUT) {
if (ctrl TXBUF_UNDERRUN)
printf(%s: TX underrun\n, netdev-name);
if (ctrl TXBUF_EXHAUSTED)
@@ -256,7 +257,7 @@ static void reclaim_rx_buffers(struct macb_device *macb,
while (i new_tail) {
macb-rx_ring[i].addr = ~RXADDR_USED;
i++;
- if (i CONFIG_SYS_MACB_RX_RING_SIZE)
+ if (i MACB_RX_RING_SIZE)
i = 0;
}
@@ -295,7 +296,7 @@ static int macb_recv(struct eth_device *netdev)
if (wrapped) {
unsigned int headlen, taillen;
- headlen = 128 * (CONFIG_SYS_MACB_RX_RING_SIZE
+ headlen = 128 * (MACB_RX_RING_SIZE
- macb-rx_tail);
taillen = length - headlen;
memcpy((void *)NetRxPackets[0],
@@ -306,11 +307,11 @@ static int macb_recv(struct eth_device *netdev)
}
NetReceive(buffer, length);
- if (++rx_tail = CONFIG_SYS_MACB_RX_RING_SIZE)
+ if (++rx_tail = MACB_RX_RING_SIZE)
rx_tail = 0;
reclaim_rx_buffers(macb, rx_tail);
} else {
- if (++rx_tail = CONFIG_SYS_MACB_RX_RING_SIZE) {
+ if (++rx_tail = MACB_RX_RING_SIZE) {
wrapped = 1;
rx_tail = 0;
}
@@ -333,7 +334,7 @@ static void macb_phy_reset(struct macb_device *macb)
macb_mdio_write(macb, MII_BMCR, (BMCR_ANENABLE
| BMCR_ANRESTART));
- for (i = 0; i CONFIG_SYS_MACB_AUTONEG_TIMEOUT / 100; i++) {
+ for (i = 0; i MACB_AUTONEG_TIMEOUT / 100; i++) {
status =
Re: [U-Boot] [PATCH v2 1/3] net: macb: enable dcache in macb
Hi Josh,
On 19.05.14 13:51, Josh Wu wrote:
Add to code to flush the dcache after we writing in DMA buffer.
Also we need invalidate the dcache before we check the status in the
DMA buffer.
Tested in SAMA5D3x-EK with gmac0. Tftp download speed shows in below:
Disable DCache: 1.1 MiB/s
Enable DCache: 1.6 MiB/s
Increase speed with about 40%.
The code should have no impact with the boards which are not
enable_dcache().
Tested in AT91SAM9M10G45EK.
Signed-off-by: Josh Wu josh...@atmel.com
---
v1 - v2:
no change.
drivers/net/macb.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 781a272..b18f07b 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -194,6 +194,39 @@ int macb_miiphy_write(const char *devname, u8 phy_adr,
u8 reg, u16 value)
}
#endif
+#define IS_RX 1
+#define IS_TX 0
+static inline void macb_invalidate_ring_desc(struct macb_device *macb, bool
is_rx)
+{
+ if (is_rx)
+ invalidate_dcache_range(macb-rx_ring_dma, macb-rx_ring_dma +
+ CONFIG_SYS_MACB_RX_RING_SIZE * sizeof(struct
macb_dma_desc));
these lines produce checkpatch 'line over 80 chars' warnings. Could you
please check my macb cleanup patch [1] and adopt yours to that one?
Could you please also do a formal review of that patch?
Also it could make sens to introduce some MACB_RX_RING_BYTE_SIZE or
something like this to prevent writing always the multiply by
sizeof(macb_dma_desc).
If you could a new version of this patch it could go in as the first
version was in merge window phase AFAIR. The other two patches in this
series are ok.
Best regards
Andreas Bießmann
[1] http://patchwork.ozlabs.org/patch/352624/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/2] ARM: atmel: switch to main crystal osc for SPL boot
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: If without switch to main crystal oscillator, the sama5d3 SoC will use internal on chip RC oscillator. In order to get better accuracy, switch to main crystal oscillator. Signed-off-by: Bo Shen voice.s...@atmel.com --- arch/arm/cpu/at91-common/spl.c| 39 +++ arch/arm/include/asm/arch-at91/at91_pmc.h | 4 2 files changed, 43 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/2] ARM: atmel: enable SPL on sama5d3_xplained board
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: It supports boot from NAND and SD/MMC card. Signed-off-by: Bo Shen voice.s...@atmel.com --- board/atmel/sama5d3_xplained/sama5d3_xplained.c | 87 + include/configs/sama5d3_xplained.h | 50 ++ 2 files changed, 137 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/4] ARM: atmel: sama5d3xek: convert to generic board
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on boot: Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Signed-off-by: Bo Shen voice.s...@atmel.com Tested-by: Josh Wu josh...@atmel.com --- include/configs/sama5d3xek.h | 2 ++ 1 file changed, 2 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/4] ARM: atmel: sama5d3_xplained: convert to generic board
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on boot: Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Signed-off-by: Bo Shen voice.s...@atmel.com --- include/configs/sama5d3_xplained.h | 2 ++ 1 file changed, 2 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,4/4] ARM: atmel: at91sam9x5ek: convert to generic board
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on boot: Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Signed-off-by: Bo Shen voice.s...@atmel.com Tested-by: Josh Wu josh...@atmel.com --- include/configs/at91sam9x5ek.h | 2 ++ 1 file changed, 2 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpio: at91: add sanity check for the NULL pointer
Dear Josh Wu, Josh Wu josh...@atmel.com writes: We need check the NULL pointer as at91_pio_get_port() may return NULL. Also print a error message when at91_pio_get_port() failed otherwise we cannot notice the failure. Signed-off-by: Josh Wu josh...@atmel.com --- drivers/gpio/at91_gpio.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/4] ARM: atmel: at91sam9m10g45ek: convert to generic board
Dear Bo Shen, Bo Shen voice.s...@atmel.com writes: Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on boot: Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Signed-off-by: Bo Shen voice.s...@atmel.com Tested-by: Josh Wu josh...@atmel.com --- include/configs/at91sam9m10g45ek.h | 2 ++ 1 file changed, 2 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mmc: atmel_mci: fix print incorrect buffer content for debug
Dear Josh Wu, Josh Wu josh...@atmel.com writes: Signed-off-by: Josh Wu josh...@atmel.com [fix checkpatch line length warning] Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- drivers/mmc/gen_atmel_mci.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) applied to u-boot-atmel/master with slight changes to be checkpatch save, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] corvus: remove unneeded CONFIG_AT91_LEGACY
Dear Andreas Devel, Andreas Devel andreas.de...@googlemail.com writes: Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Heiko Schocher h...@denx.de --- include/configs/corvus.h |1 - 1 file changed, 1 deletion(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,3/3] sama5d3xek: enable PMECC header generation
Dear Andreas Bießmann, Andreas Bießmann andreas.de...@googlemail.com writes: Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Bo Shen voice.s...@atmel.com Tested-by: Bo Shen voice.s...@atmel.com --- Changes in v3: * use CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER Changes in v2: None include/configs/sama5d3xek.h |1 + 1 file changed, 1 insertion(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/3] ARM: at91sam9x5: define the AT91FAMILY and ARM926EJS in SoC header
Dear Josh Wu, Josh Wu josh...@atmel.com writes: Signed-off-by: Josh Wu josh...@atmel.com --- v1 - v2: 1. split the patch alone. 2. add missed ARM926EJS macro. arch/arm/include/asm/arch-at91/at91sam9x5.h |3 +++ 1 file changed, 3 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,1/3] mkimage: add atmelimage
Dear Andreas Bießmann, Andreas Bießmann andreas.de...@googlemail.com writes: The new atmelimage converts a machine code BLOB to bootable ROM image. Atmel ROM has no sophisticated image format, it only checks the first 7 ARM vectors. The vectors can contain valid B or LDR opcodes, the 6'th vector contains the image size to load. Additionally the PMECC header can be written by the atmelimage target. The parameters must be given via the -n switch as a coma separated list. For example: mkimage -T atmelimage \ -n usePmecc=1,sectorPerPage=4,sectorSize=512,spareSize=64,eccBits=4,eccOffset=36 \ -d spl/u-boot-spl.bin boot.bin A provided image can be checked for correct header setup. It prints out the PMECC header parameters if it has one and the 6'th interrupt vector content. ---8--- Image Type:ATMEL ROM-Boot Image with PMECC Header PMECC header eccOffset:36 sectorSize: 512 eccBitReq: 4 spareSize:64 nbSectorPerPage: 4 usePmecc: 1 6'th vector has 17044 set ---8--- A SPL binary modified with the atmelimage mkimage target was succesfully booted on a sama5d34ek via MMC and NAND. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Bo Shen voice.s...@atmel.com Cc: Heiko Schocher h...@denx.de Tested-by: Bo Shen voice.s...@atmel.com Acked-by: Bo Shen voice.s...@atmel.com --- Changes in v3: * remove check for 'usePmecc=y' Changes in v2: * do not check filesize in atmelimage * add PMECC header generation and printout * add printout of 6'th vector common/image.c |1 + include/image.h|1 + tools/Makefile |1 + tools/atmelimage.c | 342 tools/imagetool.c |2 + tools/imagetool.h |1 + 6 files changed, 348 insertions(+) create mode 100644 tools/atmelimage.c applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,2/3] arm:at91: enable ROM loadable atmel image
Dear Andreas Bießmann, Andreas Bießmann andreas.de...@googlemail.com writes: For sama5d3xek we need to modify the SPL image for correct detection by ROM code. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Tested-by: Bo Shen voice.s...@atmel.com --- Changes in v3: * add atmel_pmecc_params host tool, it generates an appropriate string for mkimage -n switch with compiled in values also used in atmel_nand driver Changes in v2: * add -n switch to mkimage for PMECC type NAND and CONFIG_SYS_NANDFLASH arch/arm/cpu/armv7/at91/config.mk | 10 doc/README.atmel_pmecc| 21 +++ spl/Makefile | 11 tools/Makefile|2 ++ tools/atmel_pmecc_params.c| 51 + 5 files changed, 95 insertions(+) create mode 100644 arch/arm/cpu/armv7/at91/config.mk create mode 100644 tools/atmel_pmecc_params.c applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/3] at91: remove redundant AT91FAMILY definition in board config file
Dear Josh Wu, Josh Wu josh...@atmel.com writes: Now the AT91FAMILY is already defined in the at91 SoC header. The at91 board config file will include the SoC header file. So we can remove the redundant AT91FAMILY definition in at91 board config files. Signed-off-by: Josh Wu josh...@atmel.com --- v1 - v2: 1. modified more files, inclulde corvus, cpu9260, ethernut5 and vl_ma2sc board. include/configs/at91sam9m10g45ek.h |1 - include/configs/at91sam9n12ek.h|1 - include/configs/at91sam9x5ek.h |1 - include/configs/corvus.h |2 -- include/configs/cpu9260.h |1 - include/configs/ethernut5.h|1 - include/configs/sama5d3_xplained.h |1 - include/configs/sama5d3xek.h |1 - include/configs/vl_ma2sc.h |1 - 9 files changed, 10 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: at91: remove AT91X40 macro since it is not use any more
Dear Josh Wu, Josh Wu josh...@atmel.com writes: The at91x40.h is not exist. So we remove it. Signed-off-by: Josh Wu josh...@atmel.com --- arch/arm/include/asm/arch-at91/hardware.h |2 -- 1 file changed, 2 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,1/2] ARM: at91sam9m10g45ek: enable mci0 support
Dear Josh Wu, Josh Wu josh...@atmel.com writes: Also we enable the mmc command in configuration file. As both CONFIG_CMD_MMC and CONFIG_CMD_USB use the CONFIG_DOS_PARTITION, so remove the redundant CONFIG_DOS_PARTITION definition. Signed-off-by: Josh Wu josh...@atmel.com --- v1 - v2: 1. refined the comment for the pins. 2. remove detected pin initialization. 3. move the mci initialization code to devices.c 4. remove useless header file: mmc.h .../cpu/arm926ejs/at91/at91sam9m10g45_devices.c| 17 + board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c| 10 ++ include/configs/at91sam9m10g45ek.h | 15 ++- 3 files changed, 41 insertions(+), 1 deletion(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/3] ARM: at91: remove redundant ARM926EJS definition in board config files
Dear Josh Wu, Josh Wu josh...@atmel.com writes: As at91 board config file will include the SoC header, so we can remove the ARM926EJS definition in board config files. Signed-off-by: Josh Wu josh...@atmel.com --- include/configs/at91sam9n12ek.h |2 -- include/configs/ethernut5.h |1 - include/configs/vl_ma2sc.h |1 - 3 files changed, 4 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/2] ARM: at91sam9m10g45ek: add mmc environment configuration support
Dear Josh Wu, Josh Wu josh...@atmel.com writes: In this configuration the environment will save in file: uboot.env of mmc card. Signed-off-by: Josh Wu josh...@atmel.com --- v1 - v2: 1. remove mem=128m and roottype in bootargs. 2. default boot command use zImage instead of uImage. boards.cfg |1 + include/configs/at91sam9m10g45ek.h | 19 +++ 2 files changed, 20 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Dear Albert Aribaud, please pull the following changes from u-boot-atmel/master into u-boot-arm/master. The following changes since commit 49692c5f517d8e44ed9db0de778728fe7d2a300c: net/designware: Make DMA burst length configurable and reduce by default (2014-05-25 17:23:58 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 9637a1bb896efe392a58dd2772e2c3fcb646409d: ARM: at91sam9m10g45ek: add mmc environment configuration support (2014-05-27 00:10:55 +0200) Andreas Bießmann (4): corvus: remove unneeded CONFIG_AT91_LEGACY mkimage: add atmelimage arm:at91: enable ROM loadable atmel image sama5d3xek: enable PMECC header generation Bo Shen (6): ARM: atmel: switch to main crystal osc for SPL boot ARM: atmel: enable SPL on sama5d3_xplained board ARM: atmel: sama5d3xek: convert to generic board ARM: atmel: sama5d3_xplained: convert to generic board ARM: atmel: at91sam9m10g45ek: convert to generic board ARM: atmel: at91sam9x5ek: convert to generic board Wu, Josh (8): gpio: at91: add sanity check for the NULL pointer mmc: atmel_mci: fix print incorrect buffer content for debug ARM: at91: remove AT91X40 macro since it is not use any more ARM: at91sam9x5: define the AT91FAMILY and ARM926EJS in SoC header at91: remove redundant AT91FAMILY definition in board config file ARM: at91: remove redundant ARM926EJS definition in board config files ARM: at91sam9m10g45ek: enable mci0 support ARM: at91sam9m10g45ek: add mmc environment configuration support .../cpu/arm926ejs/at91/at91sam9m10g45_devices.c| 17 + arch/arm/cpu/armv7/at91/config.mk | 10 + arch/arm/cpu/at91-common/spl.c | 39 +++ arch/arm/include/asm/arch-at91/at91_pmc.h |4 + arch/arm/include/asm/arch-at91/at91sam9x5.h|3 + arch/arm/include/asm/arch-at91/hardware.h |2 - board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c| 10 + board/atmel/sama5d3_xplained/sama5d3_xplained.c| 87 + boards.cfg |1 + common/image.c |1 + doc/README.atmel_pmecc | 21 ++ drivers/gpio/at91_gpio.c |3 +- drivers/mmc/gen_atmel_mci.c|5 +- include/configs/at91sam9m10g45ek.h | 37 ++- include/configs/at91sam9n12ek.h|3 - include/configs/at91sam9x5ek.h |3 +- include/configs/corvus.h |3 - include/configs/cpu9260.h |1 - include/configs/ethernut5.h|2 - include/configs/sama5d3_xplained.h | 53 ++- include/configs/sama5d3xek.h |4 +- include/configs/vl_ma2sc.h |2 - include/image.h|1 + spl/Makefile | 11 + tools/Makefile |3 + tools/atmel_pmecc_params.c | 51 +++ tools/atmelimage.c | 342 tools/imagetool.c |2 + tools/imagetool.h |1 + 29 files changed, 701 insertions(+), 21 deletions(-) create mode 100644 arch/arm/cpu/armv7/at91/config.mk create mode 100644 tools/atmel_pmecc_params.c create mode 100644 tools/atmelimage.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos: Make sure ps_hold gets set in the SPL
Hi Akshay, On 26 May 2014 03:40, Akshay Saraswat aksha...@samsung.com wrote: Hi Simon, On 22 May 2014 01:53, Akshay Saraswat aksha...@samsung.com wrote: From: Doug Anderson diand...@chromium.org Setting ps_hold ought to be one of the first things we do when we first boot up. If we wait until the main u-boot runs we won't set it in time and the PMIC may power us back off. Moving ps_hold setup into the generic power_init() which should contain code that's currently duplicated in the board_power_init() of several boards. Signed-off-by: Doug Anderson diand...@chromium.org Signed-off-by: Akshay Saraswat aksha...@samsung.com --- arch/arm/cpu/armv7/exynos/lowlevel_init.c | 6 +- arch/arm/cpu/armv7/exynos/power.c | 14 ++ arch/arm/include/asm/arch-exynos/power.h | 8 3 files changed, 27 insertions(+), 1 deletion(-) Acked-by: Simon Glass s...@chromium.org Also see http://patchwork.ozlabs.org/patch/350693/ but your patch is better. Shall we keep this one then ? Yes. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/12] exynos5: support tps65090 pmic
Hi Minkyu, On 25 May 2014 21:15, Minkyu Kang mk7.k...@samsung.com wrote: Dear Simon, On 23/05/14 02:27, Simon Glass wrote: Hi Minkyu, On 21 May 2014 15:20, Minkyu Kang mk7.k...@samsung.com wrote: On 22/05/14 03:58, Simon Glass wrote: Hi Minkyu, On 21 May 2014 00:05, Minkyu Kang mk7.k...@samsung.com wrote: On 20/05/14 20:47, Simon Glass wrote: Hi Minkyu, On 15 May 2014 00:51, Minkyu Kang mk7.k...@samsung.com wrote: On 03/04/14 08:24, Simon Glass wrote: From: Aaron Durbin adur...@chromium.org The TSP65090 is a PMIC on some exynos5 boards. The init function is called for the TPS65090 pmic. If that device is not a part of the device tree (returns -ENODEV) then continue. Otherwise return a failure. Signed-off-by: Aaron Durbin adur...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v2: - Move code to exynos5-dt.c - Fix comment style - Add #ifdef around tps65090 code board/samsung/smdk5250/exynos5-dt.c | 13 + 1 file changed, 13 insertions(+) diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index 1a64b9b..2c1cf8a 100644 --- a/board/samsung/smdk5250/exynos5-dt.c +++ b/board/samsung/smdk5250/exynos5-dt.c @@ -20,6 +20,7 @@ #include asm/arch/sromc.h #include power/pmic.h #include power/max77686_pmic.h +#include power/tps65090_pmic.h #include tmu.h DECLARE_GLOBAL_DATA_PTR; @@ -164,7 +165,19 @@ int exynos_power_init(void) #ifdef CONFIG_POWER_MAX77686 ret = max77686_init(); + if (ret) + return ret; #endif +#ifdef CONFIG_POWER_TPS65090 + /* + * The TPS65090 may not be in the device tree. If so, it is not + * an error. Then, how we can initialise the tps65090? It is initialised if a suitable node is found in the device tree. If the device tree does not have it, then the hardware is assumed to not have this chip. then I think, it's an error. Why you said, it is not an error? I may be misunderstanding your question, but I'll try to answer what I think you are asking. The device tree contains nodes for hardware in the machine that you want to initialise, and information about each one. Devices can be enabled or disabled by including or removing this information from the device tree (or marking a device disabled with a status = disabled property in the node). The tps65090 chip is not used in all exynos5-dt boards, but is used in some. For example smdk5250 does not have it, but snow does. So we use the device tree to specify the difference, including (on snow) things like the tps65090, the display bridge chip, etc. Hm, it doesn't make sense. Then it(#define CONFIG_POWER_TPS65090) should go into each config files. Not in exynos5-dt.h. Please modify it and patch 6/12 also. The way it works at present is that there is a single exynos5-dt.h file which is used by all exynos5 boards. To the extent possible we have avoided putting particular features in things like snow.h and smdk5250.h - they just include exynos5-dt.h without changes. The idea is that we can have one U-Boot binary that runs on any exynos5 device, rather than lots of different options. This makes it much easier to test changes sine we only need to build it once. If every exynos5 board has different #defines then there are more combinations to build and test. This is similar to what the kernel does with arch/arm/mach-exynos/mach-exynos5-dt.c. Using this approach the only differences between smdk5250, daisy, snow, spring, etc. are in the device tree. I'd really like to avoid changing this now. It is easy enough for people to add their own private variants of these locally if they want to, but for mainline I believe it is better to be more generic. I totally understood what you assert. But I can't agree with you. Do you think if we collect all features at exynos5-dt.h then it can be generic? even if some boards doesn't have the device? I think no. It just wrong definition. We should separate exynos5 generic features and board specific features. Yes my intent is that we have an exynos5 build which (given the right device tree) can support any board. That has been the intent of the device tree effort for a while, and similar to the kernel approach. What is the objection of having the driver compiled in for a board that doesn't have the device? Is it the extra 1KB of code space for smdk5250 etc.? Anyway, it doesn't necessarily have to be exynos5-dt.h. If you really don't like that, we could create a new generic exynos5 board and I can target that instead. But I really want to avoid having to build multiple U-Boots for each board if possible. + ret = tps65090_init(); + if (ret == 0 || ret == -ENODEV) + return 0; At here.. whatever, the error is an error. If you got NODEV then should return it, because that board does not have device. Then the caller would need
Re: [U-Boot] pxa310 SDHC support.
On 2014/5/26 Mon 22:15, Marek Vasut wrote: On Monday, May 26, 2014 at 03:55:58 PM, aking wrote: [...] The PXA27x controller works even with SDXC , that is tested. I suspect there might be some change in the PXA3xx controller, but I don't really know for sure. You'd have to check. Thank you for your answer. are you using SD mode or SPI Mode? which version are you using? I believe the pxa_mmc_gen.c is what needs to be used. There is no other PXA MMC driver in U-Boot mainline. I now noticed it has some basic monahans (pxa3xx) support too. Could you give out a log with MACRO CONFIG_MMC_TRACE on your pxa27x device ? any initialize ,read ,write, erase operation? Sorry for disturb you. No, I cannot, sorry. I don't have the PXA27x device handy. Thanks , are you using SPI mode or SD mode with your SDXC card? This is Important. +CC panto, he might have an idea how to debug it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: fix a double-definition error of _start symbol
The symbol _start is defined twice in arch/arm/lib/vectors.S: around line 48 and line 54. If CONFIG_SYS_DV_NOR_BOOT_CFG is defined (as on calimain board), build fails: arch/arm/lib/vectors.S: Assembler messages: arch/arm/lib/vectors.S:54: Error: symbol `_start' is already defined make[1]: *** [arch/arm/lib/vectors.o] Error 1 make: *** [arch/arm/lib] Error 2 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- arch/arm/lib/vectors.S | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index fad00da..493f337 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -45,8 +45,6 @@ * */ -_start: - #ifdef CONFIG_SYS_DV_NOR_BOOT_CFG .word CONFIG_SYS_DV_NOR_BOOT_CFG #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to boot the new FIT image
Hi, On 24 May 2014 20:15, Harsha Kiran harshakiran...@gmail.com wrote: Hi Simon. I am able to successfully load the FIT image now :) Thanks for the help. I applied Heiko's patch. If CONFIG_OF_CONTROL is defined, the behaviour of the board is same as i mentioned in my previous emails. I tried removing the CONFIG_OF_CONTROL from the config file and it was able to read the u-boot.img. I modifed my uEnv.txt file and i was able to load my FIT image. I was wondering if we use CONFIG_OF_SEPERATE and CONFIG_DEFAULT_DEVICE_TREE is it fine not to use the CONFIG_OF_CONTROL? and how should i use the u-boot-dtb.bin file? I tried stopping the u-boot and entered the following in the u-boot prompt to load the u-boot-dtb.bin u-boot# fatload mmc 0 0x8100 u-boot-dtb.bin U-Boot# U-Boot# U-Boot# fatload mmc 0 0x8100 u-boot-dtb.bin reading u-boot-dtb.bin 460759 bytes read in 43 ms (10.2 MiB/s) U-Boot# go 0x8100 ## Starting application at 0x8100 ... U-Boot 2014.07-rc1 (May 25 2014 - 00:46:36) I2C: ready DRAM: 1 GiB and it hangs here.. Which address should i use to load the u-boot-dtb.bin? Check that you disabled the cache with 'dcache off' before the 'go' command (if the cache was enabled). I'm not sure what the address should be, but given that it gets that far, it is probably fine. As a rule of thumb, load it low in memory - it will relocate to high in memory. I will start working on the secure u-boot with FIT signatures soon on am335xsk EVM. OK. I will break out my Beaglebone also, perhaps this week. I really want to get these patches applied so it works smoothly on TI platforms. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mkimage: path behavior for FIT images
Hi Yegor, On 25 May 2014 23:41, Yegor Yefremov yegorsli...@googlemail.com wrote: Hi Simon, On Sat, May 24, 2014 at 3:58 AM, Simon Glass s...@chromium.org wrote: Hi Yegor, On 20 May 2014 20:59, Yegor Yefremov yegorsli...@googlemail.com wrote: I have following folder structure: board/kernel_fdt.its output/images/zImage The kernel.its has following path for the zImage: data = /incbin/(output/images/zImage); When I invoke mkimage like this, it complains, that output/images/zImage doesn't exist: mkimage -f board/kernel_fdt.its output/images/kernel_fdt.itb in other words it seems to take zImage's relative path starting from board, where kernel_fdt.its is located. Is it a desired behavior and how can I override it, so that root will be set to the mkimage invocation path? You could put ../output/... in there perhaps. Your workaround is working. Thanks. I just wanted to know, if it was a desired behavior. Can it be the dtc is invoked from board/ and this is the cause of such behavior? Yes, it uses the current directly as the base. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mkimage: path behavior for FIT images
On 26 May 2014 17:26, Simon Glass s...@chromium.org wrote: [snip[ I just wanted to know, if it was a desired behavior. Can it be the dtc is invoked from board/ and this is the cause of such behavior? Yes, it uses the current directly as the base. Sorry, I meant directory. - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] Exynos5420: DMC: Add software read leveling
On 26 May 2014 03:50, Akshay Saraswat aksha...@samsung.com wrote: Sometimes Read DQ and DQS are not in phase. Since, this phase shift differs from board to board, we need to calibrate it at DRAM init phase, that's read DQ calibration. This patch adds SW Read DQ calibration routine to compensate this skew. Signed-off-by: Alim Akhtar alim.akh...@samsung.com Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Exynos5420: Introduce support for the Peach-Pit board
Hi Akshay, On 26 May 2014 03:33, Akshay Saraswat aksha...@samsung.com wrote: Hi Simon, Hi Akshay, On 21 May 2014 23:23, Akshay Saraswat aksha...@samsung.com wrote: While the Exynos5420 chip is used in both Smdk5420 and in the Peach-Pit line of devices, there could be other boards using the same chip, so a common configuration file is being added (exynos5420.h) as well as two common device tree files (exynos54xx.dtsi exynos5420.dtsi). The peach board as declared in boards.cfg is a copy of smdk5420 declaration. The configuration files are similar, but define different default device trees, console serial ports and prompts. The device tree files for smdk5420 and peach-pit inherit from the same common file. Signed-off-by: Vadim Bendebury vben...@chromium.org Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org This looks good to me. I think you might have an extra space in the last column of your boards.cfg addition, and CONFIG_CHROMEOS_PEACH might not be needed. Will fix these in the next version. But I can't get pit to boot with these patches - it hangs in SPL. Do you know what is going on? For me, these patches are working fine. I have tested them over three different pit boards. I am not sure what could be wrong. I will try over more of those boards, if I witness something like this I will update. I am not actually using the latest Pit hardware, although what I have works fine with the Chromium tree. I suppose it could be a BL1 problems, also I am using 'crosfw' (and thus cros_bundle_firmware) to write to the board. If you have any ideas let me know, but it shouldn't hold up your patches. It just prevents me from adding 'Tested-by' to your patches. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] idirafter causes host sha256.h to be included
Hi Jeroen, On 24 May 2014 11:09, Jeroen Hofstee dasub...@myspectrum.nl wrote: Hello Simon, On vr, 2014-05-23 at 15:37 -1000, Simon Glass wrote: On 9 May 2014 12:31, Jeroen Hofstee dasub...@myspectrum.nl wrote: Hello, tools/Makefile uses the following substitution HOST_EXTRACFLAGS += -include $(srctree)/include/libfdt_env.h \ $(patsubst -I%,-idirafter%, $(UBOOTINCLUDE)) \ ... Which adds -idirafterinclude when compiling image-fit.c. Since mentioned file includes sha256.h, which is a system include on FreeBSD, the system version is included instead of the intended U-boot include/sha256.h and building fails. Without the substitution it builds successfully. What is the intention of using idirafter? I believe this is so that U-Boot headers are available when building. You might need to add a work-around like we have for libfdt_env.h. It is also possible that there is a more general solution, sorry I'm not sure what it might be. Thanks for mentioning the libfdt_env.h. As mentioned in the thread discussing the patch errno.h is one of the reasons to require the dirafter, since the tools need the host version of it. A possible solution could perhaps be to place such standard headers in a separate directory and only include it for an u-boot build. The tools can then be compiled without the idirafter and not including this location as an include path. I did originally write a patch which might have solved this problem - it force the build to use U-Boot headers except for a few special cases. You might be able to find it in patchwork (archived?) But I think Masahiro came up with what I thought was a better way - more general purpose than my patch. You have I think the opposite problem to what I was facing. I'm not sure of the best general approach now. I suggest you experiment and see if you can come up with a suitable patch. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] bootfile environment variable
Hello,I have a DHCP server set up to provide all of the environment variables listed at the bottom of this page: http://www.denx.de/wiki/view/DULG/UBootEnvVariablesSpecifically, I've configure my DHCP server to provide option #67, Bootfile name, as zImageu-boot picks up on this nicely and so when I run= dhcpu-boot downloads zImage from my TFTP server. However, I've found it impossible to download any other file with this setup. For example, I expect that when I execute= dhcp 0x12000 192.168.1.1:zImage2or= dhcp zImage2I should get the zImage2 file. Unfortunately, zImage is downloaded in all cases. I've been unable to find any command (DHCP, TFTP) that I can issue that will allow me to download any file other than the DHCP provided default file. Removing/disabling option #67 from my DHCP server solves the problem and u-boot can download any file I ask from my TFTP server. I'm running commit 9665fa8f9e1488209d5e01d0792c243e0a220c5a It seems like the proper behavior would be be that the DHCP provided file name is overridden by a file name given at the u-boot prompt and the DHCP provided file name is only downloaded when no file name is specified at the command line. Can anyone else confirm this issue? Thanks,l3iggs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 3/3] ARM: omap: merge GPMC initialization code for all platform
From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Rini, Tom On Thu, May 08, 2014 at 09:43:47PM +0530, pekon gupta wrote: GPMC controller on TI's OMAP SoC is general purpose controller to interface with different types of external devices like; - parallel NOR flash - parallel NAND flash - OneNand flash - SDR RAM - Ethernet Devices like LAN9220 Though GPMC configurations may be different for each platform depending on clock-frequency and external device interfacing with controller. But initialization sequence remains common across all platfoms. Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c files into single omap-common/mem-common.c However, actual platforms specific register config values are still sourced from corresponding platform specific headers like; AM33xx: arch/arm/include/asm/arch-am33xx/mem.h OMAP3: arch/arm/include/asm/arch-omap3/mem.h OMAP4: arch/arm/include/asm/arch-omap4/mem.h OMAP4: arch/arm/include/asm/arch-omap5/mem.h Also, CONFIG_xx passed by board-profile decide config for which set of macros need to be used for initialization CONFIG_NAND:initialize GPMC for NAND device CONFIG_NOR: initialize GPMC for NOR device CONFIG_ONENAND: initialize GPMC for ONENAND device Signed-off-by: Pekon Gupta pe...@ti.com After adding GPMC_SIZE_256M to omap3/mem.h, applied to u-boot-ti/master, thanks! And note that git detect renames got a bit too agressive here so I had to apply it kinda by hand, but I think I did everything right. Thanks much .. I'll review the changes. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
