[U-Boot] [PATCH 2/2] arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD
Add CONFIG_SYS_GENERIC_BOARD to enable generic board for kzm9g. See doc/README.generic-board Signed-off-by: Tetsuyuki Kobayashi --- include/configs/kzm9g.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h index 4d11c7d..5a13ad1 100644 --- a/include/configs/kzm9g.h +++ b/include/configs/kzm9g.h @@ -15,6 +15,7 @@ #define CONFIG_KZM_A9_GT #define CONFIG_RMOBILE_BOARD_STRING"KMC KZM-A9-GT" #define CONFIG_MACH_TYPE MACH_TYPE_KZM9G +#define CONFIG_SYS_GENERIC_BOARD #include -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] i2c: sh_i2c: bugfix: i2c probe command does now work
This is regression of commit 2035d77d i2c: sh_i2c: Update to new CONFIG_SYS_I2C
framework.
Before commit 2035d77d, i2c probe command works properly on kzm9g board.
KZM-A9-GT# i2c probe
Valid chip addresses: 0C 12 1D 32 39 3D 40 60
After commit 2035d77d, i2c probe command does not work.
KZM-A9-GT# i2c probe
Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12
13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C
2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46
47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A
7B 7C 7D 7E 7F
sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does
not read device at all. This patch changes read length to 1.
Signed-off-by: Tetsuyuki Kobayashi
---
drivers/i2c/sh_i2c.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
index cc19100..264c2e6 100644
--- a/drivers/i2c/sh_i2c.c
+++ b/drivers/i2c/sh_i2c.c
@@ -269,7 +269,7 @@ static int sh_i2c_write(struct i2c_adapter *adap, uint8_t
chip, uint addr,
static int
sh_i2c_probe(struct i2c_adapter *adap, u8 dev)
{
- return sh_i2c_read(adap, dev, 0, 0, NULL, 0);
+ return sh_i2c_read(adap, dev, 0, 0, NULL, 1);
}
static unsigned int sh_i2c_set_bus_speed(struct i2c_adapter *adap,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] i2c: sh_i2c: bugfix: i2c probe command does now work
Hello, I found i2c probe command bug on kzm9g board and fixed it. I know it is the last minute to v2014.04, but I want these patches merged. Please review. Tetsuyuki Kobayashi (2): i2c: sh_i2c: bugfix: i2c probe command does now work arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD drivers/i2c/sh_i2c.c|2 +- include/configs/kzm9g.h |1 + 2 files changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i2c: sh_i2c: bugfix: i2c probe command does now work
I am sorry. The title was typo.
"i2c: sh_i2c: bugfix: i2c probe command does not work"
(2014/04/14 11:21), Tetsuyuki Kobayashi wrote:
> This is regression of commit 2035d77d i2c: sh_i2c: Update to new
> CONFIG_SYS_I2C framework.
>
> Before commit 2035d77d, i2c probe command works properly on kzm9g board.
>
> KZM-A9-GT# i2c probe
> Valid chip addresses: 0C 12 1D 32 39 3D 40 60
>
> After commit 2035d77d, i2c probe command does not work.
>
> KZM-A9-GT# i2c probe
> Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11
> 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B
> 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45
> 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
> 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79
> 7A 7B 7C 7D 7E 7F
>
> sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does
> not read device at all. This patch changes read length to 1.
>
>
> Signed-off-by: Tetsuyuki Kobayashi
> ---
> drivers/i2c/sh_i2c.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
> index cc19100..264c2e6 100644
> --- a/drivers/i2c/sh_i2c.c
> +++ b/drivers/i2c/sh_i2c.c
> @@ -269,7 +269,7 @@ static int sh_i2c_write(struct i2c_adapter *adap, uint8_t
> chip, uint addr,
> static int
> sh_i2c_probe(struct i2c_adapter *adap, u8 dev)
> {
> - return sh_i2c_read(adap, dev, 0, 0, NULL, 0);
> + return sh_i2c_read(adap, dev, 0, 0, NULL, 1);
> }
>
> static unsigned int sh_i2c_set_bus_speed(struct i2c_adapter *adap,
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] i2c: sh_i2c: bugfix: i2c probe command does not work
Hello, Nobihiro, Heiko I found bug in this patch. When I change read length 0 to 1, I have to change buffer address NULL to some valid memory address. I am going to v3 patch as soon as possible. (2014/04/14 15:09), Nobuhiro Iwamatsu wrote: Hi, 2014-04-14 14:22 GMT+09:00 Heiko Schocher : Hello Tetsuyuki Am 14.04.2014 06:45, schrieb Tetsuyuki Kobayashi: This is regression of commit 2035d77d i2c: sh_i2c: Update to new CONFIG_SYS_I2C framework Before commit 2035d77d, i2c probe command works properly on kzm9g board. KZM-A9-GT# i2c probe Valid chip addresses: 0C 12 1D 32 39 3D 40 60 After commit 2035d77d, i2c probe command does not work. KZM-A9-GT# i2c probe Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does not read device at all. This patch changes read length to 1. Signed-off-by: Tetsuyuki Kobayashi --- drivers/i2c/sh_i2c.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I could not find your patch in patchwork ... so I think it go through u-boot-sh.git, so: Acked-by: Heiko Schocher Thanks! I think the reason that is not registered in the patchwork, the subject is because he is 0/2. Tetsuyuki, could you re-send this patch? Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Best regards, Nobuhiro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD
Add CONFIG_SYS_GENERIC_BOARD to enable generic board for kzm9g. See doc/README.generic-board Signed-off-by: Tetsuyuki Kobayashi --- include/configs/kzm9g.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h index 4d11c7d..5a13ad1 100644 --- a/include/configs/kzm9g.h +++ b/include/configs/kzm9g.h @@ -15,6 +15,7 @@ #define CONFIG_KZM_A9_GT #define CONFIG_RMOBILE_BOARD_STRING"KMC KZM-A9-GT" #define CONFIG_MACH_TYPE MACH_TYPE_KZM9G +#define CONFIG_SYS_GENERIC_BOARD #include -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] i2c: sh_i2c: bugfix: i2c probe command does not work
This is regression of commit 2035d77d i2c: sh_i2c: Update to new CONFIG_SYS_I2C
framework
Before commit 2035d77d, i2c probe command works properly on kzm9g board.
KZM-A9-GT# i2c probe
Valid chip addresses: 0C 12 1D 32 39 3D 40 60
After commit 2035d77d, i2c probe command does not work.
KZM-A9-GT# i2c probe
Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12
13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C
2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46
47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A
7B 7C 7D 7E 7F
sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does
not read device at all. This patch changes read length to 1.
Signed-off-by: Tetsuyuki Kobayashi
---
drivers/i2c/sh_i2c.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
index cc19100..264c2e6 100644
--- a/drivers/i2c/sh_i2c.c
+++ b/drivers/i2c/sh_i2c.c
@@ -269,7 +269,7 @@ static int sh_i2c_write(struct i2c_adapter *adap, uint8_t
chip, uint addr,
static int
sh_i2c_probe(struct i2c_adapter *adap, u8 dev)
{
- return sh_i2c_read(adap, dev, 0, 0, NULL, 0);
+ return sh_i2c_read(adap, dev, 0, 0, NULL, 1);
}
static unsigned int sh_i2c_set_bus_speed(struct i2c_adapter *adap,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] i2c: sh_i2c: bugfix: i2c probe command does not work
Hello, I found i2c probe command bug on kzm9g board and fixed it. The v1 patches are faild to post because I was not subscribing u-boot ML. Changes for v2: - correct typo in commit message. Tetsuyuki Kobayashi (2): i2c: sh_i2c: bugfix: i2c probe command does now work arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD drivers/i2c/sh_i2c.c|2 +- include/configs/kzm9g.h |1 + 2 files changed, 2 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD
Hi, (2014/04/14 15:12), Nobuhiro Iwamatsu wrote: Hi, 2014-04-14 14:24 GMT+09:00 Heiko Schocher : Hello Tetsuyuki, Am 14.04.2014 06:45, schrieb Tetsuyuki Kobayashi: Add CONFIG_SYS_GENERIC_BOARD to enable generic board for kzm9g. See doc/README.generic-board Hmm.. I did not find "doc/README.generic-board" in current mainline tree ... [...] Maybe, doc/README.generic-board meanes README. I worked on v2014.04-rc3 and missed reverting "Start the deprecation process for generic board". doc/README.generic-board was deleted now. Anyway, I post revised v3 patch. beside of that: Acked-by: Heiko Schocher ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
Hi Akshay,
I'm not Samsung tree maintainer, but by chance I've come across those
patches and...
First question - why have you omitted u-boot-samsung tree maintainer?
I've added Minkyu to CC.
Also in the cover letter you claim that this patch was "build tested"
for Exynos4 based boards. Why didn't you add at least one maintainer of
those boards to CC?
> +
> +/* A list of valid GPIO numbers for the asm-generic/gpio.h interface
> */ +enum exynos5_gpio_pin {
> + /* GPIO_PART1_STARTS */
> + EXYNOS5_GPIO_A00, /* 0 */
> + EXYNOS5_GPIO_A01,
> + EXYNOS5_GPIO_A02,
> + EXYNOS5_GPIO_A03,
> + EXYNOS5_GPIO_A04,
According to the patch description, you had a compilation error when
were adding the support for Exynos 5250 and 5420. Why you fix the
problem by rewriting the whole framework?
IN the patch 2/4 you have:
- gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
- gpio_set_pull(start + i, GPIO_PULL_NONE);
- gpio_set_drv(start + i, GPIO_DRV_4X);
+ gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
+ gpio_set_pull(start + i, S5P_GPIO_PULL_NONE);
+ gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
What is the rationale to change the name to S5P_GPIO and not stick to
GPIO_FUNC? In which way gpios for Exynos5 are different than for
Exynos4? Cannot we finally reuse the Exynos 4 and 5 code?
With the same patch:
- case PERIPH_ID_UART1:
- bank = &gpio1->d0;
- start = 0;
+ start = EXYNOS5_GPIO_D00;
What is wrong with specifying the bank field?
Why your gpio command cannot use the bank approach?
And one more question: Is this work compliant with new driver model,
which will be accepted at the merge window after the v2014.04 release?
If not, then there is no point to review this code, since GPIO would
need to be adjusted to use this framework.
--
Best regards,
Lukasz Majewski
Samsung R&D 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] [PATCH v6 4/4] Config: Exynos5: Enable Generic GPIO and CMD configs
Hi Simon, >Hi Akshay, > > >On 12 April 2014 13:33, Simon Glass wrote: > >On 12 April 2014 02:43, Akshay Saraswat wrote: > >From: Rajeshwari Shinde > >Enable configs for GPIO CMD and Generic GPIO. > >Signed-off-by: Rajeshwari Shinde >Signed-off-by: Akshay Saraswat > > > >Acked-by: Simon Glass > > >Tested on snow with backlight GPIOs. > > >One more question - it looks like Pit doesn't boot on ToT. It is missing a >device tree file, but it seems to be more than that - have you had it working? > Yes, it's not booting over pit with this patch-set. I forgot to test them over pit. Will fix it. > >Regards, >Simon Regards, Akshay Saraswat ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] i2c: sh_i2c: bugfix: i2c probe command does not work
This is regression of commit 2035d77d i2c: sh_i2c: Update to new CONFIG_SYS_I2C
framework
Before commit 2035d77d, i2c probe command works properly on kzm9g board.
KZM-A9-GT# i2c probe
Valid chip addresses: 0C 12 1D 32 39 3D 40 60
After commit 2035d77d, i2c probe command does not work.
KZM-A9-GT# i2c probe
Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12
13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C
2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46
47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A
7B 7C 7D 7E 7F
sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does
not read device at all. This patch prepares dummy buffer and read data into it.
Signed-off-by: Tetsuyuki Kobayashi
---
Changes for v2:
- correct typo in commit message.
Changes for v3:
- prepare dummy data buffer and use it to avoid NULL access.
drivers/i2c/sh_i2c.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
index cc19100..e7e9692 100644
--- a/drivers/i2c/sh_i2c.c
+++ b/drivers/i2c/sh_i2c.c
@@ -269,7 +269,9 @@ static int sh_i2c_write(struct i2c_adapter *adap, uint8_t
chip, uint addr,
static int
sh_i2c_probe(struct i2c_adapter *adap, u8 dev)
{
- return sh_i2c_read(adap, dev, 0, 0, NULL, 0);
+ u8 dummy[1];
+
+ return sh_i2c_read(adap, dev, 0, 0, dummy, sizeof dummy);
}
static unsigned int sh_i2c_set_bus_speed(struct i2c_adapter *adap,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/2] kzm9g i2c bugfix and CONFIG_SYS_GENERIC_BOARD
Hello, I found i2c probe command bug on kzm9g board and fixed it. Also, add CONFIG_SYS_GENERIC_BOARD for kzm9g board. Changes for v2: - correct typo in commit message. Changes for v3: - prepare dummy data buffer and use it to avoid NULL access. Tetsuyuki Kobayashi (2): i2c: sh_i2c: bugfix: i2c probe command does not work arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD drivers/i2c/sh_i2c.c|4 +++- include/configs/kzm9g.h |1 + 2 files changed, 4 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD
Add CONFIG_SYS_GENERIC_BOARD to use common/board_[fr].c for kzm9g. Signed-off-by: Tetsuyuki Kobayashi --- Changes for v3: - change commit message. include/configs/kzm9g.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h index 4d11c7d..5a13ad1 100644 --- a/include/configs/kzm9g.h +++ b/include/configs/kzm9g.h @@ -15,6 +15,7 @@ #define CONFIG_KZM_A9_GT #define CONFIG_RMOBILE_BOARD_STRING"KMC KZM-A9-GT" #define CONFIG_MACH_TYPE MACH_TYPE_KZM9G +#define CONFIG_SYS_GENERIC_BOARD #include -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange CFI flash problem
Am 14.04.2014 08:09, schrieb Matthias Weißer:
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Dear Matthias,
In message <5347bbbc.9000...@arcor.de> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01
back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via
tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:
...
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5
Are you sure your malloc arena is big enough for LZO? Try if
increasing it helps...
We increaded it from 4MB to 8MB and the behavior is still the same.
We also observed a different behavior when tftping the image to RAM and
then directly executing it without copying it to flash. It seems that
the flash device (EN29GL256H) is then in some a mode (maybe auto-select)
which prevents it from normal read operations which doesn't allow the
flash driver of the OS come up. We never saw this with our old u-boot.
If there are no ideas left we will have to bisect the problem.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook
Date: Fri Aug 16 07:59:15 2013 -0700
lzo: correctly bounds-check output buffer
This checks the size of the output buffer and fails if it was going to
overflow the buffer during lzo decompression.
Signed-off-by: Kees Cook
Acked-by: Simon Glass
This commit introduced the usage of the dst_len output parameter as
additional input parameter containing the maximum output buffer size.
This parameter isn't initialized in cmd_bootm.c:
454 #ifdef CONFIG_LZO
455 case IH_COMP_LZO: {
456 size_t size;
457
458 printf(" Uncompressing %s ... ", type_name);
459
460 ret = lzop_decompress(image_buf, image_len, load_buf, &size);
Setting size to some big value (SZE_MAX is not avialable) fixed the
behavior but I am unsure if this is the correct solution. I think its
hard to get the max output buffer size at this point in cmd_bootm.c.
Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Dear Albert Aribaud,
Please pull u-boot-sh/rmobile into u-boot-arm/master.
I want to merge these fixes into 2014.04. Could you please merge these?
Best regards,
Nobuhiro
The following changes since commit 1b82491ee6ee1e986e5521b33692a00e1f38fe75:
board:tricorder: fixup SPL OOB layout (2014-04-11 10:08:42 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-sh.git master
for you to fetch changes up to fc56da0b2fd092fabf2af98a75db323a0d432297:
arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD (2014-04-14 17:42:30 +0900)
Tetsuyuki Kobayashi (2):
i2c: sh_i2c: bugfix: i2c probe command does not work
arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD
drivers/i2c/sh_i2c.c| 4 +++-
include/configs/kzm9g.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD
Applied, thanks!
Best regards,
Nobuhiro
2014-04-14 17:13 GMT+09:00 Tetsuyuki Kobayashi :
> Add CONFIG_SYS_GENERIC_BOARD to use common/board_[fr].c for kzm9g.
>
> Signed-off-by: Tetsuyuki Kobayashi
> ---
> Changes for v3:
> - change commit message.
>
> include/configs/kzm9g.h |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h
> index 4d11c7d..5a13ad1 100644
> --- a/include/configs/kzm9g.h
> +++ b/include/configs/kzm9g.h
> @@ -15,6 +15,7 @@
> #define CONFIG_KZM_A9_GT
> #define CONFIG_RMOBILE_BOARD_STRING"KMC KZM-A9-GT"
> #define CONFIG_MACH_TYPE MACH_TYPE_KZM9G
> +#define CONFIG_SYS_GENERIC_BOARD
>
> #include
>
> --
> 1.7.9.5
>
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] i2c: sh_i2c: bugfix: i2c probe command does not work
Applied, thanks for your this fix!
Best regards,
Nobuhiro
2014-04-14 17:13 GMT+09:00 Tetsuyuki Kobayashi :
> This is regression of commit 2035d77d i2c: sh_i2c: Update to new
> CONFIG_SYS_I2C framework
>
> Before commit 2035d77d, i2c probe command works properly on kzm9g board.
>
> KZM-A9-GT# i2c probe
> Valid chip addresses: 0C 12 1D 32 39 3D 40 60
>
> After commit 2035d77d, i2c probe command does not work.
>
> KZM-A9-GT# i2c probe
> Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11
> 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B
> 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45
> 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
> 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79
> 7A 7B 7C 7D 7E 7F
>
> sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does
> not read device at all. This patch prepares dummy buffer and read data into
> it.
>
> Signed-off-by: Tetsuyuki Kobayashi
> ---
> Changes for v2:
> - correct typo in commit message.
>
> Changes for v3:
> - prepare dummy data buffer and use it to avoid NULL access.
>
> drivers/i2c/sh_i2c.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
> index cc19100..e7e9692 100644
> --- a/drivers/i2c/sh_i2c.c
> +++ b/drivers/i2c/sh_i2c.c
> @@ -269,7 +269,9 @@ static int sh_i2c_write(struct i2c_adapter *adap, uint8_t
> chip, uint addr,
> static int
> sh_i2c_probe(struct i2c_adapter *adap, u8 dev)
> {
> - return sh_i2c_read(adap, dev, 0, 0, NULL, 0);
> + u8 dummy[1];
> +
> + return sh_i2c_read(adap, dev, 0, 0, dummy, sizeof dummy);
> }
>
> static unsigned int sh_i2c_set_bus_speed(struct i2c_adapter *adap,
> --
> 1.7.9.5
>
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
Hi Lukasz,
>Hi Akshay,
>
>I'm not Samsung tree maintainer, but by chance I've come across those
>patches and...
>
>First question - why have you omitted u-boot-samsung tree maintainer?
>I've added Minkyu to CC.
>
Minkyu has an email ID "proms...@gmail.com" and I added that in CC.
Probably you don't know this email id :-)
>
>Also in the cover letter you claim that this patch was "build tested"
>for Exynos4 based boards. Why didn't you add at least one maintainer of
>those boards to CC?
>
In cover letter I have not mentioned anywhere that I have built or tested
these patches over Exynos4. Patch 2/4 says "Build tested" because Rajeshwari
did build images for Exynos4 boards and that was successfull but nobody tested
booting those images.
I do not possess any Exynos4 board. These patches are meant for Exynos5 only.
But Yes, there are compiler errors introduced for smkc100 because of this new
patch-set and I will fix them in the next patch-set.
>
>> +
>> +/* A list of valid GPIO numbers for the asm-generic/gpio.h interface
>> */ +enum exynos5_gpio_pin {
>> +/* GPIO_PART1_STARTS */
>> +EXYNOS5_GPIO_A00, /* 0 */
>> +EXYNOS5_GPIO_A01,
>> +EXYNOS5_GPIO_A02,
>> +EXYNOS5_GPIO_A03,
>> +EXYNOS5_GPIO_A04,
>
>According to the patch description, you had a compilation error when
>were adding the support for Exynos 5250 and 5420. Why you fix the
>problem by rewriting the whole framework?
>
This framework is not intended to fix compiler warnings or errors but to make
GPIO numbering easy to remember and sequential, without any holes in between.
>
>IN the patch 2/4 you have:
>
>- gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
>- gpio_set_pull(start + i, GPIO_PULL_NONE);
>- gpio_set_drv(start + i, GPIO_DRV_4X);
>+ gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
>+ gpio_set_pull(start + i, S5P_GPIO_PULL_NONE);
>+ gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
>
>What is the rationale to change the name to S5P_GPIO and not stick to
>GPIO_FUNC? In which way gpios for Exynos5 are different than for
>Exynos4? Cannot we finally reuse the Exynos 4 and 5 code?
>
We have enum member GPIO_INPUT in common/cmd_gpio.c and GPIO_INPUT define
in arch-exynos/gpio.h. To remove such conflicts we renamed all s5p defines
from "GPIO_*" to "S5P_GPIO_*".
We are using the same s5p_gpio.c for both Exynos4 and 5 as far as I know.
I dont get the exact issue here. Do you want me to remove "S5P_". Is that it ?
>
>With the same patch:
>
>- case PERIPH_ID_UART1:
>- bank = &gpio1->d0;
>- start = 0;
>+ start = EXYNOS5_GPIO_D00;
>
>What is wrong with specifying the bank field?
>Why your gpio command cannot use the bank approach?
>
Ultimately we are using banks and pin_nums specific to the bank only
after we extract exact bank from the sequential pin_num.
>
>And one more question: Is this work compliant with new driver model,
>which will be accepted at the merge window after the v2014.04 release?
>
>
>If not, then there is no point to review this code, since GPIO would
>need to be adjusted to use this framework.
>
Please explain more. I don't get this as well :-)
>--
>Best regards,
>
>Lukasz Majewski
>
>Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>
Regards,
Akshay Saraswat
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/4] Exynos5: Add GPIO numbering feature
Hello Akshay, I tried to test your patches but build breaks for trats2 and trats configs. You didn't change some old gpio code in those boards files. Please fix this. On 04/12/2014 11:43 AM, Akshay Saraswat wrote: From: Akshay Saraswat Changes in V2: - Enabled CMD_GPIO as suggested by Simon Glass and supported same for EXYNOS5. Changes in V3: - New patch added to rename S5P GPIO definitions to S5P_GPIO. - GPIO Table added to calculate the base address of input gpio bank. Changes in V4: - To have consistent 0..n-1 GPIO numbering the banks are divided into different parts where ever they have holes in them. - Function and table to support gpio command moved to s5p-gpio driver. - Rebased on latest u-boot-samsung tree. Changes in V5: - Rebased on latest u-boot-samsung tree. - Removed Exynos5 specific code in gpio driver api to get bank. - Added #define HAVE_GENERIC_GPIO in config file to remove conditinal CPU check in gpio driver. Changes in V6: - Isolated config changes in a new patch. - Updated patches with corresponding changes for Exynos 5420. Rajeshwari Shinde (4): S5P: Rename GPIO definitions EXYNOS5: Add gpio pin numbering feature EXYNOS5: GPIO: Support GPIO Command for EXYNOS5 Config: Exynos5: Enable Generic GPIO and CMD configs arch/arm/cpu/armv7/exynos/pinmux.c | 355 ++ arch/arm/include/asm/arch-exynos/cpu.h | 17 +- arch/arm/include/asm/arch-exynos/gpio.h | 796 ++- arch/arm/include/asm/arch-s5pc1xx/gpio.h | 26 +- board/samsung/goni/goni.c| 4 +- board/samsung/smdk5250/exynos5-dt.c | 20 +- board/samsung/smdk5250/smdk5250.c| 19 +- board/samsung/smdk5420/smdk5420.c| 15 +- board/samsung/smdkc100/smdkc100.c| 2 +- board/samsung/smdkv310/smdkv310.c| 10 +- board/samsung/trats/trats.c | 6 +- board/samsung/universal_c210/universal.c | 34 +- drivers/gpio/s5p_gpio.c | 169 ++- include/configs/exynos5-dt.h | 3 + 14 files changed, 1157 insertions(+), 319 deletions(-) Thanks -- Przemyslaw Marczak Samsung R&D 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 v6 1/4] EXYNOS5: Add gpio pin numbering feature
Hi Akshay,
> Hi Lukasz,
>
> >Hi Akshay,
> >
> >I'm not Samsung tree maintainer, but by chance I've come across those
> >patches and...
> >
> >First question - why have you omitted u-boot-samsung tree maintainer?
> >I've added Minkyu to CC.
> >
>
> Minkyu has an email ID "proms...@gmail.com" and I added that in CC.
> Probably you don't know this email id :-)
I do know it :-), but this is not the official one.
Adding involved people to CC really speed up things :-)
>
> >
> >Also in the cover letter you claim that this patch was "build tested"
> >for Exynos4 based boards. Why didn't you add at least one maintainer
> >of those boards to CC?
> >
>
> In cover letter I have not mentioned anywhere that I have built or
> tested these patches over Exynos4.
> Patch 2/4 says "Build tested"
> because Rajeshwari did build images for Exynos4 boards and that was
> successfull but nobody tested booting those images.
As Przemek written to you in the other mail. There is a build problem
with trats2/trats boards.
> I do not possess any Exynos4 board.
That is why it is a good practice to ask maintainer's of those boards
to test it for you.
> These patches are meant for
> Exynos5 only.
We will probably go with your approach to make (_finally_) the gpio code
consistent for Exynos4/5.
> But Yes, there are compiler errors introduced for
> smkc100 because of this new patch-set and I will fix them in the next
> patch-set.
I'm a bit confused now. Was this patch set build tested or not?
>
> >
> >> +
> >> +/* A list of valid GPIO numbers for the asm-generic/gpio.h
> >> interface */ +enum exynos5_gpio_pin {
> >> + /* GPIO_PART1_STARTS */
> >> + EXYNOS5_GPIO_A00, /* 0 */
> >> + EXYNOS5_GPIO_A01,
> >> + EXYNOS5_GPIO_A02,
> >> + EXYNOS5_GPIO_A03,
> >> + EXYNOS5_GPIO_A04,
> >
> >According to the patch description, you had a compilation error when
> >were adding the support for Exynos 5250 and 5420. Why you fix the
> >problem by rewriting the whole framework?
> >
>
> This framework is not intended to fix compiler warnings or errors but
> to make GPIO numbering easy to remember and sequential, without any
> holes in between.
Samsung boards were swinging from part+bank+pin number approach to
sequential GPIO number from time to time. I think it is a good
time to clean things up.
>
> >
> >IN the patch 2/4 you have:
> >
> >-gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
> >-gpio_set_pull(start + i, GPIO_PULL_NONE);
> >-gpio_set_drv(start + i, GPIO_DRV_4X);
> >+gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
> >+gpio_set_pull(start + i, S5P_GPIO_PULL_NONE);
> >+gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
> >
> >What is the rationale to change the name to S5P_GPIO and not stick to
> >GPIO_FUNC? In which way gpios for Exynos5 are different than for
> >Exynos4? Cannot we finally reuse the Exynos 4 and 5 code?
> >
>
> We have enum member GPIO_INPUT in common/cmd_gpio.c and GPIO_INPUT
> define in arch-exynos/gpio.h. To remove such conflicts we renamed all
> s5p defines from "GPIO_*" to "S5P_GPIO_*".
> We are using the same s5p_gpio.c for both Exynos4 and 5 as far as I
> know. I dont get the exact issue here. Do you want me to remove
> "S5P_". Is that it ?
S5P_ corresponds to at most Exynos4 SoC (Up till S5PV310). However,
since the file is named s5p_gpio.c, then I think that S5P_ is a
appropriate prefix.
>
> >
> >With the same patch:
> >
> >-case PERIPH_ID_UART1:
> >-bank = &gpio1->d0;
> >-start = 0;
> >+start = EXYNOS5_GPIO_D00;
> >
> >What is wrong with specifying the bank field?
> >Why your gpio command cannot use the bank approach?
> >
>
> Ultimately we are using banks and pin_nums specific to the bank only
> after we extract exact bank from the sequential pin_num.
Ok.
>
> >
> >And one more question: Is this work compliant with new driver model,
> >which will be accepted at the merge window after the v2014.04
> >release?
> >
> >
> >If not, then there is no point to review this code, since GPIO would
> >need to be adjusted to use this framework.
> >
>
> Please explain more. I don't get this as well :-)
My point is that the new driver model (introduced by Simon) is going to
be included. I'm concern if after introduction of it we would need to
rewrite the gpio code to comply with it.
>
> >--
> >Best regards,
> >
> >Lukasz Majewski
> >
> >Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> >
>
> Regards,
> Akshay Saraswat
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Add T4240RDB board support
T4240RDB board Specification
Memory subsystem:
6GB DDR3
128MB NOR flash
2GB NAND flash
Ethernet:
Eight 1G SGMII ports
Four 10Gbps SFP+ ports
PCIe:
Two PCIe slots
USB:
Two USB2.0 Type A ports
SDHC:
One SD-card port
SATA:
One SATA port
UART:
Dual RJ45 ports
Signed-off-by: Chunhe Lan
---
arch/powerpc/cpu/mpc85xx/t4240_ids.c |2 +
board/freescale/t4rdb/Makefile | 12 +
board/freescale/t4rdb/ddr.c | 118 ++
board/freescale/t4rdb/ddr.h | 78
board/freescale/t4rdb/eth.c | 146 +++
board/freescale/t4rdb/law.c | 28 ++
board/freescale/t4rdb/pci.c | 23 +
board/freescale/t4rdb/t4240rdb.c | 125 ++
board/freescale/t4rdb/t4_pbi.cfg | 31 ++
board/freescale/t4rdb/t4_rcw.cfg |7 +
board/freescale/t4rdb/t4rdb.h| 18 +
board/freescale/t4rdb/tlb.c | 111 +
boards.cfg |1 +
drivers/mmc/fsl_esdhc.c |2 +-
include/configs/T4240RDB.h | 752 ++
15 files changed, 1453 insertions(+), 1 deletions(-)
create mode 100644 board/freescale/t4rdb/Makefile
create mode 100644 board/freescale/t4rdb/ddr.c
create mode 100644 board/freescale/t4rdb/ddr.h
create mode 100644 board/freescale/t4rdb/eth.c
create mode 100644 board/freescale/t4rdb/law.c
create mode 100644 board/freescale/t4rdb/pci.c
create mode 100644 board/freescale/t4rdb/t4240rdb.c
create mode 100644 board/freescale/t4rdb/t4_pbi.cfg
create mode 100644 board/freescale/t4rdb/t4_rcw.cfg
create mode 100644 board/freescale/t4rdb/t4rdb.h
create mode 100644 board/freescale/t4rdb/tlb.c
create mode 100644 include/configs/T4240RDB.h
diff --git a/arch/powerpc/cpu/mpc85xx/t4240_ids.c
b/arch/powerpc/cpu/mpc85xx/t4240_ids.c
index f181315..1a3cb33 100644
--- a/arch/powerpc/cpu/mpc85xx/t4240_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/t4240_ids.c
@@ -64,11 +64,13 @@ struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
};
#endif
+#ifdef CONFIG_SYS_SRIO
struct srio_liodn_id_table srio_liodn_tbl[] = {
SET_SRIO_LIODN_BASE(1, 307),
SET_SRIO_LIODN_BASE(2, 387),
};
int srio_liodn_tbl_sz = ARRAY_SIZE(srio_liodn_tbl);
+#endif
struct liodn_id_table liodn_tbl[] = {
#ifdef CONFIG_SYS_DPAA_QBMAN
diff --git a/board/freescale/t4rdb/Makefile b/board/freescale/t4rdb/Makefile
new file mode 100644
index 000..f7f7fc0
--- /dev/null
+++ b/board/freescale/t4rdb/Makefile
@@ -0,0 +1,12 @@
+#
+# Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_T4240RDB) += t4240rdb.o
+obj-y += ddr.o
+obj-y += eth.o
+obj-$(CONFIG_PCI) += pci.o
+obj-y += law.o
+obj-y += tlb.o
diff --git a/board/freescale/t4rdb/ddr.c b/board/freescale/t4rdb/ddr.c
new file mode 100644
index 000..5a43c1b
--- /dev/null
+++ b/board/freescale/t4rdb/ddr.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ddr.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void fsl_ddr_board_options(memctl_options_t *popts,
+ dimm_params_t *pdimm,
+ unsigned int ctrl_num)
+{
+ const struct board_specific_parameters *pbsp, *pbsp_highest = NULL;
+ ulong ddr_freq;
+
+ if (ctrl_num > 2) {
+ printf("Not supported controller number %d\n", ctrl_num);
+ return;
+ }
+ if (!pdimm->n_ranks)
+ return;
+
+ /*
+* we use identical timing for all slots. If needed, change the code
+* to pbsp = rdimms[ctrl_num] or pbsp = udimms[ctrl_num];
+*/
+ if (popts->registered_dimm_en)
+ pbsp = rdimms[0];
+ else
+ pbsp = udimms[0];
+
+
+ /* Get clk_adjust, cpo, write_data_delay,2T, according to the board ddr
+* freqency and n_banks specified in board_specific_parameters table.
+*/
+ ddr_freq = get_ddr_freq(0) / 100;
+ while (pbsp->datarate_mhz_high) {
+ if (pbsp->n_ranks == pdimm->n_ranks &&
+ (pdimm->rank_density >> 30) >= pbsp->rank_gb) {
+ if (ddr_freq <= pbsp->datarate_mhz_high) {
+ popts->clk_adjust = pbsp->clk_adjust;
+ popts->wrlvl_start = pbsp->wrlvl_start;
+ popts->wrlvl_ctl_2 = pbsp->wrlvl_ctl_2;
+ popts->wrlvl_ctl_3 = pbsp->wrlvl_ctl_3;
+ goto found;
+ }
+ pbsp_highest = pbsp;
+ }
+ pbsp++;
+ }
+
+ if (pbsp_highest) {
+ printf("Error: board specific timing not found for data\n"
+ "rate %lu MT/s\n"
+
Re: [U-Boot] [PATCH 02/11] SPL: NAND: add support for mxs nand
Hi Tim,
sorry for late review.
On 03/04/2014 08:01, Tim Harvey wrote:
> This utilizes existing nand support, including the mtd layer to provide a
> a method to load an image off nand for SPL. It is somewhat bulky but avoids
> duplicating code.
>
> This will need to be split out and re-based on top of Tom's recent patch to
> add MTD NAND support which is needed here.
>
> Signed-off-by: Tim Harvey
> ---
> drivers/mtd/Makefile| 11 ++
> drivers/mtd/nand/Makefile | 9
> drivers/mtd/nand/mxs_nand_spl.c | 46
> +
> spl/Makefile| 1 +
> 4 files changed, 67 insertions(+)
> create mode 100644 drivers/mtd/nand/mxs_nand_spl.c
>
> diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
> index 5467a95..10ec470 100644
> --- a/drivers/mtd/Makefile
> +++ b/drivers/mtd/Makefile
> @@ -5,6 +5,15 @@
> # SPDX-License-Identifier: GPL-2.0+
> #
>
> +ifdef CONFIG_SPL_BUILD
> +
> +ifdef CONFIG_SPL_NAND_MXS
> +obj-y += mtdcore.o
> +obj-y += mtdpart.o
> +endif
This is usually:
obj-$(CONFIG_SPL_NAND_MXS) += mtdcore.o mtdpart.o
> +
> +else # not spl
> +
> ifneq (,$(findstring
> y,$(CONFIG_MTD_DEVICE)$(CONFIG_CMD_NAND)$(CONFIG_CMD_ONENAND)))
> obj-y += mtdcore.o
> endif
> @@ -18,3 +27,5 @@ obj-$(CONFIG_FTSMC020) += ftsmc020.o
> obj-$(CONFIG_FLASH_CFI_LEGACY) += jedec_flash.o
> obj-$(CONFIG_MW_EEPROM) += mw_eeprom.o
> obj-$(CONFIG_ST_SMI) += st_smi.o
> +
> +endif
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 02b149c..8b1a37a 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -19,6 +19,14 @@ obj-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
> obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o
> obj-$(CONFIG_SPL_NAND_INIT) += nand.o
>
> +ifdef CONFIG_SPL_NAND_MXS
> +obj-y += mxs_nand_spl.o
> +obj-y += nand_bbt.o
> +obj-y += nand_ids.o
> +obj-y += nand_util.o
> +obj-y += nand_ecc.o
> +endif
> +
Ditto.
> else # not spl
>
> NORMAL_DRIVERS=y
> @@ -65,5 +73,6 @@ else # minimal SPL drivers
> obj-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_spl.o
> obj-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_spl.o
> obj-$(CONFIG_NAND_MXC) += mxc_nand_spl.o
> +obj-$(CONFIG_NAND_MXS) += mxs_nand_spl.o mxs_nand.o
>
> endif # drivers
> diff --git a/drivers/mtd/nand/mxs_nand_spl.c b/drivers/mtd/nand/mxs_nand_spl.c
> new file mode 100644
> index 000..ec07eb1
> --- /dev/null
> +++ b/drivers/mtd/nand/mxs_nand_spl.c
> @@ -0,0 +1,46 @@
> +/*
> + * (C) Copyright 2014
> + * Tim Harvey, Gateworks Corporation, thar...@gateworks.com
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +
> +static nand_info_t mtd;
> +static struct nand_chip nand_chip;
> +
> +int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst)
> +{
> + size_t sz, actual;
> +
> + debug("%s offset:0x%08x len:%d\n", __func__, offs, size);
> + sz = size;
> + nand_read_skip_bad(&mtd, (loff_t) offs, &sz, &actual, size, dst);
> + debug("read %d/%d bytes\n", sz, actual);
> +
> + return 0;
> +}
> +
> +void nand_init(void)
> +{
> + int ret;
> +
> + board_nand_init(&nand_chip);
> + mtd.priv = &nand_chip;
> + if (nand_chip.select_chip)
> + nand_chip.select_chip(&mtd, 0);
> +
> + ret = nand_scan(&mtd, 1);
> + if (!ret)
> + ret = nand_scan_tail(&mtd);
> + debug("oobsize=%d pagesize=%d\n", mtd.oobsize, mtd.writesize);
> + printf("NAND: %llu MiB\n", (mtd.size / (1024 * 1024)));
> +}
> +
> +void nand_deselect(void)
> +{
> + if (nand_chip.select_chip)
> + nand_chip.select_chip(&mtd, -1);
> +}
> diff --git a/spl/Makefile b/spl/Makefile
> index 346d0aa..6a2c80f 100644
> --- a/spl/Makefile
> +++ b/spl/Makefile
> @@ -103,6 +103,7 @@ libs-y += fs/
> libs-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/
> libs-$(CONFIG_SPL_POWER_SUPPORT) += drivers/power/ drivers/power/pmic/
> libs-$(if $(CONFIG_CMD_NAND),$(CONFIG_SPL_NAND_SUPPORT)) += drivers/mtd/nand/
> +libs-$(CONFIG_SPL_NAND_MXS) += drivers/mtd/
> libs-$(CONFIG_SPL_DRIVERS_MISC_SUPPORT) += drivers/misc/
> libs-$(CONFIG_SPL_ONENAND_SUPPORT) += drivers/mtd/onenand/
> libs-$(CONFIG_SPL_DMA_SUPPORT) += drivers/dma/
>
The main issue (I read also Scott's answer for Patch 4/11) is due to the
fact that you link a lot of MTD code, increasing the footprint. This
becomes an exception, because only a restricted number of function were
introduces for other SOCs (see mxc_nand_spl.c or code in omap_gpmc.c).
Sure that we cannot get rid of it ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing lis
Re: [U-Boot] [PATCH 01/11] SPL: NAND: remove CONFIG_SYS_NAND_PAGE_SIZE
On 03/04/2014 08:01, Tim Harvey wrote: > We only need to read in the size of struct image_header and thus don't > need to know the page size of the nand device. > > Signed-off-by: Tim Harvey > --- > common/spl/spl_nand.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c > index 9da0218..062461b 100644 > --- a/common/spl/spl_nand.c > +++ b/common/spl/spl_nand.c > @@ -76,7 +76,7 @@ void spl_nand_load_image(void) > #endif > /* Load u-boot */ > nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS, > - CONFIG_SYS_NAND_PAGE_SIZE, (void *)header); > + sizeof(*header), (void *)header); > spl_parse_image_header(header); > nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS, > spl_image.size, (void *)spl_image.load_addr); > Acked-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Micron PC28F00AP30 flash support
Hello Stefan, I am looking at porting U-Boot to a board that is being designed with a Micron PC28D00AP30 NOR flash device and can't work out whether this is something that is already supported by U-Boot or whether it is work that I will need to undertake. I have had a good grep through the code and can't find any specific references to the device but don't know the CFI code well enough to know whether it will just detect it and work. According to the Micron datasheet, the device itself is 1Gb in density and has symmetrical 64Kword erase blocks. Any guidance would be much appreciated. Thanks in advance, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] MX6: provide linker script for SPL
Hi Tim,
On 03/04/2014 08:01, Tim Harvey wrote:
> Signed-off-by: Tim Harvey
> ---
> arch/arm/cpu/armv7/mx6/u-boot-spl.lds | 52
> +++
> 1 file changed, 52 insertions(+)
> create mode 100644 arch/arm/cpu/armv7/mx6/u-boot-spl.lds
>
> diff --git a/arch/arm/cpu/armv7/mx6/u-boot-spl.lds
> b/arch/arm/cpu/armv7/mx6/u-boot-spl.lds
> new file mode 100644
> index 000..02aa129
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/mx6/u-boot-spl.lds
> @@ -0,0 +1,52 @@
> +/*
> + * (C) Copyright 2002
> + * Gary Jennejohn, DENX Software Engineering,
> + *
> + * (C) Copyright 2010
> + * Texas Instruments,
> + * Aneesh V
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,\
> + LENGTH = CONFIG_SPL_MAX_SIZE }
> +MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \
> + LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
> +
> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
> +OUTPUT_ARCH(arm)
> +ENTRY(_start)
> +SECTIONS
> +{
> + .text :
> + {
> + __start = .;
> + arch/arm/cpu/armv7/start.o (.text*)
> + *(.text*)
> + } >.sram
> +
> + . = ALIGN(4);
> + .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
> +
> + . = ALIGN(4);
> + .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
> +
> + . = ALIGN(4);
> + .u_boot_list : {
> + KEEP(*(SORT(.u_boot_list*_i2c_*)));
> + } >.sram
> +
> + . = ALIGN(4);
> + __image_copy_end = .;
> + _end = .;
> +
> + .bss :
> + {
> + . = ALIGN(4);
> + __bss_start = .;
> + *(.bss*)
> + . = ALIGN(4);
> + __bss_end = .;
> + } >.sdram
> +}
>
This file is pretty identical to
./arch/arm/cpu/armv7/omap-common/u-boot-spl.lds. I understand that each
SOC/arch could be a different set up, but I think we should introduce
this diversity when it is needed, not as default.
Maybe can we avoid to copy the file ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] lsxl: rework boot scripts
Am 2014-04-01 20:09, schrieb Michael Walle: Move addresses for kernel, ramdisk and fdt blob to own variables. Add dtb blob loading to all existing boot scripts, dtb filenames were taken from vanilla kernel. Introduce new boot script bootcmd_legacy, which only loads a kernel and a ramdisk. Make this the default boot script. This should also restore the behaviour of the original bootloader. Cc: Prafulla Wadaskar Cc: Tom Rini Signed-off-by: Michael Walle --- Changes v2: - use CONFIG_CMD_FS_GENERIC and load commands (suggested by Tom Rini) - use loadaddresses at offsets 8MB and 16MB, leaving ~8MB for the kernel please note that the kernel is copied to 0x8000 anyway. ping :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/5] Android Fastboot support
On Fri, Apr 11, 2014 at 9:45 AM, Tom Rini wrote: > On Thu, Apr 10, 2014 at 02:18:02PM -0500, Rob Herring wrote: > >> From: Rob Herring >> >> I'm reviving the Android Fastboot support after 2+ years since the last >> posting[1]. The previous postings had some questions about licensing and >> source of some code. I believe I've traced the history sufficiently that >> the copyrights and source information are complete and correct. > > First, thanks for picking this up. I've been hoping someone would get > around to this for a while now as it's an often requested thing. > >> I've tested this series on a BeagleBoard. > > Any other boards you can test this on as well? Thanks! No, that is the only one I have with USB device. Bo Shen tested on at91, but had some issue with large files I have to look into. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] MX6: add boot device support SPL
Hi Tim,
On 03/04/2014 08:01, Tim Harvey wrote:
> Add enums, #defines, and helper functions needed for SPL images to describe
> and detect IMX6 boot device.
>
> Signed-off-by: Tim Harvey
> ---
> arch/arm/cpu/armv7/mx6/soc.c| 56
> +
> arch/arm/include/asm/arch-mx6/spl.h | 26 ++
> arch/arm/include/asm/imx-common/boot_mode.h | 17 +
> 3 files changed, 99 insertions(+)
> create mode 100644 arch/arm/include/asm/arch-mx6/spl.h
>
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index 1725279..4ee62c7 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -305,6 +305,62 @@ const struct boot_mode soc_boot_modes[] = {
> {NULL, 0},
> };
>
> +/* determine boot device from SRC_SBMR1 register (BOOT_CFG[4:1]) */
> +enum boot_device get_boot_device(void)
> +{
> + enum boot_device boot_dev;
> +
> + uint soc_sbmr = readl(SRC_BASE_ADDR + 0x4); /* SRC_SBMR1 */
Use structure to access internal registers. The structure is already
defined in imx-regs.h.
> +
> + /* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
> + switch ((soc_sbmr & 0x00FF) >> 4) {
> + /* EIM: See 8.5.1, Table 8-9 */
> + case 0x0:
> + /* BOOT_CFG1[3]: NOR/OneNAND Selection */
> + if ((soc_sbmr & 0x0008) >> 3)
> + boot_dev = MX6_ONE_NAND_BOOT;
> + else
> + boot_dev = MX6_WEIM_NOR_BOOT;
> + break;
> + /* SATA: See 8.5.4, Table 8-20 */
> + case 0x2:
Can we use #defines for that ?
> + boot_dev = MX6_SATA_BOOT;
> + break;
> + /* Serial ROM: See 8.5.5.1, Table 8-22 */
> + case 0x3:
> + /* BOOT_CFG4[2:0] */
> + switch ((soc_sbmr & 0x0700) >> 24) {
> + case 0x0 ... 0x4:
> + boot_dev = MX6_SPI_NOR_BOOT;
> + break;
> + case 0x5 ... 0x7:
> + boot_dev = MX6_I2C_BOOT;
> + break;
> + }
> + break;
> + /* SD/eSD: 8.5.3, Table 8-15 */
> + case 0x4:
> + case 0x5:
> + boot_dev = MX6_SD_BOOT;
> + break;
> + /* MMC/eMMC: 8.5.3 */
> + case 0x6:
> + case 0x7:
> + boot_dev = MX6_MMC_BOOT;
> + break;
> + /* NAND Flash: 8.5.2 */
> + case 0x8 ... 0xf:
> + boot_dev = MX6_NAND_BOOT;
> + break;
> + default:
> + boot_dev = MX6_UNKNOWN_BOOT;
> + break;
> + }
> +
The function can be used as well for MX5 SOCs. Move it into imx-common,
and use constants without SOC names. Instead of MX6_NAND_BOOT,
IMX_NAND_BOOT (or whatever you find makes sense..)
> + return boot_dev;
> +}
> +
> +
> void s_init(void)
> {
> struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
> diff --git a/arch/arm/include/asm/arch-mx6/spl.h
> b/arch/arm/include/asm/arch-mx6/spl.h
> new file mode 100644
> index 000..5611c71
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-mx6/spl.h
> @@ -0,0 +1,26 @@
> +/*
> + * Copyright (C) 2013 TechNexion Ltd.
> + *
> + * Author: Richard Hu
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#ifndef __ASM_ARCH_SPL_H__
> +#define __ASM_ARCH_SPL_H__
> +
> +#define BOOT_DEVICE_MMC1 0
> +#define BOOT_DEVICE_MMC2 1
> +#define BOOT_DEVICE_MMC2_2 2
> +#define BOOT_DEVICE_NAND 3
> +#define BOOT_DEVICE_SATA 4
> +#define BOOT_DEVICE_USBETH 5
> +#define BOOT_DEVICE_NONE 6
> +
They are only defines and are not yet related to i.MX6 anymnore, because
you have already mapped them. What about to move this defines into
imx-common ?
> +#endif /* __ASM_ARCH_SPL_H__ */
> diff --git a/arch/arm/include/asm/imx-common/boot_mode.h
> b/arch/arm/include/asm/imx-common/boot_mode.h
> index de0205c..3686367 100644
> --- a/arch/arm/include/asm/imx-common/boot_mode.h
> +++ b/arch/arm/include/asm/imx-common/boot_mode.h
> @@ -17,4 +17,21 @@ struct boot_mode {
> void add_board_boot_modes(const struct boot_mode *p);
> void boot_mode_apply(unsigned cfg_val);
> extern const struct boot_mode soc_boot_modes[];
> +
> +/* boot devices */
> +enum boot_device {
> + MX6_SD_BOOT,
> + MX6_MMC_BOOT,
> + MX6_NAND_BOOT,
> + MX6_SATA_BOOT,
> + MX6_WEIM_NOR_BOOT,
> + MX6_ONE_NAND_BOOT,
> + MX6_PATA_BOOT,
> + MX6_I2C_BOOT,
> + MX6_SPI_NOR_BOOT,
> + MX6_UNKNOWN_BOOT,
> + MX6_BOOT_DEV_NUM = MX6_UNKNOWN_BOOT,
> +};
See my remark before.
> +enum boot_device get_boot_device(void);
> +
> #endif
>
Best regards,
Stefano
Re: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot
Hi Tim,
On 03/04/2014 08:01, Tim Harvey wrote:
> This can be used to pass info between the SPL and u-boot.
>
> Signed-off-by: Tim Harvey
> ---
> arch/arm/include/asm/arch-mx6/sys_proto.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h
> b/arch/arm/include/asm/arch-mx6/sys_proto.h
> index 38851a1..f43e09c 100644
> --- a/arch/arm/include/asm/arch-mx6/sys_proto.h
> +++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
> @@ -39,4 +39,9 @@ int mxs_wait_mask_set(struct mxs_register_32 *reg,
> int mxs_wait_mask_clr(struct mxs_register_32 *reg,
> uint32_t mask,
> unsigned int timeout);
> +
> +struct mx6_spl_data {
> + uint8_t boot_mode_idx;
> + uint32_tmem_dram_size;
> +};
> #endif
I see checking your patch that the MXS uses the same concept. And as far
as I can see, boot_mode_idx is used only to print the boot devioce
However, we have not generally a concept to pass data between SPL and
u-boot. My question is even if it is really needed. The size of DRAM is
retrived at run time by u-boot running get_ram_size(), that is a better
solution.
SPL is thought to generally load an image (of course, in most cases it
is u-boot). In Falcon mode, the kernel is started without running
u-boot, making this structure useless. Do we really need such a way (but
then, it must be generalized as SPL API), or can we get rid of it ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
Dear Akshay,
On 14/04/14 19:53, Lukasz Majewski wrote:
> Hi Akshay,
>
>> Hi Lukasz,
>>
>>> Hi Akshay,
>>>
>>> I'm not Samsung tree maintainer, but by chance I've come across those
>>> patches and...
>>>
>>> First question - why have you omitted u-boot-samsung tree maintainer?
>>> I've added Minkyu to CC.
>>>
>>
>> Minkyu has an email ID "proms...@gmail.com" and I added that in CC.
>> Probably you don't know this email id :-)
>
> I do know it :-), but this is not the official one.
>
> Adding involved people to CC really speed up things :-)
>
I am always sensing about SAMSUNG related patches.
Please don't worry about it :)
>>
>>>
>>> Also in the cover letter you claim that this patch was "build tested"
>>> for Exynos4 based boards. Why didn't you add at least one maintainer
>>> of those boards to CC?
>>>
>>
>> In cover letter I have not mentioned anywhere that I have built or
>> tested these patches over Exynos4.
>> Patch 2/4 says "Build tested"
>> because Rajeshwari did build images for Exynos4 boards and that was
>> successfull but nobody tested booting those images.
>
> As Przemek written to you in the other mail. There is a build problem
> with trats2/trats boards.
Please fix it.
>
>> I do not possess any Exynos4 board.
>
> That is why it is a good practice to ask maintainer's of those boards
> to test it for you.
>
>> These patches are meant for
>> Exynos5 only.
No. please consider Exynos4 also.
If you make patches for Exynos4 too, then it will be great job.
Przemek or Lukasz will help your test.
>
> We will probably go with your approach to make (_finally_) the gpio code
> consistent for Exynos4/5.
>
>> But Yes, there are compiler errors introduced for
>> smkc100 because of this new patch-set and I will fix them in the next
>> patch-set.
next patch-set means v7? right?
>
> I'm a bit confused now. Was this patch set build tested or not?
>
>>
>>>
+
+/* A list of valid GPIO numbers for the asm-generic/gpio.h
interface */ +enum exynos5_gpio_pin {
+ /* GPIO_PART1_STARTS */
+ EXYNOS5_GPIO_A00, /* 0 */
+ EXYNOS5_GPIO_A01,
+ EXYNOS5_GPIO_A02,
+ EXYNOS5_GPIO_A03,
+ EXYNOS5_GPIO_A04,
>>>
>>> According to the patch description, you had a compilation error when
>>> were adding the support for Exynos 5250 and 5420. Why you fix the
>>> problem by rewriting the whole framework?
>>>
>>
>> This framework is not intended to fix compiler warnings or errors but
>> to make GPIO numbering easy to remember and sequential, without any
>> holes in between.
>
> Samsung boards were swinging from part+bank+pin number approach to
> sequential GPIO number from time to time. I think it is a good
> time to clean things up.
>
>>
>>>
>>> IN the patch 2/4 you have:
>>>
>>> - gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
>>> - gpio_set_pull(start + i, GPIO_PULL_NONE);
>>> - gpio_set_drv(start + i, GPIO_DRV_4X);
>>> + gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
>>> + gpio_set_pull(start + i, S5P_GPIO_PULL_NONE);
>>> + gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
>>>
>>> What is the rationale to change the name to S5P_GPIO and not stick to
>>> GPIO_FUNC? In which way gpios for Exynos5 are different than for
>>> Exynos4? Cannot we finally reuse the Exynos 4 and 5 code?
>>>
>>
>> We have enum member GPIO_INPUT in common/cmd_gpio.c and GPIO_INPUT
>> define in arch-exynos/gpio.h. To remove such conflicts we renamed all
>> s5p defines from "GPIO_*" to "S5P_GPIO_*".
>> We are using the same s5p_gpio.c for both Exynos4 and 5 as far as I
>> know. I dont get the exact issue here. Do you want me to remove
>> "S5P_". Is that it ?
>
> S5P_ corresponds to at most Exynos4 SoC (Up till S5PV310). However,
> since the file is named s5p_gpio.c, then I think that S5P_ is a
> appropriate prefix.
Actually I have plan to rename from S5P_ to EXYNOS_. but not now.
It look OK to me.
>
>>
>>>
>>> With the same patch:
>>>
>>> - case PERIPH_ID_UART1:
>>> - bank = &gpio1->d0;
>>> - start = 0;
>>> + start = EXYNOS5_GPIO_D00;
>>>
>>> What is wrong with specifying the bank field?
>>> Why your gpio command cannot use the bank approach?
>>>
>>
>> Ultimately we are using banks and pin_nums specific to the bank only
>> after we extract exact bank from the sequential pin_num.
>
> Ok.
>
>>
>>>
>>> And one more question: Is this work compliant with new driver model,
>>> which will be accepted at the merge window after the v2014.04
>>> release?
>>>
>>>
>>> If not, then there is no point to review this code, since GPIO would
>>> need to be adjusted to use this framework.
>>>
>>
>> Please explain more. I don't get this as well :-)
>
> My point is that the new driver model (introduced by Simon) is going to
> be included. I'm concern if after introduction of it we would need to
> rewrite the gpio code to comply with it.
>
>>
>>> --
>>> Best regards,
>>>
>>> Lukasz Majewski
>>>
>>> Samsung R&D Institute Pola
Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
Hi Lukasz, On 14 April 2014 01:17, Lukasz Majewski wrote: [snip[ I think your questions are mostly answered but I wanted to chime in on a few. What is wrong with specifying the bank field? > Why your gpio command cannot use the bank approach? > U-Boot has a generic GPIO API and we should try to use it where possible. This has been a long-standing TODO for exynos. > > And one more question: Is this work compliant with new driver model, > which will be accepted at the merge window after the v2014.04 release? > > If not, then there is no point to review this code, since GPIO would > need to be adjusted to use this framework. > The driver model framework is already in mainline. At present only sandbox uses it for GPIO. I started looking at exynos since I thought it might be quite easy to convert, but found that the generic GPIO stuff was still not merged. This series will make it much easier to convert exynos GPIO to driver model, since we can just change the driver. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/4] Config: Exynos5: Enable Generic GPIO and CMD configs
Hi Akshay, On 14 April 2014 02:05, Akshay Saraswat wrote: > Hi Simon, > > >Hi Akshay, > > > > > >On 12 April 2014 13:33, Simon Glass wrote: > > > >On 12 April 2014 02:43, Akshay Saraswat wrote: > > > >From: Rajeshwari Shinde > > > >Enable configs for GPIO CMD and Generic GPIO. > > > >Signed-off-by: Rajeshwari Shinde > >Signed-off-by: Akshay Saraswat > > > > > > > >Acked-by: Simon Glass > > > > > >Tested on snow with backlight GPIOs. > > > > > >One more question - it looks like Pit doesn't boot on ToT. It is missing > a device tree file, but it seems to be more than that - have you had it > working? > > > > Yes, it's not booting over pit with this patch-set. I forgot to test them > over pit. Will fix it. > Actually I don't doubt that your series works on Pit, just that I found that mainline does not work. It gets stuck in SPL I think. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] beagle-bone fdt booting problem
+Tom, Albert for this bug Hi Belisko, On 28 March 2014 03:40, Belisko Marek wrote: > Hello, > > On Thu, Mar 27, 2014 at 4:28 PM, Simon Glass wrote: > > Hi, > > > > On 26 March 2014 00:10, Belisko Marek wrote: > >> > >> Hi, > >> > >> I'm playing with fdt booting on beaglebone board. I'm using latest > >> u-boot git HEAD (2c072c958bb544c72f0e848375803dbd6971f022) + I've > >> added to am335x_evm confing : > >> #ifndef CONFIG_SPL_BUILD > >> #define CONFIG_OF_CONTROL > >> #define CONFIG_OF_SEPARATE > >> #endif > >> > >> I took beaglebone devicetree from kernel. Then I took patch [1] to > >> build image from u-boot and my compiled DT blob. > >> > >> Booting this image always fails with: > >> No valid FDT found - please append one to U-Boot binary, use > >> u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d > >> > >> ** CONFIG_OF_CONTROL defined but no FDT - please see > >> doc/README.fdt-control > >> > >> I poke around this and find out that when CONFIG_OF_SEPARATE is used > >> then fdt_blob is set to address of .__end pointer. When evaluate image > >> with hexdump it seems that fdt blob (in my particular case and > >> configuration) is shifted by 312 bytes from .__end. When I point > >> gd->fdt_blob (hack in code) to that address it boots fine. Any ideas > >> what I'm doing wrong (I must do something wrong as it seems nobody > >> complains :)). > >> > >> [1] - > >> > http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=d4ab2022cdfe098e93819c58188ad36174160872 > > > > > > You might be best taking this from the u-boot-x86.git branch 'bone'. It > is a > > little old but it does work. > It was based on that patches just [1] was reworked to fit latest > u-boot (applied with errors): > > diff --git a/Makefile b/Makefile > index 538c3bf..0505678 100644 > --- a/Makefile > +++ b/Makefile > @@ -752,8 +752,13 @@ u-boot-dtb.bin: u-boot.bin dts/dt.dtb FORCE > quiet_cmd_copy = COPY$@ >cmd_copy = cp $< $@ > > +ifneq ($(DEV_TREE_BIN),) > +u-boot.dtb: > + cp $(DEV_TREE_BIN) $@ > +else > u-boot.dtb: dts/dt.dtb > $(call cmd,copy) > +endif > > OBJCOPYFLAGS_u-boot.hex := -O ihex > > @@ -799,7 +804,7 @@ MKIMAGEFLAGS_u-boot.kwb = -n > $(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%) \ > MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \ > -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -T pblimage > > -u-boot.img u-boot.kwb u-boot.pbl: u-boot.bin FORCE > +u-boot.img u-boot.kwb u-boot.pbl: u-boot$(if > $(CONFIG_OF_SEPARATE),-dtb,).bin FORCE > $(call if_changed,mkimage) > > u-boot.imx: u-boot.bin > > > > The patches for this were never applied unfortunately. I'll update them > to > > mainline again at some point and resubmit. > OK. Basically it was working I just hit 2 issues. One with odd skip > 312 bytes and second > that signature wasn't added to final image and verification was check > only sha1 not rsa2048 ( I check when enable debug for some modules): > Verifying Hash Integrity ... fit_image_verify_required_sigs: No > signature node found: FDT_ERR_NOTFOUND > I took some patches from next (which seems fixed signature issue) but > it doesn't solve above problem. > The 312 bytes issue turns out to be a problem with the hash section being appended after the supposed end of U-Boot. It was introduced in b02bfc4 and will go out in this release unless we fix it. I've got a patch which fixes it - will be doing some more testing and then submit along with a resubmit of the Beaglebone black verified boot patches. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
Hi Minkyu, Simon and Lukasz,
>Dear Akshay,
>
>On 14/04/14 19:53, Lukasz Majewski wrote:
>> Hi Akshay,
>>
>>> Hi Lukasz,
>>>
Hi Akshay,
I'm not Samsung tree maintainer, but by chance I've come across those
patches and...
First question - why have you omitted u-boot-samsung tree maintainer?
I've added Minkyu to CC.
>>>
>>> Minkyu has an email ID "proms...@gmail.com" and I added that in CC.
>>> Probably you don't know this email id :-)
>>
>> I do know it :-), but this is not the official one.
>>
>> Adding involved people to CC really speed up things :-)
>>
>
>I am always sensing about SAMSUNG related patches.
>Please don't worry about it :)
>
>>>
Also in the cover letter you claim that this patch was "build tested"
for Exynos4 based boards. Why didn't you add at least one maintainer
of those boards to CC?
>>>
>>> In cover letter I have not mentioned anywhere that I have built or
>>> tested these patches over Exynos4.
>>> Patch 2/4 says "Build tested"
>>> because Rajeshwari did build images for Exynos4 boards and that was
>>> successfull but nobody tested booting those images.
>>
>> As Przemek written to you in the other mail. There is a build problem
>> with trats2/trats boards.
>
>Please fix it.
>
>>
>>> I do not possess any Exynos4 board.
>>
>> That is why it is a good practice to ask maintainer's of those boards
>> to test it for you.
>>
>>> These patches are meant for
>>> Exynos5 only.
>
>No. please consider Exynos4 also.
>If you make patches for Exynos4 too, then it will be great job.
>Przemek or Lukasz will help your test.
>
>>
I borrowed an Origen board and doing changes for Exynos4 as well.
I'll push next patch-set tomorrow with Exynos4 and 5 support together.
>> We will probably go with your approach to make (_finally_) the gpio code
>> consistent for Exynos4/5.
>>
>>> But Yes, there are compiler errors introduced for
>>> smkc100 because of this new patch-set and I will fix them in the next
>>> patch-set.
>
>next patch-set means v7? right?
>
Yes, next patch set would be v7.
>>
>> I'm a bit confused now. Was this patch set build tested or not?
>>
>>>
> +
> +/* A list of valid GPIO numbers for the asm-generic/gpio.h
> interface */ +enum exynos5_gpio_pin {
> + /* GPIO_PART1_STARTS */
> + EXYNOS5_GPIO_A00, /* 0 */
> + EXYNOS5_GPIO_A01,
> + EXYNOS5_GPIO_A02,
> + EXYNOS5_GPIO_A03,
> + EXYNOS5_GPIO_A04,
According to the patch description, you had a compilation error when
were adding the support for Exynos 5250 and 5420. Why you fix the
problem by rewriting the whole framework?
>>>
>>> This framework is not intended to fix compiler warnings or errors but
>>> to make GPIO numbering easy to remember and sequential, without any
>>> holes in between.
>>
>> Samsung boards were swinging from part+bank+pin number approach to
>> sequential GPIO number from time to time. I think it is a good
>> time to clean things up.
>>
>>>
IN the patch 2/4 you have:
- gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
- gpio_set_pull(start + i, GPIO_PULL_NONE);
- gpio_set_drv(start + i, GPIO_DRV_4X);
+ gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
+ gpio_set_pull(start + i, S5P_GPIO_PULL_NONE);
+ gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
What is the rationale to change the name to S5P_GPIO and not stick to
GPIO_FUNC? In which way gpios for Exynos5 are different than for
Exynos4? Cannot we finally reuse the Exynos 4 and 5 code?
>>>
>>> We have enum member GPIO_INPUT in common/cmd_gpio.c and GPIO_INPUT
>>> define in arch-exynos/gpio.h. To remove such conflicts we renamed all
>>> s5p defines from "GPIO_*" to "S5P_GPIO_*".
>>> We are using the same s5p_gpio.c for both Exynos4 and 5 as far as I
>>> know. I dont get the exact issue here. Do you want me to remove
>>> "S5P_". Is that it ?
>>
>> S5P_ corresponds to at most Exynos4 SoC (Up till S5PV310). However,
>> since the file is named s5p_gpio.c, then I think that S5P_ is a
>> appropriate prefix.
>
>Actually I have plan to rename from S5P_ to EXYNOS_. but not now.
>It look OK to me.
>
>>
>>>
With the same patch:
- case PERIPH_ID_UART1:
- bank = &gpio1->d0;
- start = 0;
+ start = EXYNOS5_GPIO_D00;
What is wrong with specifying the bank field?
Why your gpio command cannot use the bank approach?
>>>
>>> Ultimately we are using banks and pin_nums specific to the bank only
>>> after we extract exact bank from the sequential pin_num.
>>
>> Ok.
>>
>>>
And one more question: Is this work compliant with new driver model,
which will be accepted at the merge window after the v2014.04
release?
If not, then there is no point to review this code, since GPIO would
need to be adjusted to use this fr
Re: [U-Boot] [PATCH v6 2/4] S5P: Rename GPIO definitions
Hi, On 04/12/2014 11:43 AM, Akshay Saraswat wrote: From: Rajeshwari Shinde This patch rename GPIO definitions from GPIO_... to S5P_GPIO_... This changes was done to enable cmd_gpio for EXYNOS and cmd_gpio has GPIO_INPUT same as s5p_gpio driver and hence getting a error during compilation. Build tested for s5p_goni, origen, smdk5250, s5pc210_universal, trats, smdkc100, smdkv310 config files. Signed-off-by: Rajeshwari Shinde Signed-off-by: Akshay Saraswat Please check boards files: origen.c, trats.c and trats2.c, there is still old gpio naming style. Thanks -- Przemyslaw Marczak Samsung R&D 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 v6 1/4] EXYNOS5: Add gpio pin numbering feature
Hello,
I like this idea. This is a good feature for easy and fast gpio
maintaining. I have few comments to this.
On 04/12/2014 11:43 AM, Akshay Saraswat wrote:
From: Rajeshwari Shinde
This patch adds gpio pin numbering support for EXYNOS 5250 & 5420.
To have consistent 0..n-1 GPIO numbering the banks are divided
into different parts where ever they have holes in them.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Rajeshwari Shinde
Signed-off-by: Akshay Saraswat
---
You use quite magic numbers in gpio names like "EXYNOS5_GPIO_A05",
maybe better is to add "PIN" word here like this: EXYNOS5_GPIO_A0_PIN5.
So then we really know what we are using and I think this just looks better.
diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
b/arch/arm/include/asm/arch-exynos/gpio.h
index d6868fa..211383d 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -141,14 +141,16 @@ struct exynos5420_gpio_part1 {
It seems that those all exynos5*_gpio_partX structures and also
exynos5*_gpio_get() macros can be removed now.
struct exynos5420_gpio_part2 {
struct s5p_gpio_bank y7; /* 0x1340_ */
- struct s5p_gpio_bank res[0x5f]; /* */
+};
+
+struct exynos5420_gpio_part3 {
struct s5p_gpio_bank x0; /* 0x1340_0C00 */
struct s5p_gpio_bank x1; /* 0x1340_0C20 */
struct s5p_gpio_bank x2; /* 0x1340_0C40 */
struct s5p_gpio_bank x3; /* 0x1340_0C60 */
};
-struct exynos5420_gpio_part3 {
+struct exynos5420_gpio_part4 {
struct s5p_gpio_bank c0;
struct s5p_gpio_bank c1;
struct s5p_gpio_bank c2;
@@ -164,7 +166,7 @@ struct exynos5420_gpio_part3 {
struct s5p_gpio_bank y6;
};
-struct exynos5420_gpio_part4 {
+struct exynos5420_gpio_part5 {
struct s5p_gpio_bank e0; /* 0x1400_ */
struct s5p_gpio_bank e1; /* 0x1400_0020 */
struct s5p_gpio_bank f0; /* 0x1400_0040 */
@@ -175,7 +177,7 @@ struct exynos5420_gpio_part4 {
struct s5p_gpio_bank j4; /* 0x1400_00E0 */
};
-struct exynos5420_gpio_part5 {
+struct exynos5420_gpio_part6 {
struct s5p_gpio_bank z0; /* 0x0386_ */
};
@@ -200,16 +202,20 @@ struct exynos5_gpio_part1 {
struct s5p_gpio_bank y4;
struct s5p_gpio_bank y5;
struct s5p_gpio_bank y6;
- struct s5p_gpio_bank res1[0x3];
+};
+
+struct exynos5_gpio_part2 {
struct s5p_gpio_bank c4;
- struct s5p_gpio_bank res2[0x48];
+};
+
+struct exynos5_gpio_part3 {
struct s5p_gpio_bank x0;
struct s5p_gpio_bank x1;
struct s5p_gpio_bank x2;
struct s5p_gpio_bank x3;
};
-struct exynos5_gpio_part2 {
+struct exynos5_gpio_part4 {
struct s5p_gpio_bank e0;
struct s5p_gpio_bank e1;
struct s5p_gpio_bank f0;
@@ -221,20 +227,25 @@ struct exynos5_gpio_part2 {
struct s5p_gpio_bank h1;
};
-struct exynos5_gpio_part3 {
+struct exynos5_gpio_part5 {
struct s5p_gpio_bank v0;
struct s5p_gpio_bank v1;
- struct s5p_gpio_bank res1[0x1];
+};
+
+struct exynos5_gpio_part6 {
struct s5p_gpio_bank v2;
struct s5p_gpio_bank v3;
- struct s5p_gpio_bank res2[0x1];
+};
+
+struct exynos5_gpio_part7 {
struct s5p_gpio_bank v4;
};
-struct exynos5_gpio_part4 {
+struct exynos5_gpio_part8 {
struct s5p_gpio_bank z;
};
There are also unchanged gpios initializations in files:
- arndale/arndale.c line 19
- smdk5420/smdk5420.c line 45
Thanks
--
Przemyslaw Marczak
Samsung R&D 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 v6 3/4] EXYNOS5: GPIO: Support GPIO Command for EXYNOS5
Hi,
On 04/12/2014 11:43 AM, Akshay Saraswat wrote:
From: Rajeshwari Shinde
This patch adds support for name to gpio conversion in s5p_gpio
to enable gpio command EXYNOS 5250 & 5420.
Function has been added to asm/gpio.h to decode the
input gpio name to gpio number.
Example: SMDK5420 # gpio set gpa00
Signed-off-by: Rajeshwari Shinde
Signed-off-by: Akshay Saraswat
---
arch/arm/include/asm/arch-exynos/gpio.h | 28 +
drivers/gpio/s5p_gpio.c | 105
2 files changed, 133 insertions(+)
diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
b/arch/arm/include/asm/arch-exynos/gpio.h
index 697e6f3..3736a22 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -1038,6 +1038,34 @@ static inline unsigned int get_bank_num(void)
}
}
+/*
+ * This structure helps mapping symbolic GPIO names into indices from
+ * exynos5_gpio_pin/exynos5420_gpio_pin enums.
+ *
+ * By convention, symbolic GPIO name is defined as follows:
+ *
+ * g[p], where
+ * p is optional
+ *- a single character bank name, as defined by the SOC
+ *- a single digit set number
+ *- bit number within the set (in 0..7 range).
+ *
+ * essentially form an octal number of the GPIO pin within the bank
+ * space. On the 5420 architecture some banks' sets do not start not from zero
+ * ('d' starts from 1 and 'j' starts from 4). To compensate for that and
+ * maintain flat number space withoout holes, those banks use offsets to be
+ * deducted from the pin number.
+ */
+struct gpio_name_num_table {
+ char bank; /* bank name symbol */
+ u8 bank_size; /* total number of pins in the bank */
+ char bank_offset; /* offset of the first bank's pin */
+ unsigned int base; /* index of the first bank's pin in the enum */
+};
+
+int s5p_name_to_gpio(const char *name);
+#define name_to_gpio(n) s5p_name_to_gpio(n)
+
void gpio_cfg_pin(int gpio, int cfg);
void gpio_set_pull(int gpio, int mode);
void gpio_set_drv(int gpio, int mode);
diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index b1b6fbe..9a80b0c 100644
--- a/drivers/gpio/s5p_gpio.c
+++ b/drivers/gpio/s5p_gpio.c
@@ -28,6 +28,111 @@
#define RATE_MASK(x) (0x1 << (x + 16))
#define RATE_SET(x) (0x1 << (x + 16))
This driver is common so you can't put here SOC specific code.
This is also the reason of build break for s5pc1xx architecture.
It should be initialized in arch/arm/include/asm/arch-exynos/gpio.h.
The same should be defined for Exynos4 and for s5pc1xx: in
arch/arm/include/asm/arch-s5pc1xx/gpio.h.
This also can require introduce a s5p_gpio.h header with structure
gpio_name_num_table. And maybe better name for this structure type is
gpio_name_to_num ?
+#define GPIO_ENTRY(name, base, top, offset) { name, top - base, offset, base }
+static const struct gpio_name_num_table exynos5_gpio_table[] = {
+ GPIO_ENTRY('a', EXYNOS5_GPIO_A00, EXYNOS5_GPIO_B00, 0),
+ GPIO_ENTRY('b', EXYNOS5_GPIO_B00, EXYNOS5_GPIO_C00, 0),
+ GPIO_ENTRY('c', EXYNOS5_GPIO_C00, EXYNOS5_GPIO_D00, 0),
+ GPIO_ENTRY('d', EXYNOS5_GPIO_D00, EXYNOS5_GPIO_Y00, 0),
+ GPIO_ENTRY('y', EXYNOS5_GPIO_Y00, EXYNOS5_GPIO_C40, 0),
+ GPIO_ENTRY('x', EXYNOS5_GPIO_X00, EXYNOS5_GPIO_E00, 0),
+ GPIO_ENTRY('e', EXYNOS5_GPIO_E00, EXYNOS5_GPIO_F00, 0),
+ GPIO_ENTRY('f', EXYNOS5_GPIO_F00, EXYNOS5_GPIO_G00, 0),
+ GPIO_ENTRY('g', EXYNOS5_GPIO_G00, EXYNOS5_GPIO_H00, 0),
+ GPIO_ENTRY('h', EXYNOS5_GPIO_H00, EXYNOS5_GPIO_V00, 0),
+ GPIO_ENTRY('v', EXYNOS5_GPIO_V00, EXYNOS5_GPIO_Z0, 0),
+ GPIO_ENTRY('z', EXYNOS5_GPIO_Z0, EXYNOS5_GPIO_MAX_PORT, 0),
+ { 0 }
+};
+
+static const struct gpio_name_num_table exynos5420_gpio_table[] = {
+ GPIO_ENTRY('a', EXYNOS5420_GPIO_A00, EXYNOS5420_GPIO_B00, 0),
+ GPIO_ENTRY('b', EXYNOS5420_GPIO_B00, EXYNOS5420_GPIO_H00, 0),
+ GPIO_ENTRY('h', EXYNOS5420_GPIO_H00, EXYNOS5420_GPIO_Y70, 0),
+ GPIO_ENTRY('x', EXYNOS5420_GPIO_X00, EXYNOS5420_GPIO_C00, 0),
+ GPIO_ENTRY('c', EXYNOS5420_GPIO_C00, EXYNOS5420_GPIO_D10, 0),
+ GPIO_ENTRY('d', EXYNOS5420_GPIO_D10, EXYNOS5420_GPIO_Y00, 010),
+ GPIO_ENTRY('y', EXYNOS5420_GPIO_Y00, EXYNOS5420_GPIO_E00, 0),
+ GPIO_ENTRY('e', EXYNOS5420_GPIO_E00, EXYNOS5420_GPIO_F00, 0),
+ GPIO_ENTRY('f', EXYNOS5420_GPIO_F00, EXYNOS5420_GPIO_G00, 0),
+ GPIO_ENTRY('g', EXYNOS5420_GPIO_G00, EXYNOS5420_GPIO_J40, 0),
+ GPIO_ENTRY('j', EXYNOS5420_GPIO_J40, EXYNOS5420_GPIO_Z0, 040),
+ GPIO_ENTRY('z', EXYNOS5420_GPIO_Z0, EXYNOS5420_GPIO_MAX_PORT, 0),
+ { 0 }
+};
+
+int s5p_name_to_gpio(const char *name)
+{
+ unsigned num, irregular_set_number, irregular_bank_base;
+ const struct gpio_name_num_table *tabp;
+ char this_bank, bank_name, irregular_bank_name;
+ char *endp;
+
+ /*
+* The gpio name starts with either
Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
Hi,
I missed this email before.
On 04/14/2014 04:55 PM, Akshay Saraswat wrote:
Hi Minkyu, Simon and Lukasz,
Dear Akshay,
On 14/04/14 19:53, Lukasz Majewski wrote:
Hi Akshay,
Hi Lukasz,
Hi Akshay,
I'm not Samsung tree maintainer, but by chance I've come across those
patches and...
First question - why have you omitted u-boot-samsung tree maintainer?
I've added Minkyu to CC.
Minkyu has an email ID "proms...@gmail.com" and I added that in CC.
Probably you don't know this email id :-)
I do know it :-), but this is not the official one.
Adding involved people to CC really speed up things :-)
I am always sensing about SAMSUNG related patches.
Please don't worry about it :)
Also in the cover letter you claim that this patch was "build tested"
for Exynos4 based boards. Why didn't you add at least one maintainer
of those boards to CC?
In cover letter I have not mentioned anywhere that I have built or
tested these patches over Exynos4.
Patch 2/4 says "Build tested"
because Rajeshwari did build images for Exynos4 boards and that was
successfull but nobody tested booting those images.
As Przemek written to you in the other mail. There is a build problem
with trats2/trats boards.
Please fix it.
I do not possess any Exynos4 board.
That is why it is a good practice to ask maintainer's of those boards
to test it for you.
These patches are meant for
Exynos5 only.
No. please consider Exynos4 also.
If you make patches for Exynos4 too, then it will be great job.
Przemek or Lukasz will help your test.
I borrowed an Origen board and doing changes for Exynos4 as well.
I'll push next patch-set tomorrow with Exynos4 and 5 support together.
Great. Please look at my comments. If you finish work with your patches
then I add the same feature for s5pc1xx.
We will probably go with your approach to make (_finally_) the gpio code
consistent for Exynos4/5.
But Yes, there are compiler errors introduced for
smkc100 because of this new patch-set and I will fix them in the next
patch-set.
next patch-set means v7? right?
Yes, next patch set would be v7.
I'm a bit confused now. Was this patch set build tested or not?
+
+/* A list of valid GPIO numbers for the asm-generic/gpio.h
interface */ +enum exynos5_gpio_pin {
+ /* GPIO_PART1_STARTS */
+ EXYNOS5_GPIO_A00, /* 0 */
+ EXYNOS5_GPIO_A01,
+ EXYNOS5_GPIO_A02,
+ EXYNOS5_GPIO_A03,
+ EXYNOS5_GPIO_A04,
According to the patch description, you had a compilation error when
were adding the support for Exynos 5250 and 5420. Why you fix the
problem by rewriting the whole framework?
This framework is not intended to fix compiler warnings or errors but
to make GPIO numbering easy to remember and sequential, without any
holes in between.
Samsung boards were swinging from part+bank+pin number approach to
sequential GPIO number from time to time. I think it is a good
time to clean things up.
IN the patch 2/4 you have:
- gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
- gpio_set_pull(start + i, GPIO_PULL_NONE);
- gpio_set_drv(start + i, GPIO_DRV_4X);
+ gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
+ gpio_set_pull(start + i, S5P_GPIO_PULL_NONE);
+ gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
What is the rationale to change the name to S5P_GPIO and not stick to
GPIO_FUNC? In which way gpios for Exynos5 are different than for
Exynos4? Cannot we finally reuse the Exynos 4 and 5 code?
We have enum member GPIO_INPUT in common/cmd_gpio.c and GPIO_INPUT
define in arch-exynos/gpio.h. To remove such conflicts we renamed all
s5p defines from "GPIO_*" to "S5P_GPIO_*".
We are using the same s5p_gpio.c for both Exynos4 and 5 as far as I
know. I dont get the exact issue here. Do you want me to remove
"S5P_". Is that it ?
S5P_ corresponds to at most Exynos4 SoC (Up till S5PV310). However,
since the file is named s5p_gpio.c, then I think that S5P_ is a
appropriate prefix.
Actually I have plan to rename from S5P_ to EXYNOS_. but not now.
It look OK to me.
With the same patch:
- case PERIPH_ID_UART1:
- bank = &gpio1->d0;
- start = 0;
+ start = EXYNOS5_GPIO_D00;
What is wrong with specifying the bank field?
Why your gpio command cannot use the bank approach?
Ultimately we are using banks and pin_nums specific to the bank only
after we extract exact bank from the sequential pin_num.
Ok.
And one more question: Is this work compliant with new driver model,
which will be accepted at the merge window after the v2014.04
release?
If not, then there is no point to review this code, since GPIO would
need to be adjusted to use this framework.
Please explain more. I don't get this as well :-)
My point is that the new driver model (introduced by Simon) is going to
be included. I'm concern if after introduction of it we would need to
rewrite the gpio code to comply wit
Re: [U-Boot] Strange CFI flash problem
On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer wrote:
> Am 14.04.2014 08:09, schrieb Matthias Weißer:
>
>> Hi Wolfgang
>>
>> Am 11.04.2014 12:43, schrieb Wolfgang Denk:
>>>
>>> Dear Matthias,
>>>
>>> In message <5347bbbc.9000...@arcor.de> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01
back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via
tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:
>>>
>>> ...
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5
>>>
>>>
>>> Are you sure your malloc arena is big enough for LZO? Try if
>>> increasing it helps...
>>
>>
>> We increaded it from 4MB to 8MB and the behavior is still the same.
>>
>> We also observed a different behavior when tftping the image to RAM and
>> then directly executing it without copying it to flash. It seems that
>> the flash device (EN29GL256H) is then in some a mode (maybe auto-select)
>> which prevents it from normal read operations which doesn't allow the
>> flash driver of the OS come up. We never saw this with our old u-boot.
>> If there are no ideas left we will have to bisect the problem.
>
>
> Bisecting was successfull. The commit introducing the problem is
>
> commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
> Author: Kees Cook
> Date: Fri Aug 16 07:59:15 2013 -0700
>
> lzo: correctly bounds-check output buffer
>
> This checks the size of the output buffer and fails if it was going to
> overflow the buffer during lzo decompression.
>
> Signed-off-by: Kees Cook
> Acked-by: Simon Glass
>
> This commit introduced the usage of the dst_len output parameter as
> additional input parameter containing the maximum output buffer size. This
> parameter isn't initialized in cmd_bootm.c:
>
> 454 #ifdef CONFIG_LZO
> 455 case IH_COMP_LZO: {
> 456 size_t size;
> 457
> 458 printf(" Uncompressing %s ... ", type_name);
> 459
> 460 ret = lzop_decompress(image_buf, image_len, load_buf, &size);
>
> Setting size to some big value (SZE_MAX is not avialable) fixed the behavior
> but I am unsure if this is the correct solution. I think its hard to get the
> max output buffer size at this point in cmd_bootm.c.
Does this work?
---
From: Kees Cook
Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by: Matthias Weißer
Signed-off-by: Kees Cook
---
common/cmd_bootm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9751edc..c243a5b 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images,
unsigned long *load_end,
#endif /* CONFIG_LZMA */
#ifdef CONFIG_LZO
case IH_COMP_LZO: {
- size_t size;
+ size_t size = unc_len;
printf(" Uncompressing %s ... ", type_name);
--
1.7.9.5
--
Kees Cook
Chrome OS Security
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6slevk: Add SPI NOR flash support
On Sun, Apr 13, 2014 at 2:29 AM, Marek Vasut wrote: > On Saturday, April 12, 2014 at 07:50:35 PM, Jagan Teki wrote: > [...] > >> >> > diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h >> >> > index 1876dbf..3d05a64 100644 >> >> > --- a/include/configs/mx6slevk.h >> >> > +++ b/include/configs/mx6slevk.h >> >> > @@ -10,6 +10,7 @@ >> >> > >> >> > #define __CONFIG_H >> >> > >> >> > #include >> >> > >> >> > +#include >> >> > >> >> > #include >> >> > #include "mx6_common.h" >> >> > >> >> > @@ -196,4 +197,15 @@ >> >> > >> >> > #define CONFIG_CMD_CACHE >> >> > #endif >> >> > >> >> > +#define CONFIG_CMD_SF >> >> > +#ifdef CONFIG_CMD_SF >> >> > +#define CONFIG_SPI_FLASH >> >> > +#define CONFIG_SPI_FLASH_STMICRO >> >> > +#define CONFIG_MXC_SPI >> >> > +#define CONFIG_SF_DEFAULT_BUS 0 >> >> >> >> *no_need* to define DEFAULT_BUS as 0 - it's default. >> > >> > We better be explicit here. >> >> *explicit* fine - don't you think defining a default value may >> increase extra macro which looks *duplicate* > > No. > > Explicitly defining the value in the board file serves well for people who > will > dig in the SPI on this particular MX6 board as it will make it immediatelly > clear to them which SPI bus is the SPI NOR sitting on. It makes things easily > tweakable as well. Ok. > Also, is there any reason to put asterisks around random words in the > sentence? For important words in a sentence. I saw could be see couple of warnings on this. Reviewed-by: Jagannadha Sutradharudu Teki thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers
On Fri, Apr 11, 2014 at 12:47 AM, Andrew Ruder wrote: > On Fri, Apr 11, 2014 at 12:33:45AM +0530, Jagan Teki wrote: >> >> It would be great if you mentioned issue scenario for status poll case >> >> drivers/mtd/spi/sf_ops.c: ret = spi_xfer(spi, 8, NULL, >> >> &status, 0); >> OK - means issue only with soft_spi.c is it? > > Yes, and a couple other drivers. > >> Can you share the issue log or typical use case scenario w.r.t soft_spi.c, >> I need to understand how this got resolved with your change. > > Yes, you actually posted one such case that will not work "correctly" > with soft_spi. In the line of code you posted above, soft_spi will > actually perform a read from address 0x0. In most cases, the read side > isn't a huge deal, but on the write side it can cause all kinds of > surprises. > >> I understand you assigned '0' when dout is NULL and you took the buf >> only when din is !NULL. > > Yes, just handling NULL case to be how most drivers are handling it and > how apparently most users of the spi modules (like mtd/spi/sf_ops) are > clearly expecting it to work. I saw some check-patch issues, can you fix - plan to apply. thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] i2c: sh_i2c: bugfix: i2c probe command does not work
On Mon, Apr 14, 2014 at 05:13:57PM +0900, Tetsuyuki Kobayashi wrote:
> This is regression of commit 2035d77d i2c: sh_i2c: Update to new
> CONFIG_SYS_I2C framework
>
> Before commit 2035d77d, i2c probe command works properly on kzm9g board.
>
> KZM-A9-GT# i2c probe
> Valid chip addresses: 0C 12 1D 32 39 3D 40 60
>
> After commit 2035d77d, i2c probe command does not work.
>
> KZM-A9-GT# i2c probe
> Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11
> 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B
> 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45
> 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
> 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79
> 7A 7B 7C 7D 7E 7F
>
> sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does
> not read device at all. This patch prepares dummy buffer and read data into
> it.
>
> Signed-off-by: Tetsuyuki Kobayashi
> ---
> Changes for v2:
> - correct typo in commit message.
>
> Changes for v3:
> - prepare dummy data buffer and use it to avoid NULL access.
>
> drivers/i2c/sh_i2c.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
> index cc19100..e7e9692 100644
> --- a/drivers/i2c/sh_i2c.c
> +++ b/drivers/i2c/sh_i2c.c
> @@ -269,7 +269,9 @@ static int sh_i2c_write(struct i2c_adapter *adap, uint8_t
> chip, uint addr,
> static int
> sh_i2c_probe(struct i2c_adapter *adap, u8 dev)
> {
> - return sh_i2c_read(adap, dev, 0, 0, NULL, 0);
> + u8 dummy[1];
> +
> + return sh_i2c_read(adap, dev, 0, 0, dummy, sizeof dummy);
> }
>
> static unsigned int sh_i2c_set_bus_speed(struct i2c_adapter *adap,
I will take this patch as-is, but please use sizeof(foo) rather than
sizeof foo. It's valid but uncommon syntax for the project, 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] Pull request: u-boot-sh/rmobile into u-boot-arm/master
On Mon, Apr 14, 2014 at 05:53:19PM +0900, Nobuhiro Iwamatsu wrote: > Dear Albert Aribaud, > > Please pull u-boot-sh/rmobile into u-boot-arm/master. > I want to merge these fixes into 2014.04. Could you please merge these? > > Best regards, > Nobuhiro > > The following changes since commit 1b82491ee6ee1e986e5521b33692a00e1f38fe75: > > board:tricorder: fixup SPL OOB layout (2014-04-11 10:08:42 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to fc56da0b2fd092fabf2af98a75db323a0d432297: > > arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD (2014-04-14 17:42:30 +0900) > > > Tetsuyuki Kobayashi (2): > i2c: sh_i2c: bugfix: i2c probe command does not work > arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD > > drivers/i2c/sh_i2c.c| 4 +++- > include/configs/kzm9g.h | 1 + > 2 files changed, 4 insertions(+), 1 deletion(-) 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
[U-Boot] [ANN] U-Boot v2014.04 released
Hey all, I've pushed v2014.04 out to the repository and tarballs should exist soon. As always, lots of nice little fixes here and there and everywhere. Since I've had a few requests to include some sort of ChangeLog (other than what git spits out), here's what I've come up with: - Improve 'test' command, add -e for file exists on FAT and ext4 (and ext2/3 when using ext4 support). - Switch to Kbuild for build system. - tools-only build target, to build just the host tools - Slight build speed improvement - Can no longer do 'make fooboard' but can do 'make fooboard_config all' - Under the hood DFU improvements - New arc architecture support - Sandbox now has a display - Further device tree usage on Samsung platforms - Better HW RAND support, generate UUIDs when making new a new GPT if none are provided. And I would encourge custodians to follow-up with anything big I've overlooked. Thanks for the hard work everyone! The merge window is now open until Saturday May 03 2014. -- 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] U-Boot Loop
Hi James, I'm using U-Boot 2010.06 (Jun 18 2013 - 14:03:16) Thanks Dang -Original Message- From: James Chargin [mailto:jimccr...@gmail.com] Sent: Friday, April 11, 2014 9:46 AM To: u-boot@lists.denx.de; Tran, Dang Subject: Re: [U-Boot] U-Boot Loop Greetings, On 04/11/2014 09:23 AM, Tran, Dang wrote: > Hi, > > I'm running a PowerPC board that uses U-Boot and I get into this loop (see > terminal output below). > It doesn't matter how I get into this loop. What I really care about is how > to break out of it without manually resetting the board. > Is there a way to break out of this loop and reset the system via the > terminal? Ctrl-X and Ctrl-C doesn't seem to do anything. > It might be helpful to know which version of U-Boot you are using. > > > TERMINAL OUTPUT > Waiting for PHY auto negotiation to complete.. TIMEOUT ! > eTSEC1: No link. > Speed: 1000, full duplex > Using eTSEC2 device > TFTP from server 192.168.128.127; our IP address is 192.168.128.128 Filename > 'oe/bsp/mvme2500/vxWorks'. > Load address: 0x100 > Loading: T T T T T T T T T T > Retry count exceeded; starting again > Waiting for PHY auto negotiation to complete.. TIMEOUT ! For U-Boot builds made from official sources, ctrl-C works for me to terminate the retry TFTP, as shown => # with no Ethernet connection... => tftp 50 test.txt Waiting for PHY auto negotiation to completeuser interrupt! eTSEC1: No link. show_boot_progress(-81) boot fail => # in the above, "user interrupt!" was the response to ^C => => # 10.10.0.10 is known to not exist => setenv serverip 10.10.0.10 => tftp 50 test.txt Speed: 1000, full duplex Using eTSEC1 device TFTP from server 10.10.0.10; our IP address is 10.10.0.15 Filename 'test.txt'. Load address: 0x50 Loading: T T Abort show_boot_progress(-81) boot fail => # in the above, "Abort" was the response to ^C => Please make sure your serial communication terminal emulator correctly transmits the ctrl-C when you type it. To see if this works, get to a U-Boot prompt and type ctrl-C, you should see > ... > > > Thanks > Dang > > > This email is non-binding, is subject to contract, and neither Kulicke & > Soffa Industries Inc nor its subsidiaries shall have any obligation to you to > consummate the transactions herein or to enter into any agreement, other than > in accordance with the terms and conditions of a definitive agreement if and > when negotiated, finalized and executed between the parties. This sort of disclaimer in email to the U-Boot mailing list is frowned upon. Please try to eliminate it for any future postings. Best regards, Jim --- Jim Chargin AJA Video Systems j...@aja.com (530) 271-3334 http://www.aja.com This email is non-binding, is subject to contract, and neither Kulicke & Soffa Industries Inc nor its subsidiaries shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.04 released
Hi Tom, On Mon, 14 Apr 2014 15:20:25 -0400, Tom Rini wrote: > Hey all, > > I've pushed v2014.04 out to the repository and tarballs should exist > soon. > > As always, lots of nice little fixes here and there and everywhere. > Since I've had a few requests to include some sort of ChangeLog (other > than what git spits out), here's what I've come up with: > > - Improve 'test' command, add -e for file exists on FAT and ext4 (and > ext2/3 when using ext4 support). > - Switch to Kbuild for build system. > - tools-only build target, to build just the host tools > - Slight build speed improvement > - Can no longer do 'make fooboard' but can do 'make fooboard_config > all' > - Under the hood DFU improvements > - New arc architecture support > - Sandbox now has a display > - Further device tree usage on Samsung platforms > - Better HW RAND support, generate UUIDs when making new a new GPT if > none are provided. > > And I would encourge custodians to follow-up with anything big I've > overlooked. > > Thanks for the hard work everyone! The merge window is now open until > Saturday May 03 2014. Thanks to you Tom. I have fast-forwarded the ARM repo to 2014.04. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Loop
On 04/14/2014 01:11 PM, Tran, Dang wrote: Hi James, I'm using U-Boot 2010.06 (Jun 18 2013 - 14:03:16) This is a version of U-Boot that is even older than the version I used for my demonstration that ctrl-c works. (I used 2010.12) You should make efforts towards using a more recent version. What information can you provide as to the settings of your serial terminal emulator? Is it known to send your ctrl-c to the target device? Jim -- Jim Chargin AJA Video Systems j...@aja.com (530) 271-3334 http://www.aja.com Thanks Dang -Original Message- From: James Chargin [mailto:jimccr...@gmail.com] Sent: Friday, April 11, 2014 9:46 AM To: u-boot@lists.denx.de; Tran, Dang Subject: Re: [U-Boot] U-Boot Loop Greetings, On 04/11/2014 09:23 AM, Tran, Dang wrote: Hi, I'm running a PowerPC board that uses U-Boot and I get into this loop (see terminal output below). It doesn't matter how I get into this loop. What I really care about is how to break out of it without manually resetting the board. Is there a way to break out of this loop and reset the system via the terminal? Ctrl-X and Ctrl-C doesn't seem to do anything. It might be helpful to know which version of U-Boot you are using. TERMINAL OUTPUT Waiting for PHY auto negotiation to complete.. TIMEOUT ! eTSEC1: No link. Speed: 1000, full duplex Using eTSEC2 device TFTP from server 192.168.128.127; our IP address is 192.168.128.128 Filename 'oe/bsp/mvme2500/vxWorks'. Load address: 0x100 Loading: T T T T T T T T T T Retry count exceeded; starting again Waiting for PHY auto negotiation to complete.. TIMEOUT ! For U-Boot builds made from official sources, ctrl-C works for me to terminate the retry TFTP, as shown => # with no Ethernet connection... => tftp 50 test.txt Waiting for PHY auto negotiation to completeuser interrupt! eTSEC1: No link. show_boot_progress(-81) boot fail => # in the above, "user interrupt!" was the response to ^C => => # 10.10.0.10 is known to not exist => setenv serverip 10.10.0.10 => tftp 50 test.txt Speed: 1000, full duplex Using eTSEC1 device TFTP from server 10.10.0.10; our IP address is 10.10.0.15 Filename 'test.txt'. Load address: 0x50 Loading: T T Abort show_boot_progress(-81) boot fail => # in the above, "Abort" was the response to ^C => Please make sure your serial communication terminal emulator correctly transmits the ctrl-C when you type it. To see if this works, get to a U-Boot prompt and type ctrl-C, you should see ... Thanks Dang This email is non-binding, is subject to contract, and neither Kulicke & Soffa Industries Inc nor its subsidiaries shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. This sort of disclaimer in email to the U-Boot mailing list is frowned upon. Please try to eliminate it for any future postings. Best regards, Jim --- Jim Chargin AJA Video Systems j...@aja.com (530) 271-3334 http://www.aja.com This email is non-binding, is subject to contract, and neither Kulicke & Soffa Industries Inc nor its subsidiaries shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Loop
Jim, I'm using TeraTerm version 2.3. I can send Ctrl-C the board. However when I'm in this looping mode I can't. >From what you descried, version 2010.12 works and maybe I should update to a >later version and see if that fixes my issue. Thanks Dang -Original Message- From: James Chargin [mailto:jimccr...@gmail.com] Sent: Monday, April 14, 2014 2:10 PM To: Tran, Dang; u-boot@lists.denx.de Subject: Re: [U-Boot] U-Boot Loop On 04/14/2014 01:11 PM, Tran, Dang wrote: > Hi James, > > I'm using U-Boot 2010.06 (Jun 18 2013 - 14:03:16) This is a version of U-Boot that is even older than the version I used for my demonstration that ctrl-c works. (I used 2010.12) You should make efforts towards using a more recent version. What information can you provide as to the settings of your serial terminal emulator? Is it known to send your ctrl-c to the target device? Jim -- Jim Chargin AJA Video Systems j...@aja.com (530) 271-3334 http://www.aja.com > > Thanks > Dang > > -Original Message- > From: James Chargin [mailto:jimccr...@gmail.com] > Sent: Friday, April 11, 2014 9:46 AM > To: u-boot@lists.denx.de; Tran, Dang > Subject: Re: [U-Boot] U-Boot Loop > > Greetings, > > On 04/11/2014 09:23 AM, Tran, Dang wrote: >> Hi, >> >> I'm running a PowerPC board that uses U-Boot and I get into this loop (see >> terminal output below). >> It doesn't matter how I get into this loop. What I really care about is how >> to break out of it without manually resetting the board. >> Is there a way to break out of this loop and reset the system via the >> terminal? Ctrl-X and Ctrl-C doesn't seem to do anything. >> > > It might be helpful to know which version of U-Boot you are using. > >> >> >> TERMINAL OUTPUT >> Waiting for PHY auto negotiation to complete.. TIMEOUT ! >> eTSEC1: No link. >> Speed: 1000, full duplex >> Using eTSEC2 device >> TFTP from server 192.168.128.127; our IP address is 192.168.128.128 Filename >> 'oe/bsp/mvme2500/vxWorks'. >> Load address: 0x100 >> Loading: T T T T T T T T T T >> Retry count exceeded; starting again >> Waiting for PHY auto negotiation to complete.. TIMEOUT ! > > For U-Boot builds made from official sources, ctrl-C works for me to > terminate the retry TFTP, as shown > > => # with no Ethernet connection... > => tftp 50 test.txt > Waiting for PHY auto negotiation to completeuser interrupt! > eTSEC1: No link. > show_boot_progress(-81) boot fail > => # in the above, "user interrupt!" was the response to ^C => => # > 10.10.0.10 is known to not exist => setenv serverip 10.10.0.10 => tftp 50 > test.txt > Speed: 1000, full duplex > Using eTSEC1 device > TFTP from server 10.10.0.10; our IP address is 10.10.0.15 Filename 'test.txt'. > Load address: 0x50 > Loading: T T > Abort > show_boot_progress(-81) boot fail > => # in the above, "Abort" was the response to ^C => > > > Please make sure your serial communication terminal emulator correctly > transmits the ctrl-C when you type it. To see if this works, get to a U-Boot > prompt and type ctrl-C, you should see > >> ... > >> >> >> Thanks >> Dang >> >> >> This email is non-binding, is subject to contract, and neither Kulicke & >> Soffa Industries Inc nor its subsidiaries shall have any obligation to you >> to consummate the transactions herein or to enter into any agreement, other >> than in accordance with the terms and conditions of a definitive agreement >> if and when negotiated, finalized and executed between the parties. > > This sort of disclaimer in email to the U-Boot mailing list is frowned upon. > Please try to eliminate it for any future postings. > > Best regards, > Jim > --- > Jim Chargin > AJA Video Systems j...@aja.com > (530) 271-3334 http://www.aja.com > > This email is non-binding, is subject to contract, and neither Kulicke & > Soffa Industries Inc nor its subsidiaries shall have any obligation to you to > consummate the transactions herein or to enter into any agreement, other than > in accordance with the terms and conditions of a definitive agreement if and > when negotiated, finalized and executed between the parties. > This email is non-binding, is subject to contract, and neither Kulicke & Soffa Industries Inc nor its subsidiaries shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] i2c: sh_i2c: bugfix: i2c probe command does not work
(2014/04/15 4:17), Tom Rini wrote:
On Mon, Apr 14, 2014 at 05:13:57PM +0900, Tetsuyuki Kobayashi wrote:
This is regression of commit 2035d77d i2c: sh_i2c: Update to new CONFIG_SYS_I2C
framework
Before commit 2035d77d, i2c probe command works properly on kzm9g board.
KZM-A9-GT# i2c probe
Valid chip addresses: 0C 12 1D 32 39 3D 40 60
After commit 2035d77d, i2c probe command does not work.
KZM-A9-GT# i2c probe
Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12
13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C
2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46
47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A
7B 7C 7D 7E 7F
sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does
not read device at all. This patch prepares dummy buffer and read data into it.
Signed-off-by: Tetsuyuki Kobayashi
---
Changes for v2:
- correct typo in commit message.
Changes for v3:
- prepare dummy data buffer and use it to avoid NULL access.
drivers/i2c/sh_i2c.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
index cc19100..e7e9692 100644
--- a/drivers/i2c/sh_i2c.c
+++ b/drivers/i2c/sh_i2c.c
@@ -269,7 +269,9 @@ static int sh_i2c_write(struct i2c_adapter *adap, uint8_t
chip, uint addr,
static int
sh_i2c_probe(struct i2c_adapter *adap, u8 dev)
{
- return sh_i2c_read(adap, dev, 0, 0, NULL, 0);
+ u8 dummy[1];
+
+ return sh_i2c_read(adap, dev, 0, 0, dummy, sizeof dummy);
}
static unsigned int sh_i2c_set_bus_speed(struct i2c_adapter *adap,
I will take this patch as-is, but please use sizeof(foo) rather than
sizeof foo. It's valid but uncommon syntax for the project, thanks!
I understand about sizeof(foo).
Anyway thank you very much!
U-Boot v2014.04 works fine on kzm9g board.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.04 released
Hi Tom, On 14 April 2014 12:20, Tom Rini wrote: > Hey all, > > I've pushed v2014.04 out to the repository and tarballs should exist > soon. > > As always, lots of nice little fixes here and there and everywhere. > Since I've had a few requests to include some sort of ChangeLog (other > than what git spits out), here's what I've come up with: > > - Improve 'test' command, add -e for file exists on FAT and ext4 (and > ext2/3 when using ext4 support). > - Switch to Kbuild for build system. > - tools-only build target, to build just the host tools > - Slight build speed improvement > - Can no longer do 'make fooboard' but can do 'make fooboard_config > all' > - Under the hood DFU improvements > - New arc architecture support > - Sandbox now has a display > - Further device tree usage on Samsung platforms > - Better HW RAND support, generate UUIDs when making new a new GPT if > none are provided. > > And I would encourge custodians to follow-up with anything big I've > overlooked. > And driver model! > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] fdt_support: add 'const' qualifier for unchanged argument.
Hi Tom, On Thu, 20 Feb 2014 08:31:56 -0500 Tom Rini wrote: > On Thu, Feb 20, 2014 at 05:55:47PM +0900, Masahiro Yamada wrote: > > Hi. > > > > > > > [PATCH 6/9] fdt_support: add 'const' qualifier for unchanged argument. > > > > This might be really trivial, but I notice I had added a period at the > > end of the subject by mistake. > > > > Is it possible to remove it when this patch is applied? > > Or need to post v2? > > I'll do my best to remember to fix it up. > > -- > Tom When and by whom will my fdt_support series be reviewed? This series includes endian bug fixes (and various refactoring), so I believe it is worth the review. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] freescale: m5253demo: fix unused-but-set-variable warnings
Fix the following warning messages:
In function 'flash_erase': 180:21:
warning: variable 'last' set but not used [-Wunused-but-set-variable]
In function 'write_buff': 322:10:
warning: variable 'port_width' set but not used [-Wunused-but-set-variable]
Signed-off-by: Masahiro Yamada
Cc: TsiChung Liew
---
board/freescale/m5253demo/flash.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/board/freescale/m5253demo/flash.c
b/board/freescale/m5253demo/flash.c
index 387e454..16bba59 100644
--- a/board/freescale/m5253demo/flash.c
+++ b/board/freescale/m5253demo/flash.c
@@ -177,7 +177,7 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
{
FPWV *addr;
int flag, prot, sect, count;
- ulong type, start, last;
+ ulong type, start;
int rcode = 0, flashtype = 0;
if ((s_first < 0) || (s_first > s_last)) {
@@ -217,7 +217,6 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
flag = disable_interrupts();
start = get_timer(0);
- last = start;
if ((s_last - s_first) == (CONFIG_SYS_SST_SECT - 1)) {
if (prot == 0) {
@@ -319,14 +318,13 @@ int write_buff(flash_info_t * info, uchar * src, ulong
addr, ulong cnt)
{
ulong wp, count;
u16 data;
- int rc, port_width;
+ int rc;
if (info->flash_id == FLASH_UNKNOWN)
return 4;
/* get lower word aligned address */
wp = addr;
- port_width = sizeof(FPW);
/* handle unaligned start bytes */
if (wp & 1) {
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kbuild: sync with Linux Kernel v3.15-rc1
This commit imports Kbuild-related updates from v3.14 to v3.15-rc1. - commit 3d3d6b8474204b6819688c9800774d52d370a538 kbuild: LLVMLinux: Adapt warnings for compilation with clang - commit 61163efae02040f66a95c8ed17f4407951ba58fa kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang - commit 79192ca8ebd9a25c583aa46024a250fef1e7766f scripts: objdiff: detect object code changes between two commits - commit 1c9e70a55b088d97a59241744fe459409d0c3582 kbuild: create a build directory automatically for out-of-tree build - commit a03fcb50e816a69acffb13b5e56db75063aeba8a kbuild: remove redundant '.*.cmd' pattern from make distclean - commit 13338935f1574a2dcd1c891461b0dcc42f8cff42 kbuild: move "quote" to Kbuild.include to be consistent - commit bfdfaeae500a3b194b73b01e92a8034791a58b7f kbuild: specify build_docproc as a phony target - commit f4d4ffc03efc864645b990e1d579bbe1b8e358a4 kbuild: dtbs_install: new make target - commit 1e64ff42ea3d8d2fc8aa71f9717b3c1cb6c2f893 Kbuild, lto: Disable LTO for asm-offsets.c - commit ccbef1674a1579842c7dbdf554efca85d2cd245a Kbuild, lto: add ld-version and ld-ifversion macros - commit ae63b2d7bdd9bd66b88843be0daf8e37d8f0b574 scripts/tags.sh: Ignore *.mod.c - commit e36aaea28972c57a32a3ba5365e61633739719b9 kbuild: Fix silent builds with make-4 Signed-off-by: Masahiro Yamada --- Makefile | 49 ++--- scripts/Kbuild.include | 10 scripts/Makefile | 2 +- scripts/Makefile.build | 14 - scripts/Makefile.lib | 16 -- scripts/ld-version.sh | 8 +++ scripts/objdiff| 141 + 7 files changed, 227 insertions(+), 13 deletions(-) create mode 100755 scripts/ld-version.sh create mode 100755 scripts/objdiff diff --git a/Makefile b/Makefile index c91c10e..970a219 100644 --- a/Makefile +++ b/Makefile @@ -127,7 +127,7 @@ saved-output := $(KBUILD_OUTPUT) KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \ && /bin/pwd) $(if $(KBUILD_OUTPUT),, \ - $(error output directory "$(saved-output)" does not exist)) + $(error failed to create output directory "$(saved-output)")) PHONY += $(MAKECMDGOALS) sub-make @@ -205,7 +205,14 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ else echo sh; fi ; fi) HOSTCC = gcc +HOSTCXX = g++ HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +HOSTCXXFLAGS = -O2 + +ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1) +HOSTCFLAGS += -Wno-unused-value -Wno-unused-parameter \ + -Wno-missing-field-initializers -fno-delete-null-pointer-checks +endif ifeq ($(HOSTOS),cygwin) HOSTCFLAGS += -ansi @@ -301,12 +308,26 @@ endif # If the user is running make -s (silent mode), suppress echoing of # commands +ifneq ($(filter 4.%,$(MAKE_VERSION)),) # make-4 +ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),) + quiet=silent_ +endif +else # make-3.8x ifneq ($(filter s% -s%,$(MAKEFLAGS)),) quiet=silent_ endif +endif export quiet Q KBUILD_VERBOSE +ifneq ($(CC),) +ifeq ($(shell $(CC) -v 2>&1 | grep -c "clang version"), 1) +COMPILER := clang +else +COMPILER := gcc +endif +export COMPILER +endif # Look for make include files relative to root of kernel src MAKEFLAGS += --include-dir=$(srctree) @@ -368,8 +389,9 @@ export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_ve # Files to ignore in find ... statements -RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS \ - -o -name .pc -o -name .hg -o -name .git \) -prune -o +export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o \ + -name CVS -o -name .pc -o -name .hg -o -name .git \) \ + -prune -o export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn \ --exclude CVS --exclude .pc --exclude .hg --exclude .git @@ -523,6 +545,20 @@ endif KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector) +ifeq ($(COMPILER),clang) +KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,) +KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,) +KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable) +KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier) +KBUILD_CFLAGS += $(call cc-disable-warning, gnu) +# Quiet clang warning: comparison of unsigned expression < 0 is always false +KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare) +# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the +# source of a reference will be _MergedGlobals and not on of the whitelisted names. +# See modpost pattern 2 +KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,) +endif + KBUILD_CFLAGS += -
[U-Boot] [PATCH] kbuild: docbook: sync with Linux Kernel v3.15-rc1
This commit imports DocBook-related updates from v3.14 to v3.15-rc1. - commit ec3fadd64b9940baa2a369bf978e8561837db3f5 kbuild: docbook: use $(obj) and $(src) rather than specific path - commit 100da4c0150c97ce34d4d3b38bf2f5449b05ae4f kbuild: docbook: specify KERNELDOC dependency correctly - commit 6f89b9c1d6b29eaa600ac4a8ac1314b0d06f15e3 kbuild: docbook: include cmd files more simply - commit ac6d662a95a6989d83b259ccf8ec01dd7903af73 doc: Add "*.svg" to DocBook/.gitignore - commit 832919bfcf0cfd75767c68b0c61f7cf48be860a8 DocBook: Make mandocs parallel-safe - commit c4d79a4799719f2b0cd354ee498aad605730c97e work around xmlto bug in htmldocs Signed-off-by: Masahiro Yamada --- doc/DocBook/.gitignore | 1 + doc/DocBook/Makefile | 28 +--- 2 files changed, 10 insertions(+), 19 deletions(-) diff --git a/doc/DocBook/.gitignore b/doc/DocBook/.gitignore index 720f245..7ebd546 100644 --- a/doc/DocBook/.gitignore +++ b/doc/DocBook/.gitignore @@ -10,5 +10,6 @@ *.out *.png *.gif +*.svg media-indices.tmpl media-entities.tmpl diff --git a/doc/DocBook/Makefile b/doc/DocBook/Makefile index 9b4a9b6..593237f 100644 --- a/doc/DocBook/Makefile +++ b/doc/DocBook/Makefile @@ -26,6 +26,7 @@ PS_METHOD = $(prefer-db2x) # The targets that may be used. PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs +targets += $(DOCBOOKS) BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) xmldocs: $(BOOKS) sgmldocs: xmldocs @@ -44,17 +45,18 @@ htmldocs: $(HTML) MAN := $(patsubst %.xml, %.9, $(BOOKS)) mandocs: $(MAN) + $(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9) installmandocs: mandocs mkdir -p /usr/local/man/man9/ - install doc/DocBook/man/*.9.gz /usr/local/man/man9/ + install $(obj)/man/*.9.gz /usr/local/man/man9/ ### #External programs used KERNELDOC = $(srctree)/scripts/kernel-doc DOCPROC = $(objtree)/scripts/docproc -XMLTOFLAGS = -m $(srctree)/doc/DocBook/stylesheet.xsl +XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl XMLTOFLAGS += --skip-validation ### @@ -76,21 +78,9 @@ define rule_docproc ) > $(dir $@).$(notdir $@).cmd endef -%.xml: %.tmpl FORCE +%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE $(call if_changed_rule,docproc) -### -#Read in all saved dependency files -cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd)) - -ifneq ($(cmd_files),) - include $(cmd_files) -endif - -### -# Changes in kernel-doc force a rebuild of all documentation -$(BOOKS): $(KERNELDOC) - # Tell kbuild to always build the programs always := $(hostprogs-y) @@ -128,16 +118,16 @@ quiet_cmd_db2pdf = PDF $@ index = index.html -main_idx = doc/DocBook/$(index) +main_idx = $(obj)/$(index) build_main_index = rm -rf $(main_idx); \ echo 'U-Boot Bootloader HTML Documentation' >> $(main_idx) && \ echo 'U-Boot Version: $(UBOOTVERSION)' >> $(main_idx) && \ cat $(HTML) >> $(main_idx) quiet_cmd_db2html = HTML$@ - cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \ + cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \ echo ' \ -$(patsubst %.html,%,$(notdir $@))' > $@ + $(patsubst %.html,%,$(notdir $@))' > $@ %.html:%.xml @(which xmlto > /dev/null 2>&1) || \ @@ -149,7 +139,7 @@ quiet_cmd_db2html = HTML$@ cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi quiet_cmd_db2man = MAN $@ - cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi + cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi %.9 : %.xml @(which xmlto > /dev/null 2>&1) || \ (echo "*** You need to install xmlto ***"; \ -- 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] kbuild: create a build directory automatically for out-of-tree build
Hi Tom, On Fri, 28 Mar 2014 11:37:28 +0900 Masahiro Yamada wrote: > Hi Tom, > > > On Thu, 27 Mar 2014 13:20:33 -0400 > Tom Rini wrote: > > > On Mon, Mar 24, 2014 at 05:41:47PM -0600, Simon Glass wrote: > > > +Tom > > > > > > On 23 March 2014 22:55, Masahiro Yamada wrote: > > > > > > > Prior to Kbuild, the build system created a build directory, > > > > when it did not exist, for out-of-tree build. > > > > > > > > This feature was dropped when we switched to Kbuild > > > > because many of lines in makefiles were copied from Linux Kernel. > > > > (In Linux Kernel, we have to create a build directory by ourselves > > > > before starting build.) > > > > > > > > That feature seems worth reviving for less typing > > > > even if our code and Linux Kernel diverge. > > > > > > > > Signed-off-by: Masahiro Yamada > > > > Suggested-by: Simon Glass > > > > > > > > > > Acked-by: Simon Glass > > > Tested-by: Simon Glass > > > > > > Arguably could be a bug-fix for this release. > > > > Yeah, I like this and will pick it up. The only question is, has this > > idea already been rejected in the kernel? > > > > I have not sent this patch to the kernel community yet. > OK. I will. > The good news is this feature was merged in Linux Kernel mainline (commit 1c9e70a55). Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kbuild: add user-supplied CPPFLAGS, AFLAGS and CFLAGS
Like Linux Kernel, this commit provides environment variables KCPPFLAGS, KAFLAGS and KCFLAGS, which are useful to pass additional options. Signed-off-by: Masahiro Yamada --- Makefile | 5 + 1 file changed, 5 insertions(+) diff --git a/Makefile b/Makefile index 970a219..0191869 100644 --- a/Makefile +++ b/Makefile @@ -584,6 +584,11 @@ endif export CONFIG_SYS_TEXT_BASE +# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments +KBUILD_CPPFLAGS += $(KCPPFLAGS) +KBUILD_AFLAGS += $(KAFLAGS) +KBUILD_CFLAGS += $(KCFLAGS) + # Use UBOOTINCLUDE when you must reference the include/ directory. # Needed to be compatible with the O= option UBOOTINCLUDE:= \ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Strange CFI flash problem
Am 14.04.2014 17:38, schrieb Kees Cook:
On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer wrote:
Am 14.04.2014 08:09, schrieb Matthias Weißer:
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Dear Matthias,
In message <5347bbbc.9000...@arcor.de> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01
back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via
tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:
...
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5
Are you sure your malloc arena is big enough for LZO? Try if
increasing it helps...
We increaded it from 4MB to 8MB and the behavior is still the same.
We also observed a different behavior when tftping the image to RAM and
then directly executing it without copying it to flash. It seems that
the flash device (EN29GL256H) is then in some a mode (maybe auto-select)
which prevents it from normal read operations which doesn't allow the
flash driver of the OS come up. We never saw this with our old u-boot.
If there are no ideas left we will have to bisect the problem.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook
Date: Fri Aug 16 07:59:15 2013 -0700
lzo: correctly bounds-check output buffer
This checks the size of the output buffer and fails if it was going to
overflow the buffer during lzo decompression.
Signed-off-by: Kees Cook
Acked-by: Simon Glass
This commit introduced the usage of the dst_len output parameter as
additional input parameter containing the maximum output buffer size. This
parameter isn't initialized in cmd_bootm.c:
454 #ifdef CONFIG_LZO
455 case IH_COMP_LZO: {
456 size_t size;
457
458 printf(" Uncompressing %s ... ", type_name);
459
460 ret = lzop_decompress(image_buf, image_len, load_buf, &size);
Setting size to some big value (SZE_MAX is not avialable) fixed the behavior
but I am unsure if this is the correct solution. I think its hard to get the
max output buffer size at this point in cmd_bootm.c.
Does this work?
Yes. Didn't saw that configuration option. Thanks.
---
From: Kees Cook
Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by: Matthias Weißer
Signed-off-by: Kees Cook
---
common/cmd_bootm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9751edc..c243a5b 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images,
unsigned long *load_end,
#endif /* CONFIG_LZMA */
#ifdef CONFIG_LZO
case IH_COMP_LZO: {
- size_t size;
+ size_t size = unc_len;
printf(" Uncompressing %s ... ", type_name);
Tested-by: Matthias Weißer
Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Hi, Tom.
I am grateful that you have been working during the vacation.
And thanks for release 2014.04.
Best regards,
Nobuhiro
2014-04-15 4:20 GMT+09:00 Tom Rini :
> On Mon, Apr 14, 2014 at 05:53:19PM +0900, Nobuhiro Iwamatsu wrote:
>
>> Dear Albert Aribaud,
>>
>> Please pull u-boot-sh/rmobile into u-boot-arm/master.
>> I want to merge these fixes into 2014.04. Could you please merge these?
>>
>> Best regards,
>> Nobuhiro
>>
>> The following changes since commit 1b82491ee6ee1e986e5521b33692a00e1f38fe75:
>>
>> board:tricorder: fixup SPL OOB layout (2014-04-11 10:08:42 -0400)
>>
>> are available in the git repository at:
>>
>> git://git.denx.de/u-boot-sh.git master
>>
>> for you to fetch changes up to fc56da0b2fd092fabf2af98a75db323a0d432297:
>>
>> arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD (2014-04-14 17:42:30 +0900)
>>
>>
>> Tetsuyuki Kobayashi (2):
>> i2c: sh_i2c: bugfix: i2c probe command does not work
>> arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD
>>
>> drivers/i2c/sh_i2c.c| 4 +++-
>> include/configs/kzm9g.h | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> Applied to u-boot/master, thanks!
>
> --
> Tom
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Enhance get_sys_info() to check clocking mode
T1040 and it's variants provide "Single Oscillator Source" Reference Clock Mode.
In this mode, single onboard oscillator(DIFF_SYSCLK) can provide the reference
clock
(100MHz) to the following PLLs:
• Platform PLL
• Core PLLs
• USB PLL
• DDR PLL, etc
The cfg_eng_use0 of porsr1 register identifies whether the SYSCLK
(single-ended) or
DIFF_SYSCLK (differential) is selected as the clock input to the chip.
get_sys_info has been enhanced to add the diff_sysclk so that the
various drivers can be made aware of ths diff sysclk configuration and
act accordingly.
Other changes:
-single_src to ddr_refclk_sel, as it is use for checking ddr reference clock
-Removed the print of single_src from get_sys_info as this will be
-printed whenever somebody calls get_sys_info which is not appropriate.
-Add print of single_src in checkcpu as it is called only once during
initialization
Signed-off-by: Poonam Aggrwal
Signed-off-by: Priyanka Jain
Signed-off-by: Vijay Rai
---
arch/powerpc/cpu/mpc85xx/cpu.c|5 +
arch/powerpc/cpu/mpc85xx/speed.c | 21 +
arch/powerpc/include/asm/immap_85xx.h |6 ++
include/e500.h|3 +++
4 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index cb7efc9..0697123 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -129,6 +129,11 @@ int checkcpu (void)
get_sys_info(&sysinfo);
+#ifdef CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
+ if (sysinfo.diff_sysclk == 1)
+ puts("Single Source Clock Configuration\n");
+#endif
+
puts("Clock Configuration:");
for_each_cpu(i, core, nr_cores, mask) {
if (!(i & 3))
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 74e3c1b..d516d4e 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -74,28 +74,33 @@ void get_sys_info(sys_info_t *sys_info)
uint ratio[CONFIG_SYS_FSL_NUM_CC_PLLS];
unsigned long sysclk = CONFIG_SYS_CLK_FREQ;
uint mem_pll_rat;
-#ifdef CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
- uint single_src;
-#endif
sys_info->freq_systembus = sysclk;
#ifdef CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
+ uint ddr_refclk_sel;
+ unsigned int porsr1_sys_clk;
+ porsr1_sys_clk = in_be32(&gur->porsr1) >> FSL_DCFG_PORSR1_SYSCLK_SHIFT
+ & FSL_DCFG_PORSR1_SYSCLK_MASK;
+ if (porsr1_sys_clk == FSL_DCFG_PORSR1_SYSCLK_DIFF)
+ sys_info->diff_sysclk = 1;
+ else
+ sys_info->diff_sysclk = 0;
+
/*
* DDR_REFCLK_SEL rcw bit is used to determine if DDR PLLS
* are driven by separate DDR Refclock or single source
* differential clock.
*/
- single_src = (in_be32(&gur->rcwsr[5]) >>
+ ddr_refclk_sel = (in_be32(&gur->rcwsr[5]) >>
FSL_CORENET2_RCWSR5_DDR_REFCLK_SEL_SHIFT) &
FSL_CORENET2_RCWSR5_DDR_REFCLK_SEL_MASK;
/*
-* For single source clocking, both ddrclock and syclock
+* For single source clocking, both ddrclock and sysclock
* are driven by differential sysclock.
*/
- if (single_src == FSL_CORENET2_RCWSR5_DDR_REFCLK_SINGLE_CLK) {
- printf("Single Source Clock Configuration\n");
+ if (ddr_refclk_sel == FSL_CORENET2_RCWSR5_DDR_REFCLK_SINGLE_CLK)
sys_info->freq_ddrbus = CONFIG_SYS_CLK_FREQ;
- } else
+ else
#endif
#ifdef CONFIG_DDR_CLK_FREQ
sys_info->freq_ddrbus = CONFIG_DDR_CLK_FREQ;
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index a178187..3ca142d 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1583,6 +1583,12 @@ typedef struct cpc_corenet {
typedef struct ccsr_gur {
u32 porsr1; /* POR status 1 */
u32 porsr2; /* POR status 2 */
+#ifdef CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
+#defineFSL_DCFG_PORSR1_SYSCLK_SHIFT15
+#defineFSL_DCFG_PORSR1_SYSCLK_MASK 0x1
+#defineFSL_DCFG_PORSR1_SYSCLK_SINGLE_ENDED 0x1
+#defineFSL_DCFG_PORSR1_SYSCLK_DIFF 0x0
+#endif
u8 res_008[0x20-0x8];
u32 gpporcr1; /* General-purpose POR configuration */
u32 gpporcr2; /* General-purpose POR configuration 2 */
diff --git a/include/e500.h b/include/e500.h
index 0c24326..5884a22 100644
--- a/include/e500.h
+++ b/include/e500.h
@@ -24,6 +24,9 @@ typedef struct
#ifdef CONFIG_SYS_DPAA_PME
unsigned long freq_pme;
#endif
+#ifdef CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
+ unsigned char diff_sysclk;
+#endif
} MPC85xx_SYS_INFO;
#endif /* _ASMLANGUAGE */
--
1.6.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http
Re: [U-Boot] [PATCH v6 1/4] EXYNOS5: Add gpio pin numbering feature
Hi Simon, > Hi Lukasz, > > On 14 April 2014 01:17, Lukasz Majewski > wrote: > > [snip[ > > I think your questions are mostly answered but I wanted to chime in > on a few. > > What is wrong with specifying the bank field? > > Why your gpio command cannot use the bank approach? > > > > U-Boot has a generic GPIO API and we should try to use it where > possible. This has been a long-standing TODO for exynos. I'm also fully aware that Exynos suffers from inconsistent gpio API. However, I'm very glad that with Akshay's and our effort this goal will be accomplished :-) > > > > > > And one more question: Is this work compliant with new driver model, > > which will be accepted at the merge window after the v2014.04 > > release? > > > > If not, then there is no point to review this code, since GPIO would > > need to be adjusted to use this framework. > > > > The driver model framework is already in mainline. I was rather thinking about the "big switch" as we did with KBUILD after the v2014.01. Anyway, I'm looking forward to see the wide deployment of device model in u-boot. > At present only > sandbox uses it for GPIO. I started looking at exynos since I thought > it might be quite easy to convert, but found that the generic GPIO > stuff was still not merged. > > This series will make it much easier to convert exynos GPIO to driver > model, since we can just change the driver. Thanks for clarification. > > Regards, > Simon > -- Best regards, Lukasz Majewski Samsung R&D 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] [ANN] U-Boot v2014.04 released
Hi Tom, > And I would encourge custodians to follow-up with anything big I've > overlooked. > > Thanks for the hard work everyone! The merge window is now open until > Saturday May 03 2014. A few minor patches were omitted, though :-). http://patchwork.ozlabs.org/patch/337795/ http://patchwork.ozlabs.org/patch/337796/ Those were actually Acked-by Minkyu Kang, Samsung tree maintainer. Also, I think, that this doc entry (acked by Simon Glass) would be valuable for v2014.04 release. http://patchwork.ozlabs.org/patch/337454/ -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
