Re: [PATCH 2/6] led-uclass: honour ->label field populated by driver's own .bind

[Pavel Machek]

Hi!

> > > > > > diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
> > > > > > index 5a5d07b9a7..0232fa84de 100644
> > > > > > --- a/drivers/led/led-uclass.c
> > > > > > +++ b/drivers/led/led-uclass.c
> > > > > > @@ -71,7 +71,9 @@ static int led_post_bind(struct udevice *dev)
> > > > > > struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
> > > > > > const char *default_state;
> > > > > > -uc_plat->label = dev_read_string(dev, "label");
> > > > > > +if (!uc_plat->label)
> > > > > > +uc_plat->label = dev_read_string(dev, "label");
> > > > > > +
> > > > > 
> > > > > One thing I have to wonder about is, why does this controller have 
> > > > > label
> > > > > property in the top-level node , what is that used for ?
> > > > > 
> > > > > (see Linux Documentation/devicetree/bindings/leds/leds-lp55xx.yaml)
> > > > > 
> > > > > Reviewed-by: Marek Vasut 
> > > > 
> > > > Reading the linux driver, it seems that the top-level label, if any, is
> > > > used as part of the naming for individual channels if they don't have
> > > > individual chan-name properties:
> > > > 
> > > > 
> > > >   if (pdata->led_config[chan].name) {
> > > >   led->cdev.name = pdata->led_config[chan].name;
> > > >   } else {
> > > >   snprintf(name, sizeof(name), "%s:channel%d",
> > > >   pdata->label ? : chip->cl->name, chan);
> > > >   led->cdev.name = name;
> > > >   }
> > > > 
> > > > but I think the rationale in d1188adb2dabc is a bit weak, since the only
> > > > example also does have individual chan-name properties.
> > > > 
> > > > [Complete aside: At first I thought it was related to the multi-color
> > > > LED work that has been ongoing for many many years (I think there was an
> > > > LWN article at some point), where this could be exposed as a single
> > > > multi-color LED, as opposed to the "traditional" three/four individual
> > > > LEDs. In the former case, there would only be one sysfs entry, but with
> > > > attributes exposing the multicolor functionality. I must admit I don't
> > > > know the status of that work, when something reaches v31,
> > > > http://archive.lwn.net:8080/linux-kernel/20200722071055.GA8984@amd/t/ ,
> > > > it's hard to know if it ever lands, or if pieces of it has landed.]
> > > 
> > > +CC Pavel
> 
> I think you want to coordinate the effort with Rasmus here .

This is u-boot, not Linux, right?

Anyway cc-ing linux-leds may be better than cc-ing me directly, but
don't expect much.

Best regards,
Pavel
-- 
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: PGP signature

Re: [PATCH] arm: Remove nokia_rx51 board

[Pavel Machek]

On Tue 2021-05-18 21:26:40, Tom Rini wrote:
> This board has not been converted to CONFIG_DM_USB by the deadline.
> Remove it.

Given that the board is in a active use and that Pali is actively
working on it... That does not seem like good idea or sensible thing
to do.

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature

Re: [RESEND PATCH 16/16] Nokia RX-51: Enable usbtty serial console by default

[Pavel Machek]

Hi!

> Now when usbtty serial console is fixed in U-Boot enable CONFIG_USB_TTY for
> Nokia RX-51 board by default.
> 
> Fix also USB product id as U-Boot ignores CONFIG_USBD_PRODUCTID macro and
> include U-Boot string into USB product name to indicate usage of U-Boot.
> 
> CONFIG_CONSOLE_MUX is already used and U-Boot console is available for
> all in/out devices. Therefore there is no need to have separate commands
> 'run sercon', 'run usbcon' and 'run vgacon', so remove them.
> 
> As space for U-Boot is limited to 256kB, disable some other unused options
> so CONFIG_USB_TTY can be enabled.
> 
> Nokia RX-51 does not have easily accessible UART serial console so the only
> option for easy debugging is to use device's keyboard+screen or this usbtty
> serial console over USB.
> 
> Signed-off-by: Pali Rohár 

10-16: Acked-by: Pavel Machek 

Thanks for the series.

You may want to avoid cc-ing the Leste list, as it complains about too
many recipients and bounces.

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [RESEND PATCH 10/16] usb: musb: Ensure that we set musb dynamic FIFO buffer for every endpoint

[Pavel Machek]

On Fri 2021-02-05 20:12:06, Pali Rohár wrote:
> If we do not set FIFO buffer address and size for some endpoint which is in
> use then default address 0x0 would be used which is in conflict with FIFO
> buffer for endpoint 0 which is at fixed address 0x0. Sharing address space
> between more endpoint cause data loss and unexpected errors.
> 
> This patch is fixing transmission of characters over usbtty serial console
> and allow using of usbtty for debugging purposes on Nokia N900.
> 
> Signed-off-by: Pali Rohár 

6-10: Acked-by: Pavel Machek 

Regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [RESEND PATCH 05/16] usb: musb: Fix configuring FIFO for endpoints

[Pavel Machek]

On Fri 2021-02-05 20:12:01, Pali Rohár wrote:
> This patch fixes configuring FIFO for one-directional endpoints which have
> either RX or TX queue and therefore only one FIFO.
> 
> Size of FIFO buffer is 2^(idx+3) bytes and starting address is 2^(addr+3).
> Moreover first 64 bytes are reserved for EP0.
> 
> Without this patch if FIFO size specified by caller was zero then idx was
> incorrectly calculated (expr. ffs(0)-1) and size overflowed in fifosz
> register. This register uses has only 4 bits for FIFO size. Moreover
> specifying zero size is not possible.
> 
> This patch is fixing calculation of start address and buffer size to
> minimal value and ensure that it would not overlap with reserved EP0
> buffer.
> 
> This issue caused loose of packets on USB bus in both directions and
> basically usbtty was unusable.
> 
> Signed-off-by: Pali Rohár 

1-5: Acked-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [maemo-leste] [PATCH] Nokia RX-51: Do not try calling both ext2load and ext4load

[Pavel Machek]

On Mon 2020-11-30 20:10:34, Pali Rohár wrote:
> Those two commands now doing same thing, reading from ext2/3/4 filesystem.
> So remove useless duplicated call.
> 
> Signed-off-by: Pali Rohár 

Acked-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature

Re: [maemo-leste] [PATCH] bootmenu: Allow to quit it via CTRL+C

[Pavel Machek]

Hi!

> > > > >> >entry when CTRL+C is pressed.
> > > > >> >
> > > > >> >It is useful when bootmenu is part of boot process and you want to
> > > > >> >interrupt boot process by scripts which control U-Boot (serial)
> > > > >> >console.
> > > > >> 
> > > > >> Wouldn't the escape key be a better choice?
> > > > >
> > > > >I can add also escape key. But has escape key stable ANSI sequence
> > > > >which
> > > > >is needed to catch? If you tell me which bytes to catch (for escape
> > > > >key)
> > > > >I will add it.
> > > > 
> > > > 0x1b is Escape
> > > 
> > > Does not work. 0x1b is not escape key. It is start of the ANSI escape
> > > sequence which matches also existing keys up and down.
> > 
> > Unfortunately, 0x1b _is_ escape key. That is long standing bug of
> > vt100 terminal.
> 
> Ok. And has xterm (or other terminals) somehow fixed it? Should we
> expect that some other terminals send something different for ESC
>key?

Not really. Try it:

pavel@duo:~$ cat | hexdump -C
^[ahoj
  1b 61 68 6f 6a 0a |.ahoj.|
0006

> > Usually timeout is used for detection. 0x1b followed by delay is
> > escape key; 0x1b followed by [ is some other key.
> 
> Any idea how long timeout should be used for this detection?
> 
> Heinrich wrote in his patch that sequence of 0x1b 0x1b should be handled
> by escape key. Does it mean that we need to handle both 0x1b+timeout and
> also 0x1b+0x1b as a escape key? Or we should handle 0x1b+timeout or 0x1
> followed by any non '[' character as escape key?

Yes, that makes some sense. 10msec would be right value for the
timeout, I'd say.

> Anyway, this bootmenu was initially written for Nokia N900 (used on LCD
> display with integrated keyboard) and this device does not have ESC key.
> So I would like to have CTRL+C in bootmenu working independently of ESC
> key support.

Or maybe "q" is good choice for the bootmenu?

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [maemo-leste] [PATCH] bootmenu: Allow to quit it via CTRL+C

[Pavel Machek]

On Sat 2020-12-26 20:15:40, Pali Rohár wrote:
> On Saturday 26 December 2020 20:10:10 Heinrich Schuchardt wrote:
> > Am 26. Dezember 2020 20:03:56 MEZ schrieb "Pali Rohár" :
> > >On Saturday 26 December 2020 19:44:23 Heinrich Schuchardt wrote:
> > >> Am 26. Dezember 2020 19:02:25 MEZ schrieb "Pali Rohár"
> > >:
> > >> >When CTRL+C is pressed interrupt bootmenu and jump into U-Boot
> > >console.
> > >> >As the last entry in bootmenu is always U-Boot console just choose
> > >the
> > >> >last
> > >> >entry when CTRL+C is pressed.
> > >> >
> > >> >It is useful when bootmenu is part of boot process and you want to
> > >> >interrupt boot process by scripts which control U-Boot (serial)
> > >> >console.
> > >> 
> > >> Wouldn't the escape key be a better choice?
> > >
> > >I can add also escape key. But has escape key stable ANSI sequence
> > >which
> > >is needed to catch? If you tell me which bytes to catch (for escape
> > >key)
> > >I will add it.
> > 
> > 0x1b is Escape
> 
> Does not work. 0x1b is not escape key. It is start of the ANSI escape
> sequence which matches also existing keys up and down.

Unfortunately, 0x1b _is_ escape key. That is long standing bug of
vt100 terminal.

Usually timeout is used for detection. 0x1b followed by delay is
escape key; 0x1b followed by [ is some other key.

Best regards,   Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 13/13] Nokia RX-51: Enable usbtty serial console by default

[Pavel Machek]

On Sun 2020-11-29 17:52:52, Pali Rohár wrote:
> Now when usbtty serial console is fixed in U-Boot enable it for Nokia RX-51
> board by default.
> 
> CONFIG_CONSOLE_MUX is already used and U-Boot console is available for
> all in/out devices. Therefore there is no need to have separate commands
> 'run sercon', 'run usbcon' and 'run vgacon', so remove them.
> 
> As space for U-Boot is limited to 256kB, disable some other unused options
> so CONFIG_USB_TTY can be enabled.
> 
> Nokia RX-51 does not have easily accessible UART serial console so the only
> option for easy debugging is to use device's keyboard+screen or this usbtty
> serial console over USB.
> 
> Signed-off-by: Pali Rohár 

11-13 Reviewed-by: Pavel Machek 

Best regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 10/13] arm: omap3: Compile s_init() function only when it is used

[Pavel Machek]

On Sun 2020-11-29 17:52:07, Pali Rohár wrote:
> Function s_init() is called only from lowlevel_init(). So compile it only
> when function lowlevel_init() is compiled.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 09/13] arm: omap3: Compile lowlevel_init() function only when it is used

[Pavel Machek]

On Sun 2020-11-29 17:51:38, Pali Rohár wrote:
> Function lowlevel_init() is called only from cpu_init_crit() and this
> function is wrapped into #if .. #endif section. So compile also
> lowlevel_init() function under same #if condition.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 08/13] usb: gadget: Use dbg_ep0() macro instead of serial_printf()

[Pavel Machek]

On Sun 2020-11-29 17:49:52, Pali Rohár wrote:
> All debug messages from ep0.c except a few are printed by dbg_ep0() macro.
> So for remaining few exception use also dbg_ep0() instead of serial_printf().
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 


-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 07/13] usb: gadget: Do not export usbd_device_* arrays

[Pavel Machek]

On Sun 2020-11-29 17:46:12, Pali Rohár wrote:
> Each array is used only in one file (core.c or ep0.c). Move their content
> to correct file, mark them as static and do not export out of current file.
> 
> This change allows to decrease size of u-boot.bin as more of those strings
> are not used.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 


-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 06/13] usb: musb: Fix transmission of bigger buffers

[Pavel Machek]

On Sun 2020-11-29 17:46:11, Pali Rohár wrote:
> If udc_endpoint_write() was called with bigger payload which does not fit
> into one USB packet it needs to be transmitted in more USB packets. First
> packet is transmitted by udc_endpoint_write() call itself and other packets
> are put into waiting queue.
> 
> Implement function musb_peri_tx() which transmit checks when endpoints are
> ready and continue transmitting of waiting queue.
> 
> This patch fixes sending e.g. output of printenv command over usbtty serial
> console.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 05/13] usb: musb: Read value of PERI_RXCSR to 16bit variable

[Pavel Machek]

On Sun 2020-11-29 17:46:10, Pali Rohár wrote:
> PERI_RXCSR is 16bit register so store its value into 16bit local variable.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 04/13] usb: musb: Fix configuring FIFO for endpoints

[Pavel Machek]

On Sun 2020-11-29 17:46:09, Pali Rohár wrote:
> This patch fixes configuring FIFO for one-directional endpoints which have
> either RX or TX queue and therefore only one FIFO.
> 
> Without this patch if FIFO size was zero then idx was incorrectly
> calculated (expr. ffs(0)-1 is not zero) and size overflowed in fifosz
> register. This register uses has only 4 bits for FIFO size.
> 
> This patch is fixing it by setting zero size and zero address when
> particular endpoint does not use FIFO.
> 
> This issue caused loose of packets on USB bus in both directions and
> basically usbtty was unusable.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 


-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 03/13] usb: musb: Always clear the data toggle bit when configuring ep

[Pavel Machek]

On Sun 2020-11-29 17:46:08, Pali Rohár wrote:
> Without this patch it was done only when U-Boot was compiled with MUSB Host
> Controller. But it is needed also for MUSB Device Controller, otherwise
> Device Controller does not work.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 02/13] usb: musb: Fix compilation of gadget code

[Pavel Machek]

On Sun 2020-11-29 17:46:07, Pali Rohár wrote:
> musb udc code depends on usb gadget code provided by CONFIG_USB_DEVICE and
> defined in drivers/usb/gadget/Makefile. But this Makefile is not included
> into U-Boot build when CONFIG_USB_GADGET is not set. As CONFIG_USB_DEVICE
> cannot be enabled together with CONFIG_USB_GADGET it means that dependency
> for musb udc code is not compiled during build. Fix it by including
> drivers/usb/gadget dependency also when CONFIG_USB_DEVICE is set.
> 
_device_event_irq'
> arm-linux-gnueabi-ld.bfd: 
> drivers/usb/musb/built-in.o:u-boot/drivers/usb/musb/musb_udc.c: more 
> undefined references to `usbd_device_event_irq' follow
> arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function 
> `udc_setup_ep':
> u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_alloc_urb'
> arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function 
> `udc_startup_events':
> u-boot/drivers/usb/musb/musb_udc.c: undefined reference to 
> `usbd_device_event_irq'
> arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined 
> reference to `usbd_device_event_irq'
> arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined 
> reference to `usbd_device_event_irq'
> make: *** [Makefile:1762: u-boot] Error 1
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 01/13] serial: usbtty: Fix puts function

[Pavel Machek]

On Sun 2020-11-29 17:46:06, Pali Rohár wrote:
> This function has incorrect implementation of prepending CR prior LF.
> Without this patch it prepended CR prior whole string which is going to be
> written and let LF without leading CR. Fix this issue by inserting CR at
> correct place to make output on usbtty serial console more readable.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [maemo-leste] [PATCH] Nokia RX-51: Add test for U-Boot serial console

[Pavel Machek]

On Sun 2020-11-29 17:15:05, Pali Rohár wrote:
> This patch adds a new test which checks that U-Boot for Nokia RX-51 running
> in qemu can print test line to serial console and also checks that test
> line appeared on qemu serial console.
> 
> Signed-off-by: Pali Rohár 

Reviewed-by: Pavel Machek 


-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [maemo-leste] [PATCH] Nokia RX-51: Decrease i2c speed to 100000

[Pavel Machek]

On Sat 2020-11-21 23:30:11, Pali Rohár wrote:
> It looks like that i2c bus lot of times timeout on some units. Prior
> migration to CONFIG_DM_I2C i2c speed was set to CONFIG_SYS_OMAP24_I2C_SPEED
> value which was 10. Lower speed fixes timeout problems, so change speed
> back to its previous value.
> 
> Signed-off-by: Pali Rohár 
> Fixes: 8d8c18170325 ("Nokia RX-51: Convert to CONFIG_DM_I2C")

Reviewed-by: Pavel Machek 

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [maemo-leste] [PATCH] mmc: omap_hsmmc: Set 3.3V for IO voltage on all places

[Pavel Machek]

On Fri 2020-07-03 22:58:23, Pali Rohár wrote:
> In commit commit d2c05f50e12f ("mmc: omap_hsmmc: Set 3.3V for IO voltage")
> was changed 3.0V IO voltage to 3.3V but it was not done on all places in
> omap_hsmmc driver. That commit broke eMMC support on Nokia N900.
> 
> This patch fixes that problematic commit and changes 3.0V to 3.3V on all
> remaining places in omap_hsmmc driver.
> 
> Fixes: d2c05f50e12f ("mmc: omap_hsmmc: Set 3.3V for IO voltage")
> Signed-off-by: Pali Rohár 

Acked-by: Pavel Machek 

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: Digital signature

Re: Bisected: mmc cause reboot loops on N900 (Was: Re: U-Boot is broken on real N900 HW)

[Pavel Machek]

Hi!

> Adding Jean to the loop. Could you please look at this problem? Your
> commit (described below) is causing reboot loop on Nokia N900
> hardware.

I'm not sure Jean is still with TI. You may want to talk to Tomi
Valkeinen  if you don't get replies.

Best regards,
Pavel

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: PGP signature

Re: U-Boot is broken on real N900 HW (Was: Re: [PATCH 00/11] Fixes for Nokia RX-51)

[Pavel Machek]

On Wed 2020-04-01 00:42:54, Pali Roh??r wrote:
> On Wednesday 01 April 2020 00:35:07 Pali Roh??r wrote:
> > This patch series contain fixes for Nokia RX-51 board (aka N900).
> > After these changes it is possible to run U-Boot in qemu emulator again.
> > And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > problem.
> 
> But on real Nokia N900 device is U-Boot crashing in reboot loop.
> 
> I do not have serial console for Nokia N900 to debug this issue, but
> seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> that there is no crash and even no error in qemu emulator so I cannot
> debug this issue.

I have a serial cable I do not currently need. Would it help? 

Best regards,
Pavel

-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [U-Boot] [PATCH] mtd: nand: fsl_ifc: Fix handling of bitflips in erased pages

[Pavel Machek]

On Mon 2017-06-12 13:50:00, Darwin Dingel wrote:
> This is a fix made for the fsl_ifc_nand driver on linux kernel by
> Pavel Machek and is applied to uboot. It is currently on applied on
> linux-mtd.
> 
> https://patchwork.kernel.org/patch/9758117/
> 
> IFC always raises ECC errors on erased pages. It is only ignored when
> the buffer is checked for all 0xFF by is_blank(). The problem is a
> single bitflip will cause is_blank() and then mtd_read to fail. The fix
> makes use of nand_check_erased_ecc_chunk() to check for empty pages
> instead of is_blank(). This also makes sure that reads are made at ECC
> page size granularity to get a proper bitflip count. If the number of
> bitflips does not exceed the ECC strength, the page is considered empty
> and the bitflips will be corrected when data is sent to the higher
> layers (e.g. ubi).

Thanks for porting the fix in u-boot.

I don't have hardware to test, but the fix looks good.

Acked-by: Pavel Machek <pa...@denx.de>
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] marvell: armada385: Add the Turris Omnia board

[Pavel Machek]

Hi!


> Signed-off-by: Marek Behun 
> ---
>  arch/arm/dts/armada-385-turris-omnia.dts | 428 
> +++
>  arch/arm/mach-mvebu/Kconfig  |   7 +
>  board/CZ.NIC/turris_omnia/Makefile   |   7 +
>  board/CZ.NIC/turris_omnia/kwbimage.cfg   |  12 +
>  board/CZ.NIC/turris_omnia/turris_omnia.c | 364 ++
>  configs/turris_omnia_defconfig   |  59 +
>  include/configs/turris_omnia.h   | 181 +
>  7 files changed, 1058 insertions(+)
>  create mode 100644 arch/arm/dts/armada-385-turris-omnia.dts
>  create mode 100644 board/CZ.NIC/turris_omnia/Makefile
>  create mode 100644 board/CZ.NIC/turris_omnia/kwbimage.cfg
>  create mode 100644 board/CZ.NIC/turris_omnia/turris_omnia.c

Should the path be .../cz.nic/... (lowercase)?

> +++ b/arch/arm/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,428 @@
> +/*
> + * Device Tree file for the Turris Omnia
> + *
> + * Copyright (C) 2014 Marvell
> + *
> + * Marek Behun  at end of line.

> + * Gregory CLEMENT 

And if you want to claim copyright, you should also specify years...

> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */

We normally use spdx license tags in u-boot.
Pavel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] tools: socfpga: image installation script

[Pavel Machek]

Installing u-boot on socfpga is not trivial. Yes, it can be done with
dd, but it is easy to make a typo and destroy a partition. Introduce a
script that knows how to install all the copies, and actually checks
signatures so that killing data is not trivial.

Signed-of-by: Pavel Machek <pa...@denx.de>

diff --git a/tools/socfpga_install b/tools/socfpga_install
new file mode 100755
index 000..d02e73c
--- /dev/null
+++ b/tools/socfpga_install
@@ -0,0 +1,50 @@
+#!/usr/bin/python3
+# Copyright 2015 Pavel Machek, Denx
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Usage: sudo socfpga_install /dev/sdb3 u-boot-spl.bin u-boot-dts.img
+
+import subprocess
+import sys
+import os
+
+print("install device ", sys.argv[1])
+device = open(sys.argv[1], "r+b")
+
+sig = device.read(0x44)
+if sig[0x40] != 0x41 or sig[0x41] != 0x53 or \
+   sig[0x42] != 0x30 or sig[0x43] != 0x31:
+print("Do not see AS01 signature, do you have right partition?")
+sys.exit(1)
+else:
+print("Have partition with right signature")
+
+spl = sys.argv[2]
+if spl == "_":
+print("Skipping u-boot-spl installation")
+else:
+print("u-boot-spl.bin at ", spl)
+
+
+res = subprocess.check_call(["tools/mkimage", "-T", "socfpgaimage", "-d", 
spl, "img.tmp"])
+if res != 0:
+print("mkimage failed.")
+sys.exit(1)
+device.seek(0)
+
+spl_bin = open("img.tmp", "rb").read()
+if len(spl_bin) != 65536:
+print("Preloader image has wrong length.")
+sys.exit(1)
+ 
+device.write(spl_bin)
+device.write(spl_bin)
+device.write(spl_bin)
+device.write(spl_bin)
+
+print("u-boot.img at ", sys.argv[3])
+uboot_bin = open(sys.argv[3], "rb").read()
+print("Have u-boot, %d bytes" % len(uboot_bin))
+device.seek(65536*4)
+device.write(uboot_bin)
+print("All done.")


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] socfpga: documentation tweaks

[Pavel Machek]

Fix english, use "SoCFPGA" spelling, add pointer for help with installation.

Signed-off-by: Pavel Machek <pa...@denx.de>

diff --git a/doc/README.socfpga b/doc/README.socfpga
index cfcbbfe..b43704e 100644
--- a/doc/README.socfpga
+++ b/doc/README.socfpga
@@ -1,18 +1,18 @@
 
 
-SOCFPGA Documentation for U-Boot and SPL
+SoCFPGA Documentation for U-Boot and SPL
 
 
 This README is about U-Boot and SPL support for Altera's ARM Cortex-A9MPCore
-based SOCFPGA. To know more about the hardware itself, please refer to
+based SoCFPGA. To know more about the hardware itself, please refer to
 www.altera.com.
 
 
 
 socfpga_dw_mmc
 
-Here are macro and detailed configuration required to enable DesignWare SDMMC
-controller support within SOCFPGA
+Here are macros and detailed configuration required to enable DesignWare SDMMC
+controller support within SoCFPGA:
 
 #define CONFIG_MMC
 -> To enable the SD MMC framework support
@@ -30,10 +30,10 @@ controller support within SOCFPGA
 -> Enable the common DesignWare SDMMC controller framework
 
 #define CONFIG_SOCFPGA_DWMMC
--> Enable the SOCFPGA specific driver for DesignWare SDMMC controller
+-> Enable the SoCFPGA specific driver for DesignWare SDMMC controller
 
 #define CONFIG_SOCFPGA_DWMMC_FIFO_DEPTH1024
--> The FIFO depth for SOCFPGA DesignWare SDMMC controller
+-> The FIFO depth for SoCFPGA DesignWare SDMMC controller
 
 #define CONFIG_SOCFPGA_DWMMC_DRVSEL3
 -> Phase-shifted clock of sdmmc_clk for controller to drive command and data to
@@ -43,11 +43,20 @@ is 135 / 360 * 20ns = 7.5ns.
 
 #define CONFIG_SOCFPGA_DWMMC_SMPSEL0
 -> Phase-shifted clock of sdmmc_clk used to sample the command and data from
-the card
+the card.
 
 #define CONFIG_SOCFPGA_DWMMC_BUS_WIDTH 4
--> Bus width of data line which either 1, 4 or 8 and based on board routing.
+-> Bus width of data line which is either 1, 4 or 8 and is based on board
+routing.
 
 #define CONFIG_SOCFPGA_DWMMC_BUS_HZ5000
 -> The clock rate to controller. Do note the controller have a wrapper which
 divide the clock from PLL by 4.
+
+
+Installing U-Boot / U-Boot SPL
+
+
+Boot ROM loads U-Boot SPL from magic partition, (id 0xa2). See
+http://xillybus.com/tutorials/u-boot-image-altera-soc .
+

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/8] arm: socfpga: Add distro boot to socfpga common header

[Pavel Machek]

Hi!

> > > > >  /* Environment for SDMMC boot */
> > > > >  #if defined(CONFIG_ENV_IS_IN_MMC) && !defined(CONFIG_ENV_OFFSET)
> > > > > -#define CONFIG_SYS_MMC_ENV_DEV   0   /* device 0 */
> > > > > -#define CONFIG_ENV_OFFSET512 /* just after the
> > > > > MBR
> > > > > */
> > > > > +#define CONFIG_SYS_MMC_ENV_DEV   0   /*
> > > > > device 0
> > > > > */
> > > > > +#define CONFIG_ENV_OFFSET(34*512)/* just after the GPT
> > > > > */
...
> I actually dont believe this will cause much of an issue. the env is placed
> immediately after the partition table.  I know this size fits between the
> table and the typical location of the first partition without issue.

Hmm. It is not immediately after partition table (==MBR), it is at
sector 34. Now, by changing size you already break the setups, so
moving it back to sector 1 does not help much, but can you explain?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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] qemu-x86 issues

[Pavel Machek]

Hi!

> > Bah, lemme correct myself.  MIPS* and PowerPC fail due to sleep taking
> > slightly too long.  x86 is the only one where it's just way too fast.
> > But this is not true once Linux itself is up.
> >
> 
> U-Boot uses x86 TSC timer as the delay timer. Right now the timer
> frequency is hard-coded in device tree. Auto-calibration does not work
> on QEMU. I need have another check to see if we can do
> auto-calibration.

TSC is not really suitable for delays on x86. (Actually, TSC is pretty
much not suitable for anything :-) ). PIT should be easy to use and
work everywhere...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI

[Pavel Machek]

Hi!

> > We don't support quad mode in U-Boot . You mean not entering Quad mode
> > in Linux ?
> > 
> 
> Nope, there seems to be quad support in u-boot, from spi_flash.c (my patched 
> version):
> 
> #ifndef CONFIG_SPL_BUILD
>   /* Look for the fastest read cmd */
>   cmd = fls(params->e_rd_cmd & spi->mode_rx);
>   if (cmd) {
>   cmd = spi_read_cmds_array[cmd - 1];
>   flash->read_cmd = cmd;
>   } else {
> #endif
>   /* Go for default supported read cmd */
>   flash->read_cmd = CMD_READ_ARRAY_FAST;
> #ifndef CONFIG_SPL_BUILD  
>   }
> 
>   /* Not require to look for fastest only two write cmds yet */
>   if (params->flags & WR_QPP && spi->mode & SPI_TX_QUAD)
>   flash->write_cmd = CMD_QUAD_PAGE_PROGRAM;
>   else
> #endif
>   /* Go for default supported write cmd */
>   flash->write_cmd = CMD_PAGE_PROGRAM;
> 
>   /* Set the quad enable bit - only for quad commands */
>   if ((flash->read_cmd == CMD_READ_QUAD_OUTPUT_FAST) ||
>   (flash->read_cmd == CMD_READ_QUAD_IO_FAST) ||
>   (flash->write_cmd == CMD_QUAD_PAGE_PROGRAM)) {
>   ret = set_quad_mode(flash, idcode[0]);
>   if (ret) {
>   debug("SF: Fail to set QEB for %02x\n", idcode[0]);
>   return -EINVAL;
>   }
>   }
> 
> So there is a call to set_quad_mode that prevented the SPL to work
> in vanilla 2016.05.

Just for the record, I seen similar problems on is1 board, and they
also somehow magically went away.

One possibility was that SPL was too big, and the quad spi probing
pushed it over the limits.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] ARM: socfpga: move CONFIG_BOOTDELAY to Kconfig for IS1 board

[Pavel Machek]

On Tue 2016-06-21 14:32:42, Masahiro Yamada wrote:
> This recently added board missed the tree-wide migration of
> CONFIG_BOOTDELAY.
> 
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>

Acked-by: Pavel Machek <pa...@denx.de>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHv4] ARM: socfpga: add support for IS1 board

[Pavel Machek]

This adds support for IS1 board. Pretty usual socfpga board,
256MB of RAM, does not have MMC, two SPI chips, one ethernet port, two
additional ethernet ports connected to the FPGA.

Signed-off-by: Pavel Machek <pa...@denx.de>

---

v2: add diffstat

v3: fixes from review, add empty socfpga.c to make build system happy.

v4: fixes from review, declare that environment is in spi flash.

 arch/arm/dts/Makefile |1 
 arch/arm/dts/socfpga_cyclone5_is1.dts |  106 +
 arch/arm/mach-socfpga/Kconfig |6 
 board/is1/MAINTAINERS |6 
 board/is1/Makefile|7 
 board/is1/qts/iocsr_config.h  |  660 ++
 board/is1/qts/pinmux_config.h |  219 +++
 board/is1/qts/pll_config.h|   85 
 board/is1/qts/sdram_config.h  |  341 +
 board/is1/socfpga.c   |4 
 configs/socfpga_is1_defconfig |   43 ++
 include/configs/socfpga_is1.h |   49 ++
 12 files changed, 1527 insertions(+)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e76f56b..3738511 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -102,6 +102,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
 
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_arria5_socdk.dtb\
+   socfpga_cyclone5_is1.dtb\
socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_de0_nano_soc.dtb   \
diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts 
b/arch/arm/dts/socfpga_cyclone5_is1.dts
new file mode 100644
index 000..16a3283
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
@@ -0,0 +1,106 @@
+/*
+ *  Copyright (C) 2012 Altera Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "SoCFPGA Cyclone V IS1";
+   compatible = "anonymous,socfpga-is1", "altr,socfpga-cyclone5", 
"altr,socfpga";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+
+   aliases {
+   ethernet0 = 
+   udc0 = 
+   };
+
+   regulator_3_3v: 3-3-v-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+
+   rxd0-skew-ps = <0>;
+   rxd1-skew-ps = <0>;
+   rxd2-skew-ps = <0>;
+   rxd3-skew-ps = <0>;
+   txen-skew-ps = <0>;
+   txc-skew-ps = <2600>;
+   rxdv-skew-ps = <0>;
+   rxc-skew-ps = <2000>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   eeprom@51 {
+   compatible = "atmel,24c32";
+   reg = <0x51>;
+   pagesize = <32>;
+   };
+
+   rtc@68 {
+   compatible = "dallas,ds1339";
+   reg = <0x68>;
+   };
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   cd-gpios = < 18 0>;
+   vmmc-supply = <_3_3v>;
+   vqmmc-supply = <_3_3v>;
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   flash0: n25q00@0 {
+   u-boot,dm-pre-reloc;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "n25q00";
+   reg = <0>;  /* chip select */
+   spi-max-frequency = <1>;
+   m25p,fast-read;
+   page-size = <256>;
+   block-size = <16>; /* 2^16, 64KB */
+   read-delay = <4>;  /* delay value in read data capture register 
*/
+   tshsl-ns = <50>;
+   tsd2d-ns = <50>;
+   tchsh-ns = <4>;
+   tslch-ns = <4>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 1484607..cbc9cf6 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -31,6 +31,10 @@ config TARGET_SOCFPGA_SR1500
bool "SR1500 (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
 
+config TARGET_SOCFPGA_IS1
+   bool "IS1 (Cyclone V)"
+   sel

[U-Boot] [PATCHv3] ARM: socfpga: add support for IS1 board

[Pavel Machek]

This adds support for IS1 board. Pretty usual socfpga board,
256MB of RAM, does not have MMC, two SPI chips, one ethernet port, two
additional ethernet ports connected to the FPGA.

Signed-off-by: Pavel Machek <pa...@denx.de>

---

v2: add diffstat

v3: fixes from review, add empty socfpga.c to make build system happy.

 arch/arm/dts/Makefile |1 
 arch/arm/dts/socfpga_cyclone5_is1.dts |  106 +
 arch/arm/mach-socfpga/Kconfig |6 
 board/is1/MAINTAINERS |6 
 board/is1/Makefile|7 
 board/is1/qts/iocsr_config.h  |  660 ++
 board/is1/qts/pinmux_config.h |  219 +++
 board/is1/qts/pll_config.h|   85 
 board/is1/qts/sdram_config.h  |  341 +
 board/is1/socfpga.c   |4 
 configs/socfpga_is1_defconfig |   43 ++
 include/configs/socfpga_is1.h |   48 ++
 12 files changed, 1526 insertions(+)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 92c7545..a397c69 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -102,6 +102,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
 
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_arria5_socdk.dtb\
+   socfpga_cyclone5_is1.dtb\
socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_de0_nano_soc.dtb   \
diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts 
b/arch/arm/dts/socfpga_cyclone5_is1.dts
new file mode 100644
index 000..16a3283
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
@@ -0,0 +1,106 @@
+/*
+ *  Copyright (C) 2012 Altera Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "SoCFPGA Cyclone V IS1";
+   compatible = "anonymous,socfpga-is1", "altr,socfpga-cyclone5", 
"altr,socfpga";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+
+   aliases {
+   ethernet0 = 
+   udc0 = 
+   };
+
+   regulator_3_3v: 3-3-v-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+
+   rxd0-skew-ps = <0>;
+   rxd1-skew-ps = <0>;
+   rxd2-skew-ps = <0>;
+   rxd3-skew-ps = <0>;
+   txen-skew-ps = <0>;
+   txc-skew-ps = <2600>;
+   rxdv-skew-ps = <0>;
+   rxc-skew-ps = <2000>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   eeprom@51 {
+   compatible = "atmel,24c32";
+   reg = <0x51>;
+   pagesize = <32>;
+   };
+
+   rtc@68 {
+   compatible = "dallas,ds1339";
+   reg = <0x68>;
+   };
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   cd-gpios = < 18 0>;
+   vmmc-supply = <_3_3v>;
+   vqmmc-supply = <_3_3v>;
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   flash0: n25q00@0 {
+   u-boot,dm-pre-reloc;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "n25q00";
+   reg = <0>;  /* chip select */
+   spi-max-frequency = <1>;
+   m25p,fast-read;
+   page-size = <256>;
+   block-size = <16>; /* 2^16, 64KB */
+   read-delay = <4>;  /* delay value in read data capture register 
*/
+   tshsl-ns = <50>;
+   tsd2d-ns = <50>;
+   tchsh-ns = <4>;
+   tslch-ns = <4>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index dea4ce5..b11d510 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -31,6 +31,10 @@ config TARGET_SOCFPGA_SR1500
bool "SR1500 (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
 
+config TARGET_SOCFPGA_IS1
+   bool "IS1 (Cyclone V)"
+   select TARGET_SOCFPGA_CYCLONE5
+
 config TARGET_SOCFPGA_EBV_SOCRATES
  

Re: [U-Boot] [PATCHv2] ARM: socfpga: add support for IS1 board

[Pavel Machek]

Hi!

> > --- /dev/null
> > +++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
> > @@ -0,0 +1,109 @@
> > +/*
> > + *  Copyright (C) 2012 Altera Corporation 
> 
> This copyright notice needs to be updated.

How? dts is probably not copyrightable, and my changes are certainly
not complex enough for copyright protection.

> > +/* Extra Environment */
> > +#define CONFIG_EXTRA_ENV_SETTINGS \
> > +   "verify=n\0" \
> > +   "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> 
> This loadaddr is set by CONFIG_LOADADDR (above)

I'm not sure what you are trying to tell me, in any case
socfpga_sr1500.h has same entry.

> > +   "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
> > +   "bootm ${loadaddr} - ${fdt_addr}\0" \
> > +   "bootimage=zImage\0" \
> > +   "fdt_addr=100\0" \
> > +   "fdtimage=socfpga.dtb\0" \
> > +   "bootm ${loadaddr} - ${fdt_addr}\0" \
> > +   "mmcroot=/dev/mmcblk0p2\0" \
> > +   "mmcboot=setenv bootargs " CONFIG_BOOTARGS \
> > +   " root=${mmcroot} rw rootwait;" \
> > +   "bootz ${loadaddr} - ${fdt_addr}\0" \
> > +   "mmcload=mmc rescan;" \
> > +   "load mmc 0:1 ${loadaddr} ${bootimage};" \
> > +   "load mmc 0:1 ${fdt_addr} ${fdtimage}\0" \
> > +   "qspiload=sf probe && mtdparts default && run ubiload\0" \
> > +   "qspiboot=setenv bootargs " CONFIG_BOOTARGS \
> > +   " root=${qspiroot} rw rootfstype=${qspirootfstype};"\
> > +   "bootm ${loadaddr} - ${fdt_addr}\0" \
> > +   "uboot_env_complete=yes\0"
> 
> Can we drop this extra environment? It looks like a copy of the CV
> SoCDK env, which is broken nonetheless, so unless it's used, drop it
> in V3 please.

We can drop the extra environment for now.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Between 2015.10 and 2016.01, SPI flash changed erase size, and saveenv stopped working

[Pavel Machek]

On Mon 2016-05-30 10:43:39, Fabio Estevam wrote:
> On Mon, May 30, 2016 at 5:33 AM, Pavel Machek <pa...@denx.de> wrote:
> 
> > Commit c3c016cf75360c2a0d0a065b64b438aaf7720576 is a part of the problem:
> >
> > offset 0x4 is protected and cannot be erased
> > => sf help
> > No SPI flash selected. Please run `sf probe'
> > => sf probe
> > ...
> > SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
> > 64 MiB
> > cadence_spi_set_speed: speed=100
> > => sf protect unlock 0x4 0x2
> > cadence_spi_xfer: len=1 [bytes]
> > cadence_spi_xfer: len=1 [bytes]
> > => saveenv
> > Saving Environment to SPI Flash...
> 
> Does this quick hack help? I am wondering if yous SPI flash power up
> with the SR field protected:

This may be stupid but... is it possible that changes made by
write_sr() persist over powerdown?

Best regards,
Pavel

> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -1021,11 +1021,7 @@ int spi_flash_scan(struct spi_flash *flash)
> return -EPROTONOSUPPORT;
> }
> 
> -   /* Flash powers up read-only, so clear BP# bits */
> -   if (idcode[0] == SPI_FLASH_CFI_MFR_ATMEL ||
> -   idcode[0] == SPI_FLASH_CFI_MFR_MACRONIX ||
> -   idcode[0] == SPI_FLASH_CFI_MFR_SST)
> -   write_sr(flash, 0);
> +   write_sr(flash, 0);
> 
> /* Assign spi data */
> flash->name = params->name;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHv2] ARM: socfpga: add support for IS1 board

[Pavel Machek]

This adds support for IS1 board. Pretty usual socfpga board,
256MB of RAM, does not have MMC, two SPI chips, one ethernet port, two
additional ethernet ports connected to the FPGA.
 
Signed-off-by: Pavel Machek <pa...@denx.de>

---

v2: add diffstat

 arch/arm/dts/Makefile |1 
 arch/arm/dts/socfpga_cyclone5_is1.dts |  109 +
 arch/arm/mach-socfpga/Kconfig |6 
 board/is1/MAINTAINERS |6 
 board/is1/Makefile|5 
 board/is1/qts/iocsr_config.h  |  660 ++
 board/is1/qts/pinmux_config.h |  219 +++
 board/is1/qts/pll_config.h|   85 
 board/is1/qts/sdram_config.h  |  341 +
 configs/socfpga_is1_defconfig |   43 ++
 include/configs/socfpga_is1.h |   83 
 11 files changed, 1558 insertions(+)


diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 92c7545..a397c69 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -102,6 +102,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
 
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_arria5_socdk.dtb\
+   socfpga_cyclone5_is1.dtb\
socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_de0_nano_soc.dtb   \
diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts 
b/arch/arm/dts/socfpga_cyclone5_is1.dts
new file mode 100644
index 000..cdd2c99
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
@@ -0,0 +1,109 @@
+/*
+ *  Copyright (C) 2012 Altera Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "Altera SOCFPGA IS1 board";
+   compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+
+   aliases {
+   /* this allow the ethaddr uboot environment variable contents
+* to be added to the gmac1 device tree blob.
+*/
+   ethernet0 = 
+   udc0 = 
+   };
+
+   regulator_3_3v: 3-3-v-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+
+   rxd0-skew-ps = <0>;
+   rxd1-skew-ps = <0>;
+   rxd2-skew-ps = <0>;
+   rxd3-skew-ps = <0>;
+   txen-skew-ps = <0>;
+   txc-skew-ps = <2600>;
+   rxdv-skew-ps = <0>;
+   rxc-skew-ps = <2000>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   eeprom@51 {
+   compatible = "atmel,24c32";
+   reg = <0x51>;
+   pagesize = <32>;
+   };
+
+   rtc@68 {
+   compatible = "dallas,ds1339";
+   reg = <0x68>;
+   };
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   cd-gpios = < 18 0>;
+   vmmc-supply = <_3_3v>;
+   vqmmc-supply = <_3_3v>;
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   flash0: n25q00@0 {
+   u-boot,dm-pre-reloc;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "n25q00";
+   reg = <0>;  /* chip select */
+   spi-max-frequency = <1>;
+   m25p,fast-read;
+   page-size = <256>;
+   block-size = <16>; /* 2^16, 64KB */
+   read-delay = <4>;  /* delay value in read data capture register 
*/
+   tshsl-ns = <50>;
+   tsd2d-ns = <50>;
+   tchsh-ns = <4>;
+   tslch-ns = <4>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index dea4ce5..b11d510 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -31,6 +31,10 @@ config TARGET_SOCFPGA_SR1500
bool "SR1500 (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
 
+config TARGET_SOCFPGA_IS1
+   bool "IS1 (Cyclone V)"
+   select TARGET_SOCFPGA_CYCLONE5
+
 config TARGET_SOCFP

[U-Boot] socfpga 2016.07-rc0: have to disable parts of flash probing and limit read size to get SPL to work

[Pavel Machek]

Hi!

There's one more "funny" thing I see with SPI: SPL fails to boot if I
let it do full probing, or if I allow it to do reads in big chunks
(that may be explained by watchdog, I'll investigate it some more).

This makes SPL work for me, but I guess I'd like to understand why.

Ideas welcome.

Best regards,
Pavel

--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -515,6 +520,7 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 #endif
remain_len = ((SPI_FLASH_16MB_BOUN << flash->shift) *
(bank_sel + 1)) - offset;
+   remain_len = 32768;
if (len < remain_len)
read_len = len;
else
@@ -1176,23 +1178,28 @@ int spi_flash_scan(struct spi_flash *flash)
/* Now erase size becomes valid sector size */
flash->sector_size = flash->erase_size;
 
+#ifndef CONFIG_SPL_BUILD
/* Look for the fastest read cmd */
cmd = fls(params->e_rd_cmd & spi->mode_rx);
if (cmd) {
cmd = spi_read_cmds_array[cmd - 1];
flash->read_cmd = cmd;
} else {
+#endif
/* Go for default supported read cmd */
flash->read_cmd = CMD_READ_ARRAY_FAST;
+#ifndef CONFIG_SPL_BUILD   
}
-
/* Not require to look for fastest only two write cmds yet */
if (params->flags & WR_QPP && spi->mode & SPI_TX_QUAD)
flash->write_cmd = CMD_QUAD_PAGE_PROGRAM;
else
+#endif
/* Go for default supported write cmd */
flash->write_cmd = CMD_PAGE_PROGRAM;
 
+   /* Why are we even probing writes? SPL should not write anywhere... */
+
/* Set the quad enable bit - only for quad commands */
if ((flash->read_cmd == CMD_READ_QUAD_OUTPUT_FAST) ||
(flash->read_cmd == CMD_READ_QUAD_IO_FAST) ||




-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] ARM: socfpga: add support for IS1 board

[Pavel Machek]

This adds support for IS1 board.

Signed-off-by: Pavel Machek <pa...@denx.de>

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 92c7545..a397c69 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -102,6 +102,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
 
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_arria5_socdk.dtb\
+   socfpga_cyclone5_is1.dtb\
socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_de0_nano_soc.dtb   \
diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts 
b/arch/arm/dts/socfpga_cyclone5_is1.dts
new file mode 100644
index 000..cdd2c99
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
@@ -0,0 +1,109 @@
+/*
+ *  Copyright (C) 2012 Altera Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "Altera SOCFPGA IS1 board";
+   compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+
+   aliases {
+   /* this allow the ethaddr uboot environment variable contents
+* to be added to the gmac1 device tree blob.
+*/
+   ethernet0 = 
+   udc0 = 
+   };
+
+   regulator_3_3v: 3-3-v-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   status = "okay";
+   phy-mode = "rgmii";
+
+   rxd0-skew-ps = <0>;
+   rxd1-skew-ps = <0>;
+   rxd2-skew-ps = <0>;
+   rxd3-skew-ps = <0>;
+   txen-skew-ps = <0>;
+   txc-skew-ps = <2600>;
+   rxdv-skew-ps = <0>;
+   rxc-skew-ps = <2000>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   eeprom@51 {
+   compatible = "atmel,24c32";
+   reg = <0x51>;
+   pagesize = <32>;
+   };
+
+   rtc@68 {
+   compatible = "dallas,ds1339";
+   reg = <0x68>;
+   };
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   cd-gpios = < 18 0>;
+   vmmc-supply = <_3_3v>;
+   vqmmc-supply = <_3_3v>;
+};
+
+ {
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   flash0: n25q00@0 {
+   u-boot,dm-pre-reloc;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "n25q00";
+   reg = <0>;  /* chip select */
+   spi-max-frequency = <1>;
+   m25p,fast-read;
+   page-size = <256>;
+   block-size = <16>; /* 2^16, 64KB */
+   read-delay = <4>;  /* delay value in read data capture register 
*/
+   tshsl-ns = <50>;
+   tsd2d-ns = <50>;
+   tchsh-ns = <4>;
+   tslch-ns = <4>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index dea4ce5..b11d510 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -31,6 +31,10 @@ config TARGET_SOCFPGA_SR1500
bool "SR1500 (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
 
+config TARGET_SOCFPGA_IS1
+   bool "IS1 (Cyclone V)"
+   select TARGET_SOCFPGA_CYCLONE5
+
 config TARGET_SOCFPGA_EBV_SOCRATES
bool "EBV SoCrates (Cyclone V)"
select TARGET_SOCFPGA_CYCLONE5
@@ -53,6 +57,7 @@ config SYS_BOARD
default "sockit" if TARGET_SOCFPGA_TERASIC_SOCKIT
default "socrates" if TARGET_SOCFPGA_EBV_SOCRATES
default "sr1500" if TARGET_SOCFPGA_SR1500
+   default "is1" if TARGET_SOCFPGA_IS1
 
 config SYS_VENDOR
default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK
@@ -73,5 +78,6 @@ config SYS_CONFIG_NAME
    default "socfpga_sockit" if TARGET_SOCFPGA_TERASIC_SOCKIT
default "socfpga_socrates" if TARGET_SOCFPGA_EBV_SOCRATES
default "socfpga_sr1500" if TARGET_SOCFPGA_SR1500
+   default "socfpga_is1" if TARGET_SOCFPGA_IS1
 
 e

[U-Boot] socfpga sr1500: possible typo in console=

[Pavel Machek]

Hi!

It seems include/configs/socfpga_sr1500.h is missing a ","...

-#define CONFIG_BOOTARGS "console=ttyS0"  __stringify(CONFIG_BAUDRATE)
+#define CONFIG_BOOTARGS "console=ttyS0,"   __stringify(CONFIG_BAUDRATE)
  

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] spl: Remove bogus GD_FLG_SPL_INIT check

[Pavel Machek]

On Mon 2016-05-30 17:22:33, Marek Vasut wrote:
> Remove the check for GD_FLG_SPL_INIT in spl_relocate_stack_gd().
> The check will always fail. This is because spl_relocate_stack_gd()
> is called from ARM's crt0.S and it is called before board_init_r().
> The board_init_r() calls spl_init(), which sets the GD_FLG_SPL_INIT
> flag.
> 
> Note that reserving the malloc area in RAM is not a problem even
> if the GD_FLG_SPL_INIT flag is not set.
> 
> Signed-off-by: Marek Vasut <ma...@denx.de>
> Cc: Chin Liang See <cl...@altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: Hans de Goede <hdego...@redhat.com>
> Cc: Pavel Machek <pa...@denx.de>
> Cc: Stefan Roese <s...@denx.de>
> Cc: Stephen Warren <swar...@nvidia.com>

Acked-by: Pavel Machek <pa...@denx.de>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] arm: socfpga: Enable tiny printf and simple malloc in SPL

[Pavel Machek]

On Mon 2016-05-30 17:22:34, Marek Vasut wrote:
> Enable both features to reduce the SPL size by 6 kiB.
> 
> Signed-off-by: Marek Vasut <ma...@denx.de>
> Cc: Chin Liang See <cl...@altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>

Acked-by: Pavel Machek <pa...@denx.de>
Tested-by: Pavel Machek <pa...@denx.de>

Thanks!
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Between 2015.10 and 2016.01, SPI flash changed erase size, and saveenv stopped working

[Pavel Machek]

On Mon 2016-05-30 10:43:39, Fabio Estevam wrote:
> On Mon, May 30, 2016 at 5:33 AM, Pavel Machek <pa...@denx.de> wrote:
> 
> > Commit c3c016cf75360c2a0d0a065b64b438aaf7720576 is a part of the problem:
> >
> > offset 0x4 is protected and cannot be erased
> > => sf help
> > No SPI flash selected. Please run `sf probe'
> > => sf probe
> > ...
> > SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
> > 64 MiB
> > cadence_spi_set_speed: speed=100
> > => sf protect unlock 0x4 0x2
> > cadence_spi_xfer: len=1 [bytes]
> > cadence_spi_xfer: len=1 [bytes]
> > => saveenv
> > Saving Environment to SPI Flash...
> 
> Does this quick hack help? I am wondering if yous SPI flash power up
> with the SR field protected:

Yes, it helps. Thanks! I can now write to the enviornment.

But it still does not look like locking is working quite correctly:

Best regards,
Pavel

=> sf protect lock 0xe 0x1
=> saveenv
Saving Environment to SPI Flash...
read_ops: at e1000, len f000
read: 61440 remains
read: 28672 remains
Erasing SPI flash...SF: erase 20  e  0  0 (e)
SF: erase 20  e 10  0 (e1000)
SF: erase 20  e 20  0 (e2000)
SF: erase 20  e 30  0 (e3000)
SF: erase 20  e 40  0 (e4000)
SF: erase 20  e 50  0 (e5000)
SF: erase 20  e 60  0 (e6000)
SF: erase 20  e 70  0 (e7000)
SF: erase 20  e 80  0 (e8000)
SF: erase 20  e 90  0 (e9000)
SF: erase 20  e a0  0 (ea000)
SF: erase 20  e b0  0 (eb000)
SF: erase 20  e c0  0 (ec000)
SF: erase 20  e d0  0 (ed000)
SF: erase 20  e e0  0 (ee000)
SF: erase 20  e f0  0 (ef000)
Writing to SPI flash...SF: 0x0bf4dd50 => cmd = { 0x02 0x0e }
chunk_len = 256
SF: 0x0bf4de50 => cmd = { 0x02 0x0e0100 } chunk_len = 256
SF: 0x0bf4df50 => cmd = { 0x02 0x0e0200 } chunk_len = 256
SF: 0x0bf4e050 => cmd = { 0x02 0x0e0300 } chunk_len = 256
SF: 0x0bf4e150 => cmd = { 0x02 0x0e0400 } chunk_len = 256
SF: 0x0bf4e250 => cmd = { 0x02 0x0e0500 } chunk_len = 256


> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -1021,11 +1021,7 @@ int spi_flash_scan(struct spi_flash *flash)
> return -EPROTONOSUPPORT;
> }
> 
> -   /* Flash powers up read-only, so clear BP# bits */
> -   if (idcode[0] == SPI_FLASH_CFI_MFR_ATMEL ||
> -   idcode[0] == SPI_FLASH_CFI_MFR_MACRONIX ||
> -   idcode[0] == SPI_FLASH_CFI_MFR_SST)
> -   write_sr(flash, 0);
> +   write_sr(flash, 0);
> 
> /* Assign spi data */
> flash->name = params->name;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHv2] check u-boot SPL size to avoid producing non-working images

[Pavel Machek]

Debugging SPL is hard, and if SPL is too big, it tends to crash in
mysterious ways.

(I'm not sure what the exact threshold is, 49762 bytes works, 52426
bytes does not, so 5 should be good value).

Signed-off-by: Pavel Machek <pa...@denx.de>

---

> Please use CONFIG_SPL_MAX_*

Ok, that's simple enough. It computes the size different way, thus the
different number.

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index f657766..c82da96 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -323,7 +332,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #define CONFIG_SPL_FRAMEWORK
 #define CONFIG_SPL_RAM_DEVICE
 #define CONFIG_SPL_TEXT_BASE   CONFIG_SYS_INIT_RAM_ADDR
-#define CONFIG_SPL_MAX_SIZE(64 * 1024)
+#define CONFIG_SPL_MAX_SIZE(48 * 1024)
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_SYS_MALLOC_SIMPLE
 #endif

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot 2016.07-rc0 does not seem to compile for me

[Pavel Machek]

I did the following to fix it up. It still might be problem with some
of my local changes, but you might want to test compile.

Thanks,
Pavel



diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 6a0e971..197c4ee 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -108,7 +108,7 @@ static int socfpga_dwmmc_probe(struct udevice *dev)
return ret;
 
upriv->mmc = host->mmc;
-   host->mmc->dev = dev;
+   //  host->mmc->dev = dev;
 
return 0;
 }

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Between 2015.10 and 2016.01, SPI flash changed erase size, and saveenv stopped working

[Pavel Machek]

On Mon 2016-05-30 05:21:28, Stefan Roese wrote:
> Hi Pavel,
> 
> On 29.05.2016 22:40, Pavel Machek wrote:
> >Hi!
> >
> >On board with Altera Cyclone 5:
> >
> >=> version
> >
> >U-Boot 2016.01-05658-g81689ec (May 29 2016 - 22:25:45 +0200)
> >arm-linux-gnueabi-gcc (GCC) 4.8.2
> >GNU ld (GNU Binutils) 2.24
> >Saving Environment to SPI Flash...
> >spi_flash_std_probe: slave=0bf367d0, cs=0
> >SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
> >total 64 MiB
> >offset 0x4 is protected and cannot be erased
> >
> >...
> >
> >=> version
> >
> >U-Boot 2015.10-04078-g3b6d086 (May 29 2016 - 22:33:36 +0200)
> >arm-linux-gnueabi-gcc (GCC) 4.8.2
> >GNU ld (GNU Binutils) 2.24
> >SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
> >64 MiB
> >
> >
> >Does anyone else see the problem? Any ideas?

Commit c3c016cf75360c2a0d0a065b64b438aaf7720576 is a part of the problem:

offset 0x4 is protected and cannot be erased
=> sf help
No SPI flash selected. Please run `sf probe'
=> sf probe
...
SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
64 MiB
cadence_spi_set_speed: speed=100
=> sf protect unlock 0x4 0x2
cadence_spi_xfer: len=1 [bytes]
cadence_spi_xfer: len=1 [bytes]
=> saveenv
Saving Environment to SPI Flash...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Between 2015.10 and 2016.01, SPI flash changed erase size, and saveenv stopped working

[Pavel Machek]

Hi!

> Commit c3c016cf75360c2a0d0a065b64b438aaf7720576 is a part of the problem:
> 
> offset 0x4 is protected and cannot be erased
> => sf help
> No SPI flash selected. Please run `sf probe'
> => sf probe
> ...
> SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
> 64 MiB
> cadence_spi_set_speed: speed=100
> => sf protect unlock 0x4 0x2
> cadence_spi_xfer: len=1 [bytes]
> cadence_spi_xfer: len=1 [bytes]
> => saveenv
> Saving Environment to SPI Flash...

Disabling flash locking like this seems to do the trick:

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 907067b..b75e66a 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1131,14 +1131,16 @@ int spi_flash_scan(struct spi_flash *flash)
 
/* lock hooks are flash specific - assign them based on idcode0 */
switch (idcode[0]) {
+#if 0
 #if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
case SPI_FLASH_CFI_MFR_STMICRO:
case SPI_FLASH_CFI_MFR_SST:
flash->flash_lock = stm_lock;
flash->flash_unlock = stm_unlock;
flash->flash_is_locked = stm_is_locked;
-#endif
break;
+#endif
+#endif
default:
debug("SF: Lock ops not supported for %02x flash\n", idcode[0]);
}

and if someone is watching, the #endif should be moved. switch (...) {
break;  } is strange kind of C.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Between 2015.10 and 2016.01, SPI flash changed erase size, and saveenv stopped working

[Pavel Machek]

On Mon 2016-05-30 05:21:28, Stefan Roese wrote:
> Hi Pavel,
> 
> On 29.05.2016 22:40, Pavel Machek wrote:
> >Hi!
> >
> >On board with Altera Cyclone 5:
> >
> >=> version
> >
> >U-Boot 2016.01-05658-g81689ec (May 29 2016 - 22:25:45 +0200)
> >arm-linux-gnueabi-gcc (GCC) 4.8.2
> >GNU ld (GNU Binutils) 2.24
> >Saving Environment to SPI Flash...
> >spi_flash_std_probe: slave=0bf367d0, cs=0
> >SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
> >total 64 MiB
> >offset 0x4 is protected and cannot be erased
> >
> >...
> >
> >=> version
> >
> >U-Boot 2015.10-04078-g3b6d086 (May 29 2016 - 22:33:36 +0200)
> >arm-linux-gnueabi-gcc (GCC) 4.8.2
> >GNU ld (GNU Binutils) 2.24
> >SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
> >64 MiB
> >
> >
> >Does anyone else see the problem? Any ideas?
> 
> I think you have run into the S-bit / cache issue with version
> the 2016 U-Boot version. This was fixed with these patches:
> 
> mtd: cqspi: Simplify indirect write code
> mtd: cqspi: Simplify indirect read code
> 
> Please use the v2016.05 release.

Sorry if I was unclear, but it is also broken in v2016.03, v2016.05
and v2016.07. I hoped narowing down range where it broke would help.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Between 2015.10 and 2016.01, SPI flash changed erase size, and saveenv stopped working

[Pavel Machek]

Hi!

On board with Altera Cyclone 5:

=> version

U-Boot 2016.01-05658-g81689ec (May 29 2016 - 22:25:45 +0200)
arm-linux-gnueabi-gcc (GCC) 4.8.2
GNU ld (GNU Binutils) 2.24
Saving Environment to SPI Flash...
spi_flash_std_probe: slave=0bf367d0, cs=0
SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
total 64 MiB
offset 0x4 is protected and cannot be erased

...

=> version

U-Boot 2015.10-04078-g3b6d086 (May 29 2016 - 22:33:36 +0200)
arm-linux-gnueabi-gcc (GCC) 4.8.2
GNU ld (GNU Binutils) 2.24
SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
64 MiB


Does anyone else see the problem? Any ideas?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] check u-boot SPL size to avoid producing non-working images

[Pavel Machek]

Debugging SPL is hard, and if SPL is too big, it tends to crash in
mysterious ways.

(I'm not sure what the exact threshold is, 49762 bytes works, 52426
bytes does not, so 5 should be good value).

Signed-off-by: Pavel Machek <pa...@denx.de>

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 6d2017d..504f0d2 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -237,6 +237,7 @@ endif
 
 MKIMAGEFLAGS_$(SPL_BIN).sfp = -T socfpgaimage
 $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
+   @if test `stat -c%s $(obj)/$(SPL_BIN).bin` -gt 5; then echo `stat 
-c%s $(obj)/$(SPL_BIN).bin` is too big, it probably will not work; exit 1; fi
$(call if_changed,mkimage)
 
 quiet_cmd_mksunxiboot = MKSUNXI $@


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot 2016.07-rc0: socfpga SPL too big in default configuration

[Pavel Machek]

Hi!

If I do "make socfpga_cyclone5_config" and then build u-boot-SPL, it
results in SPL that is way too big (49K is biggest image that works in
my testing).

pavel@amd:~/stahl/u-boot$ ls -al spl/u-boot-spl*
-rwxr-xr-x 1 pavel pavel 888587 May 27 23:03 spl/u-boot-spl
-rw-r--r-- 1 pavel pavel  55486 May 27 23:03 spl/u-boot-spl.bin
-rw-r--r-- 1 pavel pavel  26073 May 27 23:03 spl/u-boot-spl.cfg
-rw-r--r-- 1 pavel pavel   1646 May 27 23:03 spl/u-boot-spl.dtb
-rw-r--r-- 1 pavel pavel  55486 May 27 23:03 spl/u-boot-spl-dtb.bin
-rw-r--r-- 1 pavel pavel   1073 May 27 23:03 spl/u-boot-spl.lds
-rw-r--r-- 1 pavel pavel 137656 May 27 23:03 spl/u-boot-spl.map
-rwxr-xr-x 1 pavel pavel  53648 May 27 23:03 spl/u-boot-spl-nodtb.bin
-rw-r--r-- 1 pavel pavel192 May 27 23:03 spl/u-boot-spl-pad.bin
-rw-r--r-- 1 pavel pavel  65536 May 27 23:03 spl/u-boot-spl.sfp

(Based on commit 6523dbf7cce8d8c903346f756e0e41e46ce6d6b9).

gcc based on eldk 5.6. Is there some trick for smaller images?

Thanks and best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 1/2] mtd: cqspi: Simplify indirect write code

[Pavel Machek]

Hi!

> The indirect write code is buggy pile of nastiness which fails horribly
> when the system runs fast enough to saturate the controller. The failure
> results in some pages (256B) not being written to the flash. This can be
> observed on systems which run with Dcache enabled and L2 cache enabled,
> like the Altera SoCFPGA.
> 
> This patch replaces the whole unmaintainable indirect write implementation
> with the one from upcoming Linux CQSPI driver, which went through multiple
> rounds of thorough review and testing. While this makes the patch look
> terrifying and violates all best-practices of software development, all
> the patch does is it plucks out duplicate ad-hoc code distributed across
> the driver and replaces it with more compact code doing exactly the same
> thing.

Ok, sorry, I still don't understand the changelog.

First, it describes the bug with L2 cache enabled, but then it says
that "all the patch does .. doing exactly the same thing".

So I assume it does not do the same thing, but replaces duplicated
code in u-boot with working code from Linux?

Thanks for doing this,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] mtd: cqspi: Simplify indirect write code

[Pavel Machek]

Hi!

> This patch replaces the whole unmaintainable indirect write implementation
> with the one from upcoming Linux CQSPI driver, which went through multiple
> rounds of thorough review and testing. While this makes the patch look
> terrifying and violates all best-practices of software development,
> all

Could we get something less terifying and less violating? :-).

> the patch does is it plucks out duplicate ad-hoc code distributed across
> the driver and replaces it with more compact code doing exactly the same
> thing.

So this one is just a cleanup, and no behaviour change yet?

Pavel

> ---
>  drivers/spi/cadence_qspi_apb.c | 122 
> +
>  1 file changed, 26 insertions(+), 96 deletions(-)
> 
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index 7786dd6..00a50cb 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "cadence_qspi.h"
>  
>  #define CQSPI_REG_POLL_US(1) /* 1us */
> @@ -214,32 +215,6 @@ static void cadence_qspi_apb_read_fifo_data(void *dest,
>   return;
>  }
>  
> -static void cadence_qspi_apb_write_fifo_data(const void *dest_ahb_addr,
> - const void *src, unsigned int bytes)
> -{
> - unsigned int temp = 0;
> - int i;
> - int remaining = bytes;
> - unsigned int *dest_ptr = (unsigned int *)dest_ahb_addr;
> - unsigned int *src_ptr = (unsigned int *)src;
> -
> - while (remaining >= CQSPI_FIFO_WIDTH) {
> - for (i = CQSPI_FIFO_WIDTH/sizeof(src_ptr) - 1; i >= 0; i--)
> - writel(*(src_ptr+i), dest_ptr+i);
> - src_ptr += CQSPI_FIFO_WIDTH/sizeof(src_ptr);
> - remaining -= CQSPI_FIFO_WIDTH;
> - }
> - if (remaining) {
> - /* dangling bytes */
> - i = remaining/sizeof(dest_ptr);
> - memcpy(, src_ptr+i, remaining % sizeof(dest_ptr));
> - writel(temp, dest_ptr+i);
> - for (--i; i >= 0; i--)
> - writel(*(src_ptr+i), dest_ptr+i);
> - }
> - return;
> -}
> -
>  /* Read from SRAM FIFO with polling SRAM fill level. */
>  static int qspi_read_sram_fifo_poll(const void *reg_base, void *dest_addr,
>   const void *src_addr,  unsigned int num_bytes)
> @@ -276,44 +251,6 @@ static int qspi_read_sram_fifo_poll(const void 
> *reg_base, void *dest_addr,
>   return 0;
>  }
>  
> -/* Write to SRAM FIFO with polling SRAM fill level. */
> -static int qpsi_write_sram_fifo_push(struct cadence_spi_platdata *plat,
> - const void *src_addr, unsigned int num_bytes)
> -{
> - const void *reg_base = plat->regbase;
> - void *dest_addr = plat->ahbbase;
> - unsigned int retry = CQSPI_REG_RETRY;
> - unsigned int sram_level;
> - unsigned int wr_bytes;
> - unsigned char *src = (unsigned char *)src_addr;
> - int remaining = num_bytes;
> - unsigned int page_size = plat->page_size;
> - unsigned int sram_threshold_words = CQSPI_REG_SRAM_THRESHOLD_WORDS;
> -
> - while (remaining > 0) {
> - retry = CQSPI_REG_RETRY;
> - while (retry--) {
> - sram_level = CQSPI_GET_WR_SRAM_LEVEL(reg_base);
> - if (sram_level <= sram_threshold_words)
> - break;
> - }
> - if (!retry) {
> - printf("QSPI: SRAM fill level (0x%08x) not hit lower 
> expected level (0x%08x)",
> -sram_level, sram_threshold_words);
> - return -1;
> - }
> - /* Write a page or remaining bytes. */
> - wr_bytes = (remaining > page_size) ?
> - page_size : remaining;
> -
> - cadence_qspi_apb_write_fifo_data(dest_addr, src, wr_bytes);
> - src += wr_bytes;
> - remaining -= wr_bytes;
> - }
> -
> - return 0;
> -}
> -
>  void cadence_qspi_apb_controller_enable(void *reg_base)
>  {
>   unsigned int reg;
> @@ -810,48 +747,41 @@ int cadence_qspi_apb_indirect_write_setup(struct 
> cadence_spi_platdata *plat,
>  }
>  
>  int cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata 
> *plat,
> - unsigned int txlen, const u8 *txbuf)
> + unsigned int n_tx, const u8 *txbuf)
>  {
> - unsigned int reg = 0;
> - unsigned int retry;
> + unsigned int page_size = plat->page_size;
> + unsigned int remaining = n_tx;
> + unsigned int write_bytes;
> + int ret;
>  
>   /* Configure the indirect read transfer bytes */
> - writel(txlen, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
> + writel(n_tx, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
>  
>   /* Start the indirect write transfer */
>   

Re: [U-Boot] [PATCH] arm: dts: socfpga: fix DTC unit name warnings

[Pavel Machek]

Hi!

> >Hi!
> >
> >>Warning (unit_address_vs_reg): Node /soc/usbphy@0 has a unit name,
> >>  but no reg property
> >
> >I don't know who produces the warnings, but perhaps fix the tool,
> >instead?
> 
> This warnigns poping up with new DTC compilers, introduced from dtc
> commit:

IMO compiler should be fixed.

> ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies
> that any

This is arm. This is not powerpc. It is 2016, not 1997.

> >>-   usbphy0: usbphy@0 {
> >>+   usbphy0: usbphy {
> >>#phy-cells = <0>;
> >>compatible = "usb-nop-xceiv";
> >>status = "okay";
> >
> >And this sounds like a bug waiting to happen..
> 
> Better fix would be to add the reg property .. could you help me?

Introduce fake "reg" property to shut up warning?

I guess this should be solved on the kernel list, and I believe the
warnings are wrong.

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: socfpga: fix DTC unit name warnings

[Pavel Machek]

Hi!

> Warning (unit_address_vs_reg): Node /soc/usbphy@0 has a unit name,
>  but no reg property

I don't know who produces the warnings, but perhaps fix the tool,
instead?

> @@ -9,5 +9,5 @@
>   #size-cells = <1>;
>   chosen { };
>   aliases { };
> - memory { device_type = "memory"; reg = <0 0>; };
> + memory@0 { device_type = "memory"; reg = <0 0>; };
>  };

This does not look like an improvement to me...

> @@ -128,7 +128,7 @@
>   compatible = "fixed-clock";
>   };
>  
> - main_pll: main_pll {
> + main_pll: main_pll@40 {
>   #address-cells = <1>;
>   #size-cells = <0>;
>   #clock-cells = <0>;
> @@ -136,7 +136,7 @@
>   clocks = <>;
>   reg = <0x40>;
>  
> - mpuclk: mpuclk {
> + mpuclk: mpuclk@48 {
>   #clock-cells = <0>;
>   compatible = 
> "altr,socfpga-perip-clk";
>   clocks = <_pll>;

Neither do these, actually. So we have clock at fixed addresses. Why
is it wrong?

> @@ -742,7 +742,7 @@
>   reg = <0xffd05000 0x1000>;
>   };
>  
> - usbphy0: usbphy@0 {
> + usbphy0: usbphy {
>   #phy-cells = <0>;
>   compatible = "usb-nop-xceiv";
>   status = "okay";

And this sounds like a bug waiting to happen..

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/10] ddr: altera: Staticize global variables

[Pavel Machek]

On Thu 2016-04-07 04:04:05, Marek Vasut wrote:
> Just staticize global variables in sequencer, since there is no
> point in having these symbols available outside of the DDR code.
> 
> Signed-off-by: Marek Vasut <ma...@denx.de>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: Chin Liang See <cl...@altera.com>

Acked-by: Pavel Machek <pa...@denx.de>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[Pavel Machek]

Hi!

I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim
that this configuration is unsupported, but it enables fairly quick
development and was very useful for me in past.

Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before
I start bisecting it, I wanted to ask if someone has idea what might
be responsible?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[Pavel Machek]

Hi!

> I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim
> that this configuration is unsupported, but it enables fairly quick
> development and was very useful for me in past.
> 
> Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before
> I start bisecting it, I wanted to ask if someone has idea what might
> be responsible?

When I merge 1c84cc6e3badb31e55bdf05ff2d3f8f058a5da47, I get:

U-Boot 2016.01-rc2-01393-gc28dfb5 (Jan 20 2016 - 10:42:36 +0100)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT:  SD/MMC External Transceiver (1.8V)
   Watchdog enabled
   I2C:   ready
   DRAM:  1 GiB
   Error binding driver 'socfpga_dwmmc'
   Some drivers failed to bind
   Error binding driver 'generic_simple_bus'
   Some drivers failed to bind
   initcall sequence 3ffb10a4 failed at call 01003257 (err=-96)
   ### ERROR ### Please RESET the board ###


(But that's not failure I was looking for).

Commit 0c890879fe2a5731df7aee3dd38e455008fa9977 worked ok.

Commit 8e535af2e441030f5e4b940a3756a0d92646b5fe breaks compilation
(previous one worked ok in my config).

  LD  lib/built-in.o
LD  u-boot
board/altera/cyclone5-socdk/built-in.o: In function
`g_dnl_board_usb_cable_connected':
/home/pavel/amp/u-boot/board/altera/cyclone5-socdk/socfpga.c:25:
multiple definition of `board_init'
arch/arm/mach-socfpga/built-in.o::(.text.board_init+0x0): first
defined here
board/altera/cyclone5-socdk/built-in.o: In function `s_init':
/home/pavel/amp/u-boot/board/altera/cyclone5-socdk/socfpga.c:17:
multiple definition of `s_init'
...

Disabling "CONFIG_USB" fixes compilation for me, and can get back to
u-boot that starts but then pritns "initcall sequence 3ffb1300 failed
at call 01003263 (err=-96)".

Commit 07806977878130dd27dfc926ef7002041f6cf288 seems to break
compilation again (previous one worked), with:

drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
drivers/usb/host/dwc2.c:1027:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
undeclared (first use in this function)
  priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
  ^
 drivers/usb/host/dwc2.c:1027:40: note: each undeclared identifier is
 reported only once for each function it appears in

I'm able to get it back to compile when I rip out complete USB
support.

I have merged 68909e823eb4074a7e559e0c03d16533813c86cf, and now it
fails to boot at all.

While bisecting, this commit jumped to my attention:

commit 574967c241301b924748ce205f29f494e32967fe
Author: Marek Vasut 
Date:   Tue Dec 22 04:16:01 2015 +0100

arm: socfpga: Enable simple bus in SPL on all boards

The simple bus support must be enabled in SPL, otherwise the
boards will not be able to parse the DT and will fail to boot.

Signed-off-by: Marek Vasut 
Cc: Dinh Nguyen 

That's probably is biting me. Any idea which commit introduced this
"U-Boot proper needs U-Boot-SPL to have CONFIG_SPL_SIMPLE_BUS=y
dependency?

Thanks,
Pavel 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[Pavel Machek]

Hi!

> On 20.01.2016 10:31, Pavel Machek wrote:
> >I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim
> >that this configuration is unsupported, but it enables fairly quick
> >development and was very useful for me in past.
> 
> Yes, I use this chainloading also quite frequently on some platforms.
> It should generally work on platforms with SPL support. Where the
> preloader / SPL / BootROM has initialized the base HW and the SDRAM.
> So that the U-Boot proper can get loaded into SDRAM. So it should
> also work on SoCFPGA. I have to admit, that I haven't tested it
> lately on SoCFPGA though.
> 
> >Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before
> >I start bisecting it, I wanted to ask if someone has idea what might
> >be responsible?
> 
> As mentioned above, I've not tested on this platform lately, sorry.
> But I assume that you also test the latest release version, yes?
> And current master as well. Also failing there?

I have not got to current master. I retested 2016.01 now, and used
config not based on my previous one, but based on defconfig, and it
seems to work.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Pavel Machek]

On Sun 2016-01-10 12:56:15, Pavel Machek wrote:
> Hi!
> 
> After updating from 2016-rc1, I get this compile error:
> 
>   CC  common/main.o
>   drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
>   drivers/usb/host/dwc2.c:1028:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
>   undeclared (first use in this function)
> priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
> ^
> make mrproper socfpga_cyclone5_config
> 
> Fixes the problem.

Well, it "fixes" the problem by not compiling dwc2.

Socfpga clearly wants DWC2:

include/configs/socfpga_common.h:#define CONFIG_USB_DWC2
include/configs/socfpga_common.h:#define CONFIG_USB_GADGET_DWC2_OTG

But does not contain required address:

[pavel@pollux u-boot]$ grep -ri USB_DWC2_REG_ADDR .
./drivers/usb/host/dwc2.c:  priv->regs = (struct dwc2_core_regs 
*)CONFIG_USB_DWC2_REG_ADDR;
./README:   CONFIG_USB_DWC2_REG_ADDR the physical CPU address of 
the DWC2
./include/configs/hikey.h:#define CONFIG_USB_DWC2_REG_ADDR 0xF72C
./include/configs/rpi-common.h:#define CONFIG_USB_DWC2_REG_ADDR 0x3f98
./include/configs/rpi-common.h:#define CONFIG_USB_DWC2_REG_ADDR 0x2098

Plus, make socfpga_cyclone5_config does not enable USB, which is
probably error.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Pavel Machek]

Hi!

After updating from 2016-rc1, I get this compile error:

  CC  common/main.o
  drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
  drivers/usb/host/dwc2.c:1028:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
  undeclared (first use in this function)
priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
^
make mrproper socfpga_cyclone5_config

Fixes the problem.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Pavel Machek]

On Sun 2016-01-10 14:45:54, Marek Vasut wrote:
> On Sunday, January 10, 2016 at 01:04:17 PM, Pavel Machek wrote:
> > On Sun 2016-01-10 12:56:15, Pavel Machek wrote:
> > > Hi!
> > > 
> > > After updating from 2016-rc1, I get this compile error:
> > >   CC  common/main.o
> > >   drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':
> > >   drivers/usb/host/dwc2.c:1028:40: error: 'CONFIG_USB_DWC2_REG_ADDR'
> > >   undeclared (first use in this function)
> > >   
> > > priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
> > > 
> > > ^
> > > 
> > > make mrproper socfpga_cyclone5_config
> > > 
> > > Fixes the problem.
> > 
> > Well, it "fixes" the problem by not compiling dwc2.
> > 
> > Socfpga clearly wants DWC2:
> > 
> > include/configs/socfpga_common.h:#define CONFIG_USB_DWC2
> > include/configs/socfpga_common.h:#define CONFIG_USB_GADGET_DWC2_OTG
> > 
> > But does not contain required address:
> > 
> > [pavel@pollux u-boot]$ grep -ri USB_DWC2_REG_ADDR .
> > ./drivers/usb/host/dwc2.c:  priv->regs = (struct dwc2_core_regs
> > *)CONFIG_USB_DWC2_REG_ADDR; ./README:   
> > CONFIG_USB_DWC2_REG_ADDR 
> the
> > physical CPU address of the DWC2 ./include/configs/hikey.h:#define
> > CONFIG_USB_DWC2_REG_ADDR 0xF72C ./include/configs/rpi-common.h:#define
> > CONFIG_USB_DWC2_REG_ADDR 0x3f98 ./include/configs/rpi-common.h:#define
> > CONFIG_USB_DWC2_REG_ADDR 0x2098
> > 
> > Plus, make socfpga_cyclone5_config does not enable USB, which is
> > probably error.
> 
> SoCFPGA is using USB DM , so these base addresses are pulled from OF
> and are no longer hard-coded.
> 
> Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you please
> test mainline _before_ reporting issues ?

Can you please test mainline before complaining?

With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
get the failure. No, CONFIG_DM_USB is not set in the config, which is
probably the problem.

Maybe socfpga should select DM_USB or depend on it?


Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#
# Automatically generated file; DO NOT EDIT.
# U-Boot 2016.01-rc4 Configuration
#
CONFIG_CREATE_ARCH_SYMLINK=y
CONFIG_HAVE_GENERIC_BOARD=y
CONFIG_SYS_GENERIC_BOARD=y
# CONFIG_ARC is not set
CONFIG_ARM=y
# CONFIG_AVR32 is not set
# CONFIG_BLACKFIN is not set
# CONFIG_M68K is not set
# CONFIG_MICROBLAZE is not set
# CONFIG_MIPS is not set
# CONFIG_NDS32 is not set
# CONFIG_NIOS2 is not set
# CONFIG_OPENRISC is not set
# CONFIG_PPC is not set
# CONFIG_SANDBOX is not set
# CONFIG_SH is not set
# CONFIG_SPARC is not set
# CONFIG_X86 is not set
CONFIG_SYS_ARCH="arm"
CONFIG_SYS_CPU="armv7"
CONFIG_SYS_SOC="socfpga"
CONFIG_SYS_VENDOR="altera"
CONFIG_SYS_BOARD="cyclone5-socdk"
CONFIG_SYS_CONFIG_NAME="socfpga_cyclone5_socdk"

#
# ARM architecture
#
CONFIG_HAS_VBAR=y
CONFIG_HAS_THUMB2=y
CONFIG_CPU_V7=y
# CONFIG_SEMIHOSTING is not set
# CONFIG_SYS_L2CACHE_OFF is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_TARGET_EDB93XX is not set
# CONFIG_TARGET_VCMA9 is not set
# CONFIG_TARGET_SMDK2410 is not set
# CONFIG_TARGET_ASPENITE is not set
# CONFIG_TARGET_GPLUGD is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_KIRKWOOD is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_TARGET_DEVKIT3250 is not set
# CONFIG_TARGET_WORK_92105 is not set
# CONFIG_TARGET_MX25PDK is not set
# CONFIG_TARGET_ZMX25 is not set
# CONFIG_TARGET_APF27 is not set
# CONFIG_TARGET_APX4DEVKIT is not set
# CONFIG_TARGET_XFI3 is not set
# CONFIG_TARGET_M28EVK is not set
# CONFIG_TARGET_MX23EVK is not set
# CONFIG_TARGET_MX28EVK is not set
# CONFIG_TARGET_MX23_OLINUXINO is not set
# CONFIG_TARGET_BG0900 is not set
# CONFIG_TARGET_SANSA_FUZE_PLUS is not set
# CONFIG_TARGET_SC_SPS_1 is not set
# CONFIG_ORION5X is not set
# CONFIG_TARGET_SPEAR300 is not set
# CONFIG_TARGET_SPEAR310 is not set
# CONFIG_TARGET_SPEAR320 is not set
# CONFIG_TARGET_SPEAR600 is not set
# CONFIG_TARGET_STV0991 is not set
# CONFIG_TARGET_X600 is not set
# CONFIG_TARGET_IMX31_PHYCORE is not set
# CONFIG_TARGET_MX31ADS is not set
# CONFIG_TARGET_MX31PDK is not set
# CONFIG_TARGET_WOODBURN is not set
# CONFIG_TARGET_WOODBURN_SD is not set
# CONFIG_TARGET_FLEA3 is not set
# CONFIG_TARGET_MX35PDK is not set
# CONFIG_ARCH_BCM283X is not set
# CONFIG_TARGET_VEXPRESS_CA15_TC2 is not set
# CONFIG_TARGET_VEXPRESS_CA5X2 is not set
# CONFIG_TARGET_VEXPRESS_CA9X4 is not set
# CONFIG_T

[U-Boot] Are non-default configurations expected to work? Re: usb: dwc2: does not compile in 2016-rc3 when updating from -rc1.

[Pavel Machek]

> > > Pristine u-boot 2016.01-rc4 compiles fine for CV SoCDK. Can you please
> > > test mainline _before_ reporting issues ?
> > 
> > Can you please test mainline before complaining?
> 
> Yes I _did_ test mainline AND booted it on the actual board. The USB does work
> (if you disable dcache, which is unrelated bug). It would be very nice if you
> did the same thing before you start yelling on the list that there is a bug.
> 
> The config you use and the one produced by make socfpga_cyclone5_defconfig 
> differ. Use the mainline one, otherwise you will observe possible
> problems.

Of course they differ. That's why they are called configuration _options_.

> > With d77a092dd3619ca747fb8290ae8f255e9799aaa6 and attached .config, I
> > get the failure. No, CONFIG_DM_USB is not set in the config, which is
> > probably the problem.
> 
> Again, the problem does not happen if you use mainline config. If you enable
> random options, you might run into random problems.
> 
> > Maybe socfpga should select DM_USB or depend on it?
> 
> u-boot$ git grep DM_USB configs/socfpga_*
> configs/socfpga_arria5_defconfig:CONFIG_DM_USB=y
> configs/socfpga_cyclone5_defconfig:CONFIG_DM_USB=y
> configs/socfpga_de0_nano_soc_defconfig:CONFIG_DM_USB=y
> configs/socfpga_mcvevk_defconfig:CONFIG_DM_USB=y
> configs/socfpga_sockit_defconfig:CONFIG_DM_USB=y
> configs/socfpga_socrates_defconfig:CONFIG_DM_USB=y
> 
> So your config is broken or outdated, please update your config.

No. Mainline is broken. Yes, it happens to work with defconfig. But it
should work with any configuration user can select.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] arm: socfpga: Enabling MTD default partitions

[Pavel Machek]

On Tue 2015-12-22 00:17:15, Marek Vasut wrote:
> On Monday, December 21, 2015 at 04:01:51 PM, Chin Liang See wrote:
> > Enabling MTD default partitions if its not defined in board
> > configuration file. The layout as below
> >  device nor0 , # parts = 6
> 
> ff705000.spi.0 (the dot is missing). I can fix it while applying though.
> 
> >  #: namesizeoffset  mask_flags
> >  0: u-boot  0x0010  0x  0
> >  1: env10x0004  0x0010  0
> >  2: env20x0004  0x0014  0
> >  3: UBI 0x03e8  0x0018  0
> >  4: boot0x00e8  0x0018  0
> >  5: rootfs  0x0100  0x0100  0
> > 
> > Signed-off-by: Chin Liang See <cl...@altera.com>
> > Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> > Cc: Dinh Nguyen <dinh.li...@gmail.com>
> > Cc: Pavel Machek <pa...@denx.de>
> > Cc: Marek Vasut <ma...@denx.de>
> > Cc: Stefan Roese <s...@denx.de>
> 
> Applied, thanks.

Would we normally list "offset" first?

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

Hi!

> > I presume you are referring to SPL? FYI, I am still using the SPL from
> > SOCEDS while using latest U-Boot from mainstream. That's why I didn't
> > the issue noticed by Shengjiang and you.
> 
> Well, at least you're honest ... but *sigh*, it'd be nice if you tested
> mainline only, really.

Actually... If there are enough resources, it would be good to keep
testing both. There's world beyond mainline Marek does not want to see
;-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/5] arm: socfpga: cyclone5: Undefine CONFIG_SPI_FLASH_USE_4K_SECTORS

[Pavel Machek]

On Tue 2015-12-22 08:59:46, Chin Liang See wrote:
> Undefine CONFIG_SPI_FLASH_USE_4K_SECTORS for UBI
> and UBIFS support on serial NOR flash
> 
> Signed-off-by: Chin Liang See <cl...@altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: Dinh Nguyen <dinh.li...@gmail.com>
> Cc: Pavel Machek <pa...@denx.de>
> Cc: Marek Vasut <ma...@denx.de>
> Cc: Stefan Roese <s...@denx.de>
> ---
> Changes for v2
> - move CONFIG_SPI_FLASH_USE_4K_SECTORS to Kconfig
> ---
>  configs/socfpga_cyclone5_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/socfpga_cyclone5_defconfig 
> b/configs/socfpga_cyclone5_defconfig
> index 864358c..4216b55 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -23,3 +23,4 @@ CONFIG_DESIGNWARE_SPI=y
>  CONFIG_DM_MMC=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
> +CONFIG_SPI_FLASH_USE_4K_SECTORS=n

Actually, do we usually specify =n in config files? It seems to be so
rare it is an error.

Normally, we have something like "# CONFIG_SYS_MALLOC_F is not set" in
config files.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Fix QSPI doesn't work on socdk board

[Pavel Machek]

On Mon 2015-12-21 11:12:29, Marek Vasut wrote:
> On Monday, December 21, 2015 at 10:37:23 AM, Pavel Machek wrote:
> > On Mon 2015-12-21 07:33:34, 圣江 吴 wrote:
> > > Hi Marek Vasut,
> > > 
> > > 
> > > On Dec 18, 2015, at 04:50 AM, Marek Vasut <ma...@denx.de> wrote:
> > > 
> > > On Friday, December 18, 2015 at 08:57:22 AM, 圣江 吴 wrote:
> > > Hi Chin,
> > > 
> > > The PLL settings are copied from previous version
> > > http://git.rocketboards.org/u-boot-socfpga.git,
> > > 
> > > This stuff should be generated by quartus, so why are you copying it from
> > > some random version of u-boot somewhere ?
> > > 
> > > Thank you for your comment, if this configuration
> > > is automatically generated by Quartus without manually modification,
> > > then I would like to withdraw this patch.
> > 
> > No, please don't. socdk should work out of the box.
> 
> SoCDK works out of the box last time I checked (2016.01rc1), did you test it 
> recently and do you observe problems ?

Did you test QSPI? Because that is what subject claims does not work.

> > I should not need
> > quartus to build a working u-boot spl for the board.
> 
> You DO need quartus to generate the header files (that go into board/nnn/qts)
> to build working U-Boot SPL for any board. I fail to understand your comment,
> sorry.

Ok, lets talk about this personally or over phone.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Fix QSPI doesn't work on socdk board

[Pavel Machek]

On Mon 2015-12-21 07:33:34, 圣江 吴 wrote:
> Hi Marek Vasut,
> 
> 
> On Dec 18, 2015, at 04:50 AM, Marek Vasut  wrote:
> 
> On Friday, December 18, 2015 at 08:57:22 AM, 圣江 吴 wrote:
> Hi Chin,
> 
> The PLL settings are copied from previous version
> http://git.rocketboards.org/u-boot-socfpga.git,
> 
> This stuff should be generated by quartus, so why are you copying it from
> some random version of u-boot somewhere ?

> Thank you for your comment, if this configuration is automatically generated 
> by Quartus without manually modification, then I would like to withdraw this 
> patch.
> 

No, please don't. socdk should work out of the box. I should not need
quartus to build a working u-boot spl for the board.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] arm: socfpga: Fix QSPI doesn't work on socdk board

[Pavel Machek]

On Fri 2015-12-18 08:48:39, 圣江 吴 wrote:
> 
> 
> On Dec 18, 2015, at 12:47 AM, Chin Liang See <cl...@altera.com> wrote:
> 
> Hi Shangjiang
> 
> On Fri, 2015-12-18 at 16:43 +0800, shengjiangwu wrote:
> Updated pinmux group MIXED1IO[15-20] for QSPI.
> Updated QSPI clock.
> 
> Signed-off-by: shengjiangwu <shengjian...@icloud.com>
> Cc: Chin Liang See <cl...@altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: Dinh Nguyen <dinh.li...@gmail.com>
> Cc: Pavel Machek <pa...@denx.de>
> Cc: Marek Vasut <ma...@denx.de>
> Cc: Stefan Roese <s...@denx.de>
> ---
> Changes for v2:
> - fixed wrong perpll for QSPI
> ---
> board/altera/cyclone5-socdk/qts/pll_config.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> I believe you forget to put back the pinmux change here.
> 
> Thanks
> Chin Liang
> 
> Understand, I need to generate the whole patch. 
> 
> 

Can you also do something with your email setup? Normally, you'd want
to have in-reply-to headers, and quote email you are replying to with
"> " at begining of line..

Thanks
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
> On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
> > (Please, trim your emails when replying)

> > > Try this:
> > > 
> > > mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@1536k
> > > (UBI)
> > > 
> > > This will create overlapping partitions "boot,root" and "UBI" .
> > 
> > Just because you can does not mean that you should. This looks like a
> > nasty trap for a user.
> 
> Please explain in detail why do you think so.

Please make a 200 page study of human psychology explaining that noone
would ever be confused by two overlapping partitions :-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

On Mon 2015-12-14 12:31:32, Marek Vasut wrote:
> On Monday, December 14, 2015 at 12:26:39 PM, Pavel Machek wrote:
> > On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
> > > On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
> > > > (Please, trim your emails when replying)
> > > > 
> > > > > Try this:
> > > > > 
> > > > > mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@1
> > > > > 536k (UBI)
> > > > > 
> > > > > This will create overlapping partitions "boot,root" and "UBI" .
> > > > 
> > > > Just because you can does not mean that you should. This looks like a
> > > > nasty trap for a user.
> > > 
> > > Please explain in detail why do you think so.
> > 
> > Please make a 200 page study of human psychology explaining that noone
> > would ever be confused by two overlapping partitions :-).
> 
> Add a comment explaining the situation and reasoning behind that, problem 
> solved.

We do partitions so that people don't overwrite data by
mistake. Having overlapping partitions kind of defeats the purpose.

Just because trap is documented does not mean that it is not
nasty. 199.95 pages to go.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

On Mon 2015-12-14 13:20:28, Marek Vasut wrote:
> On Monday, December 14, 2015 at 12:51:16 PM, Pavel Machek wrote:
> > On Mon 2015-12-14 12:31:32, Marek Vasut wrote:
> > > On Monday, December 14, 2015 at 12:26:39 PM, Pavel Machek wrote:
> > > > On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
> > > > > On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
> > > > > > (Please, trim your emails when replying)
> > > > > > 
> > > > > > > Try this:
> > > > > > > 
> > > > > > > mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root)
> > > > > > > ,-@1 536k (UBI)
> > > > > > > 
> > > > > > > This will create overlapping partitions "boot,root" and "UBI" .
> > > > > > 
> > > > > > Just because you can does not mean that you should. This looks like
> > > > > > a nasty trap for a user.
> > > > > 
> > > > > Please explain in detail why do you think so.
> > > > 
> > > > Please make a 200 page study of human psychology explaining that noone
> > > > would ever be confused by two overlapping partitions :-).
> > > 
> > > Add a comment explaining the situation and reasoning behind that, problem
> > > solved.
> > 
> > We do partitions so that people don't overwrite data by
> > mistake. Having overlapping partitions kind of defeats the purpose.
> 
> I'd expect that in case you are fiddling with MTD on a bootloader level, you
> have at least a vague idea of what you are doing.

Yes, but people should not have to expect we prepare traps for them.

> > Just because trap is documented does not mean that it is not
> > nasty. 199.95 pages to go.
> 
> Do you have a better idea how to satisfy both sets of people, ones which want
> kernel on a separate partition and ones which want to use single UBI volume
> then ?

If you expect people to read a comments explaining a situation, you
can easily add an explanation and (commented out) alternative
configutation that can be used.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARMv7 MMU shareability issue

[Pavel Machek]

Hi!

> This patch has several effects:
> 
> - it selects proper ARMv7 translation table level 1 bit definitions;
> - it provides proper ARMv7 definitions for WT/WB/WA;
> - it selects proper ARMv7 settings for TTBR0.
> 
> All these are correct as per the docs I have (although I may have missed
> something during the readings (and cross-readings with Marek) of these
> last hours/days.
> 
> Now, one specific effect goes against performance, and it is the
> setting of bit S in all TT entries. This bit makes the corresponding
> region shareable, but for all I know, in U-Boot we don't have more than
> one core accessing the same memory or registers sets so -- at least for
> the major part of its execution -- there is no reason for any region to
> be shareable.

Well, I'm currently working on AMP patch, which will mean two
processors at the same time in u-boot.

Also... we provide memory modify operations for the user. User may
be trying to communicate with second core.

> /That/ effect I certainly don't want.

How big is the slowdown from S bit?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

(Please, trim your emails when replying)

On Mon 2015-12-14 01:58:04, Marek Vasut wrote:
> On Monday, December 14, 2015 at 01:43:58 AM, Chin Liang See wrote:
> > On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
> > > On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
> > > > On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
> > > > > On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See

> > After grabbing a coffee
> 
> That's a good idea, though I think I will make do with a green tea (抹茶).
> 
> > and rethinking, we can have 2 MTD_PARTITION
> > where one for backward compatiblity (supporting raw) while another for
> > UBI.
> > 
> > MTDPARTS_RAW
> > 256k(spl),
> > 256k(env),
> > 15872k(boot),
> > -(rootfs)
> > 
> > MTDPARTS_UBI
> > 256k(spl),
> > 256k(env),
> > -(UBI)
> > 
> > We should make UBI as default then. If user care about backward
> > compatiblity, they shall use the MTDPARTS_RAW then.
> 
> Try this:
> 
> mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@1536k(UBI)
> 
> This will create overlapping partitions "boot,root" and "UBI" .

Just because you can does not mean that you should. This looks like a
nasty trap for a user.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Very confusing variable=name behaviour

[Pavel Machek]

Hi!

I'm getting quite crazy behaviour of variables in recent u-boot:

VERSION = 2016
PATCHLEVEL = 01
SUBLEVEL =
EXTRAVERSION = -rc1


Bytes transferred = 104656 (198d0 hex)
=> bootm_boot_mode=nonsec
=> echo $bootm_boot_mode
nonsec
=> prinetenv bootm_boot_mode
Unknown command 'prinetenv' - try 'help'
=> printenv bootm_boot_mode
## Error: "bootm_boot_mode" not defined
=> echo $bootm_boot_mode
nonsec
=>

What is going on there? C-level  "getenv" fails on such variable, too.

bootm_boot_mode = ''

Explicit setenv behaves as expected:

=> setenv bootm_boot_mode nonsec
=> echo $bootm_boot_mode
nonsec
=> printenv bootm_boot_mode
bootm_boot_mode=nonsec
=>

Best regards,

 Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/4] arm: socfpga: socrates: Enabling U-Boot environment in QSPI

[Pavel Machek]

On Sat 2015-12-12 08:47:41, Chin Liang See wrote:
> Enabling the support of storing U-Boot environment
> within serial NOR flash. By default, its still
> store into SDMMC
> 
> Signed-off-by: Chin Liang See <cl...@altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: Dinh Nguyen <dinh.li...@gmail.com>
> Cc: Pavel Machek <pa...@denx.de>
> Cc: Marek Vasut <ma...@denx.de>
> Cc: Stefan Roese <s...@denx.de>



> --- a/include/configs/socfpga_socrates.h
> +++ b/include/configs/socfpga_socrates.h
> @@ -54,9 +54,15 @@
>  
>  #endif
>  
> +/* U-Boot environment */
>  #define CONFIG_ENV_IS_IN_MMC
> +#ifdef CONFIG_ENV_IS_IN_MMC
>  #define CONFIG_SYS_MMC_ENV_DEV   0   /* device 0 */
>  #define CONFIG_ENV_OFFSET512 /* just after the MBR */
> +#elif CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_ENV_SECT_SIZE (64 * 1024)
> +#define CONFIG_ENV_OFFSET0x40
> +#endif

This configuration is again shared with all the boards that have NOR,
right? So time to create include/configs/socfpga_spi_nor.h or
something like that?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Pavel Machek]

On Fri 2015-12-11 17:15:50, Chin Liang See wrote:
> Enabling mtd partitioning layout which indicate partition
> for various boot partition
> 
> Signed-off-by: Chin Liang See <cl...@altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: Dinh Nguyen <dinh.li...@gmail.com>
> Cc: Pavel Machek <pa...@denx.de>
> Cc: Marek Vasut <ma...@denx.de>
> Cc: Stefan Roese <s...@denx.de>
> ---
>  include/configs/socfpga_de0_nano_soc.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/configs/socfpga_de0_nano_soc.h 
> b/include/configs/socfpga_de0_nano_soc.h
> index 16e146c..c42175d 100644
> --- a/include/configs/socfpga_de0_nano_soc.h
> +++ b/include/configs/socfpga_de0_nano_soc.h
> @@ -86,4 +86,16 @@
>  /* The rest of the configuration is shared */
>  #include 
> 
> +/* mtd partitioning for serial NOR flash */
> +#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)
> +#define MTDPARTS_DEFAULT "mtdparts=ff705000.spi:"\
> + "256k(spl),"\
> + "64k(env)," \
> + "64k(dtb)," \
> + "256k(boot),"   \
> + "16m(kernel),"  \
> + "16m(rootfs),"  \
> + "-(UBI)\0"
> +#endif
> +
>  #endif   /* __CONFIG_TERASIC_DE0_H__ */

Ok, three copies of the same table. Should it go to socfpga common?
You could at least do

MTDPARTS_DEFAULT_SOCDK

and then use

#define MTDPARTS_DEFAULT MTDPARTS_DEFAULT_SOCDK

in the socfpga_de0_nano_soc.h, so we don't have 3 copies of the same
table.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Pavel Machek]

> > > > Usage:
> > > > ubifsmount 
> > > > 
> > > > - mount 'volume-name' volume
> > > > 
> > > > In the mean time, I was not able to get ubifsmount works.
> > > > Appreciate
> > > > for any quick advise? Else will look into the code tomorrow as my
> > > > bed
> > > > is calling me :)
> > > 
> > > I usually write ubinized image into the "rootfs" partition (sf erase
> > > and
> > > then sf write) and then do 'ubi part rootfs' , which fails with error
> > > 22
> > > unless I revert this patch. If I dump the SPI NOR area after writing
> > > the
> > > data, I see that the last 2 bytes of some pages are corrupted.
> > > 
> > > I am using these parameters to generate my ~11MiB large ubinized
> > > image:
> > > MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> > > UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> > > 
> > > Here is the content of my ubinize.cfg:
> > > [rootfs]
> > > mode=ubi
> > > image=root.ubifs
> > > vol_id=0
> > > vol_type=dynamic
> > > vol_name=rootfs
> > > vol_flags=autoresize
> > 
> > Thanks for the pointers.
> > 
> > I checked the source and enabled the debug message. Noticed my failure
> > is due to small LEB and PEB size. It was set to 4k which is the sub
> > -sector erase size of NOR flash. I suspect you didn't hit this as you
> > generate ubinized image which is 64kB erase size.
> > 
> > I will continue to dig more. Need to ensure it works when user create
> > UBI part in U-Boot on top of serial NOR flash (which is commonly 4kB
> > erase size). Hopefully existing U-Boot already have source taking care
> > this :)
> 
> I am tempted to revert this patch, since it breaks USB and UBI for me
> on two different boards though.

It caused regressions it was not supposed to change. That means
revert...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: eth_designware: select PHYLIB in Kconfig

[Pavel Machek]

On Sun 2015-12-06 21:19:56, Thomas Chou wrote:
> Select PHYLIB in drivers/net/Kconfig. And remove CONFIG_PHYLIB
> from legacy board header files.
> 
> This fixed the warnings when both ALTERA_TSE and ETH_DESIGNWARE
> are selected.
> 

Acked-by: Pavel Machek <pa...@denx.de>
Tested-by: Pavel Machek <pa...@denx.de>

Thanks!
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Don't redefine CONFIG_PHYLIB

[Pavel Machek]

On Sat 2015-12-05 18:54:01, Marek Vasut wrote:
> On Saturday, December 05, 2015 at 06:25:19 PM, Pavel Machek wrote:
> > On Sat 2015-12-05 15:04:25, Marek Vasut wrote:
> > > On Saturday, December 05, 2015 at 08:50:39 AM, Pavel Machek wrote:
> > > > CONFIG_PHYLIB is already set by the config system
> > > 
> > > Where exactly is it set by the config system ?
> > > 
> > > > don't set it again.
> > > > Avoids ton of warnings.
> > > 
> > > Sorry, I don't seem to be able to replicate these warnings. Can you
> > > provide more details ?
> > 
> > U-boot based on be30dfbabbee12770221f434d2aa08627e712b97 .
> > 
> > pavel@duo:~/amp/u-boot$ grep -ri PHYLIB `find . -name "Kconfig"`
> > ./drivers/net/Kconfig:config PHYLIB
> > ./drivers/net/Kconfig:   select PHYLIB
> > ./drivers/net/Kconfig: 100Mbit and 1 Gbit operation. You must
> > enable CONFIG_PHYLIB to
> > ./drivers/net/Kconfig:  select PHYLIB
> > 
> > ALTERA_TSE selects it.
> 
> Altera TSE is not selected on any socfpga platform to my knowledge.
> Could it be your patch which is causing the interference ?

Ok, that explains why you don't see it. I have ALTERA_TSE
enabled. ... which is probably useless, but still should not cause ton
of warnings.

Question is: how to solve it properly?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Don't redefine CONFIG_PHYLIB

[Pavel Machek]

On Sat 2015-12-05 15:04:25, Marek Vasut wrote:
> On Saturday, December 05, 2015 at 08:50:39 AM, Pavel Machek wrote:
> > CONFIG_PHYLIB is already set by the config system
> 
> Where exactly is it set by the config system ?
> 
> > don't set it again.
> > Avoids ton of warnings.
> 
> Sorry, I don't seem to be able to replicate these warnings. Can you provide
> more details ?

U-boot based on be30dfbabbee12770221f434d2aa08627e712b97 .

pavel@duo:~/amp/u-boot$ grep -ri PHYLIB `find . -name "Kconfig"`
./drivers/net/Kconfig:config PHYLIB
./drivers/net/Kconfig:   select PHYLIB
./drivers/net/Kconfig: 100Mbit and 1 Gbit operation. You must
enable CONFIG_PHYLIB to
./drivers/net/Kconfig:  select PHYLIB

ALTERA_TSE selects it.

Let me know if you need more info.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm: socfpga: Don't redefine CONFIG_PHYLIB

[Pavel Machek]

CONFIG_PHYLIB is already set by the config system, don't set it again.
Avoids ton of warnings.

Signed-off-by: Pavel Machek <pa...@denx.de>

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index b3f65b6..86eccba 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -105,7 +105,6 @@
 #define CONFIG_DW_ALTDESCRIPTOR
 #define CONFIG_MII
 #define CONFIG_AUTONEG_TIMEOUT (15 * CONFIG_SYS_HZ)
-#define CONFIG_PHYLIB
 #define CONFIG_PHY_GIGE
 #endif
 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv4 3/9] arm: socfpga: arria10: add reset manager for Arria10

[Pavel Machek]

On Wed 2015-12-02 13:31:27, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> Add the defines for the reset manager and some basic reset functionality.
> 
> Signed-off-by: Dinh Nguyen 
> ---
> v4: rename mod_reset names to be used by both gen5 and a10
> v3: remove duplicate reset function
> use CONFIG_SOCFPGA_GEN5
> v2: integrate into a5/c5 reset manager
> ---
>  arch/arm/mach-socfpga/include/mach/reset_manager.h | 71 
> +-
>  arch/arm/mach-socfpga/reset_manager.c  | 36 ---
>  2 files changed, 97 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> index e50fbd8..b34c7c6 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> @@ -15,19 +15,56 @@ void socfpga_bridges_reset(int enable);
>  void socfpga_per_reset(u32 reset, int set);
>  void socfpga_per_reset_all(void);
>  
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  struct socfpga_reset_manager {
>   u32 status;
>   u32 ctrl;
>   u32 counts;
>   u32 padding1;
>   u32 mpu_mod_reset;
> - u32 per_mod_reset;
> - u32 per2_mod_reset;
> + u32 per0_mod_reset; /* per_mod_reset */
> + u32 per1_mod_reset; /* per2_mod_reset */
>   u32 brg_mod_reset;
> - u32 misc_mod_reset;
> + u32 sys_mod_reset; /* misc_mod_reset */

Umm. Those comments are really hard to understand. Add "in the
datasheet" at the end so that poor reader has chance to see what is
going on?

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv2 4/9] arm: socfpga: arria10: add misc functions for Arria10

[Pavel Machek]

> > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > +   puts("CPU   : Altera SOCFPGA Arria 10 Platform\n");
> 
> No FPGA type detection happens on A10 ? :) Also, CPU is not "Arria 10 
> platform",
> CPU is still Altera SoCFPGA or possibly Altera SoCFPGA Arria 10 , right ?
>

Well. .. cpu is "generic ARM embedded in SoCFPGA". Maybe replace
"CPU:" with "SoC:"?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv2 1/9] arm: socfpga: arria10: add system manager defines

[Pavel Machek]

On Tue 2015-12-01 10:48:31, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen <dingu...@opensource.altera.com>
> 
> Add system manager defines for Arria10.
> 
> Signed-off-by: Dinh Nguyen <dingu...@opensource.altera.com>

With whitespace cleaned up:

Acked-by: Pavel Machek <pa...@denx.de>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv2 2/9] arm: socfpga: arria10: add reset manager for Arria10

[Pavel Machek]

On Tue 2015-12-01 19:51:39, Marek Vasut wrote:
> On Tuesday, December 01, 2015 at 05:48:32 PM, dingu...@opensource.altera.com 
> wrote:
> > From: Dinh Nguyen 
> > 
> > Add the defines for the reset manager and some basic reset functionality.
> > 
> > Signed-off-by: Dinh Nguyen 
> > ---
> > v2: integrate into a5/c5 reset manager
> 
> [...]
> 
> Hi!
> 
> > diff --git a/arch/arm/mach-socfpga/reset_manager.c
> > b/arch/arm/mach-socfpga/reset_manager.c index b6beaa2..b955d39 100644
> > --- a/arch/arm/mach-socfpga/reset_manager.c
> > +++ b/arch/arm/mach-socfpga/reset_manager.c
> > @@ -18,7 +18,51 @@ static const struct socfpga_reset_manager
> > *reset_manager_base = static struct socfpga_system_manager *sysmgr_regs =
> > (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
> > 
> > -/* Assert or de-assert SoCFPGA reset manager reset. */
> > +/*
> > + * Assert or de-assert SoCFPGA reset manager reset.
> > + */
> > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > +void socfpga_per_reset(u32 reset, int set)
> > +{
> > +   const void *reg;
> 
> OK, Dinh, come on. I know you _can_ do better than this crap.

Umm. Take a look. We already have that code in tree :-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] mmc: socfpga_dw_mmc: Enable calibration for drvsel and smplsel

[Pavel Machek]

Hi!
> > > OK, this is bad. Originally, if we didn't specify these in the DT, we
> > > would
> > > use the default values of 0x3 and 0x0 , but now we do the
> > > calibration. I wonder,
> > > do we care about DT ABI compatibility on the U-Boot level or not ?
> > 
> > If the compatibility failed, it will still invoke the calibration to
> > get the correct value. Just that its in the cost of boot time.
> 
> Hopefully the calibration does it's job then.
> 
> > At same time, I am rethinking another email thread on suggesting to put
> > this into common dw_mmc code. Here are my proposal
> 
> Having this in common code would make sense.
> 
> > 1. Put back the correct default value for DT ABI compatiblity
> > 2. Adding a node to enable calibration. If node not exist, calibration
> > will disabled as default.
> 
> But "enable calibration" is not really a hardware property, so it shouldn't
> be in the DT. The DT is purely a hardware description and only the smplsel
> and drvsel fit into this, some "enable-calibration" does not.

Well... "enable calibration" is not hardware property, but "well-known
autocalibration works on this hardware" is.. Anyway, config option is
probably fine, too.

How does Linux solve this? It needs to do some calibration, too, no?
We should use whatever dts Linux uses...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: fix up a questionable macro for SDMMC

[Pavel Machek]

On Tue 2015-12-01 17:33:02, Dinh Nguyen wrote:
> On 12/01/2015 05:30 PM, Marek Vasut wrote:
> > On Wednesday, December 02, 2015 at 12:20:47 AM, 
> > dingu...@opensource.altera.com 
> > wrote:
> >> From: Dinh Nguyen 
> >>
> >> Not sure what made this macro questionable, but edit the macro to be
> >> similar to what is used in Linux.
> > 
> > It should most likely be dissolved and moved into socfpga_dw_mmc.c , since
> > it's used only once in there. What do you think ?
> > 
> 
> Hmm...if you move this to socfpga_dw_mmc.c then the #if defined(A10)
> would have to follow as the bit for smplsel is at shift 4 instead of 3.
> 
> So if you had this for in system_manager.h, then socfpga_dw_mmc.c
> doesn't have to change.
> 
> --- a/arch/arm/mach-socfpga/include/mach/system_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
> @@ -201,8 +201,13 @@ struct socfpga_system_manager {
>  #define SYSMGR_FPGAINTF_NAND   (1 << 4)
>  #define SYSMGR_FPGAINTF_SDMMC  (1 << 5)
> 
> +#if defined(SOCFPGA_GEN5)
>  #define SYSMGR_SDMMC_CTRL_SET(smplsel, drvsel) \
> smplsel) & 0x7) << 3) | (((drvsel) & 0x7) << 0))
> +#else /* Arria10 */
> +#define SYSMGR_SDMMC_CTRL_SET(smplsel, drvsel) \
> +   smplsel) & 0x7) << 4) | (((drvsel) & 0x7) << 0))
> +#endif

Also... can we get a rid of << 0 here?

Is it ever valid to pass values >= 8 to this macro?

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1] arm: socfpga: Enable load zImage and Linux DTB from QSPI

[Pavel Machek]

Hi!

> Adding new environment qspiload which will load zImage and
> Linux DTB from serial NOR flash. The default flash offset for
> the images as below and they are configurable during run time.
> 
> - zImage located at0xa with assuming file size 6MB
> - Linux DTB located at 0x5 with assuming file size 28kB

Hmm. Ok, zImage second, so that it can grow. Makes sense. Not sure if
28kB is not a bit small for DTB. I'd reserve at least 64kB.

> Please adjust the file size env var if exceeding the default
> 
> Signed-off-by: Chin Liang See <cl...@altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: Dinh Nguyen <dinh.li...@gmail.com>

Acked-by: Pavel Machek <pa...@denx.de>

Notice that you sent two patches marked "v1".

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Pavel Machek]

Hi!

> > > > So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS
> > > > won't
> > > > fit into 256kiB, so I think using SPL might be the sensible thing
> > > > afterall,
> > > > since you would be able to use arbitrarily-sized U-Boot.
> > > 
> > > I hope Chin Liang can chime here, I know that we have support for
> > > NAND,
> > > but I haven't been part of that task, so I don't know how it's being
> > > done.
> > 
> > Finally my email is back online :)
> > 
> > We do have NAND support but not with UBI and UBIFS.
> 
> I just hope you're not using raw NAND and just hoping it will work.

HERE:

> > For this support, user can use U-Boot to load arbitrarily-sized U-Boot
> > that run on SDRAM.

...

> > One of the nice thing of U-Boot over SPL is the console support and
> > ability to troubleshoot.
> > This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
> > SoC 64kB).
> 
> OK, that's not really the point here -- the point is, if you compile enough
> features into U-Boot, it will be bigger than those 256k. What will you do
> then ?

You'll compile small U-Boot, and use it to load larger U-Boot, as he
said in the mark "HERE" above.

And yes, I guess that makes sense, and yes, we should finally make
loading U-Boot from U-Boot oficially supported, at least on Socfpga.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Pavel Machek]

Hi!

> > > > > One of the nice thing of U-Boot over SPL is the console support
> > > > > and
> > > > > ability to troubleshoot.
> > > > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB
> > > > > vs CV
> > > > > SoC 64kB).
> > > > 
> > > > OK, that's not really the point here -- the point is, if you
> > > > compile enough
> > > > features into U-Boot, it will be bigger than those 256k. What will
> > > > you do
> > > > then ?
> > > 
> > > You'll compile small U-Boot, and use it to load larger U-Boot, as he
> > > said in the mark "HERE" above.
> > > 
> > > And yes, I guess that makes sense, and yes, we should finally make
> > > loading U-Boot from U-Boot oficially supported, at least on Socfpga.
> > 
> > Yup, you got it :)
> > Thanks
> 
> So why exactly don't we use SPL instead ? The purpose of SPL is to do exactly 
> this without the extra cruft which is part of U-Boot and the unnecessary 
> overhead of the full U-Boot. And you don't need to hack U-Boot to support 
> loading U-Boot.

You don't need to hack anything, it just works today.

And yes, U-Boot is easier to work with, because it has commandline,
etc.

In ideal world, U-Boot SPL would disappear. You'd just compile small
"U-Boot 1" and bigger "U-Boot 2". Lets get there...  No need for
arbitrary limitations like "Full U-Boot can't initialize sdram" or
"U-Boot SPL can't have command line".
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 07/10] ARM: socfpga: arria10: add board files for the Arria10 SoCDK

[Pavel Machek]

Hi!

> index 000..86f9b78
> --- /dev/null
> +++ b/board/altera/arria10-socdk/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# (C) Copyright 2001-2006
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> +# (C) Copyright 2010, Thomas Chou 
> +#

You can delete these. There's nothing left of the old Makefile here.

> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +obj-y:= socfpga.o


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Pavel Machek]

On Thu 2015-11-19 17:28:47, Dinh Nguyen wrote:
> On 11/19/2015 04:45 PM, Marek Vasut wrote:
> > On Thursday, November 19, 2015 at 10:35:47 PM, 
> > dingu...@opensource.altera.com 
> > wrote:
> >> From: Dinh Nguyen 
> >>
> >> Update Makefile to build Arria 10.
> >>
> >> Signed-off-by: Dinh Nguyen 
> >> ---
> >>  arch/arm/mach-socfpga/Makefile | 7 +--
> >>  arch/arm/mach-socfpga/arria10/Makefile | 7 +++
> >>  2 files changed, 12 insertions(+), 2 deletions(-)
> >>  create mode 100644 arch/arm/mach-socfpga/arria10/Makefile
> >>
> >> diff --git a/arch/arm/mach-socfpga/Makefile
> >> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
> >> --- a/arch/arm/mach-socfpga/Makefile
> >> +++ b/arch/arm/mach-socfpga/Makefile
> >> @@ -6,15 +6,18 @@
> >>  #
> >>  # SPDX-License-Identifier:GPL-2.0+
> >>  #
> >> -
> >> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
> >>  obj-y += misc.o timer.o reset_manager.o system_manager.o 
> > clock_manager.o \
> >>   fpga_manager.o scan_manager.o
> >>  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
> >> -
> >>  # QTS-generated config file wrappers
> >>  obj-y += wrap_pll_config.o
> >>  obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o   
> >> \
> >>   wrap_sdram_config.o
> >> +else
> >> +obj-y += arria10/
> > 
> > So why exactly does A10 have it's own dedicated dir if most of the code
> > is probably shared between A10 and AV/CV ?
> > 
> 
> Yes, there are some sharing. But I think that there will be enough
> differences that will ultimately warrant it's own directory. I think
> with it's own directory, the Makefile changes stay a bit cleaner. I
> 
> One of the biggest differences is that the A10's SDRAM support is going
> to be a bit ugly. The main point is that we need to program the FPGA
> during U-Boot booting up with a ~>10 MB rbf file while being limited to
> the OCRAM's size. I would like to contain this ugliness in it's own
> directory.

Well.. so you'll have to optimize memory consuption of the fpga
programming. It may be ugly, but once you are done, you'll want to use
the optimized version for everyone -- not to keep two versions.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 04/10] ARM: socfpga: arria10: add stub sdram init for Arria10

[Pavel Machek]

Hi!

> +union dramaddrw_reg {
> + struct {
> + u32 cfg_col_addr_width:5;
> + u32 cfg_row_addr_width:5;
> + u32 cfg_bank_addr_width:4;
> + u32 cfg_bank_group_addr_width:2;
> + u32 cfg_cs_addr_width:3;
> + u32 reserved:13;
> + };
> + u32 word;
> +};

Umm. Are you sure this is good idea? Is gcc allowed  to do something
funny and reorder bitfields in unexpected way?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] arm: socfpga: Add SoCFPGA SR1500 board

[Pavel Machek]

On Wed 2015-11-18 11:06:09, Stefan Roese wrote:
> The SR1500 board is a CycloneV based board, similar to the EBV
> SoCrates, equipped with the following devices:
> 
> - SPI NOR
> - eMMC
> - Ethernet
> 
> Signed-off-by: Stefan Roese <s...@denx.de>
> Reviewed-by: Marek Vasut <ma...@denx.de>

Acked-by: Pavel Machek <pa...@denx.de>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: socfpga: add "u-boot, dm-pre-reloc" to socfpga_cyclone5_socdk dts

[Pavel Machek]

On Mon 2015-10-12 11:59:04, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen <dingu...@opensource.altera.com>
> 
> We need "u-boot,dm-pre-reloc" in the socfpga_cyclone5_socdk.dts file in
> order for the SPL to use SD/MMC.

Acked-by: Pavel Machek <pa...@denx.de>

Pavel

> Signed-off-by: Dinh Nguyen <dingu...@opensource.altera.com>
> ---
>  arch/arm/dts/socfpga_cyclone5_socdk.dts | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/dts/socfpga_cyclone5_socdk.dts 
> b/arch/arm/dts/socfpga_cyclone5_socdk.dts
> index 9650eb0..5465609 100644
> --- a/arch/arm/dts/socfpga_cyclone5_socdk.dts
> +++ b/arch/arm/dts/socfpga_cyclone5_socdk.dts
> @@ -69,6 +69,9 @@
>  };
>  
>   {
> + status = "okay";
> + u-boot,dm-pre-reloc;
> +
>   cd-gpios = < 18 0>;
>   vmmc-supply = <_3_3v>;
>   vqmmc-supply = <_3_3v>;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] arm: socfpga: enable data/inst prefetch and shared override in the L2

[Pavel Machek]

On Mon 2015-10-12 09:59:57, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> Update the L2 AUX CTRL settings for the SoCFPGA.
> 
> Enabling D and I prefetch bits helps improve SDRAM performance on the
> platform.
> 
> Also, we need to enable bit 22 of the L2. By not having bit 22 set in the
> PL310 Auxiliary Control register (shared attribute override enable) has the
> side effect of transforming Normal Shared Non-cacheable reads into Cacheable
> no-allocate reads.
> 
> Coherent DMA buffers in Linux always have a Cacheable alias via the
> kernel linear mapping and the processor can speculatively load cache
> lines into the PL310 controller. With bit 22 cleared, Non-cacheable
> reads would unexpectedly hit such cache lines leading to buffer
> corruption.
> 
> Signed-off-by: Dinh Nguyen 
> ---
>  arch/arm/include/asm/pl310.h |  2 ++
>  arch/arm/mach-socfpga/misc.c | 12 
>  2 files changed, 14 insertions(+)
> 
> diff --git a/arch/arm/include/asm/pl310.h b/arch/arm/include/asm/pl310.h
> index 18b90b7..7a11405 100644
> --- a/arch/arm/include/asm/pl310.h
> +++ b/arch/arm/include/asm/pl310.h
> @@ -17,6 +17,8 @@
>  #define L2X0_CTRL_EN 1
>  
>  #define PL310_SHARED_ATT_OVERRIDE_ENABLE (1 << 22)
> +#define PL310_AUX_CTRL_DATA_PREFETCH_MASK(1 << 28)
> +#define PL310_AUX_CTRL_INST_PREFETCH_MASK(1 << 29)

These would be

arch/arm/include/asm/hardware/cache-l2x0.h:#define
L310_PREFETCH_CTRL_DATA_PREFETCH BIT(28)
arch/arm/include/asm/hardware/cache-l2x0.h:#define
L310_PREFETCH_CTRL_INSTR_PREFETCHBIT(29)

...in kernel. So maybe staying with L310_ prefix makes sense?
Otherwise it looks ok.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] pl310: arm: fix up define typo for the share override bit

[Pavel Machek]

On Mon 2015-10-12 09:59:56, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> s/L310_SHARED_ATT_OVERRIDE_ENABLE/PL310_SHARED_ATT_OVERRIDE_ENABLE
> 
> Signed-off-by: Dinh Nguyen 

Well, in kernel, pl310 -related registers also have L310 prefix (no
PL), so I'm not sure it was a typo...

Pavel


> index de7650e..18b90b7 100644
> --- a/arch/arm/include/asm/pl310.h
> +++ b/arch/arm/include/asm/pl310.h
> @@ -16,7 +16,7 @@
>  #define L2X0_STNDBY_MODE_EN  (1 << 0)
>  #define L2X0_CTRL_EN 1
>  
> -#define L310_SHARED_ATT_OVERRIDE_ENABLE  (1 << 22)
> +#define PL310_SHARED_ATT_OVERRIDE_ENABLE (1 << 22)
>  
>  struct pl310_regs {
>   u32 pl310_cache_id;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv3] arm: socfpga: Enable saveenv for SD/MMC

[Pavel Machek]

Hi!

> From: Dinh Nguyen 
> 
> Enable the able to save the environment variables when SD/MMC is used.
> 
> Signed-off-by: Dinh Nguyen 
> ---
> v3: Only define ENV_IS_NOWHERE if env is not in MMC, NAND, FAT, and SPI_FLASH
> v2: Move this option to be on a per-board basis
> Add config for socfpga_cyclone5 and socfpga_arria5
> ---
>  include/configs/socfpga_arria5_socdk.h   | 4 
>  include/configs/socfpga_common.h | 5 +
>  include/configs/socfpga_cyclone5_socdk.h | 4 
>  include/configs/socfpga_de0_nano_soc.h   | 4 
>  include/configs/socfpga_sockit.h | 4 
>  5 files changed, 21 insertions(+)
> 
> diff --git a/include/configs/socfpga_arria5_socdk.h 
> b/include/configs/socfpga_arria5_socdk.h
> index 3193684..b75b0a2 100644
> --- a/include/configs/socfpga_arria5_socdk.h
> +++ b/include/configs/socfpga_arria5_socdk.h
> @@ -59,6 +59,10 @@
>  
>  #endif
>  
> +#define CONFIG_ENV_IS_IN_MMC
> +#define CONFIG_SYS_MMC_ENV_DEV   0   /* device 0 */
> +#define CONFIG_ENV_OFFSET512 /* just after the MBR */
> +
>  /* USB */
>  #ifdef CONFIG_CMD_USB
>  #define CONFIG_USB_DWC2_REG_ADDR SOCFPGA_USB1_ADDRESS
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index a2811ba..b3fba5b 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -281,7 +281,12 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  #define CONFIG_SYS_CONSOLE_IS_IN_ENV
>  #define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
>  #define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
> +#if !defined CONFIG_ENV_IS_IN_MMC && \
> +!defined CONFIG_ENV_IS_IN_NAND && \
> +!defined CONFIG_ENV_IS_IN_FAT && \
> +!defined CONFIG_ENV_IS_IN_SPI_FLASH
>  #define CONFIG_ENV_IS_NOWHERE
> +#endif
>  #define CONFIG_ENV_SIZE  4096
>


Actually... if we decided that position of u-boot environment is
board-specific, size should be board-specific, too.

But it might be better to just define

#define ENV_IN_MMC_SECTOR_1

in each board, and have the common code in socfpga_common.h... so that
we can change environment size for all boards using "after mmc"
layout, for example.

Ouch and 4K is way too small.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Pavel Machek]

On Thu 2015-09-17 17:30:29, Stefan Roese wrote:
> By not defining CONFIG_SYS_ARM_CACHE_WRITEALLOC, the WRITEBACK cache
> policy is selected. This leads to much better performance on the SoCFPGA.
> A quick network test shows this:
> 
> Without this patch:
> => tftp 10 big-40mb
> Speed: 1000, full duplex
> Using dwmac.ff702000 device
> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> Filename 'big-40mb'.
> Load address: 0x10
> Loading: #
>  #
>  #
>  #
>  ##
>  2.5 MiB/s
> 
> With this patch:
> => tftp 10 big-40mb
> Speed: 1000, full duplex
> Using dwmac.ff702000 device
> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> Filename 'big-40mb'.
> Load address: 0x10
> Loading: #
>  #
>  #
>  #
>  ##
>  7.6 MiB/s
> 
> A performance improvement of factor ~3.

Ok, so you turn on write-back cache and it is faster.

Now... do you have an explanation why this is safe to do? Are there
cache flushes that need to be added to the code now that we turned on
write-back?

Best regards,
Pavel

> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index 38ae763..a2811ba 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -73,7 +73,6 @@
>  /*
>   * Cache
>   */
> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
>  #define CONFIG_SYS_CACHELINE_SIZE 32
>  #define CONFIG_SYS_L2_PL310
>  #define CONFIG_SYS_PL310_BASESOCFPGA_MPUL2_ADDRESS

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot