[U-Boot] [PATCH] Avoid using gawk-specific strtonum()
We need to subtract two hex numbers. Avoid using strtonum() by doing the
subtraction in bc with a suitable input base.
Signed-off-by: Simon Glass s...@chromium.org
Reported-by: Vasili Galka vvv...@gmail.com
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 24d9687..bb2f615 100644
--- a/Makefile
+++ b/Makefile
@@ -788,7 +788,8 @@ OBJCOPYFLAGS_u-boot.bin := -O binary
binary_size_check: u-boot.bin System.map FORCE
@file_size=`stat -c %s u-boot.bin` ; \
map_size=$(shell cat System.map | \
- awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print strtonum(0x end) -
strtonum(0x start)}'); \
+ awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print ibase=16; toupper(end) -
toupper(start)}' \
+ | bc); \
if [ != $$map_size ]; then \
if test $$map_size -ne $$file_size; then \
echo System.map shows a binary size of $$map_size 2
; \
--
2.0.0.526.g5318336
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] strtonum() is gawk specific extension
Hi, On 15 June 2014 06:56, Vasili Galka vvv...@gmail.com wrote: The following patch Check that u-boot.bin size looks correct: http://patchwork.ozlabs.org/patch/355151/ Uses strtonum() function which is gawk specific extension: https://www.gnu.org/software/gawk/manual/html_node/Strtonum-Function.html As a result, currenlty, u-boot/master generates build errors on systems with alternative awk implementations e.g. I get: awk: line 2: function strtonum never defined Either gawk shall be required and explicitly used or the implementation changed. I thought of an ugly way and sent a patch using bc, but please let me know if you have something better. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: free entities when parsing fails
Hi Stephen,
From: Stephen Warren swar...@nvidia.com
When dfu_init_env_entities() fails part-way through, some entities may
have been added to dfu_list. These are only removed by
dfu_free_entities(). If that function isn't called, those stale
entities will still exist the next time dfu_init_env_entities() is
called, leading to confusion. Fix do_dfu() to ensure that
dfu_free_entities() is always called, to avoid this confusion.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
common/cmd_dfu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
index a03538dabb37..433bddd5d2bd 100644
--- a/common/cmd_dfu.c
+++ b/common/cmd_dfu.c
@@ -27,8 +27,9 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[]) ret = dfu_init_env_entities(interface,
simple_strtoul(devstring, NULL, 10));
if (ret)
- return ret;
+ goto done;
+ ret = CMD_RET_SUCCESS;
if (argc 4 strcmp(argv[4], list) == 0) {
dfu_show_entities();
goto done;
@@ -61,7 +62,7 @@ done:
if (dfu_reset())
run_command(reset, 0);
- return CMD_RET_SUCCESS;
+ return ret;
}
U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
Acked-by: Lukasz Majewski l.majew...@samsung.com
Test HW: Exynos4412 - Trats2
Tested-by: Lukasz Majewski l.majew...@samsung.com
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Use UART1 port on p1022 through U-Boot
Just use #define CONFIG_CONS_INDEX 2 to select UART1 as u-boot console. Remember to set consoledev=ttyS1 in the kernel parameters. Cheers Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/11] board:samsung: check the mmc boot device and init the right mmc driver.
Dear Przemyslaw Marczak,
On 12/06/14 18:46, Przemyslaw Marczak wrote:
It is possible to boot from a few media devices, especially using a micro
SD or eMMC slots. In this situation, boot device should be registered
as block device 0 in the MMC framework, because CONFIG_SYS_MMC_ENV_DEV
is usually set to 0 in the most config cases.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Piotr Wilczek p.wilc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
board/samsung/common/board.c | 32
include/samsung/misc.h | 5 +
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..2970340 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -25,6 +25,8 @@
#include lcd.h
#include samsung/misc.h
+static int bootmode;
+
DECLARE_GLOBAL_DATA_PTR;
int __exynos_early_init_f(void)
@@ -243,19 +245,33 @@ int board_eth_init(bd_t *bis)
int board_mmc_init(bd_t *bis)
{
int ret;
+ struct exynos4_power *pwr = (struct exynos4_power *)
+ samsung_get_base_power();
Hm, no. This file is samsung common not only for exynos4.
Although this code will not be made any problems for other SoCs (because
om_stat is always first item of power), it looks weird.
I think you can make new function for getting boot mode.
+
+ bootmode = BOOT_MODE(readl(pwr-om_stat));
+ if (bootmode == BOOT_SDMMC) {
+#ifdef CONFIG_SDHCI
+ /* mmc initializattion for available channels */
+ ret = exynos_mmc_init(gd-fdt_blob);
+#endif
#ifdef CONFIG_DWMMC
- /* dwmmc initializattion for available channels */
- ret = exynos_dwmmc_init(gd-fdt_blob);
- if (ret)
- debug(dwmmc init failed\n);
+ /* dwmmc initializattion for available channels */
+ ret = exynos_dwmmc_init(gd-fdt_blob);
+#endif
+ } else {
+#ifdef CONFIG_DWMMC
+ /* dwmmc initializattion for available channels */
+ ret = exynos_dwmmc_init(gd-fdt_blob);
#endif
-
#ifdef CONFIG_SDHCI
- /* mmc initializattion for available channels */
- ret = exynos_mmc_init(gd-fdt_blob);
+ /* mmc initializattion for available channels */
+ ret = exynos_mmc_init(gd-fdt_blob);
+#endif
+ }
+
if (ret)
debug(mmc init failed\n);
-#endif
+
return ret;
}
#endif
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 10653a1..87b53ec 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -28,4 +28,9 @@ void check_boot_mode(void);
void draw_logo(void);
#endif
+#define BOOT_SDMMC 0x2
+#define BOOT_MODE_MASK (0x1f)
+#define BOOT_MODE_SHIFT (0x1)
+#define BOOT_MODE(x) ((x BOOT_MODE_SHIFT) BOOT_MODE_MASK)
((x) BOOT_MODE_SHIFT)
+
#endif /* __SAMSUNG_MISC_COMMON_H__ */
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] Exynos: Split 5250 and 5420 memory bank configuration
On 18/06/14 11:11, Simon Glass wrote: Hi Minkyu, On 16 June 2014 23:28, Minkyu Kang mk7.k...@samsung.com wrote: Dear Akshay Saraswat, On 04/06/14 01:17, Akshay Saraswat wrote: From: Michael Pratt mpr...@chromium.org Since snow has a different memory configuration than peach, split the configuration between the 5250 and 5420. Exynos 5420 supports runtime memory configuration detection, and can make the determination between 4 and 7 banks at runtime. I think this patch should be included to your peach-pit patchset. And I think, the number of banks and the size of bank seems to board specific feature. Can you guarantee if it uses same SoC then have same memory banks? I think this is better than what we have there at present. There is a patch from Chromium that puts this in the device tree, but it is probably best dealt with when more patches have landed. I didn't deny this patch. My comment is about present state. If you can not guarantee that have same memory banks then please split this configuration to each board's configs. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] strtonum() is gawk specific extension
Hi Simon, On Wed, Jun 18, 2014 at 9:10 AM, Simon Glass s...@chromium.org wrote: I thought of an ugly way and sent a patch using bc, but please let me know if you have something better. I honestly don't know. Is bc considered standard and always comes on Linux systems? Maybe there shall be a list of prerequisites in README file? For example some configurations require openssl on the host. Best, Vasili ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] Exynos: Split 5250 and 5420 memory bank configuration
Hi Minkyu, On 17 June 2014 23:30, Minkyu Kang mk7.k...@samsung.com wrote: On 18/06/14 11:11, Simon Glass wrote: Hi Minkyu, On 16 June 2014 23:28, Minkyu Kang mk7.k...@samsung.com wrote: Dear Akshay Saraswat, On 04/06/14 01:17, Akshay Saraswat wrote: From: Michael Pratt mpr...@chromium.org Since snow has a different memory configuration than peach, split the configuration between the 5250 and 5420. Exynos 5420 supports runtime memory configuration detection, and can make the determination between 4 and 7 banks at runtime. I think this patch should be included to your peach-pit patchset. And I think, the number of banks and the size of bank seems to board specific feature. Can you guarantee if it uses same SoC then have same memory banks? I think this is better than what we have there at present. There is a patch from Chromium that puts this in the device tree, but it is probably best dealt with when more patches have landed. I didn't deny this patch. My comment is about present state. If you can not guarantee that have same memory banks then please split this configuration to each board's configs. For Pit which can support 2GB or 4GB, U-Boot detects the correct size at run-time. So the setting in the config file is the *maximum* memory supported by that SOC, which is indeed fixed by the SOC and has nothing to do with the board. But i maybe misunderstand what you are getting at? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] Exynos: Split 5250 and 5420 memory bank configuration
Dear Simon Glass, On 18/06/14 15:47, Simon Glass wrote: Hi Minkyu, On 17 June 2014 23:30, Minkyu Kang mk7.k...@samsung.com wrote: On 18/06/14 11:11, Simon Glass wrote: Hi Minkyu, On 16 June 2014 23:28, Minkyu Kang mk7.k...@samsung.com wrote: Dear Akshay Saraswat, On 04/06/14 01:17, Akshay Saraswat wrote: From: Michael Pratt mpr...@chromium.org Since snow has a different memory configuration than peach, split the configuration between the 5250 and 5420. Exynos 5420 supports runtime memory configuration detection, and can make the determination between 4 and 7 banks at runtime. I think this patch should be included to your peach-pit patchset. And I think, the number of banks and the size of bank seems to board specific feature. Can you guarantee if it uses same SoC then have same memory banks? I think this is better than what we have there at present. There is a patch from Chromium that puts this in the device tree, but it is probably best dealt with when more patches have landed. I didn't deny this patch. My comment is about present state. If you can not guarantee that have same memory banks then please split this configuration to each board's configs. For Pit which can support 2GB or 4GB, U-Boot detects the correct size at run-time. So the setting in the config file is the *maximum* memory supported by that SOC, which is indeed fixed by the SOC and has nothing to do with the board. I see. Then looks good to me. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Use UART1 port on p1022 through U-Boot
Hi, I am using a Freescale p1022 processor, and I need to write to the UART1 port of this processor, through U-Boot. I know it currently uses UART0 as the console input/output. I could not find out how to configure it so I can use UART1 as well. If somebody have a hint, I will be really grateful. Cheers, Nildo Junior ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14
Hello Scott,
Am 17.06.2014 17:54, schrieb Scott Wood:
On Tue, 2014-06-17 at 09:15 +0200, Heiko Schocher wrote:
- Following Code in drivers/mtd/nand/nand_base.c nand_do_write_ops()
adapted for U-Boot:
+#ifndef __UBOOT__
/* Reject writes, which are not page aligned */
if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
+else
+ /* Reject writes, which are not page aligned */
+ if (NOTALIGNED(to)) {
+endif
This sort of ifdeffing is a bad idea -- if a larger number of lines are
ifdeffed, to avoid context conflicts, subsequent merges can silently put
updates into the non-U-Boot section that are needed in the U-Boot
section.
Yes, in general I agree, this is a bad idea. But I introduced it
here to get all differences between U-Boot and Linux marked with
the _UBOOT_ define, so a future sync with linux should be easier ...
Plus, it impairs readability, and in this case breaks text-editor
brace-matching.
Yes, could be fixed, see below.
Plus plus, that line has been that way in Linux since 2006 -- why is it
being touched at all? Did you merge in changes from the previous mtd
sync, or did you just copy the new files over and then try to fix
resulting problems? (answered below)
Yes. Above Code is a good example. In Linux this piece of code looks like:
-
static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
struct mtd_oob_ops *ops)
[...]
ops-retlen = 0;
if (!writelen)
return 0;
/* Reject writes, which are not page aligned */
if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
pr_notice(%s: attempt to write non page aligned data\n,
__func__);
return -EINVAL;
}
column = to (mtd-writesize - 1);
-
in current U-Boot:
-
static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
struct mtd_oob_ops *ops)
[...]
ops-retlen = 0;
if (!writelen)
return 0;
column = to (mtd-writesize - 1);
-
Why is this if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
missing in U-Boot? Do we allow not aligned writes in U-Boot?
If so, we should have documented this, and best place for it,
I think, would be with a comment in the source code...
so if we delete this linux code in U-Boot, mark it with the
_UBOOT_ define... and differences between linux and U-Boot are
documented and visible ...
I added for U-Boot the surely good NOTALIGNED(to) check, but not
the NOTALIGNED(ops-len) check, as it prevents such currently
working commands: nand write xxx yyy ${filesize} ... Maybe this
is the reason for missing this piece of linux code in U-Boot?
maybe I should add here a comment ... proposal:
-
#ifndef __UBOOT__
/* Reject writes, which are not page aligned */
if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
pr_notice(%s: attempt to write non page aligned data\n,
__func__);
return -EINVAL;
}
#else
/*
* Reject writes, which are not page aligned, but
* in U-Boot we accept not page aligned data len writes
* so commands for example nand write xxx yyy ${filesize}
* are working.
*/
if (NOTALIGNED(to)) {
pr_notice(%s: attempt to write non page aligned data\n,
__func__);
return -EINVAL;
}
#endif
-
With this approach, the difference between linux and u-boot is
documented, and text-editor brace-matching is not broken ...
as the original linux code leads in not working use of the env
var filesize. For example a nand write 8000 8 ${filesize}
would not work with it ...
- add CONFIG_MTD_NAND_VERIFY_WRITE from U-Boot code
(only compile tested)
- Documented the config defines in README
- kmalloc now uses memalign for allocating memory. This prevented
crashes when tested ubi/ubifs on imx6 board.
- To produce this patch I did three steps:
- copied the linux source files to U-Boot tree - commit this
- adapt license text in each file - commit this
- make the code again compile clean and working - commit this
OK, so you did just copy stuff over. This method will lead to U-Boot
Yes.
changes being reverted every time. You should look in the U-Boot
Yes and No. If they are documented with the define _UBOOT_, they will
pop up after the copy from linux operation and you hopefully can
decide, if the U-Boot specific changes are longer necessary or not.
Above Code is a good example for that. Linux has this code
since 2006, why has U-Boot not this code?
history to see what Linux version corresponded to the last mtd sync, and
generate a diff relative to that.
I think, we should have the linux code as the reference, and on top
of this, we should add our U-Boot changes ... Thats the
Re: [U-Boot] Atmel SAMA5D31 NOR boot - sanity check required
Hi Bo, I think you should check more detail in section 12 Standard Boot Strategies. It needs more things to do. I will give a picture in following answer. snip As the code execute on NOR flash, so, the SPL configure the CPU clock will cause SMC access abortion. So, a brief guide as following: The datasheet says the user software in external memory should: a) Enable the 32768 Hz oscillator if best accuracy is needed. b) Reprogram the SMC setup, cycle, hold, mode timing registers for EBI CS0, to adapt them to the new clock. c) Program the PMC (Main Oscillator Enable or Bypass mode). d) Program and start the PLL. e) Switch the system clock to the new value. So my current thinking is that: - I am not so worried about (a), as I don't think accuracy is essential at this point in time. - (b) needs to be taken care of in the steps that you outline below. - (c) ??? - The function at91_pmc_init() in board\atmel\sama5d3xek\sama5d3xek.c takes care of items (d) and (e) It has been a while since I have done this much low level code so I may be a little rusty :-) 1. Write a ram function, which do as the datasheet says. 2. Add copy function (copy the ram function into sram) at the begin of the SPL code. 3. After the step 1, finished to execute, then, you can jump back to NOR to execute. I'm not sure I follow how to do this. Are there any similar implementations elsewhere in U-Boot that I could use as a reference. I should say that ARM assembler isn't my strongest skill as most of my previous experience has been gained with x86 and MIPS. Thanks for all your help. Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] test:dfu: Add test scripts for testing DFU regression
This commit adds test scripts for testing if any commit has introduced
regression to the DFU subsystem.
It uses md5 to test if sent and received file is correct.
The test detailed description is available at README file.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v3:
- Rename COLOR with COLOUR
- Add README description for the optional second parameter passed to
dfu_gadget_test.sh
Changes for v2:
- Rename DESCRIPTION.TXT to README
- Introduction of COLOUR_* variables to hold code necessary to change
console color
- File to create initial setup - dfu_gadget_test_init.sh has been added
- Test files are now automatically generated with the above script
---
test/dfu/README | 30 ++
test/dfu/dfu_gadget_test.sh | 88
test/dfu/dfu_gadget_test_init.sh | 34
3 files changed, 152 insertions(+)
create mode 100644 test/dfu/README
create mode 100755 test/dfu/dfu_gadget_test.sh
create mode 100755 test/dfu/dfu_gadget_test_init.sh
diff --git a/test/dfu/README b/test/dfu/README
new file mode 100644
index 000..f8c1a74
--- /dev/null
+++ b/test/dfu/README
@@ -0,0 +1,30 @@
+DFU TEST CASE DESCRIPTION:
+
+The prerequisites for running this script are assured by
dfu_gadget_test_init.sh.
+In this file user is able to generate their own set of test files by altering
+the default set of TEST_FILES_SIZES variable.
+The dfu_gadget_test_init.sh would generate test images only if they are not
+already generated.
+
+Moreover, on a target device the dfu_alt_info env variable should be extended
+to have dfu_test.bin fat 0 6; \ entry ([1]). For reference please consult the
+config file for TRATS/TRATS2 devices (./include/configs/trats{2}.h)
+
+One can use fat, ext4 or any other supported file system, which can be
+created in a convenient way with exporting partitions via UMS (ums 0 mmc 0)
+and using standard tools on host (like mkfs.ext4).
+
+Example usage:
+1. On the target:
+ env default -a
+ dfu 0 mmc 0
+2. On the host:
+ ./dfu_gadget_test.sh 11 [test_file]
+
+where 11 is the mumber of alt setting corresponding to entry [1] and
[test_file]
+is an optional parameter, with which one can explicitly indicate the test file
+to be used.
+
+The number of the alt setting entry can be obtained with dfu-util -l command.
+In its output one should look for the 'name=dfu_test1.bin' and corresponding
+alt=11.
diff --git a/test/dfu/dfu_gadget_test.sh b/test/dfu/dfu_gadget_test.sh
new file mode 100755
index 000..4a848c8
--- /dev/null
+++ b/test/dfu/dfu_gadget_test.sh
@@ -0,0 +1,88 @@
+#! /bin/bash
+set -e # any command return if not equal to zero
+clear
+
+COLOUR_RED=\33[31m
+COLOUR_GREEN=\33[32m
+COLOUR_DEFAULT=\33[0m
+
+DIR=./
+SUFFIX=img
+RCV_DIR=rcv/
+LOG_FILE=./log/log-`date +%d-%m-%Y_%H-%M-%S`
+
+./dfu_gadget_test_init.sh
+
+cleanup () {
+rm -rf $RCV_DIR
+}
+
+die () {
+ printf$COLOUR_RED FAILED $COLOUR_DEFAULT \n
+ cleanup
+ exit 1
+}
+
+calculate_md5sum () {
+MD5SUM=`md5sum $1`
+MD5SUM=`echo $MD5SUM | cut -d ' ' -f1`
+echo md5sum:$MD5SUM
+}
+
+dfu_test_file () {
+printf $COLOUR_GREEN
=
$COLOUR_DEFAULT\n
+printf File:$COLOUR_GREEN %s $COLOUR_DEFAULT\n $1
+
+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 $LOG_FILE 21 || die $?
+
+echo -n RX:
+calculate_md5sum $N_FILE
+MD5_RX=$MD5SUM
+
+if [ $MD5_TX == $MD5_RX ]; then
+ printf$COLOUR_GREEN --- OK $COLOUR_DEFAULT \n
+else
+ printf$COLOUR_RED --- FAILED $COLOUR_DEFAULT \n
+ cleanup
+ exit 1
+fi
+
+}
+
+printf
$COLOUR_GREEN=
$COLOUR_DEFAULT\n
+echo DFU EP0 transmission test program
+echo Trouble shoot - disable DBG (even the KERN_DEBUG) in the UDC driver
+echo @ - TRATS2 # dfu 0 mmc 0
+mkdir -p $RCV_DIR
+touch $LOG_FILE
+
+if [ $# -eq 0 ]
+then
+ printf$COLOUR_RED Please pass alt setting number!!
$COLOUR_DEFAULT \n
+ exit 0
+fi
+
+TARGET_ALT_SETTING=$1
+
+if [ -n $2 ]
+then
+ dfu_test_file $2
+else
+ for file in $DIR*.$SUFFIX
+ do
+ dfu_test_file $file
+ done
+fi
+
+cleanup
+
+exit 0
diff --git a/test/dfu/dfu_gadget_test_init.sh b/test/dfu/dfu_gadget_test_init.sh
new file mode 100755
index 000..b319ed0
--- /dev/null
+++ b/test/dfu/dfu_gadget_test_init.sh
@@ -0,0 +1,34 @@
+#! /bin/bash
+set -e # any command return if not equal to zero
+clear
+
+COLOUR_RED=\33[31m
+COLOUR_GREEN=\33[32m
+COLOUR_DEFAULT=\33[0m
+
+LOG_DIR=./log
+BKP_DIR=./bkp
+
+TEST_FILES_SIZES=127 128 129 8M 4095 4096 4097 63 64 65 960
+
+printf Init script for generating data
Re: [U-Boot] [Patch v6 3/5] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC
Hi York,
Apologies for the late reply on this.
I'm somewhat concerned regarding the issues you're seeing with cacheable
page table walks, but I'll ignore that for the moment so we can get the
ordering of maintenance sorted.
On Thu, Jun 05, 2014 at 08:23:09PM +0100, York Sun wrote:
Freescale LayerScape with Chassis Generation 3 is a set of SoCs with
ARMv8 cores and 3rd generation of Chassis. We use different MMU setup
to support memory map and cache attribute for these SoCs. MMU and cache
are enabled very early to bootst performance, especially for early
development on emulators. After u-boot relocates to DDR, a new MMU
table with QBMan cache access is created in DDR. SMMU pagesize is set
in SMMU_sACR register. Both DDR3 and DDR4 are supported.
Signed-off-by: York Sun york...@freescale.com
Signed-off-by: Varun Sethi varun.se...@freescale.com
Signed-off-by: Arnab Basu arnab.b...@freescale.com
---
[...]
+ /* point TTBR to the new table */
+ el = current_el();
Could we not place a dsb() here...
+ if (el == 1) {
+ asm volatile(dsb sy;msr ttbr0_el1, %0;isb
+: : r ((u64)level0_table) : memory);
+ } else if (el == 2) {
+ asm volatile(dsb sy;msr ttbr0_el2, %0;isb
+: : r ((u64)level0_table) : memory);
+ } else if (el == 3) {
+ asm volatile(dsb sy;msr ttbr0_el3, %0;isb
+: : r ((u64)level0_table) : memory);
+ } else {
+ hang();
+ }
...and an isb() here?
It would save duplicating them for each EL.
+ /*
+* MMU is already enabled, just need to invalidate TLB to load the
+* new table. The new table is compatible with the current table, if
+* MMU somehow walks through the new table before invalidation TLB,
+* it still works. So we don't need to turn off MMU here.
+*/
+}
+
+int arch_cpu_init(void)
+{
+ icache_enable();
Just to check: the icache is clean/invalid at this point?
+ __asm_invalidate_dcache_all();
+ __asm_invalidate_tlb_all();
+ early_mmu_setup();
+ set_sctlr(get_sctlr() | CR_C);
+ return 0;
+}
[...]
+/*
+ * This function is called from lib/board.c.
+ * It recreates MMU table in main memory. MMU and d-cache are enabled
earlier.
+ * There is no need to disable d-cache for this operation.
+ */
+void enable_caches(void)
+{
+ final_mmu_setup();
+ flush_dcache_range(gd-arch.tlb_addr,
+ gd-arch.tlb_addr + gd-arch.tlb_size);
+ __asm_invalidate_tlb_all();
+}
This looks wrong, given your previous comments that you couldn't get the
MMU to lookup from the cache.
In final_mmu_setup() you pointed the TTBR0_ELx to the new tables, but at
that point the tables aren't guaranteed to be in memory, because they
haven't been flushed. The MMU can start fetching the garbage from memory
immediately, and things might go wrong before __asm_invalidate_tlb_all()
blows away the garbage the MMU read from memory (for instance, the
mapping covering the enable_caches function might get replaced by
garbage).
If the page table walks are non-cacheable, you need to flush the tables
to memory before programming the relevant TTBR.
Thanks,
Mark.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Avoid using gawk-specific strtonum()
Dear Simon,
In message 1403071815-32055-1-git-send-email-...@chromium.org you wrote:
We need to subtract two hex numbers. Avoid using strtonum() by doing the
subtraction in bc with a suitable input base.
Signed-off-by: Simon Glass s...@chromium.org
Reported-by: Vasili Galka vvv...@gmail.com
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 24d9687..bb2f615 100644
--- a/Makefile
+++ b/Makefile
@@ -788,7 +788,8 @@ OBJCOPYFLAGS_u-boot.bin := -O binary
binary_size_check: u-boot.bin System.map FORCE
@file_size=`stat -c %s u-boot.bin` ; \
map_size=$(shell cat System.map | \
- awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print strtonum(0x end) -
strtonum(0x start)}'); \
+ awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print ibase=16; toupper(end) -
toupper(start)}' \
+ | bc); \
I think instead of introducing yet another tool dependency this could
be rewritten to use just bash:
awk '/_image_copy_start/ {start = $1}
/_image_binary_end/ {end = $1}
END { if (start != end != )
print printf %d $$((0x end - 0x start ))
}' |
bash
?
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
Q: What's a light-year?
A: One-third less calories than a regular year.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/11] board:samsung: check the mmc boot device and init the right mmc driver.
Hello Minkyu,
On 06/18/2014 08:30 AM, Minkyu Kang wrote:
Dear Przemyslaw Marczak,
On 12/06/14 18:46, Przemyslaw Marczak wrote:
It is possible to boot from a few media devices, especially using a micro
SD or eMMC slots. In this situation, boot device should be registered
as block device 0 in the MMC framework, because CONFIG_SYS_MMC_ENV_DEV
is usually set to 0 in the most config cases.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Piotr Wilczek p.wilc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
board/samsung/common/board.c | 32
include/samsung/misc.h | 5 +
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..2970340 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -25,6 +25,8 @@
#include lcd.h
#include samsung/misc.h
+static int bootmode;
+
DECLARE_GLOBAL_DATA_PTR;
int __exynos_early_init_f(void)
@@ -243,19 +245,33 @@ int board_eth_init(bd_t *bis)
int board_mmc_init(bd_t *bis)
{
int ret;
+ struct exynos4_power *pwr = (struct exynos4_power *)
+ samsung_get_base_power();
Hm, no. This file is samsung common not only for exynos4.
Although this code will not be made any problems for other SoCs (because
om_stat is always first item of power), it looks weird.
I think you can make new function for getting boot mode.
Yes, this was bad. What about that:
# unsigned int om_stat = samsung_get_base_power();
#
# bootmode = BOOT_MODE(readl(om_stat));
or maybe just
# bootmode = BOOT_MODE(readl(samsung_get_base_power()));
like in the Exynos spl code.
Simply and proper for every SOC.
And a function for this code will be added.
+
+ bootmode = BOOT_MODE(readl(pwr-om_stat));
+ if (bootmode == BOOT_SDMMC) {
+#ifdef CONFIG_SDHCI
+ /* mmc initializattion for available channels */
+ ret = exynos_mmc_init(gd-fdt_blob);
+#endif
#ifdef CONFIG_DWMMC
- /* dwmmc initializattion for available channels */
- ret = exynos_dwmmc_init(gd-fdt_blob);
- if (ret)
- debug(dwmmc init failed\n);
+ /* dwmmc initializattion for available channels */
+ ret = exynos_dwmmc_init(gd-fdt_blob);
+#endif
+ } else {
+#ifdef CONFIG_DWMMC
+ /* dwmmc initializattion for available channels */
+ ret = exynos_dwmmc_init(gd-fdt_blob);
#endif
-
#ifdef CONFIG_SDHCI
- /* mmc initializattion for available channels */
- ret = exynos_mmc_init(gd-fdt_blob);
+ /* mmc initializattion for available channels */
+ ret = exynos_mmc_init(gd-fdt_blob);
+#endif
+ }
+
if (ret)
debug(mmc init failed\n);
-#endif
+
return ret;
}
#endif
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 10653a1..87b53ec 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -28,4 +28,9 @@ void check_boot_mode(void);
void draw_logo(void);
#endif
+#define BOOT_SDMMC 0x2
+#define BOOT_MODE_MASK (0x1f)
+#define BOOT_MODE_SHIFT(0x1)
+#define BOOT_MODE(x) ((x BOOT_MODE_SHIFT) BOOT_MODE_MASK)
((x) BOOT_MODE_SHIFT)
Ok, will fix this.
+
#endif /* __SAMSUNG_MISC_COMMON_H__ */
Thanks,
Minkyu Kang.
Thank you,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Arndale: Enable preboot support
On 10/06/14 18:24, Tushar Behera wrote: We need to run 'usb start' as preboot command so that ethernet comes up during u-boot prompt. Signed-off-by: Tushar Behera tusha...@samsung.com --- include/configs/arndale.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index 30ecd45..370db82 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -229,6 +229,8 @@ #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-arndale +#define CONFIG_PREBOOT + /* Ethernet Controllor Driver */ #ifdef CONFIG_CMD_NET #define CONFIG_SMC911X applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FIX: config: goni: Change goni configuration to use Tizen's THOR downlodader
On 09/06/14 21:02, Lukasz Majewski wrote: Modify GONI's configuration to utilize THOR downloader. Signed-off-by: Lukasz Majewski l.majew...@samsung.com --- include/configs/s5p_goni.h | 8 1 file changed, 8 insertions(+) diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index 804f97f..6e795bf 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -79,10 +79,18 @@ #define CONFIG_USBDOWNLOAD_GADGET #define CONFIG_DFU_FUNCTION #define CONFIG_DFU_MMC +#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_32M +#define DFU_DEFAULT_POLL_TIMEOUT 300 + +/* TIZEN THOR downloader support */ +#define CONFIG_CMD_THOR_DOWNLOAD +#define CONFIG_THOR_FUNCTION /* USB Samsung's IDs */ #define CONFIG_G_DNL_VENDOR_NUM 0x04E8 #define CONFIG_G_DNL_PRODUCT_NUM 0x6601 +#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM +#define CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D #define CONFIG_G_DNL_MANUFACTURER Samsung /* Actual modem binary size is 16MiB. Add 2MiB for bad block handling */ applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] drivers:dfu: new feature: separated bootloader alt setting
Hello,
On 06/17/2014 06:36 PM, Stephen Warren wrote:
On 06/17/2014 04:20 AM, Przemyslaw Marczak wrote:
Hello Stephen,
On 06/16/2014 09:52 PM, Stephen Warren wrote:
On 06/12/2014 03:46 AM, Przemyslaw Marczak wrote:
This patch introduces new feature: initialization of the dfu
bootloader entity from a separate environmental variable which
can be set on a boot time.
By default, DFU always check environmental variable: $dfu_alt_info.
Changes:
- DFU will also look for environmental variable: $dfu_alt_bootloader
- if any of dfu_alt_* variable is properly defined, then function
dfu_init_env_entities() will return success.
Use case:
Some devices can boot from various media type (SD, eMMC, NAND, etc.)
or some board configs are common for more than one board type.
In a such case, bootloader is probably placed on a different
devices or even offsets. So such DFU feature is welcome.
Why should the dfu command look at different environment variables?
Whatever code dynamically sets the value of $dfu_alt_bootloader should
simply set $dfu_alt_info instead.
Dynamically setting of any entity cold be done at boot time, like this:
# int buf_len = strlen(alt_bootloader) + strlen(CONFIG_DFU_ALT) + 4;
# char *buf = memalign(1, buf_len);
#
# sprintf(buf, %s; %s, alt_bootloader, CONFIG_DFU_ALT);
Note that you can't have a space after the ; due to the use of strsep().
Switching to strtok() might solve that.
Yes - this wasn't tested - just some pseudo code.
# setenv(dfu_alt_info, buf);
But overwriting the $dfu_alt_info on each boot is not a good idea.
If user modify the dfu entities - then it will be overwritten at next boot.
What if the user sees that $dfu_alt_bootloader is set, and modifies that
without realizing that it's an auto-generated variable? The same thing
then applies.
Perhaps we need a standard where system-/automatically-set variables are
named with a auto_ prefix or _auto suffix or something, to make this clear?
Yes, right note.
I'd prefer that the dfu command didn't use any environment variables,
but rather required the user to always pass the list on the
command-line. Then, the user could invoke either:
dfu foo mmc x... # Manually specified
dfu $dfu_alt_info # Use 'user-defined' variable
dfu $dfu_alt_bootloaer # Use 'system-defined' variable
Yes, definitely such feature was missing there.
That way, the code doesn't have to loop over a bunch of variables and
get more complex. Implicitly depending on environment variables make it
hard to tell what a sequence of commands will do.
...
Maybe better could be modification of the function
dfu_init_env_entities() to support parsing variables
in the $dfu_alt_info instead of hard coded env variables
names, e.g:
dfu_alt_info=${alt_info_boot}, ${alt_info_system},...
I feel like the shell already has the capability to interpolate variable
values into strings, so this would be quite easy to do in the shell
rather than duplicating that code inside the dfu command.
Every env macro passed with cmdline will be expanded. And then, we can
use such style like this:
# setenv alt_kernel uImage ext4 0 2;zImage ext4 0 2
# setenv alt_system boot part 0 2;root part 0 3
# setenv auto_alt_bootloader u-boot raw 0x0 0x800
# setenv alt_info ${alt_kernel};${alt_system};${auto_alt_bootloader}
(this will expand when passing to setenv)
or just put this in env default config:
alt_info=${alt_kernel};${alt_system};${auto_alt_bootloader}\0 ...
So summarizing, I don't want to break your DFU rework, I want just to
add the Odroid U3 support, so in the next patch set I will use the
$dfu_alt_info, instead of combining with a short time solution.
And after your work will be done, then I will update Odroid code.
Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FIX: config: goni: Change goni configuration to store envs at eMMC
On 09/06/14 18:36, Lukasz Majewski wrote: Up till now goni's configuration has been stored at OneNAND. Since u-boot itself is now stored at eMMC it is more handy to store envs there as well. Signed-off-by: Lukasz Majewski l.majew...@samsung.com --- include/configs/s5p_goni.h | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index fce1716..804f97f 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -220,9 +220,12 @@ #define CONFIG_SYS_MONITOR_LEN (256 10) /* 256 KiB */ /* FLASH and environment organization */ -#define CONFIG_ENV_IS_IN_ONENAND 1 -#define CONFIG_ENV_SIZE (256 10) /* 256 KiB, 0x4 */ -#define CONFIG_ENV_ADDR (1 20) /* 1 MB, 0x10 */ +#define CONFIG_MMC_DEFAULT_DEV 0 +#define CONFIG_ENV_IS_IN_MMC +#define CONFIG_SYS_MMC_ENV_DEV CONFIG_MMC_DEFAULT_DEV +#define CONFIG_ENV_SIZE 4096 +#define CONFIG_ENV_OFFSET((32 - 4) 10) /* 32KiB - 4KiB */ +#define CONFIG_ENV_OVERWRITE #define CONFIG_USE_ONENAND_BOARD_INIT #define CONFIG_SAMSUNG_ONENAND 1 applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] Exynos: SPI: Fix reading data from SPI flash
SPI recieve and transfer code in exynos_spi driver has a logical bug.
We read data in a variable which can hold an integer. Then we assign
this integer 32 bit value to another variable which has data type uchar.
Latter represents a unit of our recieve buffer. Everytime when we write
a value to our recieve buffer we step ahead by 4 units when actually we
wrote to one unit. This results in the loss of 3 bytes out of every 4
bytes recieved. This patch intends to fix this bug.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes since v3:
- Rebased to top of Tree.
Changes since v2:
- Added Acked-by Tested-by.
- Changed assignment for *rxp.
Changes since v1:
- Added check for step.
drivers/spi/exynos_spi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 4d5def2..c92276f 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -302,7 +302,10 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
}
} else {
if (rxp || stopping) {
- *rxp = temp;
+ if (step == 4)
+ *(uint32_t *)rxp = temp;
+ else
+ *rxp = temp;
rxp += step;
}
in_bytes -= step;
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/6] 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. This patch set also intends to place env at the end of flash, increase SPL footprint, enable USB boot mode and split memory bank config. 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. Changes since v3: - Took four patches in this set from a different patch set. - Rebased all the patches to Top of Tree. Akshay Saraswat (5): Exynos5420: Let macros be used for exynos5420 Exynos5420: Introduce support for the Peach-Pit board Exynos5: Config: Place environment at the end of SPI flash Exynos5: Config: Increase SPL footprint for Exynos5420 Exynos5: Config: Enable USB boot mode for all Exynos5 SoCs Michael Pratt (1): Exynos: Split 5250 and 5420 memory bank configuration 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/exynos5-dt.h | 15 ++- include/configs/exynos5250-dt.h | 13 +-- include/configs/exynos5420.h | 52 ++ include/configs/peach-pit.h | 25 + include/configs/smdk5420.h| 49 ++ 12 files changed, 388 insertions(+), 147 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.7.12.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/6] 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 d91e585..3242093 100644 --- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h +++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h @@ -435,10 +435,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.7.12.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/6] 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
Tested-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
+
[U-Boot] [PATCH v4 3/6] Exynos5: Config: Place environment at the end of SPI flash
Currently environment resides at the location where BL2 ends. This may hold good in case there is an empty space at this position. But what if this place already has a binary or is expected to have one. To avoid such scenarios it is better to save environment at the end of the flash. Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- Changes since v3: - Introduced to this patch-set. Changes since v2: - Added Acked-by Tested-by. Changes since v1: - Added new config for SPI flash size. include/configs/exynos5-dt.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index b830495..d9f5625 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -207,7 +207,10 @@ #define CONFIG_BL1_OFFSET (CONFIG_RES_BLOCK_SIZE + CONFIG_SEC_FW_SIZE) #define CONFIG_BL2_OFFSET (CONFIG_BL1_OFFSET + CONFIG_BL1_SIZE) -#define CONFIG_ENV_OFFSET (CONFIG_BL2_OFFSET + CONFIG_BL2_SIZE) + +/* Store environment at the end of a 4 MB SPI flash */ +#define FLASH_SIZE (0x4 20) +#define CONFIG_ENV_OFFSET (FLASH_SIZE - CONFIG_BL2_SIZE) /* U-boot copy size from boot Media to DRAM.*/ #define BL2_START_OFFSET (CONFIG_BL2_OFFSET/512) -- 1.7.12.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/6] Exynos5: Config: Increase SPL footprint for Exynos5420
Max footprint for SPL in both Exynos 5250 and 5420 is limited to 14 KB. For Exynos5250 we need to keep it 14 KB because BL1 supports only fixed size SPL downloading. But in case of Exynos5420 we need not restrict it to 14 KB. And also, the SPL size for Exynos5420 is expected to increase with the upcoming patches and the patches under review right now. Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- Changes since v3: - Introduced to this patch-set. Changes since v2: - Added Acked-by Tested-by. Changes since v1: - Changed 5420 SPL footprint from 32 to 30 KB. include/configs/exynos5-dt.h| 2 -- include/configs/exynos5250-dt.h | 2 ++ include/configs/exynos5420.h| 2 ++ 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index d9f5625..1129f59 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -144,8 +144,6 @@ /* specific .lds file */ #define CONFIG_SPL_LDSCRIPTboard/samsung/common/exynos-uboot-spl.lds -#define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) - /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 9d1d56a..4cfbf25 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -20,6 +20,8 @@ #define MACH_TYPE_SMDK5250 3774 #define CONFIG_MACH_TYPE MACH_TYPE_SMDK5250 +#define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) + /* USB */ #define CONFIG_CMD_USB #define CONFIG_USB_XHCI diff --git a/include/configs/exynos5420.h b/include/configs/exynos5420.h index 3a28bbc..2ffe5ee 100644 --- a/include/configs/exynos5420.h +++ b/include/configs/exynos5420.h @@ -25,6 +25,8 @@ #endif #define CONFIG_IRAM_TOP0x02074000 +#define CONFIG_SPL_MAX_FOOTPRINT (30 * 1024) + #define CONFIG_DEVICE_TREE_LIST exynos5420-peach-pit exynos5420-smdk5420 #define CONFIG_MAX_I2C_NUM 11 -- 1.7.12.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/6] Exynos5: Config: Enable USB boot mode for all Exynos5 SoCs
Right now USB booting is enabled for Exynos5250 only. Moving all the configs for USB boot mode from exynos5250-dt.h to exynos5-dt.h in order to enableUSB booting for all Exynos5 SoCs. Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- Changes since v3: - Introduced to this patch-set. Changes since v2: - Added Acked-by Tested-by. Changes since v1: - Added Acked-by. include/configs/exynos5-dt.h| 6 ++ include/configs/exynos5250-dt.h | 6 -- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 1129f59..3c51650 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -292,4 +292,10 @@ #define CONFIG_CMD_GPIO +/* USB boot mode */ +#define CONFIG_USB_BOOTING +#define EXYNOS_COPY_USB_FNPTR_ADDR 0x02020070 +#define EXYNOS_USB_SECONDARY_BOOT 0xfeed0002 +#define EXYNOS_IRAM_SECONDARY_BASE 0x02020018 + #endif /* __CONFIG_H */ diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 4cfbf25..3982010 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -29,12 +29,6 @@ #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2 #define CONFIG_USB_STORAGE -/* USB boot mode */ -#define CONFIG_USB_BOOTING -#define EXYNOS_COPY_USB_FNPTR_ADDR 0x02020070 -#define EXYNOS_USB_SECONDARY_BOOT 0xfeed0002 -#define EXYNOS_IRAM_SECONDARY_BASE 0x02020018 - #define CONFIG_SPL_TEXT_BASE 0x02023400 #define CONFIG_BOOTCOMMAND mmc read 40007000 451 2000; bootm 40007000 -- 1.7.12.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 6/6] Exynos: Split 5250 and 5420 memory bank configuration
From: Michael Pratt mpr...@chromium.org Since snow has a different memory configuration than peach, split the configuration between the 5250 and 5420. Exynos 5420 supports runtime memory configuration detection, and can make the determination between 4 and 7 banks at runtime. Include the bank size with the number of banks for context to make the number of banks meaningful. Signed-off-by: Michael Pratt mpr...@chromium.org Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- Changes since v3: - Introduced to this patch-set. Changes since v2: - Added Acked-by Tested-by. Changes since v1: - New patch. include/configs/exynos5-dt.h| 2 -- include/configs/exynos5250-dt.h | 5 + include/configs/exynos5420.h| 4 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 3c51650..e36a031 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -161,8 +161,6 @@ #define CONFIG_RD_LVL -#define CONFIG_NR_DRAM_BANKS 8 -#define SDRAM_BANK_SIZE(256UL 20UL) /* 256 MB */ #define PHYS_SDRAM_1 CONFIG_SYS_SDRAM_BASE #define PHYS_SDRAM_1_SIZE SDRAM_BANK_SIZE #define PHYS_SDRAM_2 (CONFIG_SYS_SDRAM_BASE + SDRAM_BANK_SIZE) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 3982010..74e72a5 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -65,4 +65,9 @@ #define LCD_YRES 1600 #define LCD_BPPLCD_COLOR16 #endif + +/* DRAM Memory Banks */ +#define CONFIG_NR_DRAM_BANKS 8 +#define SDRAM_BANK_SIZE(256UL 20UL) /* 256 MB */ + #endif /* __CONFIG_5250_H */ diff --git a/include/configs/exynos5420.h b/include/configs/exynos5420.h index 2ffe5ee..d2a9556 100644 --- a/include/configs/exynos5420.h +++ b/include/configs/exynos5420.h @@ -45,4 +45,8 @@ */ #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_IRAM_TOP - 0x800) +/* DRAM Memory Banks */ +#define CONFIG_NR_DRAM_BANKS 7 +#define SDRAM_BANK_SIZE(512UL 20UL) /* 512 MB */ + #endif /* __CONFIG_EXYNOS5420_H */ -- 1.7.12.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot and gcc 4.9.0
I compiled the P1010RDB boot loader using the PowerPC gcc version 4.9.0.
The binary failed to boot with a DATA TLB exception. After investigating
and producing an objdump, I saw the following in the function
cpu_init_early_f:
void cpu_init_early_f(void *fdt)
{
...
#ifdef CONFIG_A003399_NOR_WORKAROUND
ccsr_l2cache_t *l2cache = (void *)CONFIG_SYS_MPC85xx_L2_ADDR;
u32 *dst, *src;
void (*setup_ifc_sram)(void);
#endif
...
init_laws();
...
setup_ifc_sram = (void *)SRAM_BASE_ADDR;
dst = (u32 *) SRAM_BASE_ADDR;
src = (u32 *) setup_ifc;
for (i = 0; i 1024; i++)
*dst++ = *src++;
setup_ifc_sram();
/* CLEANUP */
clrbits_be32(l2cache-l2ctl,
(MPC85xx_L2CTL_L2E |
MPC85xx_L2CTL_L2SRAM_ENTIRE));
out_be32(l2cache-l2srbar0, 0x0);
#endif
invalidate_tlb(1);
...
init_tlbs();
}
The GCC powerpc objdump gives:
eff433f4: 4b ff ec 0d bl eff42000 init_laws
eff433f8: 3c 80 80 00 lis r4,-32768
eff433fc: 3c 60 10 09 lis r3,4105
eff43400: 60 84 15 00 ori r4,r4,5376
eff43404: 38 a0 00 08 li r5,8
eff43408: 38 c0 00 15 li r6,21
eff4340c: 38 e0 00 00 li r7,0
eff43410: 4b ff e0 91 bl eff414a0 write_tlb
eff43414: 3d 40 ff e2 lis r10,-30
eff43418: 39 20 00 00 li r9,0
eff4341c: 61 4a 01 00 ori r10,r10,256
eff43420: 7c 00 04 ac msync
eff43424: 91 2a 00 00 stw r9,0(r10)
eff43428: 39 00 00 0c li r8,12
eff4342c: 7c 00 04 ac msync
eff43430: 91 0a 0d 44 stw r8,3396(r10)
eff43434: 3d 00 80 01 lis r8,-32767
eff43438: 3d 40 ff e2 lis r10,-30
eff4343c: 7c 00 04 ac msync
eff43440: 91 0a 00 00 stw r8,0(r10)
eff43444: 91 29 00 00 stw r9,0(r9)
eff43448: 7f e0 00 08 trap
invalidate_tlb and init_tlbs are NOT present and the function ends with
a trap instruction instead of blr.
The line of code dst = (u32 *) SRAM_BASE_ADDR; seems to be the
problem. If removed, the object dump shows the call for the last two
functions and returns.
Also the compiler options -fno-delete-null-pointer-checks or using
memcpy fixes the problem.
Likely related to the following options found in the documentation
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Maybe related to the following:
-fisolate-erroneous-paths-attribute
Detect paths which trigger erroneous or undefined behaviour due a NULL
value being used in a way which is forbidden by a returns_nonnull or
nonnull attribute. Isolate those paths from the main control flow and
turn the statement with erroneous or undefined behaviour into a trap.
This is not currently enabled, but may be enabled by -O2 in the future.
Any thoughts?
Renaud
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
Hi Albert, I had one more look at this, please see my comments below. On Wed, Jun 11, 2014 at 9:14 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Masahiro, (to: the board maintainers for enbw_cmc, da850evm_direct_nor, and calimain) On Mon, 09 Jun 2014 18:29:26 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Albert, You changed the behaviour of three boards, enbw_cmc, da850evm_direct_nor, calimain! Probably they are broken. These boards expects 0x0011 (=CONFIG_SYS_DV_NOR_BOOT_CFG) at the beginning of the image. But since commit 41623c91, that is missing. If you still don't understand, you should checkout 41623c91^ and 41623c91 and compare u-boot.dis. Your description of the effects of my change is correct. However, this raises another question which I would like to see discussed before doing anything about these boards. Taking the last commit where the prefix word was actually emitted (that is, 41623c91^, which is actually 60a4f39f, arm: remove unused _end_vect and _vectors_end symbols), and reading arch/arm/cpu/arm926ejs/start.S, I see that the start of the image looks like this: offset Content +0x prefix word CONFIG_SYS_DV_NOR_BOOT_CFG +0x0004 reset vector +0x0008 undefined instruction vector +0x000c software interrupt vector +0x0010 prefetch abort vector +0x0014 data abort vector +0x0018 unused +0x001c irq vector +0x0020 fiq vector +0x0024 (end of vectors table) And that is /wrong/: the vectors table is misaligned by 4 bytes. Let's have a look at the calimain board. The vector exception table of this CPU (ARM926EJS) can be located either at 0x or at 0x (depending on CONFIG_SYS_EXCEPTION_VECTORS_HIGH). This SoC (Texas Instruments AM1808) has no physical memory at 0x, therefore CONFIG_SYS_EXCEPTION_VECTOR must be defined. The exception vector table is located in the internal RAM of the device, that is located at 0x. However, CONFIG_SYS_TEXT_BASE is 0x6000, that is the begin of NOR flash memory on this device. Later, u-boot relocates itself to some place DDR2 memory. So in the begin u-boot's vector table is located at 0x6004. Later, it is relocated to somewhere in the DDR2 memory. There is no code that actually touches the exception vector table at 0x. Exceptions are not used at all and therefore the location of this table in memory is totally irrelevant. What we actually need would be some code that copies the vector table to the right location (0x). But this code could copy the table from anywhere, so I don't understand why the CONFIG_SYS_DV_NOR_BOOT_CFG word would disturb the alignment of the table. If we accept that we do not use any exceptions we could either restore the old behavior: --- 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 + /* * * @@ -49,7 +51,6 @@ _start: .word CONFIG_SYS_DV_NOR_BOOT_CFG #endif -_start: ldr pc, _reset Obviously, the boards have been working fine for a long time, because no exception vector was used apparently (or because when exceptions did happen, the error was debugged without the need to analyze the exception). I suspect we could just remove the '.word CONFIG_SYS_DV_NOR_BOOT_CFG' line from the vectors.S file and prepend the word to the image /after/ linking. Or we could remove .word CONFIG_SYS_DV_NOR_BOOT_CFG as you suggested and later add the word after linking. But for this case we should be able to set CONFIG_SYS_TEXT_BASE to 0x6004. But due to the .align 5 statements below in arch/arm/lib/vectors.S this leads to a padding at the start of u-boot.bin, since the entire .vectors section will be aligned to 32 bytes: hexdump -C u-boot.bin 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0010 00 00 00 00 00 00 00 00 00 00 00 00 18 f0 9f e5 || 0020 18 f0 9f e5 18 f0 9f e5 18 f0 9f e5 18 f0 9f e5 || Now the ldr pc, _reset is at the wrong location, u-boot does not boot. Am I missing something here? What would be the preferred solution to make the board working again? Best regards, Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
On Wed, Jun 18, 2014 at 2:55 PM, Christian Riesch christian.rie...@omicron.at wrote: [...] And that is /wrong/: the vectors table is misaligned by 4 bytes. Let's have a look at the calimain board. The vector exception table of this CPU (ARM926EJS) can be located either at 0x or at 0x (depending on CONFIG_SYS_EXCEPTION_VECTORS_HIGH). This SoC (Texas Instruments AM1808) has no physical memory at 0x, therefore CONFIG_SYS_EXCEPTION_VECTOR must be defined. The exception s/CONFIG_SYS_EXCEPTION_VECTOR/CONFIG_SYS_EXCEPTION_VECTORS_HIGH/ :-) Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup
hi York, On 06/10/2014 02:15 AM, Mark Rutland wrote: Hi, Apologies for the delay in replying. On Fri, Jun 06, 2014 at 11:14:23PM +0100, York Sun wrote: On 06/06/2014 01:17 PM, York Sun wrote: On 06/06/2014 10:32 AM, Mark Rutland wrote: How is TCR_EL2.SH0 (or TCR_EL1.SH*) configured? You'll only need to flush the cache if they're configured non shareable. It is configured as non shareable. Is there any reason not to configure them as inner shareable? That way the MMU will look in the D-cache, and you won't have to spend time flushing them. Mark, I appreciate the reminder. I tried on our emulator. With inner share set for TCR SH0 bits, u-boot works with the flushing, but doesn't work without flushing. It went to exception. Can you share more information about the inner share? I need to follow up with our designer to confirm. A second thought, do I need to set the first MMU table so DDR is inner shareable? I assume you mean configuring MAIR_ELx such that the mapping covering DDR is cacheable for the inner shareable domain? If so, yes. Mark, I tried both inner share and outer. It doesn't work without flushing the cache. I will keep this part of code until I learn otherwise. York The shareability attribute is different with cacheablilty attribute, it means whether the memory region would be accessed by other processors. If a memory region is configured as non sharable the access will not be snooped but still can be cached. It is the situation that current u-boot-armv8 used due to only master processor is active. If secondary processors also access the same memory region it should be configured as inner-sharable or outer-sharable otherwise the cache coherence between processors will not be maintained. The above is what I know. Wish this could help. David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/ddr: Fix DDR4 driver for ARM
On Tue, Jun 17, 2014 at 5:07 PM, York Sun york...@freescale.com wrote:
Previously the driver was only tested on Power SoCs. Minor fix is needed
for ARM SoCs.
Signed-off-by: York Sun york...@freescale.com
Hi York!
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -183,12 +184,20 @@ step2:
* we choose the max, that is 500 us for all of case.
*/
udelay(500);
+#ifdef CONFIG_PPC
asm volatile(sync;isync);
+#else
+ asm volatile(dsb sy;isb);
+#endif
/* Let the controller go */
temp_sdram_cfg = ddr_in32(ddr-sdram_cfg) ~SDRAM_CFG_BI;
ddr_out32(ddr-sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
+#ifdef CONFIG_PPC
asm volatile(sync;isync);
+#else
+ asm volatile(dsb sy;isb);
+#endif
total_gb_size_per_controller = 0;
for (i = 0; i CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
This is a great example where we should try to introduce better abstractions
in much the same way that Linux has. Specifically, we (U-Boot) collective
might work toward some common lower-level abstractions such as a
memory_barrier() (and variants), and let those generic names get mapped
into architecture-specific implementations via a linked binding. Then this
code would not need to change, nor would #ifdefs be needed.
HTH,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup
On 06/18/2014 07:09 AM, feng...@phytium.com.cn wrote: hi York, On 06/10/2014 02:15 AM, Mark Rutland wrote: Hi, Apologies for the delay in replying. On Fri, Jun 06, 2014 at 11:14:23PM +0100, York Sun wrote: On 06/06/2014 01:17 PM, York Sun wrote: On 06/06/2014 10:32 AM, Mark Rutland wrote: How is TCR_EL2.SH0 (or TCR_EL1.SH*) configured? You'll only need to flush the cache if they're configured non shareable. It is configured as non shareable. Is there any reason not to configure them as inner shareable? That way the MMU will look in the D-cache, and you won't have to spend time flushing them. Mark, I appreciate the reminder. I tried on our emulator. With inner share set for TCR SH0 bits, u-boot works with the flushing, but doesn't work without flushing. It went to exception. Can you share more information about the inner share? I need to follow up with our designer to confirm. A second thought, do I need to set the first MMU table so DDR is inner shareable? I assume you mean configuring MAIR_ELx such that the mapping covering DDR is cacheable for the inner shareable domain? If so, yes. Mark, I tried both inner share and outer. It doesn't work without flushing the cache. I will keep this part of code until I learn otherwise. York The shareability attribute is different with cacheablilty attribute, it means whether the memory region would be accessed by other processors. If a memory region is configured as non sharable the access will not be snooped but still can be cached. It is the situation that current u-boot-armv8 used due to only master processor is active. If secondary processors also access the same memory region it should be configured as inner-sharable or outer-sharable otherwise the cache coherence between processors will not be maintained. The above is what I know. Wish this could help. David, Thanks for chime in. It is not clear to me if I can put a new MMU table in d-cache and have MMU fetch from the d-cache. I tried several ways but it doesn't work. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] drivers:dfu: new feature: separated bootloader alt setting
On 06/18/2014 04:56 AM, Przemyslaw Marczak wrote: On 06/17/2014 06:36 PM, Stephen Warren wrote: ... I'd prefer that the dfu command didn't use any environment variables, but rather required the user to always pass the list on the command-line. Then, the user could invoke either: dfu foo mmc x... # Manually specified dfu $dfu_alt_info # Use 'user-defined' variable dfu $dfu_alt_bootloaer # Use 'system-defined' variable Yes, definitely such feature was missing there. ... So summarizing, I don't want to break your DFU rework, I want just to add the Odroid U3 support, so in the next patch set I will use the $dfu_alt_info, instead of combining with a short time solution. Which rework are you referring to? I'm not actively working on changing the command-line parameters to the dfu command in any way. I've certainly discussed how I'd prefer the dfu command to work, but I don't have time to actually implement that. So, the existing command-line format is likely to stay as it is for now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/ddr: Fix DDR4 driver for ARM
On 06/18/2014 07:57 AM, Jon Loeliger wrote:
On Tue, Jun 17, 2014 at 5:07 PM, York Sun york...@freescale.com wrote:
Previously the driver was only tested on Power SoCs. Minor fix is needed
for ARM SoCs.
Signed-off-by: York Sun york...@freescale.com
Hi York!
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -183,12 +184,20 @@ step2:
* we choose the max, that is 500 us for all of case.
*/
udelay(500);
+#ifdef CONFIG_PPC
asm volatile(sync;isync);
+#else
+ asm volatile(dsb sy;isb);
+#endif
/* Let the controller go */
temp_sdram_cfg = ddr_in32(ddr-sdram_cfg) ~SDRAM_CFG_BI;
ddr_out32(ddr-sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
+#ifdef CONFIG_PPC
asm volatile(sync;isync);
+#else
+ asm volatile(dsb sy;isb);
+#endif
total_gb_size_per_controller = 0;
for (i = 0; i CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
This is a great example where we should try to introduce better abstractions
in much the same way that Linux has. Specifically, we (U-Boot) collective
might work toward some common lower-level abstractions such as a
memory_barrier() (and variants), and let those generic names get mapped
into architecture-specific implementations via a linked binding. Then this
code would not need to change, nor would #ifdefs be needed.
Agreed. I will work on that.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v6 3/5] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC
On 06/18/2014 02:43 AM, Mark Rutland wrote:
Hi York,
Apologies for the late reply on this.
I'm somewhat concerned regarding the issues you're seeing with cacheable
page table walks, but I'll ignore that for the moment so we can get the
ordering of maintenance sorted.
On Thu, Jun 05, 2014 at 08:23:09PM +0100, York Sun wrote:
Freescale LayerScape with Chassis Generation 3 is a set of SoCs with
ARMv8 cores and 3rd generation of Chassis. We use different MMU setup
to support memory map and cache attribute for these SoCs. MMU and cache
are enabled very early to bootst performance, especially for early
development on emulators. After u-boot relocates to DDR, a new MMU
table with QBMan cache access is created in DDR. SMMU pagesize is set
in SMMU_sACR register. Both DDR3 and DDR4 are supported.
Signed-off-by: York Sun york...@freescale.com
Signed-off-by: Varun Sethi varun.se...@freescale.com
Signed-off-by: Arnab Basu arnab.b...@freescale.com
---
[...]
+ /* point TTBR to the new table */
+ el = current_el();
Could we not place a dsb() here...
+ if (el == 1) {
+ asm volatile(dsb sy;msr ttbr0_el1, %0;isb
+: : r ((u64)level0_table) : memory);
+ } else if (el == 2) {
+ asm volatile(dsb sy;msr ttbr0_el2, %0;isb
+: : r ((u64)level0_table) : memory);
+ } else if (el == 3) {
+ asm volatile(dsb sy;msr ttbr0_el3, %0;isb
+: : r ((u64)level0_table) : memory);
+ } else {
+ hang();
+ }
...and an isb() here?
It would save duplicating them for each EL.
Sure. I can move them out.
+ /*
+* MMU is already enabled, just need to invalidate TLB to load the
+* new table. The new table is compatible with the current table, if
+* MMU somehow walks through the new table before invalidation TLB,
+* it still works. So we don't need to turn off MMU here.
+*/
+}
+
+int arch_cpu_init(void)
+{
+ icache_enable();
Just to check: the icache is clean/invalid at this point?
It is not, but it is done first thing inside icache_enable().
+ __asm_invalidate_dcache_all();
+ __asm_invalidate_tlb_all();
+ early_mmu_setup();
+ set_sctlr(get_sctlr() | CR_C);
+ return 0;
+}
[...]
+/*
+ * This function is called from lib/board.c.
+ * It recreates MMU table in main memory. MMU and d-cache are enabled
earlier.
+ * There is no need to disable d-cache for this operation.
+ */
+void enable_caches(void)
+{
+ final_mmu_setup();
+ flush_dcache_range(gd-arch.tlb_addr,
+ gd-arch.tlb_addr + gd-arch.tlb_size);
+ __asm_invalidate_tlb_all();
+}
This looks wrong, given your previous comments that you couldn't get the
MMU to lookup from the cache.
In final_mmu_setup() you pointed the TTBR0_ELx to the new tables, but at
that point the tables aren't guaranteed to be in memory, because they
haven't been flushed. The MMU can start fetching the garbage from memory
immediately, and things might go wrong before __asm_invalidate_tlb_all()
blows away the garbage the MMU read from memory (for instance, the
mapping covering the enable_caches function might get replaced by
garbage).
If the page table walks are non-cacheable, you need to flush the tables
to memory before programming the relevant TTBR.
Agreed here. I will move the flushing before setting TTBR.
Thanks for review. v7 patch is coming after I verify all the changes.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: iocon: Enabling CONFIG_CMD_FPGAD again
On Tue, Jun 17, 2014 at 12:36:14AM +0200, Michal Simek wrote: Revert changes in iocon.h config file caused by these two commits: configs: iocom: Fix typo on CMD_FPGA command (sha1: d0db28f94034ef02c1d6737895766fb3c19de47f) and fpga: Guard the LOADMK functionality with CMD_FPGA_LOADMK (sha1: 64e809afeaf1572c3246a5bca198a77d0498fd89) CONFIG_CMD_FPGAD is own command. Reported-by: Dirk Eibach dirk.eib...@gdsys.cc Signed-off-by: Michal Simek michal.si...@xilinx.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix bug in io64 target (introduced by commit aba27ac)
On Mon, Jun 16, 2014 at 05:40:59PM +0300, Vasili Galka wrote: From comparison of current logic and the logic that was prior to commit aba27ac, we see that first parameter of FPGA_GET_REG() shall be the FPGA index and not channel number. The re-factoring in commit aba27ac accidentally changed that. Signed-off-by: Vasili Galka vvv...@gmail.com Cc: Dirk Eibach dirk.eib...@gdsys.cc, Stefan Roese s...@denx.de Applied to u-boot/master (and updated commit message to have an acked-by from Dirk), thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] fs: implement size/fatsize/ext4size
On Tue, Jun 17, 2014 at 10:57:19AM +0200, Lukasz Majewski wrote: Hi Stephen, From: Stephen Warren swar...@nvidia.com These commands may be used to determine the size of a file without actually reading the whole file content into memory. This may be used to determine if the file will fit into the memory buffer that will contain it. In particular, the DFU code will use it for this purpose in the next commit. Signed-off-by: Stephen Warren swar...@nvidia.com --- v2: New patch Stephen thanks for the patch. Acked-by: Lukasz Majewski l.majew...@samsung.com Test HW: Trats2 (Exynos4412): Tested-by: Lukasz Majewski l.majew...@samsung.com Organizational issue: File systems don't have their own trees, so if Tom or Marek don't mind I would like to take this patch to -dfu tree. Justification: This patch was written solely for fixing flaws of DFU, so I think that it is appropriate to take it to -dfu tree and in this way provide consistency with the following DFU patch. Works for me, thanks. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Kbuild: sync with Linux 3.16-rc1
On Mon, Jun 16, 2014 at 06:56:35PM +0900, Masahiro Yamada wrote: The merge window for Linux 3.16 is closed and Linux 3.16-rc1 is out now. During the merge window, various Kbuild-related updates were merged into the upstream. This series imports them to U-Boot. I see you saw there's problems been reported and have moved this to RFC. My thoughts on this right now are that as a rule of thumb we should: 1) If our merge window and kernel merge window line up (say -rc1 kernel came out, and we are -rc1 or haven't yet snapped -rc1), sync up, and stay in sync to release on the kernel side (as close as possible) 2) If our merge windows aren't in sync, just stick with kernel release. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] m68k: Fix warnings with gcc 4.6
On Tue, Jun 17, 2014 at 08:52:09PM -0700, Simon Glass wrote: Hi Masahiro, On 17 June 2014 01:34, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Simon, On Wed, 11 Jun 2014 18:19:28 -0400 Tom Rini tr...@ti.com wrote: On Sat, Jun 07, 2014 at 10:07:58PM -0600, Simon Glass wrote: Most of the warnings seem to be related to using 'int' for size_t. Change this and fix up the remaining warnings and problems. For bootm, the warning was masked by others, and there is an actual bug in the code. Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom Since commit ddc94378d, I see lots of warnings when compiling m68k boards like this: Configuring for M52277EVB - Board: M52277EVB, Options: SYS_SPANSION_BOOT,SYS_TEXT_BASE=0x textdata bss dec hex filename 117375 115304092 132997 20785 ./u-boot common/cli_simple.c: In function 'process_macros': common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] drivers/mtd/spi/sf.c: In function 'spi_flash_read_write': drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops': drivers/mtd/spi/sf_ops.c:323:3: warning: format '%zu' expects argument of type 'size_t', but argument 7 has type 'long unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update_block': common/cmd_sf.c:154:2: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'long unsigned int' [-Wformat] common/cmd_sf.c:161:3: warning: format '%zx' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update': common/cmd_sf.c:218:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_read_write': common/cmd_sf.c:291:10: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_erase': common/cmd_sf.c:326:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_export': common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_import': common/cmd_nvedit.c:1036:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] common/cmd_nvedit.c:1036:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] lib/hashtable.c: In function 'hexport_r': lib/hashtable.c:605:2: warning: format '%zu' expects argument of type 'size_t', but argument 5 has type 'long unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] lib/hashtable.c: In function 'himport_r': lib/hashtable.c:793:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] Reverting the following fixes the warnings. --- a/arch/m68k/include/asm/posix_types.h +++ b/arch/m68k/include/asm/posix_types.h @@ -15,7 +15,7 @@ typedef long __kernel_off_t; typedef int__kernel_pid_t; typedef unsigned int __kernel_uid_t; typedef unsigned int __kernel_gid_t; -typedef unsigned int __kernel_size_t; +typedef unsigned long __kernel_size_t; typedef int__kernel_ssize_t; typedef long __kernel_ptrdiff_t; typedef long __kernel_time_t; In m68k Linux, __kernel_size_t is set to unsigned int. So I am not sure if your change is good. (At least for me, it worsens the situation.) Does it depend on each tool-chain ? My
Re: [U-Boot] [PATCH] includes: move openssl headers to include/u-boot
On di, 2014-06-17 at 22:25 -0700, Simon Glass wrote: Hi Jeroen, On 12 June 2014 13:27, Jeroen Hofstee jer...@myspectrum.nl wrote: commit 18b06652cd tools: include u-boot version of sha256.h unconditionally forced the sha256.h from u-boot to be used for tools instead of the host version. This is fragile though as it will also include the host version. Therefore move it to include/u-boot to join u-boot/md5.h etc which were renamed for the same reason. cc: Simon Glass s...@chromium.org Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl This seems like a much better solution. But I think you should keep the sort order - so u-boot/xxx should go after asm/xxx in the #includes I think. I considered it, but e.g. common/image.c contains this before this patch: #include u-boot/md5.h #include sha1.h #include asm/errno.h #include asm/io.h While I can rearrange them, I think it should be a separate patch, since it is not sorted in the first place. Furthermore if possible I would prefer this commit to go into the current release and hence want to keep it as short as possible. What I hadn't realized with the original patch is that we don't replace the header but include them all. On FreeBSD u-boot/sha256.h is included because the makefile said so, but the host version of sha256.h is included as well by the source code and the openssl/* will include similar headers again. And hence fails to compile in the end. Likely the same holds for libfdt_env.h, but this likely works for the time being, since they have the same include guard. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mxs: fixed battery boot on imx233-olinuxino-micro
Am 17.06.2014 18:00, schrieb Stefano Babic: Hi peter, ... On 17/06/2014 00:19, Marek Vasut wrote: Agree. Reason is that this change is for all boards, and without a proper testing I will avoid to merge it in the release. Best regards, Stefano Babic Hi Stefano, I've only the imx233 olimex board for testing. The DOUBLE_FETS switch in HW_POWER_MINPWR is some thing were maybe problems emerge. I have very little load on the powerrails (imx233 + DRAM), so maybe with more current demand DOUBLE_FETS is working OK and even more may require it to be set. The DOUBLE_FETS and HALF_FETS switches control the switching MOSFET size in the DCDC Converter. My assumption is that if we have a to big FET setting and to low current demand we trigger some failsafe mechanism. Because the required on time of the FET is smaller than the minimum possible on time of then DCDC FET control logic. I don't have an easy way to test this assumption without an adjustable load. The other change regarding mxs_power_enable_4p2() should be relatively safe to apply. If I can help with some testing let me know. Best regards, Peter Schumann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Avoid using gawk-specific strtonum()
On Wed, Jun 18, 2014 at 12:01:12PM +0200, Wolfgang Denk wrote:
Dear Simon,
In message 1403071815-32055-1-git-send-email-...@chromium.org you wrote:
We need to subtract two hex numbers. Avoid using strtonum() by doing the
subtraction in bc with a suitable input base.
Signed-off-by: Simon Glass s...@chromium.org
Reported-by: Vasili Galka vvv...@gmail.com
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 24d9687..bb2f615 100644
--- a/Makefile
+++ b/Makefile
@@ -788,7 +788,8 @@ OBJCOPYFLAGS_u-boot.bin := -O binary
binary_size_check: u-boot.bin System.map FORCE
@file_size=`stat -c %s u-boot.bin` ; \
map_size=$(shell cat System.map | \
- awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print strtonum(0x end) -
strtonum(0x start)}'); \
+ awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print ibase=16; toupper(end)
- toupper(start)}' \
+ | bc); \
I think instead of introducing yet another tool dependency this could
be rewritten to use just bash:
awk '/_image_copy_start/ {start = $1}
/_image_binary_end/ {end = $1}
END { if (start != end != )
print printf %d $$((0x end - 0x start ))
}' |
bash
But now we're forcing bash. Jeroen, since you most often run into the
but now you've introduced a Linux'ism problems, bash or bc or
something else for a portable hex to decimal conversion? Or since so
much of U-Boot is hex when talking numbers, maybe we should just make
the echos say ... size of 0x$foo expected 0x$bar ?
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Avoid using gawk-specific strtonum()
On wo, 2014-06-18 at 14:26 -0400, Tom Rini wrote:
On Wed, Jun 18, 2014 at 12:01:12PM +0200, Wolfgang Denk wrote:
Dear Simon,
In message 1403071815-32055-1-git-send-email-...@chromium.org you wrote:
We need to subtract two hex numbers. Avoid using strtonum() by doing the
subtraction in bc with a suitable input base.
Signed-off-by: Simon Glass s...@chromium.org
Reported-by: Vasili Galka vvv...@gmail.com
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 24d9687..bb2f615 100644
--- a/Makefile
+++ b/Makefile
@@ -788,7 +788,8 @@ OBJCOPYFLAGS_u-boot.bin := -O binary
binary_size_check: u-boot.bin System.map FORCE
@file_size=`stat -c %s u-boot.bin` ; \
map_size=$(shell cat System.map | \
- awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print strtonum(0x end) -
strtonum(0x start)}'); \
+ awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print ibase=16; toupper(end)
- toupper(start)}' \
+ | bc); \
I think instead of introducing yet another tool dependency this could
be rewritten to use just bash:
awk '/_image_copy_start/ {start = $1}
/_image_binary_end/ {end = $1}
END { if (start != end != )
print printf %d $$((0x end - 0x start ))
}' |
bash
But now we're forcing bash. Jeroen, since you most often run into the
but now you've introduced a Linux'ism problems, bash or bc or
something else for a portable hex to decimal conversion? Or since so
much of U-Boot is hex when talking numbers, maybe we should just make
the echos say ... size of 0x$foo expected 0x$bar ?
I haven't checked but bc is part of POSIX standard, so it should be
fine, social pressure demands I watch soccer ;). But anyway see:
http://pubs.opengroup.org/onlinepubs/95399/utilities/bc.html
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v7 3/5] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC
Freescale LayerScape with Chassis Generation 3 is a set of SoCs with
ARMv8 cores and 3rd generation of Chassis. We use different MMU setup
to support memory map and cache attribute for these SoCs. MMU and cache
are enabled very early to bootst performance, especially for early
development on emulators. After u-boot relocates to DDR, a new MMU
table with QBMan cache access is created in DDR. SMMU pagesize is set
in SMMU_sACR register. Both DDR3 and DDR4 are supported.
Signed-off-by: York Sun york...@freescale.com
Signed-off-by: Varun Sethi varun.se...@freescale.com
Signed-off-by: Arnab Basu arnab.b...@freescale.com
---
v7: Move dsb sy and isb out of each EL level.
Move flusing final MMU table before setting TTBR.
v6: Add dsb sy before setting TTBR and add isb after.
v5: Revise the 2nd MMU table code to use the same macros
Only change TTBR to point to new MMU table without rewriting MAIR, TCR
v4: Slit ARMv8 MMU change to another patch, v4 2/5
Add more comment for final MMU table setup
Remove mmu.h added in v3 and v2
Remove GICv2 macro testing in lowlevel.S
Rename function init_type() to initiator_type()
Use ARMv8 generic timer code
v3: Remove blank lines at the of files
Fix cluster PLL GSR register for accessing beyond array size
Update final MMU table to support QBMan memory with cache
Set SMMU pagesize in SMMU_sACR register in lowlevel init.
Add DDR4 support
Remove forcing L3 cache flusing
Update GICv3 redistributor base address
Some of these changes are caused by model change.
arch/arm/cpu/armv8/cache_v8.c |7 +-
arch/arm/cpu/armv8/fsl-lsch3/Makefile |9 +
arch/arm/cpu/armv8/fsl-lsch3/README | 10 +
arch/arm/cpu/armv8/fsl-lsch3/cpu.c| 425 +
arch/arm/cpu/armv8/fsl-lsch3/cpu.h|7 +
arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S | 65
arch/arm/cpu/armv8/fsl-lsch3/speed.c | 176 +
arch/arm/cpu/armv8/fsl-lsch3/speed.h |7 +
arch/arm/include/asm/arch-fsl-lsch3/clock.h | 23 ++
arch/arm/include/asm/arch-fsl-lsch3/config.h | 65
arch/arm/include/asm/arch-fsl-lsch3/gpio.h|9 +
arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h | 116 ++
arch/arm/include/asm/arch-fsl-lsch3/imx-regs.h| 13 +
arch/arm/include/asm/config.h |4 +
arch/arm/include/asm/system.h |2 +
drivers/i2c/mxc_i2c.c |5 +
include/common.h |5 +-
17 files changed, 944 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/Makefile
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/README
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/cpu.c
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/cpu.h
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/speed.c
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/speed.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/clock.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/config.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/gpio.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/imx-regs.h
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index af3c494..9dbcdf2 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -73,12 +73,17 @@ void invalidate_dcache_all(void)
__asm_invalidate_dcache_all();
}
+void __weak flush_l3_cache(void)
+{
+}
+
/*
* Performs a clean invalidation of the entire data cache at all levels
*/
void flush_dcache_all(void)
{
__asm_flush_dcache_all();
+ flush_l3_cache();
}
/*
@@ -211,7 +216,7 @@ void invalidate_icache_all(void)
* Enable dCache iCache, whether cache is actually enabled
* depend on CONFIG_SYS_DCACHE_OFF and CONFIG_SYS_ICACHE_OFF
*/
-void enable_caches(void)
+void __weak enable_caches(void)
{
icache_enable();
dcache_enable();
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/Makefile
b/arch/arm/cpu/armv8/fsl-lsch3/Makefile
new file mode 100644
index 000..9249537
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-lsch3/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright 2014, Freescale Semiconductor
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += cpu.o
+obj-y += lowlevel.o
+obj-y += speed.o
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
new file mode 100644
index 000..de34a91
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -0,0 +1,10 @@
+#
+# Copyright 2014 Freescale Semiconductor
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+Freescale LayerScape with Chassis Generation 3
+
+This architecture supports Freescale ARMv8 SoCs with Chassis
[U-Boot] [Patch v7 2/5] ARMv8: Adjust MMU setup
Make MMU function reusable. Platform code can setup its own MMU tables.
Signed-off-by: York Sun york...@freescale.com
CC: David Feng feng...@phytium.com.cn
---
Change log
v7: no change
v6: Modified from v4. Add dsb sy before setting MMU registers and add isb
after.
v5: Drop the addition of inline function set_pgtable_section() from v4
It is only used twice and causes confusion.
v4: new patch, splitted from v3 2/4
Revise set_pgtable_section() to be reused by platform MMU code
Add inline function set_ttbr_tcr_mair() to be used by this and platform
mmu code
arch/arm/cpu/armv8/cache_v8.c| 50 +++---
arch/arm/include/asm/armv8/mmu.h | 24 ++
2 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index a96ecda..af3c494 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -12,15 +12,14 @@
DECLARE_GLOBAL_DATA_PTR;
#ifndef CONFIG_SYS_DCACHE_OFF
-
-static void set_pgtable_section(u64 section, u64 memory_type)
+void set_pgtable_section(u64 *page_table, u64 index, u64 section,
+u64 memory_type)
{
- u64 *page_table = (u64 *)gd-arch.tlb_addr;
u64 value;
- value = (section SECTION_SHIFT) | PMD_TYPE_SECT | PMD_SECT_AF;
+ value = section | PMD_TYPE_SECT | PMD_SECT_AF;
value |= PMD_ATTRINDX(memory_type);
- page_table[section] = value;
+ page_table[index] = value;
}
/* to activate the MMU we need to set up virtual memory */
@@ -28,10 +27,13 @@ static void mmu_setup(void)
{
int i, j, el;
bd_t *bd = gd-bd;
+ u64 *page_table = (u64 *)gd-arch.tlb_addr;
/* Setup an identity-mapping for all spaces */
- for (i = 0; i (PGTABLE_SIZE 3); i++)
- set_pgtable_section(i, MT_DEVICE_NGNRNE);
+ for (i = 0; i (PGTABLE_SIZE 3); i++) {
+ set_pgtable_section(page_table, i, i SECTION_SHIFT,
+ MT_DEVICE_NGNRNE);
+ }
/* Setup an identity-mapping for all RAM space */
for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
@@ -39,38 +41,26 @@ static void mmu_setup(void)
ulong end = bd-bi_dram[i].start + bd-bi_dram[i].size;
for (j = start SECTION_SHIFT;
j end SECTION_SHIFT; j++) {
- set_pgtable_section(j, MT_NORMAL);
+ set_pgtable_section(page_table, j, j SECTION_SHIFT,
+ MT_NORMAL);
}
}
/* load TTBR0 */
el = current_el();
if (el == 1) {
- asm volatile(msr ttbr0_el1, %0
-: : r (gd-arch.tlb_addr) : memory);
- asm volatile(msr tcr_el1, %0
-: : r (TCR_FLAGS | TCR_EL1_IPS_BITS)
-: memory);
- asm volatile(msr mair_el1, %0
-: : r (MEMORY_ATTRIBUTES) : memory);
+ set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
+ TCR_FLAGS | TCR_EL1_IPS_BITS,
+ MEMORY_ATTRIBUTES);
} else if (el == 2) {
- asm volatile(msr ttbr0_el2, %0
-: : r (gd-arch.tlb_addr) : memory);
- asm volatile(msr tcr_el2, %0
-: : r (TCR_FLAGS | TCR_EL2_IPS_BITS)
-: memory);
- asm volatile(msr mair_el2, %0
-: : r (MEMORY_ATTRIBUTES) : memory);
+ set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
+ TCR_FLAGS | TCR_EL2_IPS_BITS,
+ MEMORY_ATTRIBUTES);
} else {
- asm volatile(msr ttbr0_el3, %0
-: : r (gd-arch.tlb_addr) : memory);
- asm volatile(msr tcr_el3, %0
-: : r (TCR_FLAGS | TCR_EL2_IPS_BITS)
-: memory);
- asm volatile(msr mair_el3, %0
-: : r (MEMORY_ATTRIBUTES) : memory);
+ set_ttbr_tcr_mair(el, gd-arch.tlb_addr,
+ TCR_FLAGS | TCR_EL3_IPS_BITS,
+ MEMORY_ATTRIBUTES);
}
-
/* enable the mmu */
set_sctlr(get_sctlr() | CR_M);
}
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index 1193e76..4b7b67b 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -108,4 +108,28 @@
TCR_IRGN_WBWA | \
TCR_T0SZ(VA_BITS))
+#ifndef __ASSEMBLY__
+void set_pgtable_section(u64 *page_table, u64 index,
+u64 section, u64 memory_type);
+static inline void set_ttbr_tcr_mair(int el, u64 table,
[U-Boot] [Patch v7 1/5] Added 64-bit MMIO accessors for ARMv8
From: J. German Rivera german.riv...@freescale.com
This is needed for accessing peripherals with 64-bit MMIO registers,
from ARMv8 processors.
Signed-off-by: J. German Rivera german.riv...@freescale.com
Signed-off-by: York Sun york...@freescale.com
---
Change log
v7: no change
v6: no change
v5: no change
v4: no change
v3: no change
arch/arm/include/asm/io.h |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 6a1f05a..95528dd 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -70,10 +70,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr)
#define __arch_getb(a) (*(volatile unsigned char *)(a))
#define __arch_getw(a) (*(volatile unsigned short *)(a))
#define __arch_getl(a) (*(volatile unsigned int *)(a))
+#define __arch_getq(a) (*(volatile unsigned long long *)(a))
#define __arch_putb(v,a) (*(volatile unsigned char *)(a) = (v))
#define __arch_putw(v,a) (*(volatile unsigned short *)(a) = (v))
#define __arch_putl(v,a) (*(volatile unsigned int *)(a) = (v))
+#define __arch_putq(v,a) (*(volatile unsigned long long *)(a) =
(v))
extern inline void __raw_writesb(unsigned long addr, const void *data,
int bytelen)
@@ -123,10 +125,12 @@ extern inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
#define __raw_writeb(v,a) __arch_putb(v,a)
#define __raw_writew(v,a) __arch_putw(v,a)
#define __raw_writel(v,a) __arch_putl(v,a)
+#define __raw_writeq(v,a) __arch_putq(v,a)
#define __raw_readb(a) __arch_getb(a)
#define __raw_readw(a) __arch_getw(a)
#define __raw_readl(a) __arch_getl(a)
+#define __raw_readq(a) __arch_getq(a)
/*
* TODO: The kernel offers some more advanced versions of barriers, it might
@@ -139,10 +143,12 @@ extern inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
#define writeb(v,c)({ u8 __v = v; __iowmb(); __arch_putb(__v,c); __v; })
#define writew(v,c)({ u16 __v = v; __iowmb(); __arch_putw(__v,c); __v; })
#define writel(v,c)({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
+#define writeq(v,c)({ u64 __v = v; __iowmb(); __arch_putq(__v,c); __v; })
#define readb(c) ({ u8 __v = __arch_getb(c); __iormb(); __v; })
#define readw(c) ({ u16 __v = __arch_getw(c); __iormb(); __v; })
#define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
+#define readq(c) ({ u64 __v = __arch_getq(c); __iormb(); __v; })
/*
* The compiler seems to be incapable of optimising constants
@@ -168,9 +174,11 @@ extern inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
#define out_arch(type,endian,a,v) __raw_write##type(cpu_to_##endian(v),a)
#define in_arch(type,endian,a) endian##_to_cpu(__raw_read##type(a))
+#define out_le64(a,v) out_arch(q,le64,a,v)
#define out_le32(a,v) out_arch(l,le32,a,v)
#define out_le16(a,v) out_arch(w,le16,a,v)
+#define in_le64(a) in_arch(q,le64,a)
#define in_le32(a) in_arch(l,le32,a)
#define in_le16(a) in_arch(w,le16,a)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v7 5/5] ARMv8/ls2100a_emu: Add LS2100A emulator and simulator board support
LS2100A is an ARMv8 implementation. This adds board support for emulator
and simulator:
Two DDR controllers
UART2 is used as the console
IFC timing is tightened for speedy booting
Support DDR3 and DDR4 as separated targets
Management Complex (MC) is enabled
Signed-off-by: York Sun york...@freescale.com
Signed-off-by: Arnab Basu arnab.b...@freescale.com
Signed-off-by: J. German Rivera german.riv...@freescale.com
Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com
---
v7: no change
v6: no change
v5: no change
v4: no change
v3: Add support for DDR4 target and simulator target
Squash Manage complex patch (previous 5/5) into this
Reserve last 512MB memory for MC use
Change MC firmware location in NOR flash
Fix UART clock source speed
Update IFC address mux
Use generic board
Disable DDR memory beyound 39 physical address space due to Linux
limitation
board/freescale/ls2100a/Makefile |8 ++
board/freescale/ls2100a/README | 16 +++
board/freescale/{t4rdb = ls2100a}/ddr.c | 89 +---
board/freescale/ls2100a/ddr.h| 57
board/freescale/ls2100a/ls2100a.c| 100 +
boards.cfg |3 +
include/configs/ls2100a_common.h | 226 ++
include/configs/ls2100a_emu.h| 19 +++
include/configs/ls2100a_simu.h | 16 +++
9 files changed, 518 insertions(+), 16 deletions(-)
create mode 100644 board/freescale/ls2100a/Makefile
create mode 100644 board/freescale/ls2100a/README
copy board/freescale/{t4rdb = ls2100a}/ddr.c (53%)
create mode 100644 board/freescale/ls2100a/ddr.h
create mode 100644 board/freescale/ls2100a/ls2100a.c
create mode 100644 include/configs/ls2100a_common.h
create mode 100644 include/configs/ls2100a_emu.h
create mode 100644 include/configs/ls2100a_simu.h
diff --git a/board/freescale/ls2100a/Makefile b/board/freescale/ls2100a/Makefile
new file mode 100644
index 000..c8da338
--- /dev/null
+++ b/board/freescale/ls2100a/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright 2014 Freescale Semiconductor
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += ls2100a.o
+obj-y += ddr.o
diff --git a/board/freescale/ls2100a/README b/board/freescale/ls2100a/README
new file mode 100644
index 000..9a8a618
--- /dev/null
+++ b/board/freescale/ls2100a/README
@@ -0,0 +1,16 @@
+Freescale ls2100a_emu
+
+This is a emulator target with limited peripherals.
+
+Memory map from core's view
+
+0x00__ .. 0x00_000F_ Boot Rom
+0x00_0100_ .. 0x00_0FFF_ CCSR
+0x00_1800_ .. 0x00_181F_ OCRAM
+0x00_3000_ .. 0x00_3FFF_ IFC region #1
+0x00_8000_ .. 0x00__ DDR region #1
+0x05_1000_ .. 0x05__ IFC region #2
+0x80_8000_ .. 0xFF__ DDR region #2
+
+Other addresses are either reserved, or not used directly by u-boot.
+This list should be updated when more addresses are used.
diff --git a/board/freescale/t4rdb/ddr.c b/board/freescale/ls2100a/ddr.c
similarity index 53%
copy from board/freescale/t4rdb/ddr.c
copy to board/freescale/ls2100a/ddr.c
index 5a43c1b..257bc16 100644
--- a/board/freescale/t4rdb/ddr.c
+++ b/board/freescale/ls2100a/ddr.c
@@ -5,12 +5,8 @@
*/
#include common.h
-#include i2c.h
-#include hwconfig.h
-#include asm/mmu.h
#include fsl_ddr_sdram.h
#include fsl_ddr_dimm_params.h
-#include asm/fsl_law.h
#include ddr.h
DECLARE_GLOBAL_DATA_PTR;
@@ -22,7 +18,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
const struct board_specific_parameters *pbsp, *pbsp_highest = NULL;
ulong ddr_freq;
- if (ctrl_num 2) {
+ if (ctrl_num 3) {
printf(Not supported controller number %d\n, ctrl_num);
return;
}
@@ -39,7 +35,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
pbsp = udimms[0];
- /* Get clk_adjust, cpo, write_data_delay,2T, according to the board ddr
+ /* Get clk_adjust, wrlvl_start, wrlvl_ctl, according to the board ddr
* freqency and n_banks specified in board_specific_parameters table.
*/
ddr_freq = get_ddr_freq(0) / 100;
@@ -59,8 +55,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
}
if (pbsp_highest) {
- printf(Error: board specific timing not found for data\n
- rate %lu MT/s\n
+ printf(Error: board specific timing not found for data rate
%lu MT/s\n
Trying to use the highest speed (%u) parameters\n,
ddr_freq, pbsp_highest-datarate_mhz_high);
popts-clk_adjust = pbsp_highest-clk_adjust;
@@ -72,8 +67,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
}
found:
debug(Found timing match: n_ranks %d, data rate %d, rank_gb %d\n
- \tclk_adjust %d, wrlvl_start %d, wrlvl_ctrl_2 0x%x,\n
-
[U-Boot] [Patch v7 4/5] armv8/fsl-lsch3: Add support to load and start MC Firmware
From: J. German Rivera german.riv...@freescale.com
Adding support to load and start the Layerscape Management Complex (MC)
firmware. First, the MC GCR register is set to 0 to reset all cores. MC
firmware and DPL images are copied from their location in NOR flash to
DDR. MC registers are updated with the location of these images.
Deasserting the reset bit of MC GCR register releases core 0 to run.
Core 1 will be released by MC firmware. Stop bits are not touched for
this step. U-boot waits for MC until it boots up. In case of a failure,
device tree is updated accordingly. The MC firmware image uses FIT format.
Signed-off-by: J. German Rivera german.riv...@freescale.com
Signed-off-by: York Sun york...@freescale.com
Signed-off-by: Lijun Pan lijun@freescale.com
Signed-off-by: Shruti Kanetkar shr...@freescale.com
---
Change log
v7: no change
v6: no change
v5: Fix a typo in commit message supoort
Fix variable declaration cause by squashing patches
v4: no change
v3: Add error detection and update device tree if failure
Revise loading address to avoid overlap
Use FIT image for the firmware
Remove blank lines at the end of files
README | 27
arch/arm/cpu/armv8/fsl-lsch3/cpu.c | 11 ++
drivers/net/Makefile |1 +
drivers/net/fsl_mc/Makefile|8 ++
drivers/net/fsl_mc/mc.c| 272
include/fdt_support.h | 14 +-
include/fsl_mc.h | 59
7 files changed, 389 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/fsl_mc/Makefile
create mode 100644 drivers/net/fsl_mc/mc.c
create mode 100644 include/fsl_mc.h
diff --git a/README b/README
index 7129df8..9470c30 100644
--- a/README
+++ b/README
@@ -4653,6 +4653,33 @@ within that device.
window-master inbound window-master LAW-the ucode address in
master's memory space.
+Freescale Layerscape Management Complex Firmware Support:
+-
+The Freescale Layerscape Management Complex (MC) supports the loading of
+firmware.
+This firmware often needs to be loaded during U-Boot booting, so macros
+are used to identify the storage device (NOR flash, SPI, etc) and the address
+within that device.
+
+- CONFIG_FSL_MC_ENET
+ Enable the MC driver for Layerscape SoCs.
+
+- CONFIG_SYS_LS_MC_FW_ADDR
+ The address in the storage device where the firmware is located. The
+ meaning of this address depends on which CONFIG_SYS_LS_MC_FW_IN_xxx
macro
+ is also specified.
+
+- CONFIG_SYS_LS_MC_FW_LENGTH
+ The maximum possible size of the firmware. The firmware binary format
+ has a field that specifies the actual size of the firmware, but it
+ might not be possible to read any part of the firmware unless some
+ local storage is allocated to hold the entire firmware first.
+
+- CONFIG_SYS_LS_MC_FW_IN_NOR
+ Specifies that MC firmware is located in NOR flash, mapped as
+ normal addressable memory via the LBC. CONFIG_SYS_LS_MC_FW_ADDR is the
+ virtual address in NOR flash.
+
Building the Software:
==
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
index 46965f0..c129d03 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
@@ -12,6 +12,7 @@
#include asm/arch-fsl-lsch3/immap_lsch3.h
#include cpu.h
#include speed.h
+#include fsl_mc.h
DECLARE_GLOBAL_DATA_PTR;
@@ -423,3 +424,13 @@ int print_cpuinfo(void)
return 0;
}
#endif
+
+int cpu_eth_init(bd_t *bis)
+{
+ int error = 0;
+
+#ifdef CONFIG_FSL_MC_ENET
+ error = mc_init(bis);
+#endif
+ return error;
+}
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6005f7e..6226cb2 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o xilinx_ll_temac_mdio.o \
xilinx_ll_temac_fifo.o xilinx_ll_temac_sdma.o
obj-$(CONFIG_ZYNQ_GEM) += zynq_gem.o
+obj-$(CONFIG_FSL_MC_ENET) += fsl_mc/
diff --git a/drivers/net/fsl_mc/Makefile b/drivers/net/fsl_mc/Makefile
new file mode 100644
index 000..4834086
--- /dev/null
+++ b/drivers/net/fsl_mc/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+# Layerscape MC driver
+obj-y += mc.o
diff --git a/drivers/net/fsl_mc/mc.c b/drivers/net/fsl_mc/mc.c
new file mode 100644
index 000..056424b
--- /dev/null
+++ b/drivers/net/fsl_mc/mc.c
@@ -0,0 +1,272 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include errno.h
+#include asm/io.h
+#include fsl_mc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+static int mc_boot_status;
+
+/**
+ * Copying MC firmware or DPL image to DDR
+ */
+static int mc_copy_image(const char
Re: [U-Boot] [PATCH] Avoid using gawk-specific strtonum()
Hi Tom,
On 18 June 2014 11:26, Tom Rini tr...@ti.com wrote:
On Wed, Jun 18, 2014 at 12:01:12PM +0200, Wolfgang Denk wrote:
Dear Simon,
In message 1403071815-32055-1-git-send-email-...@chromium.org you wrote:
We need to subtract two hex numbers. Avoid using strtonum() by doing the
subtraction in bc with a suitable input base.
Signed-off-by: Simon Glass s...@chromium.org
Reported-by: Vasili Galka vvv...@gmail.com
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 24d9687..bb2f615 100644
--- a/Makefile
+++ b/Makefile
@@ -788,7 +788,8 @@ OBJCOPYFLAGS_u-boot.bin := -O binary
binary_size_check: u-boot.bin System.map FORCE
@file_size=`stat -c %s u-boot.bin` ; \
map_size=$(shell cat System.map | \
- awk '/_image_copy_start/ {start = $$1} /_image_binary_end/
{end = $$1} END {if (start != end != ) print strtonum(0x end) -
strtonum(0x start)}'); \
+ awk '/_image_copy_start/ {start = $$1} /_image_binary_end/
{end = $$1} END {if (start != end != ) print ibase=16;
toupper(end) - toupper(start)}' \
+ | bc); \
I think instead of introducing yet another tool dependency this could
be rewritten to use just bash:
awk '/_image_copy_start/ {start = $1}
/_image_binary_end/ {end = $1}
END { if (start != end != )
print printf %d $$((0x end - 0x start ))
}' |
bash
But now we're forcing bash. Jeroen, since you most often run into the
but now you've introduced a Linux'ism problems, bash or bc or
something else for a portable hex to decimal conversion? Or since so
much of U-Boot is hex when talking numbers, maybe we should just make
the echos say ... size of 0x$foo expected 0x$bar ?
That's why I didn't use bash - I recall hitting that problem before
but it might have been dtc rather than U-Boot. I thought bc might be
safer. But let me know and I will respin.
Tom, the problem is that I need to subtract the two values to get an
answer for the size.
Regards
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: emif4: wait for CM_DLL_READYST to be set
The code intends for the CM_DLL_READYST to be set, but actually polls till any bit is set since the logical AND is used instead of the bitwise one is used. Fix it. cc: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- and yes this also fixes a clang warning --- arch/arm/cpu/armv7/am33xx/emif4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/am33xx/emif4.c b/arch/arm/cpu/armv7/am33xx/emif4.c index a7a3e88..8b7527c 100644 --- a/arch/arm/cpu/armv7/am33xx/emif4.c +++ b/arch/arm/cpu/armv7/am33xx/emif4.c @@ -115,7 +115,7 @@ void config_ddr(unsigned int pll, const struct ctrl_ioregs *ioregs, #endif #ifdef CONFIG_AM43XX writel(readl(cm_device-cm_dll_ctrl) ~0x1, cm_device-cm_dll_ctrl); - while ((readl(cm_device-cm_dll_ctrl) CM_DLL_READYST) == 0) + while ((readl(cm_device-cm_dll_ctrl) CM_DLL_READYST) == 0) ; writel(0x8000, ddrctrl-ddrioctrl); -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Avoid using gawk-specific strtonum()
On Wed, Jun 18, 2014 at 12:14:14PM -0700, Simon Glass wrote:
Hi Tom,
On 18 June 2014 11:26, Tom Rini tr...@ti.com wrote:
On Wed, Jun 18, 2014 at 12:01:12PM +0200, Wolfgang Denk wrote:
Dear Simon,
In message 1403071815-32055-1-git-send-email-...@chromium.org you wrote:
We need to subtract two hex numbers. Avoid using strtonum() by doing the
subtraction in bc with a suitable input base.
Signed-off-by: Simon Glass s...@chromium.org
Reported-by: Vasili Galka vvv...@gmail.com
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 24d9687..bb2f615 100644
--- a/Makefile
+++ b/Makefile
@@ -788,7 +788,8 @@ OBJCOPYFLAGS_u-boot.bin := -O binary
binary_size_check: u-boot.bin System.map FORCE
@file_size=`stat -c %s u-boot.bin` ; \
map_size=$(shell cat System.map | \
- awk '/_image_copy_start/ {start = $$1} /_image_binary_end/
{end = $$1} END {if (start != end != ) print strtonum(0x end)
- strtonum(0x start)}'); \
+ awk '/_image_copy_start/ {start = $$1} /_image_binary_end/
{end = $$1} END {if (start != end != ) print ibase=16;
toupper(end) - toupper(start)}' \
+ | bc); \
I think instead of introducing yet another tool dependency this could
be rewritten to use just bash:
awk '/_image_copy_start/ {start = $1}
/_image_binary_end/ {end = $1}
END { if (start != end != )
print printf %d $$((0x end - 0x start ))
}' |
bash
But now we're forcing bash. Jeroen, since you most often run into the
but now you've introduced a Linux'ism problems, bash or bc or
something else for a portable hex to decimal conversion? Or since so
much of U-Boot is hex when talking numbers, maybe we should just make
the echos say ... size of 0x$foo expected 0x$bar ?
That's why I didn't use bash - I recall hitting that problem before
but it might have been dtc rather than U-Boot. I thought bc might be
safer. But let me know and I will respin.
Given Jeroen's answer, we'll keep to bc.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.07-rc3 released
On Thu, Jun 12, 2014 at 09:28:20AM +0200, Lukasz Majewski wrote: Hi Tom, Hey all, I've pushed v2014.07-rc3 out to the repository and tarballs should exist soon. We're getting better on the syncing up of things out of patchwork and I know there's still a few items to go (and some bigger ideas I need to come back to commenting on). As always, if anything is broken please speak up. There is a problem with Trats2 board when we have switched to the generic board. Przemek has already prepared fix for this: [U-Boot] trats/trats2: exynos_power_init: return 0 if no battery detected. http://patchwork.ozlabs.org/patch/357957/ Tom, could you apply it to ML? I expect this to come via u-boot-samsung - u-boot-arm right now. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] PMIC: MAX77686: fix invalid bus check
Since p-bus is unsigned checking for negative values
is optimized away. Since bus is already used as an argument
use tmp. While at it, don't declare variables in the middle
of a function.
cc: Rajeshwari Shinde rajeshwar...@samsung.com
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
drivers/power/pmic/pmic_max77686.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index d4c430e..df1fd91 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -210,6 +210,10 @@ int pmic_init(unsigned char bus)
{
static const char name[] = MAX77686_PMIC;
struct pmic *p = pmic_alloc();
+#ifdef CONFIG_OF_CONTROL
+ const void *blob = gd-fdt_blob;
+ int node, parent, tmp;
+#endif
if (!p) {
printf(%s: POWER allocation error!\n, __func__);
@@ -217,9 +221,6 @@ int pmic_init(unsigned char bus)
}
#ifdef CONFIG_OF_CONTROL
- const void *blob = gd-fdt_blob;
- int node, parent;
-
node = fdtdec_next_compatible(blob, 0, COMPAT_MAXIM_MAX77686_PMIC);
if (node 0) {
debug(PMIC: No node for PMIC Chip in device tree\n);
@@ -233,11 +234,13 @@ int pmic_init(unsigned char bus)
return -1;
}
- p-bus = i2c_get_bus_num_fdt(parent);
- if (p-bus 0) {
+ /* tmp since p-bus is unsigned */
+ tmp = i2c_get_bus_num_fdt(parent);
+ if (tmp 0) {
debug(%s: Cannot find I2C bus\n, __func__);
return -1;
}
+ p-bus = tmp;
p-hw.i2c.addr = fdtdec_get_int(blob, node, reg, 9);
#else
p-bus = bus;
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Avoid using gawk-specific strtonum()
Tom Rini tr...@ti.com writes:
On Wed, Jun 18, 2014 at 12:01:12PM +0200, Wolfgang Denk wrote:
Dear Simon,
In message 1403071815-32055-1-git-send-email-...@chromium.org you wrote:
We need to subtract two hex numbers. Avoid using strtonum() by doing the
subtraction in bc with a suitable input base.
Signed-off-by: Simon Glass s...@chromium.org
Reported-by: Vasili Galka vvv...@gmail.com
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 24d9687..bb2f615 100644
--- a/Makefile
+++ b/Makefile
@@ -788,7 +788,8 @@ OBJCOPYFLAGS_u-boot.bin := -O binary
binary_size_check: u-boot.bin System.map FORCE
@file_size=`stat -c %s u-boot.bin` ; \
map_size=$(shell cat System.map | \
- awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print strtonum(0x end) -
strtonum(0x start)}'); \
+ awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end
= $$1} END {if (start != end != ) print ibase=16; toupper(end)
- toupper(start)}' \
+ | bc); \
I think instead of introducing yet another tool dependency this could
be rewritten to use just bash:
awk '/_image_copy_start/ {start = $1}
/_image_binary_end/ {end = $1}
END { if (start != end != )
print printf %d $$((0x end - 0x start ))
}' |
bash
But now we're forcing bash.
Arithmetic expansion including hex constants is POSIX shell:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
--
Måns Rullgård
m...@mansr.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] vcma9/lowlevel_init.S: trivial: terminate comment
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- board/mpl/vcma9/lowlevel_init.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/mpl/vcma9/lowlevel_init.S b/board/mpl/vcma9/lowlevel_init.S index cca9c0c..ee9b7a9 100644 --- a/board/mpl/vcma9/lowlevel_init.S +++ b/board/mpl/vcma9/lowlevel_init.S @@ -229,7 +229,7 @@ lowlevel_init: bne 0b /* PLD access is now possible */ - /* r3 = SDRAMDATA + /* r3 = SDRAMDATA */ /* r13 = pointer to MEM controller regs */ ldr r1, =PLD_BASE mov r4, #SDRAMENTRY_SIZE -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tpm: don't use unneeded double brackets
clang is tempted to inteprete such a condition as a assignment
as well. Since it isn't don't use double brackets.
cc: Tom Wai-Hong Tam waih...@chromium.org
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
drivers/tpm/tpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tpm/tpm.c b/drivers/tpm/tpm.c
index b657334..bc0f964 100644
--- a/drivers/tpm/tpm.c
+++ b/drivers/tpm/tpm.c
@@ -411,7 +411,7 @@ static ssize_t tpm_transmit(const unsigned char *buf,
size_t bufsiz)
goto out_recv;
}
- if ((status == chip-vendor.req_canceled)) {
+ if (status == chip-vendor.req_canceled) {
error(Operation Canceled\n);
rc = -ECANCELED;
goto out;
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/2] lib, fdt: move fdtdec_get_int() out of lib/fdtdec.c
On Mon, Jun 16, 2014 at 09:58:39AM +0200, Heiko Schocher wrote: move fdtdec_get_int() out of lib/fdtdec.c into lib/fdtdec_common.c as this function is also used, if CONFIG_OF_CONTROL is not used. Poped up on the ids8313 board using signed FIT images, and activating CONFIG_SYS_GENERIC_BOARD. Without this patch it shows on boot: [snip] diff --git a/lib/Makefile b/lib/Makefile index 377ab13..dd87ee2 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -23,6 +23,13 @@ obj-$(CONFIG_USB_TTY) += circbuf.o obj-y += crc7.o obj-y += crc8.o obj-y += crc16.o +ifdef CONFIG_FIT +obj-y += fdtdec_common.o +else +ifdef CONFIG_OF_CONTROL +obj-y += fdtdec_common.o +endif +endif OK, but why not: obj-$(CONFIG_FIT) += fdtdec_common.o obj-$(CONFIG_OF_CONTROL) += fdtdec_common.o Since we filter out duplicates I would swear. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14
On Wed, 2014-06-18 at 09:55 +0200, Heiko Schocher wrote:
Hello Scott,
Am 17.06.2014 17:54, schrieb Scott Wood:
On Tue, 2014-06-17 at 09:15 +0200, Heiko Schocher wrote:
- Following Code in drivers/mtd/nand/nand_base.c nand_do_write_ops()
adapted for U-Boot:
+#ifndef __UBOOT__
/* Reject writes, which are not page aligned */
if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
+else
+ /* Reject writes, which are not page aligned */
+ if (NOTALIGNED(to)) {
+endif
This sort of ifdeffing is a bad idea -- if a larger number of lines are
ifdeffed, to avoid context conflicts, subsequent merges can silently put
updates into the non-U-Boot section that are needed in the U-Boot
section.
Yes, in general I agree, this is a bad idea. But I introduced it
here to get all differences between U-Boot and Linux marked with
the _UBOOT_ define, so a future sync with linux should be easier ...
Again, I don't think having the differences be marked with #ifdef
__UBOOT__ is a good thing.
Plus, it impairs readability, and in this case breaks text-editor
brace-matching.
Yes, could be fixed, see below.
Plus plus, that line has been that way in Linux since 2006 -- why is it
being touched at all? Did you merge in changes from the previous mtd
sync, or did you just copy the new files over and then try to fix
resulting problems? (answered below)
Yes. Above Code is a good example. In Linux this piece of code looks like:
-
static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
struct mtd_oob_ops *ops)
[...]
ops-retlen = 0;
if (!writelen)
return 0;
/* Reject writes, which are not page aligned */
if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
pr_notice(%s: attempt to write non page aligned data\n,
__func__);
return -EINVAL;
}
column = to (mtd-writesize - 1);
-
in current U-Boot:
-
static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
struct mtd_oob_ops *ops)
[...]
ops-retlen = 0;
if (!writelen)
return 0;
column = to (mtd-writesize - 1);
-
Why is this if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
missing in U-Boot? Do we allow not aligned writes in U-Boot?
The block skipping accessors have their own enforcement of non-aligned
accesses. Other than that, non-aligned accesses should work.
If so, we should have documented this, and best place for it,
I think, would be with a comment in the source code...
You could look at the commit history where the code was altered, though
in some cases a comment may be warranted. I don't think that comment
should take the form of the Linux code under an ifndef.
Above Code is a good example for that. Linux has this code
since 2006, why has U-Boot not this code?
It was removed by commit f9a5254111a6be2a39464f65a96f4fc2305e3c76, which
moved the check into the block-skipping accessors.
history to see what Linux version corresponded to the last mtd sync, and
generate a diff relative to that.
I think, we should have the linux code as the reference, and on top
of this, we should add our U-Boot changes ... Thats the reason
for the git tree [1].
One of the strengths of version control is the ability to do three-way
merges, rather than throw away the downstream code and reassemble it
from scratch.
What does #ifndef __UBOOT__ tell you that a diff between the U-Boot and
Linux files, as of the SHA1 that was last merged into U-Boot, doesn't
tell you?
There we have the simple copy from linux patch [2]. It overwrites
the U-Boot specific changes, yes, but only in an intermediate step
in this git tree ... (Maybe I should add in the commit message, that
this is a simple copy from linux sources)
Then a U-Boot specifc patch [3], which introduces again hopefully
all U-Boot specific changes... so *all* U-Boot specific changs are
documented. At last a seperate licencse file patch [4] added which
changes the license text.
My hope was, that future linux mtd syncs could look like:
a) copy new linux source files to u-boot tree [1] (make a new branch
go back to commit [2] ... and copy new files from linux)
(commit this, to have all linux changes since last sync
with linux documented)
b) apply [3] and fix problems
All U-Boot changes documented
c) apply [4] and fix problems
d) add newly added U-Boot specific patches
(mark them with _UBOOT_ define if they are not yet marked with it)
(maybe squash them to step b ?)
- new git tree ready
e) squash all patches into one patch and send it to mainline ...
so the mainline patch has only new changes with all U-Boot
specific changes.
If you take over as NAND custodian, you can
Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14
On Wed, Jun 18, 2014 at 04:24:39PM -0500, Scott Wood wrote: On Wed, 2014-06-18 at 09:55 +0200, Heiko Schocher wrote: Hello Scott, [snip] history to see what Linux version corresponded to the last mtd sync, and generate a diff relative to that. I think, we should have the linux code as the reference, and on top of this, we should add our U-Boot changes ... Thats the reason for the git tree [1]. One of the strengths of version control is the ability to do three-way merges, rather than throw away the downstream code and reassemble it from scratch. Indeed. [snip] What does #ifndef __UBOOT__ tell you that a diff between the U-Boot and Linux files, as of the SHA1 that was last merged into U-Boot, doesn't tell you? There we have the simple copy from linux patch [2]. It overwrites the U-Boot specific changes, yes, but only in an intermediate step in this git tree ... (Maybe I should add in the commit message, that this is a simple copy from linux sources) Then a U-Boot specifc patch [3], which introduces again hopefully all U-Boot specific changes... so *all* U-Boot specific changs are documented. At last a seperate licencse file patch [4] added which changes the license text. My hope was, that future linux mtd syncs could look like: a) copy new linux source files to u-boot tree [1] (make a new branch go back to commit [2] ... and copy new files from linux) (commit this, to have all linux changes since last sync with linux documented) b) apply [3] and fix problems All U-Boot changes documented c) apply [4] and fix problems d) add newly added U-Boot specific patches (mark them with _UBOOT_ define if they are not yet marked with it) (maybe squash them to step b ?) - new git tree ready e) squash all patches into one patch and send it to mainline ... so the mainline patch has only new changes with all U-Boot specific changes. If you take over as NAND custodian, you can of course do the updates as you please (unless Tom or Wolfgang disagree), but until then I insist on doing a proper merge, and not littering the code with #ifndef __UBOOT__. Thats sounds easy ... and you have all linux and all U-Boot changes visible and documented ... I must admit, I did not tried your proposal to look into the linux changes since the last mtd sync ... but that sounds the more tricky way to get this sync, as the history can be long ... and shouldn;t be the result the same? Why does the length of the history matter? I'm not asking you to go patch by patch. Just take a diff between the SHA1 of last merge and the SHA1 you want to merge now, and apply that patch. But it's not even that hard to do so! git format-patch -o mtd-resync v3.7..v3.14 drivers/mtd/nand will give you only the relevant patches, and they should mostly apply, and then you can squash them after the fact. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] trats/trats2: exynos_power_init: return 0 if no battery detected.
On 10/06/14 23:55, Przemyslaw Marczak wrote: Generic board support is now enabled for Exynos 4, and if any init function returns an error then the init process is stopped. This makes a boot issue on the Trats and Trats2 devices. If the device is supplied by USB cable or an external power supply then it can't boot because function exynos_power_init returns an error. Now this function returns 0 if battery is not connected. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Piotr Wilczek p.wilc...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- board/samsung/trats/trats.c | 2 +- board/samsung/trats2/trats2.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.07-rc3 released
On 19/06/14 05:08, Tom Rini wrote: On Thu, Jun 12, 2014 at 09:28:20AM +0200, Lukasz Majewski wrote: Hi Tom, Hey all, I've pushed v2014.07-rc3 out to the repository and tarballs should exist soon. We're getting better on the syncing up of things out of patchwork and I know there's still a few items to go (and some bigger ideas I need to come back to commenting on). As always, if anything is broken please speak up. There is a problem with Trats2 board when we have switched to the generic board. Przemek has already prepared fix for this: [U-Boot] trats/trats2: exynos_power_init: return 0 if no battery detected. http://patchwork.ozlabs.org/patch/357957/ Tom, could you apply it to ML? I expect this to come via u-boot-samsung - u-boot-arm right now. I picked up this patch. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/11] board:samsung: check the mmc boot device and init the right mmc driver.
On 18/06/14 19:47, Przemyslaw Marczak wrote:
Hello Minkyu,
On 06/18/2014 08:30 AM, Minkyu Kang wrote:
Dear Przemyslaw Marczak,
On 12/06/14 18:46, Przemyslaw Marczak wrote:
It is possible to boot from a few media devices, especially using a micro
SD or eMMC slots. In this situation, boot device should be registered
as block device 0 in the MMC framework, because CONFIG_SYS_MMC_ENV_DEV
is usually set to 0 in the most config cases.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Piotr Wilczek p.wilc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
board/samsung/common/board.c | 32
include/samsung/misc.h | 5 +
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..2970340 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -25,6 +25,8 @@
#include lcd.h
#include samsung/misc.h
+static int bootmode;
+
DECLARE_GLOBAL_DATA_PTR;
int __exynos_early_init_f(void)
@@ -243,19 +245,33 @@ int board_eth_init(bd_t *bis)
int board_mmc_init(bd_t *bis)
{
int ret;
+struct exynos4_power *pwr = (struct exynos4_power *)
+samsung_get_base_power();
Hm, no. This file is samsung common not only for exynos4.
Although this code will not be made any problems for other SoCs (because
om_stat is always first item of power), it looks weird.
I think you can make new function for getting boot mode.
Yes, this was bad. What about that:
# unsigned int om_stat = samsung_get_base_power();
#
# bootmode = BOOT_MODE(readl(om_stat));
or maybe just
# bootmode = BOOT_MODE(readl(samsung_get_base_power()));
looks good to me. both of them.
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] includes: move openssl headers to include/u-boot
Hi, On 18 June 2014 11:12, Jeroen Hofstee jer...@myspectrum.nl wrote: On di, 2014-06-17 at 22:25 -0700, Simon Glass wrote: Hi Jeroen, On 12 June 2014 13:27, Jeroen Hofstee jer...@myspectrum.nl wrote: commit 18b06652cd tools: include u-boot version of sha256.h unconditionally forced the sha256.h from u-boot to be used for tools instead of the host version. This is fragile though as it will also include the host version. Therefore move it to include/u-boot to join u-boot/md5.h etc which were renamed for the same reason. cc: Simon Glass s...@chromium.org Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl This seems like a much better solution. But I think you should keep the sort order - so u-boot/xxx should go after asm/xxx in the #includes I think. I considered it, but e.g. common/image.c contains this before this patch: #include u-boot/md5.h #include sha1.h #include asm/errno.h #include asm/io.h While I can rearrange them, I think it should be a separate patch, since it is not sorted in the first place. Furthermore if possible I would prefer this commit to go into the current release and hence want to keep it as short as possible. What I hadn't realized with the original patch is that we don't replace the header but include them all. OK with me, will await the follow-up patch. Acked-by: Simon Glass s...@chromium.org Also I built it for everything and saw no regressions. ./tools/buildman/buildman -b try-jer -s Summary of 2 commits for 1198 boards (32 threads, 1 job per thread) 01: Merge branch 'master' of git://git.denx.de/u-boot-mmc blackfin: + bf609-ezkit m68k: + M5249EVB M54418TWR_serial_rmii M5253DEMO TASREG M5235EVB M54418TWR_nand_mii M54418TWR_nand_rmii_lowfreq M54418TWR_nand_rmii M54418TWR M5253EVBE M5235EVB_Flash32 M54418TWR_serial_mii M5272C3 powerpc: + neo io dlvision-10g P1022DS_36BIT iocon kilauea socrates O2DNT2_RAMBOOT rainier NSCU MPC832XEMDS_HOST_33 mcc200_highboot_SDRAM quantum sh: + rsk7269 rsk7264 rsk7203 nios2: + nios2-generic PCI5441 PK1C20 microblaze: + microblaze-generic openrisc: + openrisc-generic arm: + highbank lager_nor integratorcp_cm920t omap4_sdp4430 sama5d3_xplained_mmc mx53loco omap4_panda duovero Cubietruck lager k2hk_evm koelsch_nor koelsch trats2 02: includes: move openssl headers to include/u-boot Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] socfpga: Relocate arch common functions away from board
On Thu, 2014-06-12 at 11:02 +0200, Detlev Zundel wrote: Hi Chin, To move the arch common function away from board folder to arch/arm/cpu/armv7/socfpga folder. Its to avoid code duplication for other non Altera dev kit which is using socfpga device. This looks like a good first step. I'm sure that followup patches are neccessary to clean up the division between generic and board specific patches, but we'll see this once other boards (like socrates) are added. Pavel, can you rebase your intended change on this? Thanks! Acked-by: Detlev Zundel d...@denx.de Thanks Detlev. Hi Albert, Can you help to apply this patch? Thanks Chin Liang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] nand/denali: Adding Denali NAND driver support
On Tue, 2014-06-10 at 21:45 +0900, Masahiro Yamada wrote: Hi Chin, On Tue, 10 Jun 2014 00:42:19 -0500 Chin Liang See cl...@altera.com wrote: To add the Denali NAND driver support into U-Boot. It required information such as register base address from configuration header file within include/configs folder. Signed-off-by: Chin Liang See cl...@altera.com Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com Cc: David Woodhouse david.woodho...@intel.com Cc: Brian Norris computersforpe...@gmail.com Cc: Scott Wood scottw...@freescale.com Cc: Masahiro Yamada yamad...@jp.panasonic.com Thanks for posting v8 when you are busy! Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Tested-by: Masahiro Yamada yamad...@jp.panasonic.com Scott, Could you apply this patch please? Thanks Masahiro Hi Scott / Tom, Can you help to apply this patch? Thanks Chin Liang Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_fat: use get_device_and_partition() during env save and load
Hi, Stephen On 6/17/2014 3:51 AM, Stephen Warren wrote: On 06/16/2014 02:14 AM, Josh Wu wrote: Use get_device_and_partition() is better since: 1. It will call the device initialize function internally. So we can remove the mmc intialization code to save many lines. 2. It is used by fatls/fatload/fatwrite. So saveenv load env should use it too. 3. It can parse the D:P, D, D:, D:auto string to get correct device and partition information by run-time. Also we remove the FAT_ENV_DEVICE and FAT_ENV_PART. We use a string: FAT_ENV_DEVICE_AND_PART. For at91sam9m10g45ek, it is 0. That means use device 0 and if: a)device 0 has no partition table, use the whole device as a FAT file system. b)device 0 has partittion table, use the partition #1. Refer to the commit: 10a37fd7a4 for details of device partition string. (briefly) Reviewed-by: Stephen Warren swar...@nvidia.com Questions though: * Can we delete the implementation of fat_register_device() now it's not used? If it is used, shouldn't the other uses be converted in a similar fashion? currently It still be used by SPL (common/spl/spl_fat.c) and three board's firmware auto_update. For SPL, I think they need use simpler fat functions. My first thought is: to split the get_device_and_partition() into smaller parts(dev:part string parser, get_device, and register partition ). Then the SPL can use the the register partition code. For board's auto_update case, I think it is same as above. But above two changes (not do yet) will not included in this patch series. * Should the new config variable FAT_ENV_DEVICE_AND_PART be documented in README? It seems all CONFIG_ENV_IS_IN_FAT related variables are not documented. I will send a v2 version of this patch and add this. The CONFIG_ENV_IS_IN_FAT will be put below of CONFIG_ENV_IS_IN_UBI in README file. Best Regards, Josh Wu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/2] lib, fdt: move fdtdec_get_int() out of lib/fdtdec.c
Hello Tom, Am 18.06.2014 23:09, schrieb Tom Rini: On Mon, Jun 16, 2014 at 09:58:39AM +0200, Heiko Schocher wrote: move fdtdec_get_int() out of lib/fdtdec.c into lib/fdtdec_common.c as this function is also used, if CONFIG_OF_CONTROL is not used. Poped up on the ids8313 board using signed FIT images, and activating CONFIG_SYS_GENERIC_BOARD. Without this patch it shows on boot: [snip] diff --git a/lib/Makefile b/lib/Makefile index 377ab13..dd87ee2 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -23,6 +23,13 @@ obj-$(CONFIG_USB_TTY) += circbuf.o obj-y += crc7.o obj-y += crc8.o obj-y += crc16.o +ifdef CONFIG_FIT +obj-y += fdtdec_common.o +else +ifdef CONFIG_OF_CONTROL +obj-y += fdtdec_common.o +endif +endif OK, but why not: obj-$(CONFIG_FIT) += fdtdec_common.o obj-$(CONFIG_OF_CONTROL) += fdtdec_common.o Since we filter out duplicates I would swear. If so, I change this. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
