Re: [PATCH 4/7] ARM: socfpga: add arria10 support

2017-04-04 Thread Trent Piepho 
On Mon, 2017-04-03 at 12:55 +0200, Steffen Trumtrar wrote:

> + vco = src_hz;
> + vco /= (1 + denom);
> + vco *= (1 + numer);

Don't you get rounding error by dividing first?

> + /* dedicated pins */
> + writel(pinmux->dedicated_io_4, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 0x0c);
> + writel(pinmux->dedicated_io_5, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 0x10);
> + writel(pinmux->dedicated_io_6, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 0x14);
> + writel(pinmux->dedicated_io_7, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 0x18);
> + writel(pinmux->dedicated_io_8, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 0x1c);
> + writel(pinmux->dedicated_io_9, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 0x20);
> + writel(pinmux->dedicated_io_10, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 
> 0x24);
> + writel(pinmux->dedicated_io_11, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 
> 0x28);
> + writel(pinmux->dedicated_io_12, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 
> 0x2c);
> + writel(pinmux->dedicated_io_13, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 
> 0x30);
> + writel(pinmux->dedicated_io_14, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 
> 0x34);
> + writel(pinmux->dedicated_io_15, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 
> 0x38);
> + writel(pinmux->dedicated_io_16, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 
> 0x3c);
> + writel(pinmux->dedicated_io_17, ARRIA10_PINMUX_DEDICATED_IO_ADDR + 
> 0x40);
> +
> + writel(pinmux->cfg_dedicated_io_bank, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x00);
> + writel(pinmux->cfg_dedicated_io_1, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x04);
> + writel(pinmux->cfg_dedicated_io_2, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x08);
> + writel(pinmux->cfg_dedicated_io_3, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x0c);
> + writel(pinmux->cfg_dedicated_io_4, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x10);
> + writel(pinmux->cfg_dedicated_io_5, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x14);
> + writel(pinmux->cfg_dedicated_io_6, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x18);
> + writel(pinmux->cfg_dedicated_io_7, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x1c);
> + writel(pinmux->cfg_dedicated_io_8, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x20);
> + writel(pinmux->cfg_dedicated_io_9, ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR 
> + 0x24);
> + writel(pinmux->cfg_dedicated_io_10, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x28);
> + writel(pinmux->cfg_dedicated_io_11, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x2c);
> + writel(pinmux->cfg_dedicated_io_12, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x30);
> + writel(pinmux->cfg_dedicated_io_13, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x3c);
> + writel(pinmux->cfg_dedicated_io_14, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x38);
> + writel(pinmux->cfg_dedicated_io_15, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x3c);
> + writel(pinmux->cfg_dedicated_io_16, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x40);
> + writel(pinmux->cfg_dedicated_io_17, 
> ARRIA10_PINMUX_DEDICATED_IO_CFG_ADDR + 0x44);

Sure are a lot of copied lines there.  Wouldn't an array and loop be
more elegant?


> +void arria10_reset_deassert_dedicated_peripherals(void)
> +{
> + uint32_t mask0 = 0;
> + uint32_t mask1 = 0;
> + uint32_t mask = 0;
> +
> + mask |= ARRIA10_RSTMGR_PER0MODRST_SDMMCECC;
> + mask |= ARRIA10_RSTMGR_PER0MODRST_QSPIECC;
> + mask |= ARRIA10_RSTMGR_PER0MODRST_NANDECC;
> + mask |= ARRIA10_RSTMGR_PER0MODRST_DMAECC;
> +
> + /* enable ECC OCP first */
> + clrbits_le32(ARRIA10_RSTMGR_ADDR + ARRIA10_RSTMGR_PER0MODRST, mask);
> +
> + mask = 0;
> + mask |= ARRIA10_RSTMGR_PER0MODRST_SDMMC;
> + mask |= ARRIA10_RSTMGR_PER0MODRST_QSPI;
> + mask |= ARRIA10_RSTMGR_PER0MODRST_NAND;
> + mask |= ARRIA10_RSTMGR_PER0MODRST_DMA;

It looks like the peripherals to bring out of reset are hard coded here?
Should unused peripherals be brought out of reset?

> +
> + clrbits_le32(ARRIA10_RSTMGR_ADDR + ARRIA10_RSTMGR_PER0MODRST, mask);
> +
> + mask = ARRIA10_RSTMGR_PER1MODRST_L4SYSTMR0;

How come this time mask isn't set to 0 first like the two blocks above?
I.e., why not write it in a consistent style?

> +
> + mask |= ARRIA10_RSTMGR_PER1MODRST_UART1;
> + mask |= ARRIA10_RSTMGR_PER1MODRST_UART0;
> +
> + clrbits_le32(ARRIA10_RSTMGR_ADDR + ARRIA10_RSTMGR_PER1MODRST, mask);

Is there a reason to bring system timer0, and uart 0 & 1 out of reset
here, and then a bunch of other peripherals in the same register out of
reset below?  Why not do them all at once?

> +
> + mask1 |= ARRIA10_RSTMGR_PER1MODRST_I2C3;
> + mask1 |= ARRIA10_RSTMGR_PER1MODRST_I2C4;
> + mask1 |= ARRIA10_RSTMGR_PER1MODRST_I2C2;
> + mask0 |= ARRIA10_RSTMGR_PER0MODRST_EMACECC1 |
> +  ARRIA10_RSTMGR_PER0MODRST_EMAC1;
> + mask0 |= ARRIA10_RSTMGR_PER0MODRST_EMACECC2 |
> +  ARRIA10_RSTMGR_PER0MODRST_EMAC2;
> + mask0 |= ARRIA10_RSTMGR_PER0MODRST_EMACECC0 |
> +

Re: [PATCH 0/7] SoCFPGA: add support for Arria10

2017-04-04 Thread Trent Piepho 
On Mon, 2017-04-03 at 12:55 +0200, Steffen Trumtrar wrote:
> Although Cyclone5 and Arria10 share a lot of the peripherals,
> they a different in the critical parts (SDRAM controller, clock setup,...)
> 
> The Arria10 has a larger OCRAM (64KB vs 256KB), that is why we can
> omit the xload support for now. The xload support can be added, once
> Arria10 boards that need to program the FPGA very early (might be needed for
> the SDRAM controller) are available.
> 

That means this support doesn't include loading the FPGA from barebox?

The boot strategy is that the Barebox PBL image will fit in OCRAM and be
loaded by the ROM loader, and then the PBL will decompress barebox into
SDRAM?  If so, it will be necessary to have the FPGA loaded from an
external device, such as an EPCQ flash chip, before barebox boots.  As
SDRAM is not accessible until at least the peripheral FPGA image is
loaded.

U-Boot is able to load a FPGA image with a single bootloader.  A U-Boot
image can be made that is small enough run in 256 kB yet has enough
drivers to load an FPGA image from eMMC or NOR flash into the FPGA and
then enable SDRAM.

It seems like this might be possible for barebox as well.  If enough
drivers to load the FPGA were part of the PBL.

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

Re: State Framework and dtb

2017-04-04 Thread Ian Abbott 

On 04/04/17 11:27, Çağlar Kilimci wrote:

Hey,

2017-04-04 11:04 GMT+03:00 Jan Remmet :

On Mon, Apr 03, 2017 at 11:59:50PM +0300, Çağlar Kilimci wrote:

Hello,

2017-03-31 16:00 GMT+03:00 Sascha Hauer :

On Fri, Mar 31, 2017 at 02:41:19PM +0300, Çağlar Kilimci wrote:

Hey,


I tried but got the same result and then I would like to apply your
serious patch series of the state framework but release that our
working branch is 2016.07 so could not apply patches. Let me update
barebox and apply those patches. Are those based on master branch
right?  Or, which branch do you recommend to work on?


The patches are based on master, yes. Anyway, you seem to have a problem
in getting your changes in the dts file to the running barebox. Please
try to add some nodes/properties to your dts file and verify that a
of_dump shows these nodes. Before that is the case it's not worth to
look any further.


Finally, I updated and patched the code and now I can see state@0
device in the of_dump:
state@0 {
magic = <0x27031977>;
compatible = "barebox,state";
backend-type = "raw";
backend = <0x42>;
foo {
reg = <0x0 0x4>;
type = "uint32";
default = <0x0>;
};
bar {
reg = <0x10 0x4>;
type = "enum32";
names = "baz", "qux";
default = <0x1>;
};
};


Here a working example for barebox 2016.11.0 so there may be changes with the
actual state cleanup patches

+   state2: state_socket {
+   magic = <0x456ef363>;
+   compatible = "barebox,state";
+   backend-type = "raw";
+   backend = 


I changed to:
backend = <>;
then it works :)
barebox@Phytec phyCORE AM335x:/ state
registered state instances:
state_socket (backend: raw, path: /dev/eeprom0)


Won't that use the whole EEPROM rather than a partition thereof? 
According to the documentation, you can use:


backend = <>, "partname:state";

assuming the partition has `label = "state";`.

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

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

Re: State Framework and dtb

2017-04-04 Thread Çağlar Kilimci 
Hey,

2017-04-04 11:04 GMT+03:00 Jan Remmet :
> On Mon, Apr 03, 2017 at 11:59:50PM +0300, Çağlar Kilimci wrote:
>> Hello,
>>
>> 2017-03-31 16:00 GMT+03:00 Sascha Hauer :
>> > On Fri, Mar 31, 2017 at 02:41:19PM +0300, Çağlar Kilimci wrote:
>> >> Hey,
>> >>
>> >>
>> >> I tried but got the same result and then I would like to apply your
>> >> serious patch series of the state framework but release that our
>> >> working branch is 2016.07 so could not apply patches. Let me update
>> >> barebox and apply those patches. Are those based on master branch
>> >> right?  Or, which branch do you recommend to work on?
>> >
>> > The patches are based on master, yes. Anyway, you seem to have a problem
>> > in getting your changes in the dts file to the running barebox. Please
>> > try to add some nodes/properties to your dts file and verify that a
>> > of_dump shows these nodes. Before that is the case it's not worth to
>> > look any further.
>>
>> Finally, I updated and patched the code and now I can see state@0
>> device in the of_dump:
>> state@0 {
>> magic = <0x27031977>;
>> compatible = "barebox,state";
>> backend-type = "raw";
>> backend = <0x42>;
>> foo {
>> reg = <0x0 0x4>;
>> type = "uint32";
>> default = <0x0>;
>> };
>> bar {
>> reg = <0x10 0x4>;
>> type = "enum32";
>> names = "baz", "qux";
>> default = <0x1>;
>> };
>> };
>
> Here a working example for barebox 2016.11.0 so there may be changes with the
> actual state cleanup patches
>
> +   state2: state_socket {
> +   magic = <0x456ef363>;
> +   compatible = "barebox,state";
> +   backend-type = "raw";
> +   backend = 

I changed to:
backend = <>;
then it works :)
barebox@Phytec phyCORE AM335x:/ state
registered state instances:
state_socket (backend: raw, path: /dev/eeprom0)

>
> Maybe the missing backend-storage-type is a problem?

As a documentation, it should not be.

Thank you all.

-- 
Çağlar Kilimci

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

Directory mirroring

2017-04-04 Thread Daniel Schultz 

Hi everyone,

my boot partition is mounted to /boot/. Now, I want to make it 
accessible in /mnt/ as mmc or emmc, depending to the bootsource. Sadly, 
ln can only create symlinks for files and two mounts for one device 
seems not to work.


Are there other ways to mirror a file system?

--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz

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

Re: State Framework and dtb

2017-04-04 Thread Jan Remmet 
On Mon, Apr 03, 2017 at 11:59:50PM +0300, Çağlar Kilimci wrote:
> Hello,
> 
> 2017-03-31 16:00 GMT+03:00 Sascha Hauer :
> > On Fri, Mar 31, 2017 at 02:41:19PM +0300, Çağlar Kilimci wrote:
> >> Hey,
> >>
> >>
> >> I tried but got the same result and then I would like to apply your
> >> serious patch series of the state framework but release that our
> >> working branch is 2016.07 so could not apply patches. Let me update
> >> barebox and apply those patches. Are those based on master branch
> >> right?  Or, which branch do you recommend to work on?
> >
> > The patches are based on master, yes. Anyway, you seem to have a problem
> > in getting your changes in the dts file to the running barebox. Please
> > try to add some nodes/properties to your dts file and verify that a
> > of_dump shows these nodes. Before that is the case it's not worth to
> > look any further.
> 
> Finally, I updated and patched the code and now I can see state@0
> device in the of_dump:
> state@0 {
> magic = <0x27031977>;
> compatible = "barebox,state";
> backend-type = "raw";
> backend = <0x42>;
> foo {
> reg = <0x0 0x4>;
> type = "uint32";
> default = <0x0>;
> };
> bar {
> reg = <0x10 0x4>;
> type = "enum32";
> names = "baz", "qux";
> default = <0x1>;
> };
> };

Here a working example for barebox 2016.11.0 so there may be changes with the
actual state cleanup patches

+   state2: state_socket {
+   magic = <0x456ef363>;
+   compatible = "barebox,state";
+   backend-type = "raw";
+   backend = 
+   backend-storage-type = "direct";
+   backend-stridesize = <0x53>;
+
+   stateapi {
+   reg = <0x00 0x1>;
+   type = "uint8";
+   default = <0x0>;
+   };
+   socketid {
+   reg = <0x01 0x1>;
+   type = "uint8";
+   default = <0x0>;
+   };
+
+   socketname {
+   reg = <0x02 0x10>;
+   type = "string";
+   default = "none";
+   };
+
+   socketserial {
+   reg = <0x12 0x19>;
+   type = "string";
+   default = "none";
+   };
+   };
+}

Maybe the missing backend-storage-type is a problem?
Im not sure how I calculate the backend-stridesize last time.


config fragments:
CONFIG_STATE=y
# CONFIG_STATE_CRYPTO is not set
CONFIG_CMD_STATE=y
CONFIG_STATE_DRV=y

Jan

> I can see in the eeprom section, too:
> barebox@Phytec phyCORE AM335x:/ of_dump i2c0
> i2c@44e0b000 {
> compatible = "ti,omap4-i2c";
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> ti,hwmods = "i2c1";
> reg = <0x44e0b000 0x1000>;
> interrupts = <0x46>;
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <0x2c>;
> clock-frequency = <0x61a80>;
> eeprom@52 {
> status = "okay";
> compatible = "atmel,24c32";
> pagesize = <0x20>;
> reg = <0x52>;
> state@1000 {
> label = "state";
> reg = <0x1000 0x1000>;
> linux,phandle = <0x42>;
> phandle = <0x42>;
> };
> };
> };
> 
> But still state command does not show any state device:
> barebox@Phytec phyCORE AM335x:/ state
> registered state instances:
> 
> Here is my diff for the dts:
> diff --git a/arch/arm/dts/am335x-phytec-phycore-som.dtsi
> b/arch/arm/dts/am335x-phytec-phycore-som.dtsi
> index 0b8c454..0d71e8b 100644
> --- a/arch/arm/dts/am335x-phytec-phycore-som.dtsi
> +++ b/arch/arm/dts/am335x-phytec-phycore-som.dtsi
> @@ -14,6 +14,26 @@
> status = "disabled";
> };
> };
> +
> +   state: state@0 {
> +   magic = <0x27031977>;
> +   compatible = "barebox,state";
> +   backend-type = "raw";
> +   backend = <_part>;
> +
> +   foo {
> + reg = <0x00 0x4>;
> + type = "uint32";
> + default = <0x0>;
> +   };
> +
> +   bar {
> + reg = <0x10 0x4>;
> + type = "enum32";
> + names = "baz", "qux";
> + default = <1>;
> +   };
> +   };
>  };
> 
>  _pinmux {
> @@ -148,6 +168,10 @@
> compatible = "atmel,24c32";
>

Re: State Framework and dtb

2017-04-04 Thread Çağlar Kilimci 
2017-04-04 9:22 GMT+03:00 Sascha Hauer :
> On Mon, Apr 03, 2017 at 11:59:50PM +0300, Çağlar Kilimci wrote:
>> Hello,
>>
>> Finally, I updated and patched the code and now I can see state@0
>> device in the of_dump:
>
> Ok, looks good. How does the boot log look like? Still the same?

I think so. Here it is:
barebox 2017.03.0-00129-g444ee36 #1 Mon Apr 3 10:28:04 +03 2017


Board: Phytec phyCORE AM335x
omap-hsmmc 4806.mmc: registered as 4806.mmc
booting from MMC
mmc0: detected SD card version 2.0
mmc0: registered mmc0


barebox 2017.03.0-00153-g880fa12-dirty #3 Mon Apr 3 23:14:34 +03 2017


Board: Phytec phyCORE AM335x
cpsw 4a10.ethernet: detected phy mask 0x3
mdio_bus: miibus0: probed
eth0: got preset MAC address: a0:f6:fd:6c:0d:b0
am335x-phy-driver 47401b00.usb-phy: am_usbphy 87f71cdc enabled
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk
split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
m25p80 m25p80@00: unrecognized JEDEC id bytes: 00,  0,  0
m25p80 m25p80@00: probe failed: No such file or directory
i2c-omap 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
omap-hsmmc 4806.mmc: registered as 4806.mmc
mmc0: detected SD card version 2.0
mmc0: registered mmc0
omap_wdt 44e35000.wdt: OMAP Watchdog Timer Rev 0x01
nand: ONFI flash detected
nand: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xf1 (Micron
MT29F1G08ABADAH4), 128MiB, page size: 2048, OOB size: 64
netconsole: registered as netconsole-1
malloc space: 0x87efef60 -> 0x8fdfdebf (size 127 MiB)
running /env/bin/init...
eth0: 100Mbps full duplex link detected
DHCP client bound to address 192.168.1.29

Hit m for menu or any other key to stop autoboot:3

type exit to get to the menu
barebox@Phytec phyCORE AM335x:/


-- 
Çağlar Kilimci

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

Re: [PATCH] openrisc: fix call to restart_handler_register_fn

2017-04-04 Thread Sascha Hauer 
On Wed, Mar 29, 2017 at 03:45:04PM +0200, Franck Jullien wrote:
> 2017-03-29 8:42 GMT+02:00 Sascha Hauer :
> > On Fri, Mar 24, 2017 at 08:35:22PM +0100, Franck Jullien wrote:
> >> Signed-off-by: Franck Jullien 
> >> ---
> >>  arch/openrisc/cpu/cpu.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/openrisc/cpu/cpu.c b/arch/openrisc/cpu/cpu.c
> >> index d52b021..e7f9445 100644
> >> --- a/arch/openrisc/cpu/cpu.c
> >> +++ b/arch/openrisc/cpu/cpu.c
> >> @@ -41,6 +41,6 @@ static void __noreturn openrisc_restart_cpu(struct 
> >> restart_handler *rst)
> >>
> >>  static int restart_register_feature(void)
> >>  {
> >> - restart_handler_register_fn(openrisc_restart_cpu, NULL, 
> >> RESET_SCOPE_CPU);
> >> + return restart_handler_register_fn(openrisc_restart_cpu);
> >>  }
> >
> > Applied, thanks. It seems I have disabled my openrisc autobuild at some
> > point. Just re-enabled it. Normally such build failures shouldn't
> > happen.
> >
> 
> FYI, you can get the lastest toolchain here:
> 
> https://github.com/openrisc/or1k-gcc/releases/tag/or1k-5.4.0-20170218

Thanks for noting. I just updated my toolchain to the latest one. From a
quick test it seems to work.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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

Re: [PATCH v1] i.MX: hab: fix compile after define renames

2017-04-04 Thread Sascha Hauer 
On Tue, Mar 28, 2017 at 11:14:16AM +0200, Oleksij Rempel wrote:
> Some defines was renamed by this patch:
> | commit 75e98198234ce18ab15f581cf7b52aaf0b46d792
> | i.MX: Add fusemap for VF610
> 
> which was not included in my initial patch. So fix it.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  drivers/hab/hab.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Applied, thanks

Sascha

> 
> diff --git a/drivers/hab/hab.c b/drivers/hab/hab.c
> index 56d49e8e3..512ff7ecf 100644
> --- a/drivers/hab/hab.c
> +++ b/drivers/hab/hab.c
> @@ -126,7 +126,7 @@ static int imx_hab_read_srk_hash_ocotp(u8 *__srk)
>   int ret, i;
>  
>   for (i = 0; i < SRK_HASH_SIZE / sizeof(uint32_t); i++) {
> - ret = imx_ocotp_read_field(IMX6_OCOTP_SRK_HASH(i), [i]);
> + ret = imx_ocotp_read_field(OCOTP_SRK_HASH(i), [i]);
>   if (ret < 0)
>   return ret;
>   }
> @@ -140,13 +140,13 @@ static int imx_hab_write_srk_hash_ocotp(const u8 
> *__newsrk, unsigned flags)
>   int ret, i;
>  
>   for (i = 0; i < SRK_HASH_SIZE / sizeof(uint32_t); i++) {
> - ret = imx_ocotp_write_field(IMX6_OCOTP_SRK_HASH(i), newsrk[i]);
> + ret = imx_ocotp_write_field(OCOTP_SRK_HASH(i), newsrk[i]);
>   if (ret < 0)
>   return ret;
>   }
>  
>   if (flags & IMX_SRK_HASH_WRITE_LOCK) {
> - ret = imx_ocotp_write_field(IMX6_OCOTP_SRK_LOCK, 1);
> + ret = imx_ocotp_write_field(OCOTP_SRK_LOCK, 1);
>   if (ret < 0)
>   return ret;
>   }
> @@ -161,7 +161,7 @@ static int imx_hab_permanent_write_enable_ocotp(int 
> enable)
>  
>  static int imx_hab_lockdown_device_ocotp(void)
>  {
> - return imx_ocotp_write_field(IMX6_OCOTP_SEC_CONFIG, 1);
> + return imx_ocotp_write_field(OCOTP_SEC_CONFIG_1, 1);
>  }
>  
>  static int imx_hab_device_locked_down_ocotp(void)
> @@ -169,7 +169,7 @@ static int imx_hab_device_locked_down_ocotp(void)
>   int ret;
>   unsigned int v;
>  
> - ret = imx_ocotp_read_field(IMX6_OCOTP_SEC_CONFIG, );
> + ret = imx_ocotp_read_field(OCOTP_SEC_CONFIG_1, );
>   if (ret < 0)
>   return ret;
>  
> -- 
> 2.11.0
> 
> 
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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

[PATCH] state: remove unused variable type

2017-04-04 Thread Sascha Hauer 
enum state_variable_type is never used. Remove it.

Signed-off-by: Sascha Hauer 
---
 common/state/state.h   | 10 --
 common/state/state_variables.c |  5 -
 2 files changed, 15 deletions(-)

diff --git a/common/state/state.h b/common/state/state.h
index ead8cc88c1..8e4cbfc215 100644
--- a/common/state/state.h
+++ b/common/state/state.h
@@ -114,20 +114,10 @@ enum state_convert {
STATE_CONVERT_FIXUP,
 };
 
-enum state_variable_type {
-   STATE_TYPE_INVALID = 0,
-   STATE_TYPE_ENUM,
-   STATE_TYPE_U8,
-   STATE_TYPE_U32,
-   STATE_TYPE_MAC,
-   STATE_TYPE_STRING,
-};
-
 struct state_variable;
 
 /* A variable type (uint32, enum32) */
 struct variable_type {
-   enum state_variable_type type;
const char *type_name;
struct list_head list;
int (*export) (struct state_variable *, struct device_node *,
diff --git a/common/state/state_variables.c b/common/state/state_variables.c
index fd072a0c27..5b8e6284d9 100644
--- a/common/state/state_variables.c
+++ b/common/state/state_variables.c
@@ -439,31 +439,26 @@ static struct state_variable *state_string_create(struct 
state *state,
 
 static struct variable_type types[] = {
{
-   .type = STATE_TYPE_U8,
.type_name = "uint8",
.export = state_uint32_export,
.import = state_uint32_import,
.create = state_uint8_create,
}, {
-   .type = STATE_TYPE_U32,
.type_name = "uint32",
.export = state_uint32_export,
.import = state_uint32_import,
.create = state_uint32_create,
}, {
-   .type = STATE_TYPE_ENUM,
.type_name = "enum32",
.export = state_enum32_export,
.import = state_enum32_import,
.create = state_enum32_create,
}, {
-   .type = STATE_TYPE_MAC,
.type_name = "mac",
.export = state_mac_export,
.import = state_mac_import,
.create = state_mac_create,
}, {
-   .type = STATE_TYPE_STRING,
.type_name = "string",
.export = state_string_export,
.import = state_string_import,
-- 
2.11.0


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

[PATCH] global command: print info about variables

2017-04-04 Thread Sascha Hauer 
The info contains useful information at least for enums, for these the
possible values are printed. This makes the output of the "global"
command more useful and similar to "devinfo global"

Signed-off-by: Sascha Hauer 
---
 common/globalvar.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/common/globalvar.c b/common/globalvar.c
index 52808f8852..4cf635c0c7 100644
--- a/common/globalvar.c
+++ b/common/globalvar.c
@@ -321,7 +321,10 @@ static void device_param_print(struct device_d *dev)
if (IS_ENABLED(CONFIG_NVVAR) && dev != _device)
nv = dev_get_param(_device, param->name);
 
-   printf("%s%s: %s\n", nv ? "* " : "  ", param->name, p);
+   printf("%s%s: %s", nv ? "* " : "  ", param->name, p);
+   if (param->info)
+   param->info(param);
+   printf("\n");
}
 }
 
-- 
2.11.0


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

Re: State Framework and dtb

2017-04-04 Thread Sascha Hauer 
On Mon, Apr 03, 2017 at 11:59:50PM +0300, Çağlar Kilimci wrote:
> Hello,
> 
> 2017-03-31 16:00 GMT+03:00 Sascha Hauer :
> > On Fri, Mar 31, 2017 at 02:41:19PM +0300, Çağlar Kilimci wrote:
> >> Hey,
> >>
> >>
> >> I tried but got the same result and then I would like to apply your
> >> serious patch series of the state framework but release that our
> >> working branch is 2016.07 so could not apply patches. Let me update
> >> barebox and apply those patches. Are those based on master branch
> >> right?  Or, which branch do you recommend to work on?
> >
> > The patches are based on master, yes. Anyway, you seem to have a problem
> > in getting your changes in the dts file to the running barebox. Please
> > try to add some nodes/properties to your dts file and verify that a
> > of_dump shows these nodes. Before that is the case it's not worth to
> > look any further.
> 
> Finally, I updated and patched the code and now I can see state@0
> device in the of_dump:

Ok, looks good. How does the boot log look like? Still the same?

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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

Re: State patches

2017-04-04 Thread Sascha Hauer 
Hi Sam,

On Mon, Apr 03, 2017 at 10:15:11PM +0200, Sam Ravnborg wrote:
> Hi Sasha.
> 
> On Fri, Mar 31, 2017 at 09:03:04AM +0200, Sascha Hauer wrote:
> > Hi All,
> > 
> > Here is a ton of patches working on the state framework:
> > 
> > - make code easier to follow
> >   - Drop cached backend, replace with open coded more direct code
> >   - drop backend as extra struct type
> >   - drop lazy init code
> > - update documentation
> > - Add keystore command
> >   Using authenticated state requires hardware support which currently
> >   is only available for i.MX6. At least for testing purposes a keystore
> >   command to set keys is useful. This way authenticated state can be
> >   tested without hardware support
> > - more robust conversion of the backend path to a device node
> > - make work better with NOR flash: The current code ended up reading
> >   from NOR Flash byte by byte which was painfully slow
> 
> From browsing the patches this also brings a nice boot time improvement.
> We avoid earsing the whole block (or whatever the right name is) until
> we have filled it up with state entries.
> I expect this tospeed up booting with at least a second on our target.
> 
> Will this require a newer version of dt-utils to work?
> (When we for example update the sate from linux userspace)

No new tools required, the binary format is still the same.

The circular format which fills up blocks before erasing them existed before
this series, but this format is the default now. So if you end up with
the new format because you haven't specified the format before, then
this format change is still passed to userspace in the device tree and
and the userspace utility will do the right thing.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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