date:20170703

Re: Observations with AT91SAM9263-EK

2017-07-03 Thread Sam Ravnborg

On Tue, Jul 04, 2017 at 12:34:58AM +0800, Jean-Christophe PLAGNIOL-VILLARD 
wrote:
> 
> > On 4 Jul 2017, at 12:19 AM, Sam Ravnborg  wrote:
> > 
> > Hi all.
> > 
> > I recently purchased an AT91SAM9263-EK from ebay and
> > have played around a little with barebox.
> > For now only some observations.
> > 
> > I had the impression that I could
> > drop AT91BootStrap when using barebox.
> 
> Yes Wrote the support for that but on the 9263 you are limited.
> 
> you have 2 choice boot a small barebox <= 72kiB
> 
> or use a console less barebox to boot the second barebox
> 
> as the rom code on at91 will load the barebox from the SD or Nand
> into SRAM

Thanks for the info.
I will try to collect this in a at91.rst file in Documentation/boards/
When there is something useful I will post a patch for review.

> > 
> > But I could not make it boot until I deployed 
> > at91bootstrap (named BOOT.BIN) on the SD-card.
> > And I named arch/arm/pbl/zbarebox.bin => u-boot.bin
> > on the SD-card.
> > 
> 
> on 9263ek you have a nor flash so why not flash it
> 
> in this case barebox will boot by itself
> 
> without the bootstrap

The EK only have NAND, the NOR is not mounted.
But anyway - the idea here is to have a testbed for my at91
patches that I can use before I send them upstream.

I have a proprietary at91sam9263 based board that
I will try to add support for in barebox.
But only the parts touching the atmel boards are relevant for the
upstream barebox.

Step 1 was to get barebox workign with the EK, and with
the two small patches I already sent it looks like I
had some luck there.

Sam

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 1/2] clk: fix clk_get error handling

2017-07-03 Thread Sam Ravnborg

>From feaf9f379a1100b3e56faa83e22360b25a5eb904 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg 
Date: Mon, 3 Jul 2017 21:21:02 +0200
Subject: [PATCH 1/2] clk: fix clk_get error handling
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

If there is no OFTREE support of_clk_get_by_name failed with
-ENOENT, which caused clk_get to bail out.
This had the effect that nothing was printed on the serial console
with at91sam9263-ek.

Fix this by modifying the logic to explicitly check for -EPROBE_DEFER
like we do in the kernel.

Fixes: 90f7eacb ("clk: let clk_get return errors from of_clk_get_by_name")
Cc: Uwe Kleine-König 
Signed-off-by: Sam Ravnborg 
---
 drivers/clk/clkdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 6b1666355..939b067cc 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -181,7 +181,7 @@ struct clk *clk_get(struct device_d *dev, const char 
*con_id)
 
if (dev) {
clk = of_clk_get_by_name(dev->device_node, con_id);
-   if (!IS_ERR(clk) || PTR_ERR(clk) != -ENODEV)
+   if (!IS_ERR(clk) || PTR_ERR(clk) == -EPROBE_DEFER)
return clk;
}
 
-- 
2.12.0


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Observations with AT91SAM9263-EK

2017-07-03 Thread Jean-Christophe PLAGNIOL-VILLARD


> On 4 Jul 2017, at 12:19 AM, Sam Ravnborg  wrote:
> 
> Hi all.
> 
> I recently purchased an AT91SAM9263-EK from ebay and
> have played around a little with barebox.
> For now only some observations.
> 
> I had the impression that I could
> drop AT91BootStrap when using barebox.

Yes Wrote the support for that but on the 9263 you are limited.

you have 2 choice boot a small barebox <= 72kiB

or use a console less barebox to boot the second barebox

as the rom code on at91 will load the barebox from the SD or Nand
into SRAM
> 
> But I could not make it boot until I deployed 
> at91bootstrap (named BOOT.BIN) on the SD-card.
> And I named arch/arm/pbl/zbarebox.bin => u-boot.bin
> on the SD-card.
> 

on 9263ek you have a nor flash so why not flash it

in this case barebox will boot by itself

without the bootstrap

Best Regards,
J. 
> I wanted to boot barebox - but nothing happened.
> So I tried older versions af barebox:
> 
> v2017.06.0 => Boots OK (did not try to load a kernel)
> 
> v2017.07.0 => Boots but emits:
> NULL pointer dereference at address 0x0014
> ### Please RESET the board ###
> (A bit more was written to the serial console)
> 

> master from git => Nothing written to the console at all
> 
> I will as time permits dig deeper into this.
> Seems like we are facing two bugs:
> One that causes the NULL pointer, and another that
> prevents any output.
> 
> As barebox is quick to build and the bug is simple to spot
> I will likely just try to bisect and see where I end up.
> 
>   Sam
> 
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Observations with AT91SAM9263-EK

2017-07-03 Thread Sam Ravnborg

Hi all.

I recently purchased an AT91SAM9263-EK from ebay and
have played around a little with barebox.
For now only some observations.

I had the impression that I could
drop AT91BootStrap when using barebox.

But I could not make it boot until I deployed 
at91bootstrap (named BOOT.BIN) on the SD-card.
And I named arch/arm/pbl/zbarebox.bin => u-boot.bin
on the SD-card.

I wanted to boot barebox - but nothing happened.
So I tried older versions af barebox:

v2017.06.0 => Boots OK (did not try to load a kernel)

v2017.07.0 => Boots but emits:
NULL pointer dereference at address 0x0014
### Please RESET the board ###
(A bit more was written to the serial console)

master from git => Nothing written to the console at all

I will as time permits dig deeper into this.
Seems like we are facing two bugs:
One that causes the NULL pointer, and another that
prevents any output.

As barebox is quick to build and the bug is simple to spot
I will likely just try to bisect and see where I end up.

Sam

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH] readlink: Improve -f handling

2017-07-03 Thread Ian Abbott

For `readlink -f FILE VARIABLE`, set VARIABLE to the absolute, canonical
file name of FILE by following symbolic links.  All but the final
component of FILE must exist.

Prior to commit a602bebcf7e4 ("fs: Implement links to directories") the
above worked in the limited case where FILE was an absolute path, the
final component was a symbolic link, and all preceding components were
directories.  If FILE was a relative path with the final component being
a symbolic link, and all preceding paths being directories, the command
sort of worked, but produced a relative path as the result.  Both of
these cases were broken by the above commit.

Signed-off-by: Ian Abbott 
---
 commands/readlink.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/commands/readlink.c b/commands/readlink.c
index a19c8e004..2dfa56667 100644
--- a/commands/readlink.c
+++ b/commands/readlink.c
@@ -44,17 +44,21 @@ static int do_readlink(int argc, char *argv[])
if (argc < optind + 2)
return COMMAND_ERROR_USAGE;
 
-   if (readlink(argv[optind], realname, PATH_MAX - 1) < 0)
-   goto err;
-
if (canonicalize) {
-   char *buf = canonicalize_path(realname);
+   char *buf = canonicalize_path(argv[optind]);
+   struct stat s;
 
if (!buf)
goto err;
+   if (stat(dirname(argv[optind]), ) || !S_ISDIR(s.st_mode)) {
+   free(buf);
+   goto err;
+   }
setenv(argv[optind + 1], buf);
free(buf);
} else {
+   if (readlink(argv[optind], realname, PATH_MAX - 1) < 0)
+   goto err;
setenv(argv[optind + 1], realname);
}
 
@@ -65,15 +69,16 @@ err:
 }
 
 BAREBOX_CMD_HELP_START(readlink)
-BAREBOX_CMD_HELP_TEXT("Read value of a symbolic link and store it into 
VARIABLE.")
+BAREBOX_CMD_HELP_TEXT("Read value of a symbolic link or canonical file name 
and store it into VARIABLE.")
 BAREBOX_CMD_HELP_TEXT("")
 BAREBOX_CMD_HELP_TEXT("Options:")
-BAREBOX_CMD_HELP_OPT ("-f", "canonicalize by following first symlink");
+BAREBOX_CMD_HELP_OPT("-f", "canonicalize by following symlinks;")
+BAREBOX_CMD_HELP_OPT("",   "final component need not exist");
 BAREBOX_CMD_HELP_END
 
 BAREBOX_CMD_START(readlink)
.cmd= do_readlink,
-   BAREBOX_CMD_DESC("read value of a symbolic link")
+   BAREBOX_CMD_DESC("read value of a symbolic link or canonical file name")
BAREBOX_CMD_OPTS("[-f] FILE VARIABLE")
BAREBOX_CMD_GROUP(CMD_GRP_FILE)
BAREBOX_CMD_HELP(cmd_readlink_help)
-- 
2.11.0


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Barebox Environment and State placed on eMMC boot partition

2017-07-03 Thread Martin Hollingsworth

Hi folks,
I am currently enabling the bootchooser framework on my system and need some 
advice on where to place the bootchooser variables so that I can read and write 
them from linux (marking a successful boot).

My system uses eMMC as storage and offers an extra bootloader partition 
(boot0), which is 2MB and implemented completely in hardware. Currently I split 
boot0 into 1MB for barebox and 1MB for bbenv. I add the partition layouts in 
barebox using devfs_add_partition("mmc3.boot0", OFFSET, SIZE, 
DEVFS_PARTITION_FIXED, "mmc3.barebox0-env") in the env_init() function. The 
bootchooser variables are currently stored as non-volatile variables in the 
bbenv.

However under linux boot0 is shown as a raw device. To read and write bbenv I 
have to first dump the env from boot0 to a file using dd and the correct 
offsets, import the dump using bareboxenv from dt-utils, change the values and 
do the same steps backwards until overwriting env with dd again. This works, 
but it feels overly complicated, error prone due to manual offsets and my gut 
tells me there might be a better solution.

If I understand chapters 6.1 and 6.2 from the documentation correctly, this can 
be simplified by defining the environment or state nodes within the devicetree 
file (dts). However my eMMC device is not listed in the dts and is rather 
detected during runtime - hence the boot partition reports under barebox as 
/dev/mmc3.boot0 and under linux as /dev/mmcblk3boot0. So now I fail to define a 
"device-path = " entry for Barebox Environment and a "backend =" entry for 
Barebox State within the dts file as needed by the environment and/or state 
framework.

Anyone have a clue what I might be overlocking here? Someone have a barebox 
tutorial handy that is running on an eMMC based device?

Thanks and cheers,
Martin

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] gpiolib: fix: do not access oftree on non-OFDEVICE boards

2017-07-03 Thread Lucas Stach

Am Sonntag, den 02.07.2017, 22:24 +0200 schrieb Alexander Kurz:
> Non-OFDEVICE boards may have OFTREE=y set, e.g. by BOOTM_OFTREE.
> Attempts to browse the oftree will crash barebox on those boards.
> 
> Signed-off-by: Alexander Kurz 
> ---
>  drivers/gpio/gpiolib.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a3e17ad..a1ff965 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -416,7 +416,10 @@ int gpiochip_add(struct gpio_chip *chip)
>   for (i = chip->base; i < chip->base + chip->ngpio; i++)
>   gpio_desc[i].chip = chip;
>  
> - return of_gpiochip_scan_hogs(chip);
> + if (IS_ENABLED(CONFIG_OFDEVICE))
> + return of_gpiochip_scan_hogs(chip);
> + else
> + return 0;

This may also crash in mixed oftree/board file based systems (however
unlikely that is). I think an early return from of_gpiochip_scan_hogs ()
if chip->dev->device_node is NULL would be more robust.

Regards,
Lucas


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 5/8] video: tc358767: fix timing calculation

2017-07-03 Thread Lucas Stach

Am Freitag, den 30.06.2017, 14:43 +0300 schrieb Andrey Gusakov:
> Fields in HTIM01 and HTIM02 regs should be even.
> Recomended thresh_dly value is max_tu_symbol.
> ---
>  drivers/video/tc358767.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/video/tc358767.c b/drivers/video/tc358767.c
> index 033da4fb2..d2c94c616 100644
> --- a/drivers/video/tc358767.c
> +++ b/drivers/video/tc358767.c
> @@ -730,13 +730,15 @@ err_dpcd_inval:
>   return -EINVAL;
>  }
>  
> +#define EVEN_HI(val) ((val + 1) & (~0x01))
> +

Please use the commonly used ALIGN instead of defining this on your own.

>  static int tc_set_video_mode(struct tc_data *tc, struct fb_videomode *mode)
>  {
>   int ret;
>   int htotal;
>   int vtotal;
>   int vid_sync_dly;
> - int max_tu_symbol;
> + int max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
>  
>   htotal = mode->hsync_len + mode->left_margin + mode->xres +
>   mode->right_margin;
> @@ -750,14 +752,18 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
> fb_videomode *mode)
>   mode->upper_margin, mode->lower_margin, mode->vsync_len);
>   dev_dbg(tc->dev, "total: %dx%d\n", htotal, vtotal);
>  
> -
> - /* LCD Ctl Frame Size */
> - tc_write(VPCTRL0, (0x40 << 20) /* VSDELAY */ |
> + /*
> +  * Datasheet is not clear of vsdelay in case of DPI
> +  * assume we do not need any delay when DPI is a source of
> +  * sync signals
> +  */
> + tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
>OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
> - tc_write(HTIM01, (mode->left_margin << 16) |/* H back porch 
> */
> -  (mode->hsync_len << 0));   /* Hsync */
> - tc_write(HTIM02, (mode->right_margin << 16) |   /* H front 
> porch */
> -  (mode->xres << 0));/* width */
> + /* LCD Ctl Frame Size */
> + tc_write(HTIM01, (EVEN_HI(mode->left_margin) << 16) |   /* H back porch 
> */
> +  (EVEN_HI(mode->hsync_len) << 0));  /* Hsync */
> + tc_write(HTIM02, (EVEN_HI(mode->right_margin) << 16) |  /* H front 
> porch */
> +  (EVEN_HI(mode->xres) << 0));   /* width */
>   tc_write(VTIM01, (mode->upper_margin << 16) |   /* V back porch 
> */
>(mode->vsync_len << 0));   /* Vsync */
>   tc_write(VTIM02, (mode->lower_margin << 16) |   /* V front 
> porch */
> @@ -776,7 +782,7 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
> fb_videomode *mode)
>   /* DP Main Stream Attributes */
>   vid_sync_dly = mode->hsync_len + mode->left_margin + mode->xres;
>   tc_write(DP0_VIDSYNCDELAY,
> -  (0x003e << 16) |   /* thresh_dly */
> +  (max_tu_symbol << 16) |/* thresh_dly */
>(vid_sync_dly << 0));
>  
>   tc_write(DP0_TOTALVAL, (vtotal << 16) | (htotal));
> @@ -798,7 +804,6 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
> fb_videomode *mode)
>*  (output active video bandwidth in bytes))
>* Must be less than tu_size.
>*/
> - max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
>   tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) 
> | BPC_8);
>  
>   return 0;



___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH] Revert "param: fix stub prototype of dev_add_param"

2017-07-03 Thread Lucas Stach

This reverts commit 441941f5a664e0333d78ee480ea8b974a9a99d9d, which was on
top of the recently reverted nvvar rework, so needs to be reverted, too.

Signed-off-by: Lucas Stach 
---
 include/param.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/param.h b/include/param.h
index 2592a09c3afc..b618a2305d89 100644
--- a/include/param.h
+++ b/include/param.h
@@ -104,8 +104,8 @@ static inline struct param_d *get_param_by_name(struct 
device_d *dev,
 }
 
 static inline struct param_d *dev_add_param(struct device_d *dev, const char 
*name,
-   int (*set)(struct param_d *p, const char *val),
-   const char *(*get)(struct param_d *p),
+   int (*set)(struct device_d *dev, struct param_d *p, const char 
*val),
+   const char *(*get)(struct device_d *, struct param_d *p),
unsigned long flags)
 {
return ERR_PTR(-ENOSYS);
-- 
2.11.0


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Observations with AT91SAM9263-EK

[PATCH 1/2] clk: fix clk_get error handling

Re: Observations with AT91SAM9263-EK

Observations with AT91SAM9263-EK

[PATCH] readlink: Improve -f handling

Barebox Environment and State placed on eMMC boot partition

Re: [PATCH] gpiolib: fix: do not access oftree on non-OFDEVICE boards

Re: [PATCH 5/8] video: tc358767: fix timing calculation

[PATCH] Revert "param: fix stub prototype of dev_add_param"

9 matches

Site Navigation

Mail list logo

Footer information