Re: [U-Boot] please pull u-boot-arc master
On Fri, Jan 09, 2015 at 09:09:18PM +, Alexey Brodkin wrote: Dear Tom, The following changes since commit b188067f39627d977bb1db67c8456e9aaab90743: arm: vf610: fix boot from SD-card (2015-01-09 10:27:51 -0500) are available in the git repository at: git://git.denx.de/u-boot-arc.git for you to fetch changes up to 4c8c485ad9249e1ca1822474954b78799ca937e9: arc: introduce mdbtrick target (2015-01-09 23:59:54 +0300) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Hi Simon, On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 January 2015 at 22:23, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 January 2015 at 18:34, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass s...@chromium.org wrote: Hi Bin, On 7 January 2015 at 23:18, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass s...@chromium.org wrote: NOT TO APPLY This shows how to enable video for the glacier board, as an example of the emulator working on a VESA-compliant graphics card. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/canyonlands.h | 31 +++ 1 file changed, 31 insertions(+) diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h index 7a1499d..c55e076 100644 --- a/include/configs/canyonlands.h +++ b/include/configs/canyonlands.h @@ -133,6 +133,9 @@ #define CONFIG_SYS_NOR_CS 0 /* NOR chip connected to CSx */ #define CONFIG_SYS_NAND_CS 3 /* NAND chip connected to CSx */ +#define CONFIG_CONSOLE_MUX +#define CONFIG_SYS_CONSOLE_IS_IN_ENV + /*--- * FLASH related *--*/ @@ -359,6 +362,15 @@ ramdisk_addr=fc20\0 \ pciconfighost=1\0 \ pcie_mode=RP:RP\0 \ + eth1addr=00:01:ec:00:f4:9d\0 \ + eth2addr=00:01:ec:00:f4:9e\0 \ + eth3addr=00:01:ec:00:f4:9f\0 \ + ethact=ppc_4xx_eth0\0 \ + ethaddr=00:01:ec:00:f4:9c\0 \ + stderr=serial\0 \ + stdin=serial\0 \ + stdout=serial,vga\0 \ + autoload=n\0 \ #else /* defined(CONFIG_ARCHES) */ #define CONFIG_EXTRA_ENV_SETTINGS \ @@ -675,4 +687,23 @@ } #endif +#define CONFIG_VIDEO + +#ifdef CONFIG_VIDEO +#define CONFIG_BIOSEMU /* x86 bios emulator for vga bios */ +#define CONFIG_VIDEO_VESA +#define VIDEO_IO_OFFSET0xd800 +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS VIDEO_IO_OFFSET +#define CONFIG_VIDEO_SW_CURSOR +#define CONFIG_VIDEO_LOGO +#define CONFIG_CFB_CONSOLE +#define CONFIG_SPLASH_SCREEN +#define CONFIG_VGA_AS_SINGLE_DEVICE +#define CONFIG_CMD_BMP +#endif + +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE +#define CONFIG_FRAMEBUFFER_VESA_MODE 0x114 +#define CONFIG_CMD_TFTPPUT + #endif /* __CONFIG_H */ -- Could you also post the codes that actually run the vga bios on ppc target? I may find another non-x86 board to test. It is all there - I am using the existing support. If you see pci_run_vga_bios() it calls biosemu_run() in the emulation case. Sorry I mean the complete canyonlands codes which calls pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called by chromebook_link. And do you think the int15_handler() required by the biosemu needs to be common? This series is at u-boot-x86/vesa. You can see the call from the vesa video driver, vesa_fb.c. Ah, I see. I can have a try on a non-x86 board. Re int15_handler(), yes I think it should be, but so far I haven't needed it. So what does int15_hander() normally do? I see the vesa_fb.c provided NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c does not pass NULL. See the existing int15_handler() in that file. It allows selection of output device and scaling. I doubt it matters for most boards. OK, so looks we should not make this int15_handler() common. I think the ROM access code can be made more common, but I left that task for now. Re your other question I was looking for the VGA enable bit, as I remembered it from years ago. It doesn't seem to be needed for that platforms I have tested. But if it is generally needed we should add it. Which platform do you use? I doubt the VGA enable bit only affects x86 as it opens the A and I/O address decoding which is only applicable on x86. I'm only using glacier and link so far. I suspect there might be something wrong as only one of my video cards works fully on glacier - another once gives a snowy picture. So VGA enable bit is unset on Link as well? That's interesting. When you mentioned two cards, did you insert them simultaneously? I believe only one card will work due to only one card will respond VGA cycles. No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources(). I don't see where does this bd82x6x_pci_bus_enable_resources() get called. I only used one card at a time. For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
Re: [U-Boot] [PATCH 6/8] video: ssd2828: Allow using 'pclk' as the PLL clock source
On Fri, 9 Jan 2015 12:01:14 +0200
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
Instead of using the internal 'tx_clk' clock source, it is also
possible to use the pixel clock signal from the parallel LCD
interface ('pclk') as the reference clock for PLL.
The 'tx_clk' clock speed may be different on different boards/devices
(the allowed range is 8MHz - 30MHz). Which is not very convenient,
especially considering the need to know the exact 'tx_clk' clock
speed. Which may be difficult to identify without having device
schematics and/or accurate documentation/sources every time.
Using 'pclk' is free from all these problems.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Acked-by: Anatolij Gustschin ag...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] usb: gadget: pxa25x_udc: fix use-before-initialized bug
On Thursday, January 08, 2015 at 06:51:10 PM, Alex Sadovsky wrote: Fix use-before-initialized bug in pxa25x_udc driver. Function usb_gadget_register_driver calls udc_disable, and udc_disable calls pullup_off that uses dev-mach-udc_command. But dev-mach is initialized in usb_gadget_register_driver after calling udc_disable. This patch fixes the order of initialization. Signed-off-by: Alex Sadovsky nable.mainin...@googlemail.com Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: gadget: composite: Fix NULL pointer crash in USB compliance test
On Friday, January 09, 2015 at 02:54:55 PM, Stefan Roese wrote: On the DXR2 board (AM335x using MUSB) the USB compliance test suite (USB 2.0 Command Verifier) will cause the board to crash and reset upon the BOS Descriptor Test - Addressed state. Here the output from the DRX2 while running this test: GADGET DRIVER: usb_dnl_dfu musb-hdrc: peripheral reset irq lost! composite_setup (776) data abort pc : [87f693ac] lr : [87f6911c] sp : 86f33a58 ip : fp : 86f3bbac r10: 0f00 r9 : 86f33ef4 r8 : 86f37da8 r7 : 0005 r6 : 86f33a90 r5 : r4 : 86f37e30 r3 : r2 : r1 : 87f9c888 r0 : 0016 Flags: Nzcv IRQs off FIQs on Mode SVC_32 Resetting CPU ... resetting ... By adding the case statement for USB_DT_BOS and therefore not running into the default case (jump to unkown label) this crash is fixed. Applied both, thank you! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix repeated USB scans problems
On Thursday, January 08, 2015 at 06:40:19 PM, Hans de Goede wrote: Hi, Hi! [...] Only the semantics of usb start are changing, and you are suggesting renaming usb reset which remains unchanged ... Yes, that's true. So I suppose we should indeed not rename anything. OK, let's go with this approach now. So we are all in agreement, good, so through who's tree are these 2 patches going to go upstream ? Note I can take them upstream through the sunxi tree, but the usb tree seems better to me ... I can pick them, shall I pick them as they are ? Yes, AFAIK there were no requests for changes. Are they for -next or current ? They are intended for -next, the double usb scan when using a usb keyboard *and* booting from usb is a nuisance, but not fatal, and very few people actually use the combo, so given that current is about to be released in a couple of days lets play it safe :) OK, applied both to next. Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: eth: asix88179: add ability to modify MAC address
On Thursday, January 08, 2015 at 01:58:55 PM, Rene Griessl wrote:
Here is the promised patch, that enables U-Boot to modify the MAC
address of the AX88179.
Tested on RECS5250 (similar to Arndale5250)
Signed-off-by: Rene Griessl rgrie...@cit-ec.uni-bielefeld.de
---
drivers/usb/eth/asix88179.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/eth/asix88179.c b/drivers/usb/eth/asix88179.c
index b8ca720..b551540 100644
--- a/drivers/usb/eth/asix88179.c
+++ b/drivers/usb/eth/asix88179.c
@@ -271,6 +271,22 @@ static int asix_read_mac(struct eth_device *eth)
return 0;
}
+static int asix_write_mac(struct eth_device *eth)
+{
+ struct ueth_data *dev = (struct ueth_data *)eth-priv;
+ int ret;
+ u8 buf[ETH_ALEN];
+
+ memcpy(buf, eth-enetaddr, ETH_ALEN);
Why is the memcpy needed ?
+ ret = asix_write_cmd(dev, AX_ACCESS_MAC, AX_NODE_ID, ETH_ALEN,
+ ETH_ALEN, buf);
+ if (ret 0)
+ debug(Failed to set MAC address: %02x\n, ret);
+
+ return ret;
+}
Otherwise looks good :)
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
Hi Sjoerd, On 01/09/2015 04:50 PM, Sjoerd Simons wrote: On Fri, 2015-01-09 at 16:42 +0900, Joonyoung Shim wrote: Hi, On 01/09/2015 01:21 PM, Jaehoon Chung wrote: On 01/09/2015 08:23 AM, Sjoerd Simons wrote: On Thu, 2015-01-08 at 14:44 +0900, Joonyoung Shim wrote: Some exynos boards require special handling of SD4_nRESET_OUT line for eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards. This will support eMMC reset using DT from reset_misc of samsung common board file and each board files can support eMMC reset on non DT case. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com diff --git a/doc/device-tree-bindings/exynos/emmc-reset.txt b/doc/device-tree-bindings/exynos/emmc-reset.txt new file mode 100644 index 000..e48e508 --- /dev/null +++ b/doc/device-tree-bindings/exynos/emmc-reset.txt @@ -0,0 +1,15 @@ +* Samsung eMMC reset + +Some exynos boards require special handling of SD4_nRESET_OUT line for eMMC +memory to perform complete reboot. Nitpick, on XU3 the line you apparently need to twiddle is SD0_nRESET_OUT. Then, i think it's better to omit SD4_. Is this type of usage of this pin specific to the Odroid Exynos boards or potentially on more boards? (Sorry for the simple questions, but my exynos documentation just says the line exists not what its intended usage is). In case of Exynos4, eMMC can be used with sdhci controller or dw-mmc controller. So Pin name should be used to SD0 or SD4. But Exynos5 is only supported the dw-mmc controller. (So eMMC is used pin-name as SD0.) I can find only SD_4_nRESET_OUT from exynos4412 user manual and only SD_0__nRESET_OUT from exynos5422 user manual. Best Regards, Jaehoon Chung Fwiw, I did a quick check in the linux code and it doesn't seem to be using those pins for currently for any boards. However my X2 does successfully reset/reboot in u-boot and linux, so it seems optional there. The XU3 does fail to reset itself, so it seems required for that board. I checked upstream u-boot and hardkernel u-boot and i found codes to reset eMMC using gpio. upstream u-boot: reset_misc() of board/samsung/odroid/odroid.c hardkernel u-boot: reset_cpu() of arch/arm/cpu/armv7/exynos/reset.c Yeah u-boot does it, but linux upstream kernel does not. Hence wondering about the requirements. I didn't test Odroid X2 board but my Odroid U3 board cannot reboot without controlling nRESET_OUT gpio on upstream linux kernel. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
On 01/09/2015 08:13 PM, Jaehoon Chung wrote:
On 01/09/2015 04:31 PM, Joonyoung Shim wrote:
+Cc Jaehoon,
On 01/09/2015 03:18 AM, Simon Glass wrote:
Hi Joonyoung,
On 7 January 2015 at 22:44, Joonyoung Shim jy0922.s...@samsung.com wrote:
Some exynos boards require special handling of SD4_nRESET_OUT line for
eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards.
This will support eMMC reset using DT from reset_misc of samsung common
board file and each board files can support eMMC reset on non DT case.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
board/samsung/common/board.c | 27
++
board/samsung/odroid/odroid.c | 2 +-
doc/device-tree-bindings/exynos/emmc-reset.txt | 15 ++
3 files changed, 43 insertions(+), 1 deletion(-)
create mode 100644 doc/device-tree-bindings/exynos/emmc-reset.txt
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index c04ab3c..3218463 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -40,6 +40,8 @@ __weak int exynos_power_init(void)
return 0;
}
+__weak void exynos_reset_misc(void) {}
+
#if defined CONFIG_EXYNOS_TMU
/* Boot Time Thermal Analysis for SoC temperature threshold breach */
static void boot_temp_check(void)
@@ -400,3 +402,28 @@ int misc_init_r(void)
return 0;
}
#endif
+
+void reset_misc(void)
+{
+#ifdef CONFIG_OF_CONTROL
I think all Samsung boards have this defined, so this #ifdef can be removed.
OK, if it is true, we can remove this and i will not to support non DT case.
+ struct gpio_desc gpio = {};
+ int node;
+
+ node = fdt_node_offset_by_compatible(gd-fdt_blob, 0,
+ samsung,emmc-reset);
+ if (node 0)
+ return;
+
+ gpio_request_by_name_nodev(gd-fdt_blob, node, reset-gpio, 0,
gpio,
+ GPIOD_IS_OUT);
+
+ if (dm_gpio_is_valid(gpio)) {
+ /* Reset eMMC*/
+ dm_gpio_set_value(gpio, 0);
+ mdelay(10);
That's a very long reset! Is that what it needs?
Jaehoon, is there any guide about wait time of reset at eMMC spec?
Well, I'm not sure, but as Simon's comments, it's long time.
(Minimum is 1us...Maximum isn't defined.)
This just comes from reset_misc() of board/samsung/odroid/odroid.c file.
Even, hardkernel u-boot waits 50msec.
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828
On Fri, 9 Jan 2015 12:01:15 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: So that we don't need to keep it as a hardcoded magic number in the code or the hassle exposing it as a Kconfig option. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New i.MX board
Hi folks, I'm currently bringing up a new i.MX6q based board. I've got u-boot working, but its clear that a lot of the iMX stuff is still using the old configuration system. is the latest iMX stuff in u-boot mainline yet? if not, where should I be looking / what is considered a 'model platform', so that I can publish the best possible support for my board? Would more work to move stuff to Kconfig be helpful? or is this in-hand somewhere? Thanks, -Ian Hi, Ian: What version is your u-boot version? there's some git repository you can try: 1. git://git.denx.de/u-boot-imx.git - which maintained by Stefano Babic, merged imx related code with mainline u-boot. 2. https://github.com/Freescale/u-boot-fslc.git - which matained by Otavio Salvador, have every branch in mainline(2009.07 - 2014.07, 2014.10, 2015.01 etc...) with i.mx related patches. Since i.mx6q pcie is supported in Otavio's git repository branch patches-2014.10, I think u-boot-fslc is support i.mx6q very well now, it booting into kernel only spend 0.3~0.5s. If you have question which i.mx related, maybe you can also send mail to meta-freescale to ask them. regards, Wally ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] video: Add support for SSD2828 (parallel LCD to MIPI bridge)
On Fri, 9 Jan 2015 12:01:11 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the flight into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] sunxi: video: Add lvds support
On Thu, 8 Jan 2015 20:49:05 +0100 Hans de Goede hdego...@redhat.com wrote: Add support for lvds lcd panels Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] sunxi: video: Add support for Hitachi tx18d42vm LCD panels
On Thu, 8 Jan 2015 20:49:06 +0100 Hans de Goede hdego...@redhat.com wrote: Hitachi tx18d42vm LCD panels have an onboard controller which needs some initialization via spi for the panel to become functional as a regular LVDS panel. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] video: sunxi: Hook up SSD2828 with the sunxi video driver
On Fri, 9 Jan 2015 12:01:12 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: ... diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index adee5ed..92dbce7 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -345,6 +345,60 @@ config VIDEO_LCD_BL_PWM Set the backlight pwm pin for the LCD panel. This takes a string in the format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H. +config VIDEO_LCD_SPI_CS + string SPI CS pin for LCD related config job + depends on VIDEO_LCD_SSD2828 + default + ---help--- + This is one of the SPI communication pins, involved in setting up a + working LCD configuration. The exact role of SPI may differ for + different hardware setups. The option takes a string in the format + understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H. please address comments from Hans regarding the Kconfig changes. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] sun6i: Add LCD display support for MSI Primo81 tablet
On Fri, 9 Jan 2015 12:01:13 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: The MSI Primo81 tablet has B079XAN01/LP079X01 7.85 768x1024 IPS MIPI display, connected to the parallel LCD interface via SSD2828 bridge chip. The panel has 18-bit color depth and needs dithering, in spite of having RGB data delivered from A31s to SSD2828 using 24-bit arrangement. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] arm: build arch memset/memcpy in Thumb2 mode
On Thu, Dec 18, 2014 at 06:10:33PM +0100, Stefan Agner wrote: Resynchronize memcpy/memset with kernel 3.17 and build them in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). However, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set. To build the files without warning, some assembler instructions had to be replaced with their UAL compliant variant (thanks Jeroen for this input). To build the file in Thumb2 mode the implicit-it=always option need to be set to generate Thumb2 compliant IT instructions where needed. We add this option to the general AFLAGS when building for Thumb2. Reviewed-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Signed-off-by: Stefan Agner ste...@agner.ch Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] video: Add support for SSD2828 (parallel LCD to MIPI bridge)
Hi, On 09-01-15 11:01, Siarhei Siamashka wrote: Hello, This patchset adds support for the Solomon Systech SSD2828 bridge chip, which is used to convert parallel LCD interface into MIPI DSI interface and drive MIPI LCD display in some tablets. In particular, this allows to have a working LCD display in my Allwinner A31s based MSI Primo81 tablet. The core of the SSD2828 support code is generic and should work with any SoC (as long as the hardware supports the standard u-boot GPIO API). It also does not have any hardcoded assumptions about the MSI Primo81 display and should be able to drive any MIPI LCD panel (as long as the number of data lanes and the bitrate per lane is provided in the config struct). The code tries to follow the standard power-up sequence described in the SSD2828 datasheet. However it has been tested only on my MSI Primo81 tablet so far. The sunxi specific part includes a small glue code in the sunxi display driver and the defconfig update for the MSI Primo81 tablet. This can be applied after http://lists.denx.de/pipermail/u-boot/2015-January/200753.html 'sunxi: video: Add lvds support' patchset to the 'next' branch in the u-boot-sunxi repository. And here is a bonus picture :-) http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpg Cool :) Siarhei Siamashka (8): sunxi: axp221: Add ELDO[1-3] support include: Add header file with MIPI DSI constants from the Linux kernel video: Add support for SSD2828 (parallel LCD to MIPI bridge) video: sunxi: Hook up SSD2828 with the sunxi video driver sun6i: Add LCD display support for MSI Primo81 tablet video: ssd2828: Allow using 'pclk' as the PLL clock source video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828 video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id Thanks for working on this! Overall this looks good. Looks like you did a better job then I did with the Hitachi tx18d42vm LCD panel support, esp. wrt making things generic rather then sunxi specific. So assuming the Ian will ack v2 of my lvds patch I suggest that we merge my lvds patch, then your patches (pending an ack from Anatolij) and then I respin my Hitachi tx18d42vm LCD panel patch following your patches as an example. I've also reviewed all of your patches. I've one change request, can you please move all of the board/sunxi/Kconfig changes except for the last hunk to drivers/video/Kconfig, if we go the generic route we should also make the Kconfig stuff generic. This also means dropping the select VIDEO_LCD_IF_PARALLEL from config VIDEO_LCD_SSD2828 and adding it to config VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828, as that option is the only one which will stay in board/sunxi/Kconfig and VIDEO_LCD_IF_PARALLEL is sunxi specific. The changes to drivers/video/Kconfig should then become part of the video: Add support for SSD2828 (parallel LCD to MIPI bridge) commit. With that changed patches 1-7 are: Acked-by: Hans de Goede hdego...@redhat.com I'm not 100% sure about patch 8, I can see this being useful for debugging but not for normal use, and as you said it may (theoretically) be unsafe with some panels. Maybe keep the patch, but #ifdef DEBUG the entire code block it adds ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] New i.MX board
Hi folks, I'm currently bringing up a new i.MX6q based board. I've got u-boot working, but its clear that a lot of the iMX stuff is still using the old configuration system. is the latest iMX stuff in u-boot mainline yet? if not, where should I be looking / what is considered a 'model platform', so that I can publish the best possible support for my board? Would more work to move stuff to Kconfig be helpful? or is this in-hand somewhere? Thanks, -Ian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/18] trats2: config: disable i2c peripherals if testing dm i2c
Hello Minkyu, On 01/08/2015 03:11 PM, Minkyu Kang wrote: On 08/01/15 20:33, Przemyslaw Marczak wrote: Most i2c peripherals for this board doesn't support new i2c api. So CONFIG_DM_I2C on this board can be enabled for test only. The i2c command works fine with it. This is the first step before adding support to the new power framework soon. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Jaehoon Chung jh80.ch...@samsung.com Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com --- include/configs/trats2.h | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/include/configs/trats2.h b/include/configs/trats2.h index 42481ab..8b099dd 100644 --- a/include/configs/trats2.h +++ b/include/configs/trats2.h @@ -159,15 +159,18 @@ #define CONFIG_RANDOM_UUID /* I2C */ -#include asm/arch/gpio.h - +#if 0 /* For test */ +#define CONFIG_DM_I2C +#endif please remove test code. #define CONFIG_CMD_I2C - -#define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_S3C24X0 #define CONFIG_SYS_I2C_S3C24X0_SPEED 10 #define CONFIG_SYS_I2C_S3C24X0_SLAVE 0 + +#ifndef CONFIG_DM_I2C +#define CONFIG_SYS_I2C #define CONFIG_MAX_I2C_NUM8 + #define CONFIG_SYS_I2C_SOFT #define CONFIG_SYS_I2C_SOFT_SPEED 5 #define CONFIG_SYS_I2C_SOFT_SLAVE 0x00 @@ -177,6 +180,8 @@ #define CONFIG_SOFT_I2C_READ_REPEATED_START #define CONFIG_SYS_I2C_INIT_BOARD +#include asm/arch/gpio.h + #ifndef __ASSEMBLY__ int get_soft_i2c_scl_pin(void); int get_soft_i2c_sda_pin(void); @@ -192,6 +197,7 @@ int get_soft_i2c_sda_pin(void); #define CONFIG_POWER_MUIC_MAX77693 #define CONFIG_POWER_FG_MAX77693 #define CONFIG_POWER_BATTERY_TRATS2 +#endif /* ifndef CONFIG_DM_I2C */ /* Security subsystem - enable hw_rand() */ #define CONFIG_EXYNOS_ACE_SHA @@ -203,11 +209,13 @@ int get_soft_i2c_sda_pin(void); #define CONFIG_MISC_INIT_R /* Download menu - Samsung common */ +#ifndef CONFIG_DM_I2C #define CONFIG_LCD_MENU #define CONFIG_LCD_MENU_BOARD /* Download menu - definitions for check keys */ #ifndef __ASSEMBLY__ +#include power/pmic.h #include power/max77686_pmic.h #define KEY_PWR_PMIC_NAME MAX77686_PMIC @@ -219,6 +227,7 @@ int get_soft_i2c_sda_pin(void); #define KEY_VOL_UP_GPIO EXYNOS4X12_GPIO_X22 #define KEY_VOL_DOWN_GPIO EXYNOS4X12_GPIO_X33 #endif /* __ASSEMBLY__ */ +#endif /* LCD console */ #define LCD_BPP LCD_COLOR16 Thanks, Minkyu Kang Ok, I will remove it in the both cases. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/18] dm: i2c: s3c24x0: adjust to dm-i2c api
Hello Heiko Schocher,
On 01/09/2015 07:31 AM, Heiko Schocher wrote:
Hello Przemyslaw Marczak,
just some nitpick ...
Am 08.01.2015 12:33, schrieb Przemyslaw Marczak:
This commit adjusts the s3c24x0 driver to new i2c api
based on driver-model. The driver supports standard
and high-speed i2c as previous.
Tested on Trats2 and Arndale (also with HS).
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Heiko Schocher h...@denx.de
Cc: Minkyu Kang mk7.k...@samsung.com
---
drivers/i2c/s3c24x0_i2c.c | 254
--
1 file changed, 222 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index fd328f0..c21d479 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -9,8 +9,9 @@
* as they seem to have the same I2C controller inside.
* The different address mapping is handled by the s3c24xx.h files
below.
*/
-
#include common.h
+#include errno.h
+#include dm.h
#include fdtdec.h
#if (defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
#include asm/arch/clk.h
@@ -121,13 +122,23 @@
#define CONFIG_MAX_I2C_NUM 1
#endif
+DECLARE_GLOBAL_DATA_PTR;
+
/*
* For SPL boot some boards need i2c before SDRAM is initialised so
force
* variables to live in SRAM
*/
+#ifdef CONFIG_SYS_I2C
static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
__attribute__((section(.data)));
+#endif
+enum exynos_i2c_type {
+EXYNOS_I2C_STD,
+EXYNOS_I2C_HS,
+};
+
+#ifdef CONFIG_SYS_I2C
/**
* Get a pointer to the given bus index
*
@@ -147,6 +158,7 @@ static struct s3c24x0_i2c_bus *get_bus(unsigned
int bus_idx)
debug(Undefined bus: %d\n, bus_idx);
return NULL;
}
+#endif
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
static int GetI2CSDA(void)
@@ -251,6 +263,7 @@ static void ReadWriteByte(struct s3c24x0_i2c *i2c)
writel(readl(i2c-iiccon) ~I2CCON_IRPND, i2c-iiccon);
}
+#ifdef CONFIG_SYS_I2C
static struct s3c24x0_i2c *get_base_i2c(int bus)
{
#ifdef CONFIG_EXYNOS4
@@ -267,6 +280,7 @@ static struct s3c24x0_i2c *get_base_i2c(int bus)
return s3c24x0_get_base_i2c();
#endif
}
+#endif
static void i2c_ch_init(struct s3c24x0_i2c *i2c, int speed, int
slaveadd)
{
@@ -398,18 +412,20 @@ static void exynos5_i2c_reset(struct
s3c24x0_i2c_bus *i2c_bus)
hsi2c_ch_init(i2c_bus);
}
+#ifdef CONFIG_SYS_I2C
static void s3c24x0_i2c_init(struct i2c_adapter *adap, int speed,
int slaveadd)
{
struct s3c24x0_i2c *i2c;
struct s3c24x0_i2c_bus *bus;
-
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
#endif
ulong start_time = get_timer(0);
-/* By default i2c channel 0 is the current bus */
i2c = get_base_i2c(adap-hwadapnr);
+bus = i2c_bus[adap-hwadapnr];
+if (!bus)
+return;
/*
* In case the previous transfer is still going, wait to give it a
@@ -470,12 +486,13 @@ static void s3c24x0_i2c_init(struct i2c_adapter
*adap, int speed, int slaveadd)
#endif
}
#endif /* #if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5) */
+
i2c_ch_init(i2c, speed, slaveadd);
-bus = i2c_bus[adap-hwadapnr];
bus-active = true;
bus-regs = i2c;
}
+#endif /* CONFIG_SYS_I2C */
/*
* Poll the appropriate bit of the fifo status register until the
interface is
@@ -545,7 +562,6 @@ static int hsi2c_prepare_transaction(struct
exynos5_hsi2c *i2c,
bool issue_stop)
{
u32 conf;
-
why do you delete this empty line?
conf = len | HSI2C_MASTER_RUN;
if (issue_stop)
@@ -698,14 +714,24 @@ static int hsi2c_read(struct exynos5_hsi2c *i2c,
return rv;
}
+#ifdef CONFIG_SYS_I2C
static unsigned int s3c24x0_i2c_set_bus_speed(struct i2c_adapter *adap,
- unsigned int speed)
+ unsigned int speed)
+#else
+static int s3c24x0_i2c_set_bus_speed(struct udevice *dev, unsigned
int speed)
+#endif
{
struct s3c24x0_i2c_bus *i2c_bus;
-
here too ...
Oh, I missed this after removing the debug code. Will fix in both cases.
+#ifdef CONFIG_SYS_I2C
i2c_bus = get_bus(adap-hwadapnr);
+#else
+if (!dev)
+return -ENODEV;
+
+i2c_bus = dev_get_priv(dev);
+#endif
if (!i2c_bus)
-return -1;
+return -ENODEV;
i2c_bus-clock_frequency = speed;
@@ -715,23 +741,12 @@ static unsigned int
s3c24x0_i2c_set_bus_speed(struct i2c_adapter *adap,
hsi2c_ch_init(i2c_bus);
} else {
i2c_ch_init(i2c_bus-regs, i2c_bus-clock_frequency,
-CONFIG_SYS_I2C_S3C24X0_SLAVE);
+CONFIG_SYS_I2C_S3C24X0_SLAVE);
}
return 0;
}
-#ifdef CONFIG_EXYNOS5
-static void exynos_i2c_init(struct i2c_adapter *adap, int speed, int
slaveaddr)
-{
-/* This will override the speed selected in the fdt for that port */
-
Re: [U-Boot] [PATCH v3] arm: build arch memset/memcpy in Thumb2 mode
Hello Stefan, On Mon, 05 Jan 2015 23:21:41 +0100, Stefan Agner ste...@agner.ch wrote: Albert, I guess it is too late for that now. Thought it would make it into 2015.01, since your last comment in v2 suggested that you would treat it as bugfix... If Tom's OK, I or he can take it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/12] pmic:pfuze add macro for setting voltage
#define PFUZE100_SW1ABC_SETP(x) ((x - 3000) / 250)
This macro is for configuring SW1A/B/C Output Voltage easily.
Signed-off-by: Peng Fan peng@freescale.com
---
include/power/pfuze100_pmic.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/power/pfuze100_pmic.h b/include/power/pfuze100_pmic.h
index 7474afb..d304658 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -61,6 +61,8 @@ enum {
* Buck Regulators
*/
+#define PFUZE100_SW1ABC_SETP(x)((x - 3000) / 250)
+
/* SW1A/B/C Output Voltage Configuration */
#define SW1x_0_300V 0
#define SW1x_0_325V 1
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/12] imx:mx6 Support LDO bypass
The basic graph for voltage input is:
VDDARM_IN --- LDO_DIG(ARM) --- VDD_ARM_CAP
VDDSOC_IN --- LDO_DIG(SOC) --- VDD_SOC_CAP
We can bypass the LDO to save power, if the board already has pmic.
set_anatop_bypass is the function to do the bypass VDDARM and VDDSOC
work.
Current only set VDDARM_IN@1.175V/VDDSOC_IN@1.175V before ldo
bypass switch. So until ldo bypass switch happened, these voltage
setting is set in ldo-enable mode. But in datasheet, we need
1.15V + 125mV = 1.275V for VDDARM_IN. We need to downgrade cpufreq
to 400Mhz and restore after ldo bypass mode switch. So add
prep_anatop_bypass/finish_anatop_bypass/set_arm_freq_400M to do
this work.
LDO bypass is dependent on the flatten device tree file. If speed
grading fuse is for 1.2GHz, enable LDO bypass and setup PMIC voltages.
So add check for 1.2GHz core speed. So add check_1_2G function.
In ldo-bypass mode, we need trigger WDOG_B pin to reset pmic in
ldo-bypass mode. So add set_wdog_reset to do this work.
Also add related function prototype in sys_proto.h
Signed-off-by: Peng Fan peng@freescale.com
Signed-off-by: Robin Gong b38...@freescale.com
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 141 ++
arch/arm/include/asm/arch-mx6/sys_proto.h | 9 ++
2 files changed, 150 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 5f5f497..5d02755 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -18,6 +18,7 @@
#include asm/arch/sys_proto.h
#include asm/imx-common/boot_mode.h
#include asm/imx-common/dma.h
+#include libfdt.h
#include stdbool.h
#include asm/arch/mxc_hdmi.h
#include asm/arch/crm_regs.h
@@ -429,6 +430,146 @@ void s_init(void)
writel(mask528, anatop-pfd_528_clr);
}
+#ifdef CONFIG_LDO_BYPASS_CHECK
+DECLARE_GLOBAL_DATA_PTR;
+static int ldo_bypass;
+
+int check_ldo_bypass(void)
+{
+ const int *ldo_mode;
+ int node;
+
+ /* get the right fdt_blob from the global working_fdt */
+ gd-fdt_blob = working_fdt;
+ /* Get the node from FDT for anatop ldo-bypass */
+ node = fdt_node_offset_by_compatible(gd-fdt_blob, -1,
+ fsl,imx6q-gpc);
+ if (node 0) {
+ printf(No gpc device node %d, force to ldo-enable.\n, node);
+ return 0;
+ }
+ ldo_mode = fdt_getprop(gd-fdt_blob, node, fsl,ldo-bypass, NULL);
+ /*
+* return 1 if fsl,ldo-bypass = 1, else return 0 if
+* fsl,ldo-bypass = 0 or no fsl,ldo-bypass property
+*/
+ ldo_bypass = fdt32_to_cpu(*ldo_mode) == 1 ? 1 : 0;
+
+ return ldo_bypass;
+}
+
+int check_1_2G(void)
+{
+ u32 reg;
+ int result = 0;
+ struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+ struct fuse_bank *bank = ocotp-bank[0];
+ struct fuse_bank0_regs *fuse_bank0 =
+ (struct fuse_bank0_regs *)bank-fuse_regs;
+
+ reg = readl(fuse_bank0-cfg3);
+ if (((reg 16) 0x3) == 0x3) {
+ if (ldo_bypass) {
+ printf(Wrong dtb file used! i.MX6Q@1.2Ghz only works
with ldo-enable mode!\n);
+ /*
+* Currently, only imx6q-sabresd board might be here,
+* since only i.MX6Q support 1.2G and only Sabresd board
+* support ldo-bypass mode. So hardcode here.
+* You can also modify your board(i.MX6Q) dtb name if it
+* supports both ldo-bypass and ldo-enable mode.
+*/
+ printf(Please use imx6q-sabresd-ldo.dtb!\n);
+ hang();
+ }
+ result = 1;
+ }
+
+ return result;
+}
+
+static int arm_orig_podf;
+void set_arm_freq_400M(bool is_400M)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ if (is_400M)
+ writel(0x1, mxc_ccm-cacrr);
+ else
+ writel(arm_orig_podf, mxc_ccm-cacrr);
+}
+
+void prep_anatop_bypass(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ arm_orig_podf = readl(mxc_ccm-cacrr);
+ /*
+* Downgrade ARM speed to 400Mhz as half of boot 800Mhz before ldo
+* bypassed, also downgrade internal vddarm ldo to 0.975V.
+* VDDARM_IN 0.975V + 125mV = 1.1V Max(1.3V)
+* otherwise at 800Mhz(i.mx6dl):
+* VDDARM_IN 1.175V + 125mV = 1.3V = Max(1.3V)
+* We need provide enough gap in this case.
+* skip if boot from 400M.
+*/
+ if (!arm_orig_podf)
+ set_arm_freq_400M(true);
+#if !defined(CONFIG_MX6DL) !defined(CONFIG_MX6SX)
+ set_ldo_voltage(LDO_ARM, 975);
+#else
+ set_ldo_voltage(LDO_ARM, 1150);
+#endif
+}
+
+void set_wdog_reset(struct wdog_regs *wdog)
+{
+ u32 reg = readw(wdog-wcr);
+ /*
+
[U-Boot] [PATCH 10/12] imx:mx6sxsabresd add ldo mode set function
Add ldo_mode_set function. If ldo_bypass is true, it will adjust voltage.
If not, do nothing.
This function is board specific, so implement it in board file.
Signed-off-by: Peng Fan peng@freescale.com
Signed-off-by: Robin Gong b38...@freescale.com
---
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 50 +
include/configs/mx6sxsabresd.h | 2 ++
2 files changed, 52 insertions(+)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index fbf3337..36432c4 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -196,6 +196,7 @@ static struct i2c_pads_info i2c_pad_info1 = {
},
};
+static struct pmic *pfuze;
int power_init_board(void)
{
struct pmic *p;
@@ -204,6 +205,7 @@ int power_init_board(void)
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
+ pfuze = p;
ret = pfuze_mode_init(p, APS_PFM);
if (ret 0)
@@ -218,6 +220,54 @@ int power_init_board(void)
return 0;
}
+#ifdef CONFIG_LDO_BYPASS_CHECK
+void ldo_mode_set(int ldo_bypass)
+{
+ unsigned int value;
+ int is_400M;
+ u32 vddarm;
+ struct pmic *p = pfuze;
+
+ if (!p)
+ return;
+
+ /* switch to ldo_bypass mode */
+ if (ldo_bypass) {
+ prep_anatop_bypass();
+ /* decrease VDDARM to 1.275V */
+ pmic_reg_read(p, PFUZE100_SW1ABVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(12750);
+ pmic_reg_write(p, PFUZE100_SW1ABVOL, value);
+
+ /* decrease VDDSOC to 1.3V */
+ pmic_reg_read(p, PFUZE100_SW1CVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(13000);
+ pmic_reg_write(p, PFUZE100_SW1CVOL, value);
+
+ is_400M = set_anatop_bypass(1);
+ if (is_400M)
+ vddarm = PFUZE100_SW1ABC_SETP(10750);
+ else
+ vddarm = PFUZE100_SW1ABC_SETP(11750);
+
+ pmic_reg_read(p, PFUZE100_SW1ABVOL, value);
+ value = ~0x3f;
+ value |= vddarm;
+ pmic_reg_write(p, PFUZE100_SW1ABVOL, value);
+
+ pmic_reg_read(p, PFUZE100_SW1CVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(11750);
+ pmic_reg_write(p, PFUZE100_SW1CVOL, value);
+
+ finish_anatop_bypass();
+ printf(switch to ldo_bypass mode!\n);
+ }
+}
+#endif
+
#ifdef CONFIG_USB_EHCI_MX6
#define USB_OTHERREGS_OFFSET 0x800
#define UCTRL_PWR_POL (1 9)
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index 469d250..d69310e 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -181,6 +181,8 @@
#define CONFIG_POWER_PFUZE100
#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08
+#define CONFIG_LDO_BYPASS_CHECK
+
/* Network */
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/12] imx:mx6 add ldo bypass
This patch set is based on these three patches: https://patchwork.ozlabs.org/patch/426621/ https://patchwork.ozlabs.org/patch/426623/ https://patchwork.ozlabs.org/patch/426622/ If want to test this patch set, please first apply the up 3 patches. This patch set is mainly to add ldo bypass support. Since pmic related function is not readly in previous patch, patch 1/12, patch 2/12, patch 3/12 is first to add pmic related support, such as power_init_board, related iomux/pad settings and configuration in header file. Then ldo bypass function can be implemented. patch 4/12 is to update mxc_ccm_regs with more registers, since ldo setting will use them. patch 5/12 is to update fuse_bank0_regs, since ldo setting will check it. patch 6/12 is to add a macro for setting voltage easily. patch 7/12 is to add ldo bypass related common function. patch 8/12, patch 9/12, patch 10/12, patch 11/12 is to implement ldo_mode_set in different boards' file. patch 12/12 is to invoke ldo_mode_set in arch_preboot_os. Future work will integrate Device tree for i.MX6 U-Boot. Then we can move it to power_init_board. More detailed info can see each patch's commit log. Peng Fan (12): imx:mx6slevk add pmic and i2c configuration imx:mx6sl add I2c pad settings imx:mx6slevk implement power init board imx:mx6 update mxc_ccm_reg imx:mx6 update fuse_bank0_regs pmic:pfuze add macro for setting voltage imx:mx6 Support LDO bypass imx:mx6slevk add ldo mode set function imx:mx6sabresd Add ldo_mode_set function imx:mx6sxsabresd add ldo mode set function imx:mx6qsabreauto add ldo mode init ARM:imx call ldo_mode_set in arch_preboot_os arch/arm/cpu/armv7/mx6/soc.c | 141 ++ arch/arm/imx-common/cpu.c | 4 + arch/arm/include/asm/arch-mx6/crm_regs.h | 87 arch/arm/include/asm/arch-mx6/imx-regs.h | 12 ++- arch/arm/include/asm/arch-mx6/mx6sl_pins.h| 5 + arch/arm/include/asm/arch-mx6/sys_proto.h | 9 ++ board/freescale/mx6qsabreauto/mx6qsabreauto.c | 31 ++ board/freescale/mx6sabresd/mx6sabresd.c | 85 board/freescale/mx6slevk/mx6slevk.c | 100 ++ board/freescale/mx6sxsabresd/mx6sxsabresd.c | 50 + include/configs/mx6qsabreauto.h | 2 + include/configs/mx6sabresd.h | 2 + include/configs/mx6slevk.h| 14 +++ include/configs/mx6sxsabresd.h| 2 + include/power/pfuze100_pmic.h | 2 + 15 files changed, 542 insertions(+), 4 deletions(-) -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/12] imx:mx6sl add I2c pad settings
This few pad settings are for pmic i2c.
Signed-off-by: Peng Fan peng@freescale.com
---
arch/arm/include/asm/arch-mx6/mx6sl_pins.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
index 9ded3d8..0475203 100644
--- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
@@ -58,5 +58,10 @@ enum {
MX6_PAD_KEY_COL4__USB_USBOTG1_PWR =
IOMUX_PAD(0x0484, 0x017C, 6, 0x, 0, 0),
MX6_PAD_KEY_COL5__USB_USBOTG2_PWR =
IOMUX_PAD(0x0488, 0x0180, 6, 0x, 0, 0),
+
+ MX6_PAD_I2C1_SDA__I2C1_SDA =
IOMUX_PAD(0x0450, 0x0160, 0x10, 0x0720, 2, 0),
+ MX6_PAD_I2C1_SDA__GPIO_3_13 =
IOMUX_PAD(0x0450, 0x0160, 5, 0x, 0, 0),
+ MX6_PAD_I2C1_SCL__I2C1_SCL =
IOMUX_PAD(0x044C, 0x015C, 0x10, 0x071C, 2, 0),
+ MX6_PAD_I2C1_SCL__GPIO_3_12 =
IOMUX_PAD(0x044C, 0x015C, 5, 0x, 0, 0),
};
#endif /* __ASM_ARCH_MX6_MX6SL_PINS_H__ */
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/12] imx:mx6 update fuse_bank0_regs
Update fuse_bank0_regs structure according reference mannual.
Signed-off-by: Peng Fan peng@freescale.com
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index c968600..22f371d 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -624,12 +624,16 @@ struct fuse_bank0_regs {
u32 rsvd1[3];
u32 uid_high;
u32 rsvd2[3];
- u32 rsvd3[4];
- u32 rsvd4[4];
- u32 rsvd5[4];
+ u32 cfg2;
+ u32 rsvd3[3];
+ u32 cfg3;
+ u32 rsvd4[3];
+ u32 cfg4;
+ u32 rsvd5[3];
u32 cfg5;
u32 rsvd6[3];
- u32 rsvd7[4];
+ u32 cfg6;
+ u32 rsvd7[3];
};
#ifdef CONFIG_MX6SX
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/12] imx:mx6slevk implement power init board
Implement power_init_board and related I2C interface configuration.
After adding this, uboot can successfully detect and configure pmic.
U-Boot 2015.01-rc4-00110-g5697113-dirty (Jan 08 2015 - 21:06:44)
CPU: Freescale i.MX6SL rev1.0 at 396 MHz
Reset cause: POR
Board: MX6SLEVK
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Signed-off-by: Peng Fan peng@freescale.com
---
board/freescale/mx6slevk/mx6slevk.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index 838ea6c..f74b237 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -13,13 +13,18 @@
#include asm/arch/sys_proto.h
#include asm/gpio.h
#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
#include asm/imx-common/spi.h
#include asm/io.h
#include linux/sizes.h
#include common.h
#include fsl_esdhc.h
+#include i2c.h
#include mmc.h
#include netdev.h
+#include power/pmic.h
+#include power/pfuze100_pmic.h
+#include ../common/pfuze.h
#include usb.h
#include usb/ehci-fsl.h
@@ -40,6 +45,11 @@ DECLARE_GLOBAL_DATA_PTR;
#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+#define I2C_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
#define ETH_PHY_RESET IMX_GPIO_NR(4, 21)
int dram_init(void)
@@ -221,6 +231,39 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+#ifdef CONFIG_SYS_I2C_MXC
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+/* I2C1 for PMIC */
+struct i2c_pads_info i2c_pad_info1 = {
+ .sda = {
+ .i2c_mode = MX6_PAD_I2C1_SDA__I2C1_SDA | PC,
+ .gpio_mode = MX6_PAD_I2C1_SDA__GPIO_3_13 | PC,
+ .gp = IMX_GPIO_NR(3, 13),
+ },
+ .scl = {
+ .i2c_mode = MX6_PAD_I2C1_SCL__I2C1_SCL | PC,
+ .gpio_mode = MX6_PAD_I2C1_SCL__GPIO_3_12 | PC,
+ .gp = IMX_GPIO_NR(3, 12),
+ },
+};
+
+int power_init_board(void)
+{
+ struct pmic *p;
+ unsigned int ret;
+
+ p = pfuze_common_init(I2C_PMIC);
+ if (!p)
+ return -ENODEV;
+
+ ret = pfuze_mode_init(p, APS_PFM);
+ if (ret 0)
+ return -EIO;
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_FEC_MXC
int board_eth_init(bd_t *bis)
{
@@ -297,6 +340,10 @@ int board_init(void)
/* address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+#ifdef CONFIG_SYS_I2C_MXC
+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info1);
+#endif
+
#ifdef CONFIG_FEC_MXC
setup_fec();
#endif
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/12] imx:mx6qsabreauto add ldo mode init
If runs at 1.2GHz, enable ldo, and adjust voltage.
Otherwise, do nothing
Signed-off-by: Peng Fan peng@freescale.com
Signed-off-by: Robin Gong b38...@freescale.com
---
board/freescale/mx6qsabreauto/mx6qsabreauto.c | 31 +++
include/configs/mx6qsabreauto.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index b29ff2b..84ac9b7 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -29,6 +29,7 @@
#include asm/arch/crm_regs.h
#include pca953x.h
#include power/pmic.h
+#include power/pfuze100_pmic.h
#include ../common/pfuze.h
DECLARE_GLOBAL_DATA_PTR;
@@ -512,6 +513,7 @@ int board_spi_cs_gpio(unsigned bus, unsigned cs)
}
#endif
+static struct pmic *pfuze;
int power_init_board(void)
{
struct pmic *p;
@@ -520,6 +522,7 @@ int power_init_board(void)
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
+ pfuze = p;
ret = pfuze_mode_init(p, APS_PFM);
if (ret 0)
@@ -528,6 +531,34 @@ int power_init_board(void)
return 0;
}
+#ifdef CONFIG_LDO_BYPASS_CHECK
+void ldo_mode_set(int ldo_bypass)
+{
+ unsigned int value;
+ struct pmic *p = pfuze;
+
+ if (!p)
+ return;
+
+ /* increase VDDARM/VDDSOC to support 1.2G chip */
+ if (check_1_2G()) {
+ ldo_bypass = 0; /* ldo_enable on 1.2G chip */
+ printf(1.2G chip, increase VDDARM_IN/VDDSOC_IN\n);
+ /* increase VDDARM to 1.425V */
+ pmic_reg_read(p, PFUZE100_SW1ABVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(14250);
+ pmic_reg_write(p, PFUZE100_SW1ABVOL, value);
+
+ /* increase VDDSOC to 1.425V */
+ pmic_reg_read(p, PFUZE100_SW1CVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(14250);
+ pmic_reg_write(p, PFUZE100_SW1CVOL, value);
+ }
+}
+#endif
+
#ifdef CONFIG_CMD_BMODE
static const struct boot_mode board_boot_modes[] = {
/* 4 bit bus width */
diff --git a/include/configs/mx6qsabreauto.h b/include/configs/mx6qsabreauto.h
index 51042ca..5b4fb65 100644
--- a/include/configs/mx6qsabreauto.h
+++ b/include/configs/mx6qsabreauto.h
@@ -80,4 +80,6 @@
#define CONFIG_POWER_PFUZE100
#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08
+#define CONFIG_LDO_BYPASS_CHECK
+
#endif /* __MX6QSABREAUTO_CONFIG_H */
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/12] ARM:imx call ldo_mode_set in arch_preboot_os
Current i.MX6 U-Boot does not support device tree. We check
ldo-bypass from dtb file which is loaded when running
`run loadfdt`.
Future work is needed to integrate device tree in uboot. And move
related function invoke in power_init_board.
Signed-off-by: Peng Fan peng@freescale.com
Signed-off-by: Robin Gong b38...@freescale.com
---
arch/arm/imx-common/cpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index 28ccd29..1e518f2 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -204,6 +204,10 @@ u32 get_ahb_clk(void)
void arch_preboot_os(void)
{
+#if defined(CONFIG_LDO_BYPASS_CHECK)
+ ldo_mode_set(check_ldo_bypass());
+#endif
+
#if defined(CONFIG_CMD_SATA)
sata_stop();
#if defined(CONFIG_MX6)
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/12] imx:mx6slevk add ldo mode set function
Add ldo_mode_set function. If ldo_bypass is true, it will adjust voltage.
If not, do nothing.
This function is board specific, so implement it in board file.
Signed-off-by: Peng Fan peng@freescale.com
Signed-off-by: Robin Gong b38...@freescale.com
---
board/freescale/mx6slevk/mx6slevk.c | 61 ++---
include/configs/mx6slevk.h | 2 ++
2 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index f74b237..fdb6672 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -247,16 +247,69 @@ struct i2c_pads_info i2c_pad_info1 = {
},
};
+static struct pmic *pfuze;
+
+#ifdef CONFIG_LDO_BYPASS_CHECK
+void ldo_mode_set(int ldo_bypass)
+{
+ u32 value;
+ int is_400M;
+ struct pmic *p = pfuze;
+
+ if (!p)
+ return;
+
+ /* swith to ldo_bypass mode */
+ if (ldo_bypass) {
+ prep_anatop_bypass();
+
+ /* decrease VDDARM to 1.1V */
+ pmic_reg_read(p, PFUZE100_SW1ABVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(11000);
+ pmic_reg_write(p, PFUZE100_SW1ABVOL, value);
+
+ /* increase VDDSOC to 1.3V */
+ pmic_reg_read(p, PFUZE100_SW1CVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(13000);
+ pmic_reg_write(p, PFUZE100_SW1CVOL, value);
+
+ is_400M = set_anatop_bypass(0);
+
+ /*
+* MX6SL: VDDARM:1.175V@800M; VDDSOC:1.175V@800M
+*VDDARM:0.975V@400M; VDDSOC:1.175V@400M
+*/
+ pmic_reg_read(p, PFUZE100_SW1ABVOL, value);
+ value = ~0x3f;
+ if (is_400M)
+ value |= PFUZE100_SW1ABC_SETP(9750);
+ else
+ value |= PFUZE100_SW1ABC_SETP(11750);
+ pmic_reg_write(p, PFUZE100_SW1ABVOL, value);
+
+ /* decrease VDDSOC to 1.175V */
+ pmic_reg_read(p, PFUZE100_SW1CVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(11750);
+ pmic_reg_write(p, PFUZE100_SW1CVOL, value);
+
+ finish_anatop_bypass();
+ printf(switch to ldo_bypass mode!\n);
+ }
+}
+#endif
+
int power_init_board(void)
{
- struct pmic *p;
unsigned int ret;
- p = pfuze_common_init(I2C_PMIC);
- if (!p)
+ pfuze = pfuze_common_init(I2C_PMIC);
+ if (!pfuze)
return -ENODEV;
- ret = pfuze_mode_init(p, APS_PFM);
+ ret = pfuze_mode_init(pfuze, APS_PFM);
if (ret 0)
return -EIO;
diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
index 9fd7619..56c2faf 100644
--- a/include/configs/mx6slevk.h
+++ b/include/configs/mx6slevk.h
@@ -60,6 +60,8 @@
#define CONFIG_POWER_PFUZE100
#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08
+#define CONFIG_LDO_BYPASS_CHECK
+
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_MII
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/12] imx:mx6sabresd Add ldo_mode_set function
If runs at 1.2GHz, enable ldo, and adjust voltage.
If ldo_bypass is true, it will adjust voltage. If not, do nothing.
This function is board specific, so implement it in board file.
Signed-off-by: Peng Fan peng@freescale.com
Signed-off-by: Robin Gong b38...@freescale.com
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 85 +
include/configs/mx6sabresd.h| 2 +
2 files changed, 87 insertions(+)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 59544d9..9e0a8ae 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -628,6 +628,7 @@ int board_init(void)
return 0;
}
+static struct pmic *pfuze;
int power_init_board(void)
{
struct pmic *p;
@@ -636,6 +637,7 @@ int power_init_board(void)
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
+ pfuze = p;
ret = pfuze_mode_init(p, APS_PFM);
if (ret 0)
@@ -656,6 +658,89 @@ int power_init_board(void)
return 0;
}
+#ifdef CONFIG_LDO_BYPASS_CHECK
+void ldo_mode_set(int ldo_bypass)
+{
+ unsigned int value;
+ int is_400M;
+ unsigned char vddarm;
+ struct pmic *p = pfuze;
+
+ /* increase VDDARM/VDDSOC to support 1.2G chip */
+ if (check_1_2G()) {
+ ldo_bypass = 0; /* ldo_enable on 1.2G chip */
+ printf(1.2G chip, increase VDDARM_IN/VDDSOC_IN\n);
+ /* increase VDDARM to 1.425V */
+ pmic_reg_read(p, PFUZE100_SW1ABVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(14250);
+ pmic_reg_write(p, PFUZE100_SW1ABVOL, value);
+
+ /* increase VDDSOC to 1.425V */
+ pmic_reg_read(p, PFUZE100_SW1CVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(14250);
+ pmic_reg_write(p, PFUZE100_SW1CVOL, value);
+ }
+ /* switch to ldo_bypass mode , boot on 800Mhz */
+ if (ldo_bypass) {
+ prep_anatop_bypass();
+
+ /* decrease VDDARM for 400Mhz DQ:1.1V, DL:1.275V */
+ pmic_reg_read(p, PFUZE100_SW1ABVOL, value);
+ value = ~0x3f;
+#if defined(CONFIG_MX6DL)
+ value |= PFUZE100_SW1ABC_SETP(12750);
+#else
+ value |= PFUZE100_SW1ABC_SETP(11000);
+#endif
+ pmic_reg_write(p, PFUZE100_SW1ABVOL, value);
+
+ /* increase VDDSOC to 1.3V */
+ pmic_reg_read(p, PFUZE100_SW1CVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(13000);
+ pmic_reg_write(p, PFUZE100_SW1CVOL, value);
+
+ /*
+* MX6Q:
+* VDDARM:1.15V@800M; VDDSOC:1.175V@800M
+* VDDARM:0.975V@400M; VDDSOC:1.175V@400M
+* MX6DL:
+* VDDARM:1.175V@800M; VDDSOC:1.175V@800M
+* VDDARM:1.075V@400M; VDDSOC:1.175V@400M
+*/
+ is_400M = set_anatop_bypass(2);
+ if (is_400M)
+#if defined(CONFIG_MX6DL)
+ vddarm = PFUZE100_SW1ABC_SETP(10750);
+#else
+ vddarm = PFUZE100_SW1ABC_SETP(9750);
+#endif
+ else
+#if defined(CONFIG_MX6DL)
+ vddarm = PFUZE100_SW1ABC_SETP(11750);
+#else
+ vddarm = PFUZE100_SW1ABC_SETP(11500);
+#endif
+
+ pmic_reg_read(p, PFUZE100_SW1ABVOL, value);
+ value = ~0x3f;
+ value |= vddarm;
+ pmic_reg_write(p, PFUZE100_SW1ABVOL, value);
+
+ /* decrease VDDSOC to 1.175V */
+ pmic_reg_read(p, PFUZE100_SW1CVOL, value);
+ value = ~0x3f;
+ value |= PFUZE100_SW1ABC_SETP(11750);
+ pmic_reg_write(p, PFUZE100_SW1CVOL, value);
+
+ finish_anatop_bypass();
+ printf(switch to ldo_bypass mode!\n);
+ }
+}
+#endif
+
#ifdef CONFIG_MXC_SPI
int board_spi_cs_gpio(unsigned bus, unsigned cs)
{
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 99d9d4d..70dbf30 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -60,6 +60,8 @@
#define CONFIG_POWER_PFUZE100
#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08
+#define CONFIG_LDO_BYPASS_CHECK
+
/* USB Configs */
#define CONFIG_CMD_USB
#ifdef CONFIG_CMD_USB
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/8] video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828
So that we don't need to keep it as a hardcoded magic number in the code or the hassle exposing it as a Kconfig option. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com --- drivers/video/sunxi_lcd_panel.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/sunxi_lcd_panel.c b/drivers/video/sunxi_lcd_panel.c index cdde639..ebc0ca5 100644 --- a/drivers/video/sunxi_lcd_panel.c +++ b/drivers/video/sunxi_lcd_panel.c @@ -79,7 +79,6 @@ int sunxi_ssd2828_init(const struct ctfb_res_modes *mode) .sdi_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_MOSI), .sdo_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_MISO), .reset_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SSD2828_RESET), - .ssd2828_tx_clk_khz = 27000, .ssd2828_color_depth = 24, #ifdef CONFIG_VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828 .mipi_dsi_number_of_data_lanes = 4, -- 2.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id
Or at least try to do this. With the possibility of bi-directional
communication, it seems natural to expect that MIPI displays
should be able to handle automatic configuration for the screen
resolution and timings nicely. But the reality is not so pretty.
It appears that the manufacturers of MIPI LCD panels are not very
disciplined and do not follow any kind of standard guidelines
when it comes to providing the panel identification information.
MIPI DSI even has two alternative standard DCS commands for
potentially reading the vendor/panel id: MIPI_DCS_GET_DISPLAY_ID
and MIPI_DCS_READ_DDB_START. But these commands do not seem to
be widely implemented in real hardware. Moreover, the vendors
seem to sometimes invent their own custom new commands, while
ignoring the standard ones.
This particular patch just probes both of the standard DCS
commands and also a few non-standard ones. With the hope to
actually extract anything unique and/or meaningful from the
LCD panel. This information is then printed to the u-boot
console.
We don't know what the future brings. Maybe the manufacturers
are going to start acting responsibly some day. And will
implement proper panel identification.
Regarding what we have right now. The information retrieval
DCS commands still work if reducing the clock speed to the very
minimum and enabling only one lane on my MSI Primo81 tablet.
Potentially it means that one could perhaps swap two different
MIPI LCD panels (if they have a compatible connector) and still
have the software handling this fine by doing runtime selection
of the right settings (based on checking the panel id).
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
drivers/video/ssd2828.c | 140
1 file changed, 140 insertions(+)
diff --git a/drivers/video/ssd2828.c b/drivers/video/ssd2828.c
index 702afd9..cfebedd 100644
--- a/drivers/video/ssd2828.c
+++ b/drivers/video/ssd2828.c
@@ -98,6 +98,9 @@
#defineSSD2828_CFGR_LPE(1 10)
#defineSSD2828_CFGR_TXD(1 11)
+#defineSSD2828_ISR_READ_DATA_READY (1 0)
+#defineSSD2828_ISR_BTA_RESPONSE(1 2)
+
#defineSSD2828_VIDEO_MODE_NON_BURST_WITH_SYNC_PULSES (0 2)
#defineSSD2828_VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS (1 2)
#defineSSD2828_VIDEO_MODE_BURST(2 2)
@@ -167,6 +170,30 @@ static void write_hw_register(const struct ssd2828_config
*cfg, u8 regnum,
soft_spi_xfer_24bit_3wire(cfg, 0x72 | val);
}
+static int await_completion(const struct ssd2828_config *cfg,
+ u8 reg, u32 mask, u32 val)
+{
+ unsigned long tmo = timer_get_us() + 10;
+
+ while ((read_hw_register(cfg, reg) mask) != val) {
+ if (timer_get_us() tmo)
+ return 1;
+ }
+ return 0;
+}
+
+static int await_bits_set(const struct ssd2828_config *cfg,
+ u8 reg, u32 val)
+{
+ return await_completion(cfg, reg, val, val);
+}
+
+static int await_bits_clear(const struct ssd2828_config *cfg,
+ u8 reg, u32 val)
+{
+ return await_completion(cfg, reg, val, 0);
+}
+
/*
* Send MIPI command to the LCD panel (cmdnum 0xB0)
*/
@@ -179,6 +206,79 @@ static void send_mipi_dcs_command(const struct
ssd2828_config *cfg, u8 cmdnum)
}
/*
+ * Sends a MIPI DCS command to retrieve information from the LCD panel.
+ */
+static int send_mipi_dcs_read_command(const struct ssd2828_config *cfg,
+ u8 cmdnum,
+ u8 *result_buf,
+ int bufsize)
+{
+ int size, i, result = 0;
+ /* Save CFGR register */
+ u32 old_cfgr = read_hw_register(cfg, SSD2828_CFGR);
+
+ /* Set the read enable bit */
+ write_hw_register(cfg, SSD2828_CFGR, old_cfgr | SSD2828_CFGR_REN);
+ /* Clear buffers and bring the state machine to its initial state */
+ write_hw_register(cfg, SSD2828_OCR, 1);
+ if (await_bits_clear(cfg, SSD2828_OCR, 1) != 0)
+ goto err;
+ /* Clear the RW1C bits in the ISR register */
+ write_hw_register(cfg, SSD2828_ISR, read_hw_register(cfg, SSD2828_ISR));
+
+ /* Set the payload size (only the DCS command itself) */
+ write_hw_register(cfg, SSD2828_PSCR1, 1);
+ /* Set maximum return size */
+ write_hw_register(cfg, SSD2828_MRSR, bufsize);
+ /* Write the command */
+ write_hw_register(cfg, SSD2828_PDR, cmdnum);
+
+ /* Wait for the response */
+ if (await_bits_set(cfg, SSD2828_ISR, SSD2828_ISR_BTA_RESPONSE) != 0)
+ goto err; /* Timeout */
+
+ /* Check if there is anything in the read buffer */
+ if
[U-Boot] [PATCH 01/12] imx:mx6slevk add pmic and i2c configuration
Add pmic and i2c configuration in board header file. Signed-off-by: Peng Fan peng@freescale.com --- include/configs/mx6slevk.h | 12 1 file changed, 12 insertions(+) diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h index e6c4130..9fd7619 100644 --- a/include/configs/mx6slevk.h +++ b/include/configs/mx6slevk.h @@ -48,6 +48,18 @@ #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION +/* I2C Configs */ +#define CONFIG_CMD_I2C +#define CONFIG_SYS_I2C +#define CONFIG_SYS_I2C_MXC +#define CONFIG_SYS_I2C_SPEED 10 + +/* PMIC */ +#define CONFIG_POWER +#define CONFIG_POWER_I2C +#define CONFIG_POWER_PFUZE100 +#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08 + #define CONFIG_CMD_PING #define CONFIG_CMD_DHCP #define CONFIG_CMD_MII -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/9] sf: Update Atmel flash params
Hi Meng,
On 12/10/2014 08:51 PM, Bin Meng wrote:
Update flash sector size to 4KiB as long as flash supports sector
erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase
command to 50h instead of D8h. Also add AT25DF321A params per
datasheet.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/mtd/spi/sf_internal.h | 5 +
drivers/mtd/spi/sf_params.c | 17 +
drivers/mtd/spi/sf_probe.c| 4
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 785f7a9..8010fc5 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -106,6 +106,11 @@ enum {
#define SPI_FLASH_PAGE_ERASE_TIMEOUT (5 * CONFIG_SYS_HZ)
#define SPI_FLASH_SECTOR_ERASE_TIMEOUT(10 * CONFIG_SYS_HZ)
+/* Atmel specific */
+#ifdef CONFIG_SPI_FLASH_ATMEL
+# define CMD_ATMEL_BLK_ERASE 0x50
+#endif
+
/* SST specific */
#ifdef CONFIG_SPI_FLASH_SST
# define CMD_SST_BP 0x02/* Byte Program */
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 5482700..cc4cd60 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -15,14 +15,15 @@
/* SPI/QSPI flash device params structure */
const struct spi_flash_params spi_flash_params_table[] = {
#ifdef CONFIG_SPI_FLASH_ATMEL /* ATMEL */
- {AT45DB011D, 0x1f2200, 0x0, 64 * 1024, 4,
RD_NORM, SECT_4K},
- {AT45DB021D, 0x1f2300, 0x0, 64 * 1024, 8,
RD_NORM, SECT_4K},
- {AT45DB041D, 0x1f2400, 0x0, 64 * 1024, 8,
RD_NORM, SECT_4K},
- {AT45DB081D, 0x1f2500, 0x0, 64 * 1024,16,
RD_NORM, SECT_4K},
- {AT45DB161D, 0x1f2600, 0x0, 64 * 1024,32,
RD_NORM, SECT_4K},
- {AT45DB321D, 0x1f2700, 0x0, 64 * 1024,64,
RD_NORM, SECT_4K},
- {AT45DB641D, 0x1f2800, 0x0, 64 * 1024, 128,
RD_NORM, SECT_4K},
- {AT25DF321, 0x1f4701, 0x0, 64 * 1024,64, RD_NORM,
SECT_4K},
+ {AT45DB011D, 0x1f2200, 0x0,2 * 1024,64,
RD_NORM,0},
+ {AT45DB021D, 0x1f2300, 0x0,2 * 1024, 128,
RD_NORM,0},
+ {AT45DB041D, 0x1f2400, 0x0,2 * 1024, 256,
RD_NORM,0},
+ {AT45DB081D, 0x1f2500, 0x0,2 * 1024, 512,
RD_NORM,0},
+ {AT45DB161D, 0x1f2600, 0x0,4 * 1024, 512,
RD_NORM,0},
+ {AT45DB321D, 0x1f2700, 0x0,4 * 1024, 1024,
RD_NORM,0},
In datasheet, the id is 0x1f2701. Doc number is: 3597Q-DFLASH-6/11. I
can not find any new datasheet.
And I test on at91sam9m10g45ek board, it also read as this ID (0x1f2701).
So, if you plan to send new version, can you help add this ID? If not,
maybe follow up patch will be better.
Thanks.
+ {AT45DB641D, 0x1f2800, 0x0,2 * 1024, 4096,
RD_NORM,0},
+ {AT25DF321, 0x1f4700, 0x0, 4 * 1024, 1024, RD_NORM,
SECT_4K},
+ {AT25DF321A, 0x1f4701, 0x0, 4 * 1024, 1024, RD_NORM,
SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_EON /* EON */
{EN25Q32B, 0x1c3016, 0x0, 64 * 1024,64, RD_NORM,
0},
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index ce9987f..13fda44 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -179,7 +179,11 @@ static int spi_flash_validate_params(struct spi_slave
*spi, u8 *idcode,
flash-erase_cmd = CMD_ERASE_32K;
flash-erase_size = 32768 flash-shift;
} else {
+#ifdef CONFIG_SPI_FLASH_ATMEL
+ flash-erase_cmd = CMD_ATMEL_BLK_ERASE;
+#else
flash-erase_cmd = CMD_ERASE_64K;
+#endif
flash-erase_size = flash-sector_size;
}
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/8] video: Add support for SSD2828 (parallel LCD to MIPI bridge)
SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the flight into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com --- drivers/video/Makefile | 1 + drivers/video/ssd2828.c | 421 drivers/video/ssd2828.h | 123 ++ 3 files changed, 545 insertions(+) create mode 100644 drivers/video/ssd2828.c create mode 100644 drivers/video/ssd2828.h diff --git a/drivers/video/Makefile b/drivers/video/Makefile index d4fe1aa..e29dc4f 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_VIDEO_COREBOOT) += coreboot_fb.o obj-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o obj-$(CONFIG_VIDEO_IMX25LCDC) += imx25lcdc.o videomodes.o +obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o obj-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o diff --git a/drivers/video/ssd2828.c b/drivers/video/ssd2828.c new file mode 100644 index 000..566ec19 --- /dev/null +++ b/drivers/video/ssd2828.c @@ -0,0 +1,421 @@ +/* + * (C) 2015 Siarhei Siamashka siarhei.siamas...@gmail.com + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +/* + * Support for the SSD2828 bridge chip, which can take pixel data coming + * from a parallel LCD interface and translate it on the flight into MIPI DSI + * interface for driving a MIPI compatible TFT display. + */ + +#include common.h +#include mipi_display.h +#include asm/arch/gpio.h +#include asm/gpio.h + +#include videomodes.h +#include ssd2828.h + +#defineSSD2828_DIR 0xB0 +#defineSSD2828_VICR1 0xB1 +#defineSSD2828_VICR2 0xB2 +#defineSSD2828_VICR3 0xB3 +#defineSSD2828_VICR4 0xB4 +#defineSSD2828_VICR5 0xB5 +#defineSSD2828_VICR6 0xB6 +#defineSSD2828_CFGR0xB7 +#defineSSD2828_VCR 0xB8 +#defineSSD2828_PCR 0xB9 +#defineSSD2828_PLCR0xBA +#defineSSD2828_CCR 0xBB +#defineSSD2828_PSCR1 0xBC +#defineSSD2828_PSCR2 0xBD +#defineSSD2828_PSCR3 0xBE +#defineSSD2828_PDR 0xBF +#defineSSD2828_OCR 0xC0 +#defineSSD2828_MRSR0xC1 +#defineSSD2828_RDCR0xC2 +#defineSSD2828_ARSR0xC3 +#defineSSD2828_LCR 0xC4 +#defineSSD2828_ICR 0xC5 +#defineSSD2828_ISR 0xC6 +#defineSSD2828_ESR 0xC7 +#defineSSD2828_DAR10xC9 +#defineSSD2828_DAR20xCA +#defineSSD2828_DAR30xCB +#defineSSD2828_DAR40xCC +#defineSSD2828_DAR50xCD +#defineSSD2828_DAR60xCE +#defineSSD2828_HTTR1 0xCF +#defineSSD2828_HTTR2 0xD0 +#defineSSD2828_LRTR1 0xD1 +#defineSSD2828_LRTR2 0xD2 +#defineSSD2828_TSR 0xD3 +#defineSSD2828_LRR 0xD4 +#defineSSD2828_PLLR0xD5 +#defineSSD2828_TR 0xD6 +#defineSSD2828_TECR0xD7 +#defineSSD2828_ACR10xD8 +#defineSSD2828_ACR20xD9 +#defineSSD2828_ACR30xDA +#defineSSD2828_ACR40xDB +#defineSSD2828_IOCR0xDC +#defineSSD2828_VICR7 0xDD +#defineSSD2828_LCFR0xDE +#defineSSD2828_DAR70xDF +#defineSSD2828_PUCR1 0xE0 +#defineSSD2828_PUCR2 0xE1 +#defineSSD2828_PUCR3 0xE2 +#defineSSD2828_CBCR1 0xE9 +#defineSSD2828_CBCR2 0xEA +#defineSSD2828_CBSR0xEB +#defineSSD2828_ECR 0xEC +#defineSSD2828_VSDR0xED +#defineSSD2828_TMR 0xEE +#defineSSD2828_GPIO1 0xEF +#defineSSD2828_GPIO2 0xF0 +#defineSSD2828_DLYA01 0xF1 +#defineSSD2828_DLYA23 0xF2 +#defineSSD2828_DLYB01 0xF3 +#defineSSD2828_DLYB23 0xF4 +#define
[U-Boot] [PATCH 5/8] sun6i: Add LCD display support for MSI Primo81 tablet
The MSI Primo81 tablet has B079XAN01/LP079X01 7.85 768x1024 IPS MIPI display, connected to the parallel LCD interface via SSD2828 bridge chip. The panel has 18-bit color depth and needs dithering, in spite of having RGB data delivered from A31s to SSD2828 using 24-bit arrangement. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com --- configs/MSI_Primo81_defconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/configs/MSI_Primo81_defconfig b/configs/MSI_Primo81_defconfig index b4b0f6d..1be6016 100644 --- a/configs/MSI_Primo81_defconfig +++ b/configs/MSI_Primo81_defconfig @@ -1,6 +1,15 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS= CONFIG_FDTFILE=sun6i-a31s-primo81.dtb +CONFIG_VIDEO_LCD_MODE=x:768,y:1024,depth:18,pclk_khz:66000,le:56,ri:60,up:30,lo:36,hs:64,vs:50,sync:3,vmode:0 +CONFIG_VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828=y +CONFIG_VIDEO_LCD_SSD2828_RESET=PA26 +CONFIG_VIDEO_LCD_SPI_CS=PH9 +CONFIG_VIDEO_LCD_SPI_SCLK=PH10 +CONFIG_VIDEO_LCD_SPI_MOSI=PH11 +CONFIG_VIDEO_LCD_SPI_MISO=PH12 +CONFIG_VIDEO_LCD_BL_EN=PA25 +CONFIG_VIDEO_LCD_BL_PWM=PH13 CONFIG_USB_KEYBOARD=n +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y -- 2.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] sunxi: axp221: Add ELDO[1-3] support
And also add Kconfig option for selecting ELDO3 voltage. The reason
for having this option is that the Android kernel sets ELDO3 to
1.2V when powering up LCD in the case if 'lcd_if' configuration
variable is set to 6 (LCD_IF_EXT_DSI) in the FEX file. Most likely
to supply power for a SSD2828 chip.
However on the MSI Primo81 tablet, which is using this particular
'lcd_if = 6' setup for LCD, setting the ELDO3 voltage appears to
be unnecessary and it works regardless. Having no schematics of
this tablet, I can only guess that 1.2V is supplied to SSD2828
in some other way.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
board/sunxi/board.c| 1 +
drivers/power/Kconfig | 10 ++
drivers/power/axp221.c | 51 ++
include/axp221.h | 9 +
4 files changed, 71 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 7d6d075..12a2e77 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -189,6 +189,7 @@ void sunxi_board_init(void)
power_failed |= axp221_set_aldo1(CONFIG_AXP221_ALDO1_VOLT);
power_failed |= axp221_set_aldo2(CONFIG_AXP221_ALDO2_VOLT);
power_failed |= axp221_set_aldo3(CONFIG_AXP221_ALDO3_VOLT);
+ power_failed |= axp221_set_eldo3(CONFIG_AXP221_ELDO3_VOLT);
#endif
printf(DRAM:);
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index ef0c093..cf42e63 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -63,3 +63,13 @@ config AXP221_ALDO3_VOLT
Set the voltage (mV) to program the axp221 aldo3 at, set to 0 to
disable aldo3. This is typically connected to VCC-PLL and AVCC and
must be set to 3V.
+
+config AXP221_ELDO3_VOLT
+ int axp221 eldo3 voltage
+ depends on AXP221_POWER
+ default 0
+ ---help---
+ Set the voltage (mV) to program the axp221 eldo3 at, set to 0 to
+ disable eldo3. On some A31(s) tablets it might be used to supply
+ 1.2V for the SSD2828 chip (convertor of parallel LCD interface
+ into MIPI DSI).
diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c
index 1fda19a..d041b30 100644
--- a/drivers/power/axp221.c
+++ b/drivers/power/axp221.c
@@ -302,6 +302,57 @@ int axp221_set_aldo3(unsigned int mvolt)
AXP221_OUTPUT_CTRL3_ALDO3_EN);
}
+int axp221_set_eldo1(unsigned int mvolt)
+{
+ int ret;
+ u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
+
+ if (mvolt == 0)
+ return axp221_clrbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO1_EN);
+
+ ret = pmic_bus_write(AXP221_ELDO1_CTRL, cfg);
+ if (ret)
+ return ret;
+
+ return axp221_setbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO1_EN);
+}
+
+int axp221_set_eldo2(unsigned int mvolt)
+{
+ int ret;
+ u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
+
+ if (mvolt == 0)
+ return axp221_clrbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO2_EN);
+
+ ret = pmic_bus_write(AXP221_ELDO2_CTRL, cfg);
+ if (ret)
+ return ret;
+
+ return axp221_setbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO2_EN);
+}
+
+int axp221_set_eldo3(unsigned int mvolt)
+{
+ int ret;
+ u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
+
+ if (mvolt == 0)
+ return axp221_clrbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO3_EN);
+
+ ret = pmic_bus_write(AXP221_ELDO3_CTRL, cfg);
+ if (ret)
+ return ret;
+
+ return axp221_setbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO3_EN);
+}
+
int axp221_init(void)
{
u8 axp_chip_id;
diff --git a/include/axp221.h b/include/axp221.h
index e9552f6..da63891 100644
--- a/include/axp221.h
+++ b/include/axp221.h
@@ -26,6 +26,9 @@
#define AXP221_OUTPUT_CTRL1_ALDO1_EN (1 6)
#define AXP221_OUTPUT_CTRL1_ALDO2_EN (1 7)
#define AXP221_OUTPUT_CTRL20x12
+#define AXP221_OUTPUT_CTRL2_ELDO1_EN (1 0)
+#define AXP221_OUTPUT_CTRL2_ELDO2_EN (1 1)
+#define AXP221_OUTPUT_CTRL2_ELDO3_EN (1 2)
#define AXP221_OUTPUT_CTRL2_DLDO1_EN (1 3)
#define AXP221_OUTPUT_CTRL2_DLDO2_EN (1 4)
#define AXP221_OUTPUT_CTRL2_DLDO3_EN (1 5)
@@ -37,6 +40,9 @@
#define AXP221_DLDO2_CTRL 0x16
#define AXP221_DLDO3_CTRL 0x17
#define AXP221_DLDO4_CTRL 0x18
+#define AXP221_ELDO1_CTRL 0x19
+#define AXP221_ELDO2_CTRL 0x1a
+#define AXP221_ELDO3_CTRL 0x1b
#define AXP221_DCDC1_CTRL 0x21
#define AXP221_DCDC2_CTRL 0x22
#define AXP221_DCDC3_CTRL 0x23
@@ -62,5 +68,8 @@ int axp221_set_dldo4(unsigned int mvolt);
int axp221_set_aldo1(unsigned int mvolt);
int axp221_set_aldo2(unsigned int mvolt);
int axp221_set_aldo3(unsigned
[U-Boot] [PATCH 6/8] video: ssd2828: Allow using 'pclk' as the PLL clock source
Instead of using the internal 'tx_clk' clock source, it is also
possible to use the pixel clock signal from the parallel LCD
interface ('pclk') as the reference clock for PLL.
The 'tx_clk' clock speed may be different on different boards/devices
(the allowed range is 8MHz - 30MHz). Which is not very convenient,
especially considering the need to know the exact 'tx_clk' clock
speed. Which may be difficult to identify without having device
schematics and/or accurate documentation/sources every time.
Using 'pclk' is free from all these problems.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
drivers/video/ssd2828.c | 20 +---
drivers/video/ssd2828.h | 11 ---
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/video/ssd2828.c b/drivers/video/ssd2828.c
index 566ec19..702afd9 100644
--- a/drivers/video/ssd2828.c
+++ b/drivers/video/ssd2828.c
@@ -339,7 +339,7 @@ static int ssd2828_configure_video_interface(const struct
ssd2828_config *cfg,
int ssd2828_init(const struct ssd2828_config *cfg,
const struct ctfb_res_modes *mode)
{
- u32 lp_div, pll_freq_kbps, pll_config;
+ u32 lp_div, pll_freq_kbps, reference_freq_khz, pll_config;
/* The LP clock speed is limited by 10MHz */
const u32 mipi_dsi_low_power_clk_khz = 1;
/*
@@ -373,6 +373,20 @@ int ssd2828_init(const struct ssd2828_config *cfg,
}
/*
+* Pick the reference clock for PLL. If we know the exact 'tx_clk'
+* clock speed, then everything is good. If not, then we can fallback
+* to 'pclk' (pixel clock from the parallel LCD interface). In the
+* case of using this fallback, it is necessary to have parallel LCD
+* already initialized and running at this point.
+*/
+ reference_freq_khz = cfg-ssd2828_tx_clk_khz;
+ if (reference_freq_khz == 0) {
+ reference_freq_khz = mode-pixclock_khz;
+ /* Use 'pclk' as the reference clock for PLL */
+ cfgr_reg |= SSD2828_CFGR_CSS;
+ }
+
+ /*
* Setup the parallel LCD timings in the appropriate registers.
*/
if (ssd2828_configure_video_interface(cfg, mode) != 0) {
@@ -389,10 +403,10 @@ int ssd2828_init(const struct ssd2828_config *cfg,
/* PLL Configuration Register */
pll_config = construct_pll_config(
cfg-mipi_dsi_bitrate_per_data_lane_mbps * 1000,
- cfg-ssd2828_tx_clk_khz);
+ reference_freq_khz);
write_hw_register(cfg, SSD2828_PLCR, pll_config);
- pll_freq_kbps = decode_pll_config(pll_config, cfg-ssd2828_tx_clk_khz);
+ pll_freq_kbps = decode_pll_config(pll_config, reference_freq_khz);
lp_div = DIV_ROUND_UP(pll_freq_kbps, mipi_dsi_low_power_clk_khz * 8);
/* VC Control Register */
diff --git a/drivers/video/ssd2828.h b/drivers/video/ssd2828.h
index 14b96c5..1af6fa4 100644
--- a/drivers/video/ssd2828.h
+++ b/drivers/video/ssd2828.h
@@ -47,8 +47,12 @@ struct ssd2828_config {
* to TX_CLK_XIO/TX_CLK_XIN pins), which is necessary at least for
* clocking SPI after reset. The exact clock speed is not strictly,
* defined, but the datasheet says that it must be somewhere in the
-* 8MHz - 30MHz range (see TX_CLK Timing section). It is used as
-* a reference clock for PLL and must be set correctly.
+* 8MHz - 30MHz range (see TX_CLK Timing section). It can be also
+* used as a reference clock for PLL. If the exact clock frequency
+* is known, then it can be specified here. If it is unknown, or the
+* information is not trustworthy, then it can be set to 0.
+*
+* If unsure, set to 0.
*/
int ssd2828_tx_clk_khz;
@@ -115,7 +119,8 @@ struct ssd2828_config {
* The right place to insert this function call is after the parallel LCD
* interface is initialized and before turning on the backlight. This is
* advised in the Example for system sleep in and out section of the
- * SSD2828 datasheet.
+ * SSD2828 datasheet. And also SS2828 may use 'pclk' as the clock source
+ * for PLL, which means that the input signal must be already there.
*/
int ssd2828_init(const struct ssd2828_config *cfg,
const struct ctfb_res_modes *mode);
--
2.0.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8] video: sunxi: Hook up SSD2828 with the sunxi video driver
Expose the necessary configuration parameters in Kconfig.
Add SSD2828 initialization between enabling the parallel LCD
interface and turning on the backlight.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
board/sunxi/Kconfig | 60 +
drivers/video/sunxi_display.c | 3 +++
drivers/video/sunxi_lcd_panel.c | 38 ++
drivers/video/sunxi_lcd_panel.h | 3 +++
4 files changed, 104 insertions(+)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index adee5ed..92dbce7 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -345,6 +345,60 @@ config VIDEO_LCD_BL_PWM
Set the backlight pwm pin for the LCD panel. This takes a string in the
format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+config VIDEO_LCD_SPI_CS
+ string SPI CS pin for LCD related config job
+ depends on VIDEO_LCD_SSD2828
+ default
+ ---help---
+ This is one of the SPI communication pins, involved in setting up a
+ working LCD configuration. The exact role of SPI may differ for
+ different hardware setups. The option takes a string in the format
+ understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+
+config VIDEO_LCD_SPI_SCLK
+ string SPI SCLK pin for LCD related config job
+ depends on VIDEO_LCD_SSD2828
+ default
+ ---help---
+ This is one of the SPI communication pins, involved in setting up a
+ working LCD configuration. The exact role of SPI may differ for
+ different hardware setups. The option takes a string in the format
+ understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+
+config VIDEO_LCD_SPI_MOSI
+ string SPI MOSI pin for LCD related config job
+ depends on VIDEO_LCD_SSD2828
+ default
+ ---help---
+ This is one of the SPI communication pins, involved in setting up a
+ working LCD configuration. The exact role of SPI may differ for
+ different hardware setups. The option takes a string in the format
+ understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+
+config VIDEO_LCD_SPI_MISO
+ string SPI MISO pin for LCD related config job (optional)
+ depends on VIDEO_LCD_SSD2828
+ default
+ ---help---
+ This is one of the SPI communication pins, involved in setting up a
+ working LCD configuration. The exact role of SPI may differ for
+ different hardware setups. If wired up, this pin may provide additional
+ useful functionality. Such as bi-directional communication with the
+ hardware and LCD panel id retrieval (if the panel can report it). The
+ option takes a string in the format understood by sunxi_name_to_gpio,
+ e.g. PH1 for pin 1 of port H.
+
+config VIDEO_LCD_SSD2828_RESET
+ string RESET pin of SSD2828
+ depends on VIDEO_LCD_SSD2828
+ default
+ ---help---
+ The reset pin of SSD2828 chip. This takes a string in the format
+ understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+
+config VIDEO_LCD_SSD2828
+ bool
+ select VIDEO_LCD_IF_PARALLEL
# Note only one of these may be selected at a time! But hidden choices are
# not supported by Kconfig
@@ -373,6 +427,12 @@ config VIDEO_LCD_PANEL_HITACHI_TX18D42VM
bool Hitachi tx18d42vm LCD panel
select VIDEO_LCD_IF_LVDS
+config VIDEO_LCD_PANEL_MIPI_4_LANE_513_MBPS_VIA_SSD2828
+ bool MIPI 4-lane, 513Mbps LCD panel via SSD2828 bridge chip
+ select VIDEO_LCD_SSD2828
+ ---help---
+7.85 768x1024 LCD panels, such as LG LP079X01 or AUO B079XAN01.0
+
endchoice
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index c3fc732..f11b241 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -850,6 +850,9 @@ static void sunxi_mode_set(const struct ctfb_res_modes
*mode,
sunxi_lcdc_tcon0_mode_set(mode);
sunxi_composer_enable();
sunxi_lcdc_enable();
+#ifdef CONFIG_VIDEO_LCD_SSD2828
+ sunxi_ssd2828_init(mode);
+#endif
sunxi_lcdc_backlight_enable();
break;
case sunxi_monitor_vga:
diff --git a/drivers/video/sunxi_lcd_panel.c b/drivers/video/sunxi_lcd_panel.c
index 9ebaff2..cdde639 100644
--- a/drivers/video/sunxi_lcd_panel.c
+++ b/drivers/video/sunxi_lcd_panel.c
@@ -11,6 +11,8 @@
#include asm/arch/gpio.h
#include asm/gpio.h
#include asm/io.h
+#include sunxi_lcd_panel.h
+#include ssd2828.h
#ifdef CONFIG_VIDEO_LCD_PANEL_HITACHI_TX18D42VM
@@ -66,3 +68,39 @@ void sunxi_lcd_panel_hitachi_tx18d42vm_init(void)
}
#endif
+
+#ifdef CONFIG_VIDEO_LCD_SSD2828
+
+int sunxi_ssd2828_init(const struct ctfb_res_modes *mode)
+{
+ struct ssd2828_config cfg = {
+ .csx_pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_SPI_CS),
+ .sck_pin =
[U-Boot] [PATCH 0/8] video: Add support for SSD2828 (parallel LCD to MIPI bridge)
Hello, This patchset adds support for the Solomon Systech SSD2828 bridge chip, which is used to convert parallel LCD interface into MIPI DSI interface and drive MIPI LCD display in some tablets. In particular, this allows to have a working LCD display in my Allwinner A31s based MSI Primo81 tablet. The core of the SSD2828 support code is generic and should work with any SoC (as long as the hardware supports the standard u-boot GPIO API). It also does not have any hardcoded assumptions about the MSI Primo81 display and should be able to drive any MIPI LCD panel (as long as the number of data lanes and the bitrate per lane is provided in the config struct). The code tries to follow the standard power-up sequence described in the SSD2828 datasheet. However it has been tested only on my MSI Primo81 tablet so far. The sunxi specific part includes a small glue code in the sunxi display driver and the defconfig update for the MSI Primo81 tablet. This can be applied after http://lists.denx.de/pipermail/u-boot/2015-January/200753.html 'sunxi: video: Add lvds support' patchset to the 'next' branch in the u-boot-sunxi repository. And here is a bonus picture :-) http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpg Siarhei Siamashka (8): sunxi: axp221: Add ELDO[1-3] support include: Add header file with MIPI DSI constants from the Linux kernel video: Add support for SSD2828 (parallel LCD to MIPI bridge) video: sunxi: Hook up SSD2828 with the sunxi video driver sun6i: Add LCD display support for MSI Primo81 tablet video: ssd2828: Allow using 'pclk' as the PLL clock source video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828 video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id board/sunxi/Kconfig | 60 + board/sunxi/board.c | 1 + configs/MSI_Primo81_defconfig | 9 + drivers/power/Kconfig | 10 + drivers/power/axp221.c | 51 drivers/video/Makefile | 1 + drivers/video/ssd2828.c | 575 drivers/video/ssd2828.h | 128 + drivers/video/sunxi_display.c | 3 + drivers/video/sunxi_lcd_panel.c | 37 +++ drivers/video/sunxi_lcd_panel.h | 3 + include/axp221.h| 9 + include/mipi_display.h | 130 + 13 files changed, 1017 insertions(+) create mode 100644 drivers/video/ssd2828.c create mode 100644 drivers/video/ssd2828.h create mode 100644 include/mipi_display.h -- 2.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8] include: Add header file with MIPI DSI constants from the Linux kernel
It provides some constants for DCS commands, which are needed to
implement support for SSD2828.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
include/mipi_display.h | 130 +
1 file changed, 130 insertions(+)
create mode 100644 include/mipi_display.h
diff --git a/include/mipi_display.h b/include/mipi_display.h
new file mode 100644
index 000..ddcc8ca
--- /dev/null
+++ b/include/mipi_display.h
@@ -0,0 +1,130 @@
+/*
+ * Defines for Mobile Industry Processor Interface (MIPI(R))
+ * Display Working Group standards: DSI, DCS, DBI, DPI
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DISPLAY_H
+#define MIPI_DISPLAY_H
+
+/* MIPI DSI Processor-to-Peripheral transaction types */
+enum {
+ MIPI_DSI_V_SYNC_START = 0x01,
+ MIPI_DSI_V_SYNC_END = 0x11,
+ MIPI_DSI_H_SYNC_START = 0x21,
+ MIPI_DSI_H_SYNC_END = 0x31,
+
+ MIPI_DSI_COLOR_MODE_OFF = 0x02,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 0x03,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 0x04,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+
+ MIPI_DSI_DCS_SHORT_WRITE= 0x05,
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+
+ MIPI_DSI_DCS_READ = 0x06,
+
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+
+ MIPI_DSI_END_OF_TRANSMISSION= 0x08,
+
+ MIPI_DSI_NULL_PACKET= 0x09,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0x0d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0x0e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+/* MIPI DSI Peripheral-to-Processor transaction types */
+enum {
+ MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT= 0x02,
+ MIPI_DSI_RX_END_OF_TRANSMISSION = 0x08,
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE = 0x11,
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE = 0x12,
+ MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE = 0x1a,
+ MIPI_DSI_RX_DCS_LONG_READ_RESPONSE = 0x1c,
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE = 0x21,
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE = 0x22,
+};
+
+/* MIPI DCS commands */
+enum {
+ MIPI_DCS_NOP= 0x00,
+ MIPI_DCS_SOFT_RESET = 0x01,
+ MIPI_DCS_GET_DISPLAY_ID = 0x04,
+ MIPI_DCS_GET_RED_CHANNEL= 0x06,
+ MIPI_DCS_GET_GREEN_CHANNEL = 0x07,
+ MIPI_DCS_GET_BLUE_CHANNEL = 0x08,
+ MIPI_DCS_GET_DISPLAY_STATUS = 0x09,
+ MIPI_DCS_GET_POWER_MODE = 0x0A,
+ MIPI_DCS_GET_ADDRESS_MODE = 0x0B,
+ MIPI_DCS_GET_PIXEL_FORMAT = 0x0C,
+ MIPI_DCS_GET_DISPLAY_MODE = 0x0D,
+ MIPI_DCS_GET_SIGNAL_MODE= 0x0E,
+ MIPI_DCS_GET_DIAGNOSTIC_RESULT = 0x0F,
+ MIPI_DCS_ENTER_SLEEP_MODE = 0x10,
+ MIPI_DCS_EXIT_SLEEP_MODE= 0x11,
+ MIPI_DCS_ENTER_PARTIAL_MODE = 0x12,
+ MIPI_DCS_ENTER_NORMAL_MODE = 0x13,
+ MIPI_DCS_EXIT_INVERT_MODE = 0x20,
+ MIPI_DCS_ENTER_INVERT_MODE = 0x21,
+ MIPI_DCS_SET_GAMMA_CURVE= 0x26,
+ MIPI_DCS_SET_DISPLAY_OFF= 0x28,
+ MIPI_DCS_SET_DISPLAY_ON = 0x29,
+ MIPI_DCS_SET_COLUMN_ADDRESS = 0x2A,
+ MIPI_DCS_SET_PAGE_ADDRESS = 0x2B,
+
Re: [U-Boot] [PATCH 0/8] video: Add support for SSD2828 (parallel LCD to MIPI bridge)
On Fri, 9 Jan 2015 12:01:08 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: Hello, This patchset adds support for the Solomon Systech SSD2828 bridge chip, which is used to convert parallel LCD interface into MIPI DSI interface and drive MIPI LCD display in some tablets. In particular, this allows to have a working LCD display in my Allwinner A31s based MSI Primo81 tablet. The core of the SSD2828 support code is generic and should work with any SoC (as long as the hardware supports the standard u-boot GPIO API). It also does not have any hardcoded assumptions about the MSI Primo81 display and should be able to drive any MIPI LCD panel (as long as the number of data lanes and the bitrate per lane is provided in the config struct). The code tries to follow the standard power-up sequence described in the SSD2828 datasheet. However it has been tested only on my MSI Primo81 tablet so far. The sunxi specific part includes a small glue code in the sunxi display driver and the defconfig update for the MSI Primo81 tablet. This can be applied after http://lists.denx.de/pipermail/u-boot/2015-January/200753.html 'sunxi: video: Add lvds support' patchset to the 'next' branch in the u-boot-sunxi repository. And here is a bonus picture :-) http://linux-sunxi.org/File:MSI_Primo81_and_LCD_support_in_u-boot.jpg Siarhei Siamashka (8): sunxi: axp221: Add ELDO[1-3] support include: Add header file with MIPI DSI constants from the Linux kernel video: Add support for SSD2828 (parallel LCD to MIPI bridge) video: sunxi: Hook up SSD2828 with the sunxi video driver sun6i: Add LCD display support for MSI Primo81 tablet video: ssd2828: Allow using 'pclk' as the PLL clock source video: sunxi: Switch from 'tx_clk' to 'pclk' for SSD2828 video: ssd2828: Use MIPI DCS commands to retrieve the LCD panel id board/sunxi/Kconfig | 60 + board/sunxi/board.c | 1 + configs/MSI_Primo81_defconfig | 9 + drivers/power/Kconfig | 10 + drivers/power/axp221.c | 51 drivers/video/Makefile | 1 + drivers/video/ssd2828.c | 575 drivers/video/ssd2828.h | 128 + drivers/video/sunxi_display.c | 3 + drivers/video/sunxi_lcd_panel.c | 37 +++ drivers/video/sunxi_lcd_panel.h | 3 + include/axp221.h| 9 + include/mipi_display.h | 130 + 13 files changed, 1017 insertions(+) create mode 100644 drivers/video/ssd2828.c create mode 100644 drivers/video/ssd2828.h create mode 100644 include/mipi_display.h Also a short recap of the events from the last days, which led to this patch set: 1. Trying to see what needs to be done to support LCD on the MSI Primo81 tablet, I had a look into the Allwinner android kernel code from the A31 SDK. That code was pushing a small semi-magic blob through SPI, interleaved with a few magic delays. In fact the Allwinner code supports two different LCD panels in this way (768x1024 and another one 1280x800), each panel having its own blob. 2. The most useful part of the Allwinner code was a reference to ssd2828_rst, which gave away the name of the chip. Having the documentation for the hardware is great, because it allows to at least convert the magic numbers into proper named constants. 3. Also it turned out that the MISO pin is actually wired up in the MSI Primo81 tablet, even though the Allwinner android code never uses it and there are no references to this pin in the FEX file. So the SSD2828 hardware can actually talk back, and it was really easy to confirm that the hardware was indeed SSD2828. 4. If the SSD2828 chip can talk back, then maybe the LCD panel can talk back too? The B079XAN01.0 LCD panel datasheet had a teaser notice in the Power ON/OFF Sequence section: HS clock enable to vendor ID reading. 5. Now the question is: how to do this vendor ID reading? In fact MIPI specifies some standard commands exactly for this. So everything is supposedly very easy. Except that trying to use the standard panel id retrieval commands resulted in the panel just responding with a single zero byte. This (mis)led me to believe that there might have been something wrong with the clock speed setting, PHY tuning delays or other things, which could cause some sort of transmission failures in the reverse direction. Especially considering the hints that tLPX(MASTER) and tLPX(SLAVE) must be accurately matched. 6. Been reading a mountain of various MIPI related information about the communication protocol on both the PHY and higher level... 7. As nothing seemed to be obviously wrong, tried to search for the MIPI vendor ID reading methods again. Found hints that the vendors tend to be (ab)using the DCS commands and inventing something of their own. Such as
Re: [U-Boot] [PATCH 2/8] include: Add header file with MIPI DSI constants from the Linux kernel
On Fri, 9 Jan 2015 12:01:10 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: It provides some constants for DCS commands, which are needed to implement support for SSD2828. we usually ask for mentioning the exact kernel version (i.e. the commit ID of the kernel tree the file is taken from) in the commit message when code from Linux kernel is imported into U-Boot. Please add this information here. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bug fixes for v2015.01
On Fri, 2015-01-09 at 13:31 +0900, Masahiro Yamada wrote: Hi Scott, U-Boot v2015.01 will be released in a few days. (scheduled on January 12) I know you are busy, but can you please check NAND fixes? [1] http://patchwork.ozlabs.org/patch/421803/ [2] http://patchwork.ozlabs.org/patch/424123/ [3] http://patchwork.ozlabs.org/patch/424122/ Especially, [1] and [2] are apparent regressions. I believe they should be fixed by the release. Oh sorry, I forgot about these. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Hi Bin, On 8 January 2015 at 22:23, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 January 2015 at 18:34, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass s...@chromium.org wrote: Hi Bin, On 7 January 2015 at 23:18, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass s...@chromium.org wrote: NOT TO APPLY This shows how to enable video for the glacier board, as an example of the emulator working on a VESA-compliant graphics card. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/canyonlands.h | 31 +++ 1 file changed, 31 insertions(+) diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h index 7a1499d..c55e076 100644 --- a/include/configs/canyonlands.h +++ b/include/configs/canyonlands.h @@ -133,6 +133,9 @@ #define CONFIG_SYS_NOR_CS 0 /* NOR chip connected to CSx */ #define CONFIG_SYS_NAND_CS 3 /* NAND chip connected to CSx */ +#define CONFIG_CONSOLE_MUX +#define CONFIG_SYS_CONSOLE_IS_IN_ENV + /*--- * FLASH related *--*/ @@ -359,6 +362,15 @@ ramdisk_addr=fc20\0 \ pciconfighost=1\0 \ pcie_mode=RP:RP\0 \ + eth1addr=00:01:ec:00:f4:9d\0 \ + eth2addr=00:01:ec:00:f4:9e\0 \ + eth3addr=00:01:ec:00:f4:9f\0 \ + ethact=ppc_4xx_eth0\0 \ + ethaddr=00:01:ec:00:f4:9c\0 \ + stderr=serial\0 \ + stdin=serial\0 \ + stdout=serial,vga\0 \ + autoload=n\0 \ #else /* defined(CONFIG_ARCHES) */ #define CONFIG_EXTRA_ENV_SETTINGS \ @@ -675,4 +687,23 @@ } #endif +#define CONFIG_VIDEO + +#ifdef CONFIG_VIDEO +#define CONFIG_BIOSEMU /* x86 bios emulator for vga bios */ +#define CONFIG_VIDEO_VESA +#define VIDEO_IO_OFFSET0xd800 +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS VIDEO_IO_OFFSET +#define CONFIG_VIDEO_SW_CURSOR +#define CONFIG_VIDEO_LOGO +#define CONFIG_CFB_CONSOLE +#define CONFIG_SPLASH_SCREEN +#define CONFIG_VGA_AS_SINGLE_DEVICE +#define CONFIG_CMD_BMP +#endif + +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE +#define CONFIG_FRAMEBUFFER_VESA_MODE 0x114 +#define CONFIG_CMD_TFTPPUT + #endif /* __CONFIG_H */ -- Could you also post the codes that actually run the vga bios on ppc target? I may find another non-x86 board to test. It is all there - I am using the existing support. If you see pci_run_vga_bios() it calls biosemu_run() in the emulation case. Sorry I mean the complete canyonlands codes which calls pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called by chromebook_link. And do you think the int15_handler() required by the biosemu needs to be common? This series is at u-boot-x86/vesa. You can see the call from the vesa video driver, vesa_fb.c. Ah, I see. I can have a try on a non-x86 board. Re int15_handler(), yes I think it should be, but so far I haven't needed it. So what does int15_hander() normally do? I see the vesa_fb.c provided NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c does not pass NULL. See the existing int15_handler() in that file. It allows selection of output device and scaling. I doubt it matters for most boards. I think the ROM access code can be made more common, but I left that task for now. Re your other question I was looking for the VGA enable bit, as I remembered it from years ago. It doesn't seem to be needed for that platforms I have tested. But if it is generally needed we should add it. Which platform do you use? I doubt the VGA enable bit only affects x86 as it opens the A and I/O address decoding which is only applicable on x86. I'm only using glacier and link so far. I suspect there might be something wrong as only one of my video cards works fully on glacier - another once gives a snowy picture. So VGA enable bit is unset on Link as well? That's interesting. When you mentioned two cards, did you insert them simultaneously? I believe only one card will work due to only one card will respond VGA cycles. No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources(). I only used one card at a time. For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is called. I wonder if you haven't enabled the ROM BAR? I initially got the same result as you. Yes, I called pciauto_setup_rom() in my codes. I also verified the expansion ROM address register has bit0 set to 1 which means enabled. And
[U-Boot] unified keyboard queuing?
Hello, I was looking at adding another keyboard driver. So far there is USB keyboard and AT keyboard both with its own queuing code and different incomplete translation table. For one, USB keyboard has some fake arrow key hack which is *not* included in the AT keyboard code afaict. I managed to read a button state on my tablet and send KEY_ENTER which produces some weird character because I was supposed to send '\r' to stdin instead. With 3 ~ 7 buttons it is obviously desirable that users can configure what the buttons send. Both because the number of buttons is limited and because the logical button to physical button mapping may be different on some devices. So far I only saw Vol+ and Vol- swapped, though. I see a few options here 1) hard code the 3 keys commonly used on tablets to do something useful so that people can use Vol+/Vol-/power to browse a menu and select an item. Tablets that have Vol+ and Vol- swapped will just be slightly annoying 2) make this configurable with some sort of options in Kconfig (7 options total for all supported keys). This should result in compiled code the size of (1) 3) make some central keyboard translation so that USB keyboard, AT keyboard and any other keyboard can send same keycodes which are translated to characters sent to stdin the same way. Use keycodes in Kconfig options or possibly read a dtb which specifies the key layout for Linux. Will result in much larger code for small 7-key keyboard but will possibly make keyboards more predictable overall. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] sunxi: axp221: Add ELDO[1-3] support
On Fri, 9 Jan 2015 12:01:09 +0200
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
...
+int axp221_set_eldo2(unsigned int mvolt)
+{
+ int ret;
+ u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
+
+ if (mvolt == 0)
+ return axp221_clrbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO2_EN);
+
+ ret = pmic_bus_write(AXP221_ELDO2_CTRL, cfg);
+ if (ret)
+ return ret;
+
+ return axp221_setbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO2_EN);
+}
+
+int axp221_set_eldo3(unsigned int mvolt)
+{
+ int ret;
+ u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
+
+ if (mvolt == 0)
+ return axp221_clrbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO3_EN);
+
+ ret = pmic_bus_write(AXP221_ELDO3_CTRL, cfg);
+ if (ret)
+ return ret;
+
+ return axp221_setbits(AXP221_OUTPUT_CTRL2,
+ AXP221_OUTPUT_CTRL2_ELDO3_EN);
+}
Can we avoid code duplication here? I.e. only one function
should be sufficient here:
int axp221_set_eldo(int eldo_num, unsigned int mvolt)
{
int ret;
u8 cfg = axp221_mvolt_to_cfg(mvolt, 700, 3300, 100);
u8 addr, bits;
switch (eldo_num) {
case 3:
addr = AXP221_ELDO3_CTRL;
bits = AXP221_OUTPUT_CTRL2_ELDO3_EN;
break;
case 2:
addr = AXP221_ELDO2_CTRL;
bits = AXP221_OUTPUT_CTRL2_ELDO2_EN;
break;
case 1:
default:
addr = AXP221_ELDO1_CTRL;
bits = AXP221_OUTPUT_CTRL2_ELDO1_EN;
break;
}
if (mvolt == 0)
return axp221_clrbits(AXP221_OUTPUT_CTRL2, bits);
ret = pmic_bus_write(addr, cfg);
if (ret)
return ret;
return axp221_setbits(AXP221_OUTPUT_CTRL2, bits);
}
Thanks,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: vf610: fix boot from SD-card
On Thu, Jan 08, 2015 at 06:18:25PM +0100, Stefan Agner wrote: Boot from SD-card (and probably also from NAND) was broken since commit d6d07a9bec (arm: vf610: add NAND support for vf610twr). It looks like the increased size of U-Boot lead to a situation where the boot ROM overwrote its own stack/heap while loading U-Boot from the SD-card to the SRAM. However, U-Boot worked fine when loaded through USB serial loader directly into SRAM. It looks like loading from SD-card uses other stack/heap location then the serial loader (or maybe no stack or heap at all). This fix moves U-Boot to gfxRAM, which is 512kB in size and is not used by the boot ROM nor the SD-card loader of it. Signed-off-by: Stefan Agner ste...@agner.ch Acked-by: Bill Pringlemeir bpringlem...@nbsps.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] sunxi: add Linksprite pcDuino v1/v2 support
Hi,
On 06-01-15 01:09, Zoltan HERPAI wrote:
Add support for a sun4i board built by Linksprite. This addition covers
both v1 and v2 versions. As the board has been working with 408MHz memory
setting in the u-boot-sunxi branch, and has been proven to be running stable
during my tests as well, a respective new DRAM config file is added as well.
Signed-off-by: Zoltan HERPAI wigy...@uid0.hu
Thanks, I've queued this up in u-boot-sunxi for when the merge window opens.
Regards,
Hans
---
board/sunxi/Kconfig|4
board/sunxi/Makefile |1 +
board/sunxi/dram_sun4i_408_1024_iow8.c | 31 +++
configs/Linksprite_pcDuino_defconfig |7 +++
4 files changed, 43 insertions(+)
create mode 100644 board/sunxi/dram_sun4i_408_1024_iow8.c
create mode 100644 configs/Linksprite_pcDuino_defconfig
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 246cd9a..ccf583f 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -99,6 +99,10 @@ config TARGET_IPPO_Q8H_V5
bool IPPO_Q8H_V5
depends on MACH_SUN8I
+config TARGET_PCDUINO
+ bool PCDUINO
+ depends on MACH_SUN4I
+
config TARGET_PCDUINO3
bool PCDUINO3
depends on MACH_SUN7I
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index b84ff9b..c947b09 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_TARGET_MELE_A1000G) +=
dram_sun4i_360_1024_iow8.o
obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o
obj-$(CONFIG_TARGET_MINI_X) += dram_sun4i_360_512.o
obj-$(CONFIG_TARGET_MINI_X_1GB) += dram_sun4i_360_1024_iow16.o
+obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_408_1024_iow8.o
obj-$(CONFIG_TARGET_PCDUINO3) += dram_linksprite_pcduino3.o
obj-$(CONFIG_TARGET_QT840A) += dram_sun7i_384_512_busw16_iow16.o
obj-$(CONFIG_TARGET_R7DONGLE) += dram_r7dongle.o
diff --git a/board/sunxi/dram_sun4i_408_1024_iow8.c
b/board/sunxi/dram_sun4i_408_1024_iow8.c
new file mode 100644
index 000..c6d87d2
--- /dev/null
+++ b/board/sunxi/dram_sun4i_408_1024_iow8.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include common.h
+#include asm/arch/dram.h
+
+static struct dram_para dram_para = {
+ .clock = 408,
+ .type = 3,
+ .rank_num = 1,
+ .density = 2048,
+ .io_width = 8,
+ .bus_width = 32,
+ .cas = 6,
+ .zq = 123,
+ .odt_en = 0,
+ .size = 1024,
+ .tpr0 = 0x30926692,
+ .tpr1 = 0x1090,
+ .tpr2 = 0x1a0c8,
+ .tpr3 = 0,
+ .tpr4 = 0,
+ .tpr5 = 0,
+ .emr1 = 0,
+ .emr2 = 0,
+ .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(dram_para);
+}
diff --git a/configs/Linksprite_pcDuino_defconfig
b/configs/Linksprite_pcDuino_defconfig
new file mode 100644
index 000..f5b0ca9
--- /dev/null
+++ b/configs/Linksprite_pcDuino_defconfig
@@ -0,0 +1,7 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_EMAC,USB_EHCI
+CONFIG_FDTFILE=sun4i-a10-pcduino.dtb
++S:CONFIG_ARM=y
++S:CONFIG_ARCH_SUNXI=y
++S:CONFIG_MACH_SUN4I=y
++S:CONFIG_TARGET_PCDUINO=y
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc: xes: Add maintainer
Add Peter Tyser as the maintainer of Extreme Engineering Solutions products. Signed-off-by: Peter Tyser pty...@xes-inc.com --- board/xes/xpedite517x/MAINTAINERS | 2 +- board/xes/xpedite520x/MAINTAINERS | 2 +- board/xes/xpedite537x/MAINTAINERS | 2 +- board/xes/xpedite550x/MAINTAINERS | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/board/xes/xpedite517x/MAINTAINERS b/board/xes/xpedite517x/MAINTAINERS index 035cb14..26e0acc 100644 --- a/board/xes/xpedite517x/MAINTAINERS +++ b/board/xes/xpedite517x/MAINTAINERS @@ -1,5 +1,5 @@ XPEDITE517X BOARD -#M:- +M: Peter Tyser pty...@xes-inc.com S: Maintained F: board/xes/xpedite517x/ F: include/configs/xpedite517x.h diff --git a/board/xes/xpedite520x/MAINTAINERS b/board/xes/xpedite520x/MAINTAINERS index 2fd4ac0..f7bd437 100644 --- a/board/xes/xpedite520x/MAINTAINERS +++ b/board/xes/xpedite520x/MAINTAINERS @@ -1,5 +1,5 @@ XPEDITE520X BOARD -#M:- +M: Peter Tyser pty...@xes-inc.com S: Maintained F: board/xes/xpedite520x/ F: include/configs/xpedite520x.h diff --git a/board/xes/xpedite537x/MAINTAINERS b/board/xes/xpedite537x/MAINTAINERS index 45a420d..b6123ac 100644 --- a/board/xes/xpedite537x/MAINTAINERS +++ b/board/xes/xpedite537x/MAINTAINERS @@ -1,5 +1,5 @@ XPEDITE537X BOARD -#M:- +M: Peter Tyser pty...@xes-inc.com S: Maintained F: board/xes/xpedite537x/ F: include/configs/xpedite537x.h diff --git a/board/xes/xpedite550x/MAINTAINERS b/board/xes/xpedite550x/MAINTAINERS index b22f0e6..017f368 100644 --- a/board/xes/xpedite550x/MAINTAINERS +++ b/board/xes/xpedite550x/MAINTAINERS @@ -1,5 +1,5 @@ XPEDITE550X BOARD -#M:- +M: Peter Tyser pty...@xes-inc.com S: Maintained F: board/xes/xpedite550x/ F: include/configs/xpedite550x.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc: xes: Convert to generic board
From: John Schmoller jschmol...@xes-inc.com Convert Extreme Engineering Solutions products to use generic board support. Signed-off-by: John Schmoller jschmol...@xes-inc.com Signed-off-by: Peter Tyser pty...@xes-inc.com --- include/configs/xpedite1000.h | 2 ++ include/configs/xpedite517x.h | 2 ++ include/configs/xpedite520x.h | 2 ++ include/configs/xpedite537x.h | 2 ++ include/configs/xpedite550x.h | 2 ++ 5 files changed, 10 insertions(+) diff --git a/include/configs/xpedite1000.h b/include/configs/xpedite1000.h index ca322b2..15c9176 100644 --- a/include/configs/xpedite1000.h +++ b/include/configs/xpedite1000.h @@ -22,6 +22,8 @@ #define CONFIG_440GX 1 /* 440 GX */ #define CONFIG_BOARD_EARLY_INIT_F 1/* Call board_pre_init */ #define CONFIG_SYS_CLK_FREQ/* external freq to pll */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFIG_SYS_TEXT_BASE0xFFF8 diff --git a/include/configs/xpedite517x.h b/include/configs/xpedite517x.h index cbf4b8e..3414230 100644 --- a/include/configs/xpedite517x.h +++ b/include/configs/xpedite517x.h @@ -23,6 +23,8 @@ #define CONFIG_BAT_RW 1 /* Use common BAT rw code */ #define CONFIG_HIGH_BATS 1 /* High BATs supported and enabled */ #define CONFIG_ALTIVEC 1 +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFIG_SYS_TEXT_BASE0xfff0 diff --git a/include/configs/xpedite520x.h b/include/configs/xpedite520x.h index baa3039..f966a8a 100644 --- a/include/configs/xpedite520x.h +++ b/include/configs/xpedite520x.h @@ -21,6 +21,8 @@ #define CONFIG_SYS_BOARD_NAME XPedite5200 #define CONFIG_SYS_FORM_PMC_XMC1 #define CONFIG_BOARD_EARLY_INIT_R /* Call board_pre_init */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0xfff8 diff --git a/include/configs/xpedite537x.h b/include/configs/xpedite537x.h index bdf5576..d6b6143 100644 --- a/include/configs/xpedite537x.h +++ b/include/configs/xpedite537x.h @@ -21,6 +21,8 @@ #define CONFIG_SYS_BOARD_NAME XPedite5370 #define CONFIG_SYS_FORM_3U_VPX 1 #define CONFIG_BOARD_EARLY_INIT_R /* Call board_pre_init */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0xfff8 diff --git a/include/configs/xpedite550x.h b/include/configs/xpedite550x.h index 0b24f3e..4536b94 100644 --- a/include/configs/xpedite550x.h +++ b/include/configs/xpedite550x.h @@ -22,6 +22,8 @@ #define CONFIG_SYS_FORM_PMC_XMC1 #define CONFIG_PRPMC_PCI_ALIAS pci0 /* Processor PMC interface on pci0 */ #define CONFIG_BOARD_EARLY_INIT_R /* Call board_pre_init */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0xfff8 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] common: mark commands as default to match config_cmd_default.h
Hi Masahiro-san, On Tue, 2015-01-06 at 00:34 +0900, Masahiro YAMADA wrote: Hi Alexey, 2015-01-03 22:20 GMT+09:00 Alexey Brodkin alexey.brod...@synopsys.com: Now when we may select commands via menuconfig let's adjust default settings with config_cmd_default.h. As the next step we may get rid of config_cmd_default.h inclusion in include/configs/*.h and config_cmd_default.h itself. Thanks for working on this, but I think this patch changes the behavior. Some boards include config_cmd_default.h and then undefine unnecessary commands. For example, include/configs/snapper9260.h #include config_cmd_default.h #undef CONFIG_CMD_BDI #undef CONFIG_CMD_FPGA #undef CONFIG_CMD_IMI #undef CONFIG_CMD_IMLS #undef CONFIG_CMD_LOADS #undef CONFIG_CMD_SOURCE If you set the default value to y in Kconfig, it cannot be undef'ed by C-headers. That's true. But anyway at some point we'll need to switch selection of commands in Kconfig, right? Probably I'm missing details of our Kconfig migration plan if one exists. Then I'd like to get a reference to the plan so I'm not attempting to do things that are already scheduled and could be even in a process of implementation. Otherwise if there's no current plan for Kconfig migration we may start discussion on how to deal with commands in particular. The point is commands are low-hanging fruits in terms of Kconfig migration - there're no extra options and tweaks, once all commands are added in Kconfig (essentially with dependencies etc) we may clean all board headers. The only real problem here is amount of work - lots of headers/defconfigs to patch. But still this is doable. config CMD_BDI bool bdinfo + default y help Print board info This change enables CMD_BDI for all the boards. Please notice the following boards do not want to compile this command. ./include/configs/dbau1x00.h:#undef CONFIG_CMD_BDI @@ -193,6 +204,7 @@ config CMD_USB config CMD_FPGA bool fpga + default y help FPGA support. Moreover, I doubt some of default commands in config_cmd_default.h (I have used only some of commands in config_cmd_default.h) For example, it seems weird to enable CONFIG_CMD_FPGA by default. I do not think most of boards have FPGA. That's a separate topic. I do agree that CMD_FPGA makes not much sense for most of boards, as well as some others. And I think during migration process of commands to Kconfig it's a good time to reconsider default commands. I will highly appreciate input on both topics from others so we'll do some progress here and will make sure all parties are happy. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/10] arc: introduce separate section for interrupt vector table
From: Igor Guryanov gurya...@synopsys.com
Even though existing implementation works fine in preparation to
submission of ARCv2 architecture we need this change.
In case of ARCv2 interrupt vector table consists of just addresses
of corresponding handlers. And if those addresses will be in .text
section then assembler will encode them as everything in .text section
as middle-endian and then on real execution CPU will read swapped
addresses and will jump into the wild.
Once introduced new section is situated so .text section remains the
first which allows us to use common linker option for linking everything
to a specified CONFIG_SYS_TEXT_BASE.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Signed-off-by: Igor Guryanov gurya...@synopsys.com
---
arch/arc/Makefile | 2 --
arch/arc/cpu/arc700/Makefile| 3 +--
arch/arc/cpu/arc700/start.S | 49 +
arch/arc/cpu/arc700/u-boot.lds | 15 -
arch/arc/include/asm/sections.h | 2 ++
arch/arc/lib/relocate.c | 4 ++--
arch/arc/lib/sections.c | 2 ++
7 files changed, 46 insertions(+), 31 deletions(-)
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index de25cc9..374432d 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -2,7 +2,5 @@
# SPDX-License-Identifier: GPL-2.0+
#
-head-y := arch/arc/cpu/$(CPU)/start.o
-
libs-y += arch/arc/cpu/$(CPU)/
libs-y += arch/arc/lib/
diff --git a/arch/arc/cpu/arc700/Makefile b/arch/arc/cpu/arc700/Makefile
index cdc5002..021e3a2 100644
--- a/arch/arc/cpu/arc700/Makefile
+++ b/arch/arc/cpu/arc700/Makefile
@@ -4,10 +4,9 @@
# SPDX-License-Identifier: GPL-2.0+
#
-extra-y+= start.o
-
obj-y += cache.o
obj-y += cpu.o
obj-y += interrupts.o
obj-y += reset.o
+obj-y += start.o
obj-y += timer.o
diff --git a/arch/arc/cpu/arc700/start.S b/arch/arc/cpu/arc700/start.S
index 2318282..01cfba4 100644
--- a/arch/arc/cpu/arc700/start.S
+++ b/arch/arc/cpu/arc700/start.S
@@ -88,11 +88,11 @@
#endif
.endm
+.section .ivt, ax,@progbits
.align 4
-.globl _start
-_start:
+_ivt:
/* Critical system events */
- j reset /* 0 - 0x000 */
+ j _start /* 0 - 0x000 */
j memory_error/* 1 - 0x008 */
j instruction_error /* 2 - 0x010 */
@@ -110,6 +110,28 @@ _start:
j EV_Trap /* 0x128, Trap exception (0x25) */
j EV_Extension/* 0x130, Extn Intruction Excp (0x26) */
+.text
+.globl _start
+_start:
+ /* Setup interrupt vector base that matches __text_start */
+ sr __ivt_start, [ARC_AUX_INTR_VEC_BASE]
+
+ /* Setup stack pointer */
+ mov %sp, CONFIG_SYS_INIT_SP_ADDR
+ mov %fp, %sp
+
+ /* Clear bss */
+ mov %r0, __bss_start
+ mov %r1, __bss_end
+
+clear_bss:
+ st.ab 0, [%r0, 4]
+ brlt%r0, %r1, clear_bss
+
+ /* Zero the one and only argument of board_init_f */
+ mov_s %r0, 0
+ j board_init_f
+
memory_error:
SAVE_ALL_SYS
SAVE_EXCEPTION_SOURCE
@@ -164,27 +186,6 @@ EV_Extension:
mov %r0, %sp
j do_extension
-
-reset:
- /* Setup interrupt vector base that matches __text_start */
- sr __text_start, [ARC_AUX_INTR_VEC_BASE]
-
- /* Setup stack pointer */
- mov %sp, CONFIG_SYS_INIT_SP_ADDR
- mov %fp, %sp
-
- /* Clear bss */
- mov %r0, __bss_start
- mov %r1, __bss_end
-
-clear_bss:
- st.ab 0, [%r0, 4]
- brlt%r0, %r1, clear_bss
-
- /* Zero the one and only argument of board_init_f */
- mov_s %r0, 0
- j board_init_f
-
/*
* void relocate_code (addr_sp, gd, addr_moni)
*
diff --git a/arch/arc/cpu/arc700/u-boot.lds b/arch/arc/cpu/arc700/u-boot.lds
index 2d01b21..e548dc3 100644
--- a/arch/arc/cpu/arc700/u-boot.lds
+++ b/arch/arc/cpu/arc700/u-boot.lds
@@ -13,7 +13,6 @@ SECTIONS
.text : {
*(.__text_start)
*(.__image_copy_start)
- CPUDIR/start.o (.text*)
*(.text*)
}
@@ -23,6 +22,20 @@ SECTIONS
*(.__text_end)
}
+ . = ALIGN(1024);
+ .ivt_start : {
+ *(.__ivt_start)
+ }
+
+ .ivt :
+ {
+ *(.ivt)
+ }
+
+ .ivt_end : {
+ *(.__ivt_end)
+ }
+
. = ALIGN(4);
.rodata : {
*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
diff --git a/arch/arc/include/asm/sections.h b/arch/arc/include/asm/sections.h
index 18484a1..2a7a987 100644
--- a/arch/arc/include/asm/sections.h
+++ b/arch/arc/include/asm/sections.h
@@ -10,5 +10,7 @@
#include asm-generic/sections.h
extern ulong __text_end;
+extern ulong __ivt_start;
+extern ulong __ivt_end;
#endif /* __ASM_ARC_SECTIONS_H */
diff --git a/arch/arc/lib/relocate.c
[U-Boot] [PATCH 08/10] arc: move common sources in library
reset.c and cpu.c have no architecture-specific code at all.
Others are applicable to either ARC CPU.
This change is a preparation to submission of ARCv2 architecture port.
Even though ARCv1 and ARCv2 ISAs are not binary compatible most of
built-in modules still have the same programming model - AUX registers
are mapped in the same addresses and hold the same data (new featues
extend existing ones).
So only low-level assembly code (start-up, interrupt handlers) is left
as CPU(actually ISA)-specific. This significantyl simplifies maintenance
of multiple CPUs/ISAs.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Signed-off-by: Igor Guryanov gurya...@synopsys.com
---
arch/arc/cpu/arc700/Makefile | 7 +--
arch/arc/lib/Makefile | 6 ++
arch/arc/{cpu/arc700 = lib}/cache.c | 0
arch/arc/{cpu/arc700 = lib}/cpu.c| 0
arch/arc/{cpu/arc700 = lib}/interrupts.c | 0
arch/arc/{cpu/arc700 = lib}/reset.c | 0
arch/arc/{cpu/arc700 = lib}/timer.c | 0
7 files changed, 7 insertions(+), 6 deletions(-)
rename arch/arc/{cpu/arc700 = lib}/cache.c (100%)
rename arch/arc/{cpu/arc700 = lib}/cpu.c (100%)
rename arch/arc/{cpu/arc700 = lib}/interrupts.c (100%)
rename arch/arc/{cpu/arc700 = lib}/reset.c (100%)
rename arch/arc/{cpu/arc700 = lib}/timer.c (100%)
diff --git a/arch/arc/cpu/arc700/Makefile b/arch/arc/cpu/arc700/Makefile
index 021e3a2..3704ebe 100644
--- a/arch/arc/cpu/arc700/Makefile
+++ b/arch/arc/cpu/arc700/Makefile
@@ -4,9 +4,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y += cache.o
-obj-y += cpu.o
-obj-y += interrupts.o
-obj-y += reset.o
-obj-y += start.o
-obj-y += timer.o
+obj-y += start.o
diff --git a/arch/arc/lib/Makefile b/arch/arc/lib/Makefile
index 7675f85..bae4419 100644
--- a/arch/arc/lib/Makefile
+++ b/arch/arc/lib/Makefile
@@ -4,6 +4,9 @@
# SPDX-License-Identifier: GPL-2.0+
#
+obj-y += cache.o
+obj-y += cpu.o
+obj-y += interrupts.o
obj-y += sections.o
obj-y += relocate.o
obj-y += strchr-700.o
@@ -13,4 +16,7 @@ obj-y += strlen.o
obj-y += memcmp.o
obj-y += memcpy-700.o
obj-y += memset.o
+obj-y += reset.o
+obj-y += timer.o
+
obj-$(CONFIG_CMD_BOOTM) += bootm.o
diff --git a/arch/arc/cpu/arc700/cache.c b/arch/arc/lib/cache.c
similarity index 100%
rename from arch/arc/cpu/arc700/cache.c
rename to arch/arc/lib/cache.c
diff --git a/arch/arc/cpu/arc700/cpu.c b/arch/arc/lib/cpu.c
similarity index 100%
rename from arch/arc/cpu/arc700/cpu.c
rename to arch/arc/lib/cpu.c
diff --git a/arch/arc/cpu/arc700/interrupts.c b/arch/arc/lib/interrupts.c
similarity index 100%
rename from arch/arc/cpu/arc700/interrupts.c
rename to arch/arc/lib/interrupts.c
diff --git a/arch/arc/cpu/arc700/reset.c b/arch/arc/lib/reset.c
similarity index 100%
rename from arch/arc/cpu/arc700/reset.c
rename to arch/arc/lib/reset.c
diff --git a/arch/arc/cpu/arc700/timer.c b/arch/arc/lib/timer.c
similarity index 100%
rename from arch/arc/cpu/arc700/timer.c
rename to arch/arc/lib/timer.c
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/10] arc: add ECR (exception cause register) output
From: Igor Guryanov gurya...@synopsys.com
Exception cause register (ECR) contains value that describes a reason
for exception that has happened. This helps a lot to figure-out what
went wrong.
Now we print this register contents when dumping registers.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Signed-off-by: Igor Guryanov gurya...@synopsys.com
---
arch/arc/cpu/arc700/interrupts.c | 1 +
arch/arc/cpu/arc700/start.S | 10 ++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arc/cpu/arc700/interrupts.c b/arch/arc/cpu/arc700/interrupts.c
index d93a6eb..7dde74b 100644
--- a/arch/arc/cpu/arc700/interrupts.c
+++ b/arch/arc/cpu/arc700/interrupts.c
@@ -61,6 +61,7 @@ static void print_reg_file(long *reg_rev, int start_num)
void show_regs(struct pt_regs *regs)
{
+ printf(ECR:\t0x%08lx\n, regs-ecr);
printf(RET:\t0x%08lx\nBLINK:\t0x%08lx\nSTAT32:\t0x%08lx\n,
regs-ret, regs-blink, regs-status32);
printf(GP: 0x%08lx\t r25: 0x%08lx\t\n, regs-r26, regs-r25);
diff --git a/arch/arc/cpu/arc700/start.S b/arch/arc/cpu/arc700/start.S
index 563513b..4d505bf 100644
--- a/arch/arc/cpu/arc700/start.S
+++ b/arch/arc/cpu/arc700/start.S
@@ -57,11 +57,13 @@
.endm
.macro SAVE_ALL_SYS
-
+ /* saving %r0 to reg-r0 in advance since we read %ecr into it */
+ st %r0, [%sp, -8]
+ lr %r0, [%ecr] /* all stack addressing is manual so far */
st %r0, [%sp]
- lr %r0, [%ecr]
- st %r0, [%sp, 8] /* ECR */
- st %sp, [%sp, 4]
+ st %sp, [%sp, -4]
+ /* now move %sp to reg-r0 position so we can do push automatically */
+ sub %sp, %sp, 8
SAVE_R1_TO_R24
PUSH%r25
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] arc: interrupts - fix mask setup
From: Igor Guryanov gurya...@synopsys.com
To disable interrupts we need to reset corresponding flags in STATUS32
register. For this we need to OR flags for interrupts level1 and level2
and then AND with current value in STATUS32.
Before that implementation was incorrect.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Signed-off-by: Igor Guryanov gurya...@synopsys.com
---
arch/arc/cpu/arc700/interrupts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/cpu/arc700/interrupts.c b/arch/arc/cpu/arc700/interrupts.c
index 7dde74b..d7cab3b 100644
--- a/arch/arc/cpu/arc700/interrupts.c
+++ b/arch/arc/cpu/arc700/interrupts.c
@@ -23,7 +23,7 @@ int interrupt_init(void)
int disable_interrupts(void)
{
int status = read_aux_reg(ARC_AUX_STATUS32);
- int state = (status | E1_MASK | E2_MASK) ? 1 : 0;
+ int state = (status (E1_MASK | E2_MASK)) ? 1 : 0;
status = ~(E1_MASK | E2_MASK);
/* STATUS32 register is updated indirectly with FLAG instruction */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10] arc: add dependences on MMU presence
Depending on MMU presence in CPU there're differences in HW behavior. For example address of instruction that caused exception is put in ECR register if MMU exists and in ERET register otherwise. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Signed-off-by: Igor Guryanov gurya...@synopsys.com --- arch/arc/config.mk | 4 arch/arc/cpu/arc700/start.S | 18 ++ 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/arch/arc/config.mk b/arch/arc/config.mk index e408800..5321987 100644 --- a/arch/arc/config.mk +++ b/arch/arc/config.mk @@ -21,6 +21,10 @@ ifeq ($(CROSS_COMPILE),) CROSS_COMPILE := $(ARC_CROSS_COMPILE) endif +ifdef CONFIG_ARC_MMU_VER +CONFIG_MMU = 1 +endif + PLATFORM_CPPFLAGS += -ffixed-r25 -D__ARC__ -gdwarf-2 # Needed for relocation diff --git a/arch/arc/cpu/arc700/start.S b/arch/arc/cpu/arc700/start.S index 4d505bf..2318282 100644 --- a/arch/arc/cpu/arc700/start.S +++ b/arch/arc/cpu/arc700/start.S @@ -78,6 +78,16 @@ PUSHAX %erbta .endm +.macro SAVE_EXCEPTION_SOURCE +#ifdef CONFIG_MMU + /* If MMU exists exception faulting address is loaded in EFA reg */ + lr %r0, [%efa] +#else + /* Otherwise in ERET (exception return) reg */ + lr %r0, [%eret] +#endif +.endm + .align 4 .globl _start _start: @@ -102,13 +112,13 @@ _start: memory_error: SAVE_ALL_SYS - lr %r0, [%efa] + SAVE_EXCEPTION_SOURCE mov %r1, %sp j do_memory_error instruction_error: SAVE_ALL_SYS - lr %r0, [%efa] + SAVE_EXCEPTION_SOURCE mov %r1, %sp j do_instruction_error @@ -119,7 +129,7 @@ interrupt_handler: EV_MachineCheck: SAVE_ALL_SYS - lr %r0, [%efa] + SAVE_EXCEPTION_SOURCE mov %r1, %sp j do_machine_check_fault @@ -135,7 +145,7 @@ EV_TLBMissD: EV_TLBProtV: SAVE_ALL_SYS - lr %r0, [%efa] + SAVE_EXCEPTION_SOURCE mov %r1, %sp j do_tlb_prot_violation -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10] board/synopsys: remove selection of CPU from the board
Both ARCangel4 and AXS10x are FPGA-based boards so they may have different CPUs. For now we have only 1 option (ARC700) and we define this as default in arch Kconfig. Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- arch/arc/Kconfig | 3 +++ board/synopsys/Kconfig| 6 -- board/synopsys/axs101/Kconfig | 3 --- 3 files changed, 3 insertions(+), 9 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index d3ef58b..6a77b8f 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -4,6 +4,9 @@ menu ARC architecture config SYS_ARCH default arc +config SYS_CPU + default arc700 + choice prompt Target select diff --git a/board/synopsys/Kconfig b/board/synopsys/Kconfig index a54d3df..f614f88 100644 --- a/board/synopsys/Kconfig +++ b/board/synopsys/Kconfig @@ -1,8 +1,5 @@ if TARGET_ARCANGEL4 -config SYS_CPU - default arc700 - config SYS_VENDOR default synopsys @@ -13,9 +10,6 @@ endif if TARGET_ARCANGEL4_BE -config SYS_CPU - default arc700 - config SYS_VENDOR default synopsys diff --git a/board/synopsys/axs101/Kconfig b/board/synopsys/axs101/Kconfig index 8448265..79e5400 100644 --- a/board/synopsys/axs101/Kconfig +++ b/board/synopsys/axs101/Kconfig @@ -1,8 +1,5 @@ if TARGET_AXS101 -config SYS_CPU - default arc700 - config SYS_BOARD default axs101 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/10] arc: relocate - minor refactoring and clean-up
* use better symbols for relocatable region boundaries
(__image_copy_start instead of CONFIG_SYS_TEXT_BASE)
* remove useless debug messages because they will only show up in case
of both problem (when normal if branch won't be taken) and DEBUG take
place which is pretty rare situation.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
---
arch/arc/include/asm/sections.h | 1 +
arch/arc/lib/relocate.c | 15 ---
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arc/include/asm/sections.h b/arch/arc/include/asm/sections.h
index 2a7a987..b8f2a85 100644
--- a/arch/arc/include/asm/sections.h
+++ b/arch/arc/include/asm/sections.h
@@ -12,5 +12,6 @@
extern ulong __text_end;
extern ulong __ivt_start;
extern ulong __ivt_end;
+extern ulong __image_copy_start;
#endif /* __ASM_ARC_SECTIONS_H */
diff --git a/arch/arc/lib/relocate.c b/arch/arc/lib/relocate.c
index 5618b6a..7797782 100644
--- a/arch/arc/lib/relocate.c
+++ b/arch/arc/lib/relocate.c
@@ -26,7 +26,7 @@ int do_elf_reloc_fixups(void)
offset_ptr_rom = (Elf32_Addr *)re_src-r_offset;
/* Check that the location of the relocation is in .text */
- if (offset_ptr_rom = (Elf32_Addr *)CONFIG_SYS_TEXT_BASE
+ if (offset_ptr_rom = (Elf32_Addr *)__image_copy_start
offset_ptr_rom last_offset) {
unsigned int val;
/* Switch to the in-RAM version */
@@ -48,9 +48,9 @@ int do_elf_reloc_fixups(void)
val = (val 16) | (val 16);
#endif
- /* Check that the target points into .text */
- if (val = CONFIG_SYS_TEXT_BASE val =
- (unsigned int)__bss_end) {
+ /* Check that the target points into executable */
+ if (val = (unsigned int)__image_copy_start val =
+ (unsigned int)__image_copy_end) {
val += gd-reloc_off;
#ifdef __LITTLE_ENDIAN__
/* If location in .text section swap value */
@@ -59,14 +59,7 @@ int do_elf_reloc_fixups(void)
val = (val 16) | (val 16);
#endif
memcpy(offset_ptr_ram, val, sizeof(int));
- } else {
- debug( %p: rom reloc %x, ram %p, value %x,
limit %x\n,
- re_src, re_src-r_offset, offset_ptr_ram,
- val, (unsigned int)__bss_end);
}
- } else {
- debug( %p: rom reloc %x, last %p\n, re_src,
- re_src-r_offset, last_offset);
}
last_offset = offset_ptr_rom;
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/10] arc: move linker script in arch/arc/cpu folder
This way we'll be able to use the same one script for either ARC CPU.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
---
arch/arc/cpu/{arc700 = }/u-boot.lds | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename arch/arc/cpu/{arc700 = }/u-boot.lds (100%)
diff --git a/arch/arc/cpu/arc700/u-boot.lds b/arch/arc/cpu/u-boot.lds
similarity index 100%
rename from arch/arc/cpu/arc700/u-boot.lds
rename to arch/arc/cpu/u-boot.lds
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] arc: check caches existence before use
From: Igor Guryanov gurya...@synopsys.com
Some cache operations ({i|d}cache_{enable|disable|status} or
flush_dcache_all) are built and used even if CONFIG_SYS_{I|D}CACHE_OFF
is set.
This is required for force disable of caches on early boot.
What if something was executed before U-boot and enabled caches
(low-level bootloaders, previously run kernel etc.)?
But if CPU doesn't really have caches any attempt to access
cache-related AUX registers triggers instruction error exception.
So for convenience we'll try to avoid exceptions by checking if CPU
actually has caches (we check separately data and instruction cache
existence) at all.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Signed-off-by: Igor Guryanov gurya...@synopsys.com
---
arch/arc/cpu/arc700/cache.c| 29 +
arch/arc/include/asm/arcregs.h | 2 ++
2 files changed, 31 insertions(+)
diff --git a/arch/arc/cpu/arc700/cache.c b/arch/arc/cpu/arc700/cache.c
index 39d522d..fa19a13 100644
--- a/arch/arc/cpu/arc700/cache.c
+++ b/arch/arc/cpu/arc700/cache.c
@@ -14,21 +14,34 @@
#define DC_CTRL_CACHE_DISABLE (1 0)
#define DC_CTRL_INV_MODE_FLUSH (1 6)
#define DC_CTRL_FLUSH_STATUS (1 8)
+#define CACHE_VER_NUM_MASK 0xF
int icache_status(void)
{
+ /* If no cache in CPU exit immediately */
+ if (!(read_aux_reg(ARC_BCR_IC_BUILD) CACHE_VER_NUM_MASK))
+ return 0;
+
return (read_aux_reg(ARC_AUX_IC_CTRL) IC_CTRL_CACHE_DISABLE) !=
IC_CTRL_CACHE_DISABLE;
}
void icache_enable(void)
{
+ /* If no cache in CPU exit immediately */
+ if (!(read_aux_reg(ARC_BCR_IC_BUILD) CACHE_VER_NUM_MASK))
+ return;
+
write_aux_reg(ARC_AUX_IC_CTRL, read_aux_reg(ARC_AUX_IC_CTRL)
~IC_CTRL_CACHE_DISABLE);
}
void icache_disable(void)
{
+ /* If no cache in CPU exit immediately */
+ if (!(read_aux_reg(ARC_BCR_IC_BUILD) CACHE_VER_NUM_MASK))
+ return;
+
write_aux_reg(ARC_AUX_IC_CTRL, read_aux_reg(ARC_AUX_IC_CTRL) |
IC_CTRL_CACHE_DISABLE);
}
@@ -43,24 +56,40 @@ void invalidate_icache_all(void)
int dcache_status(void)
{
+ /* If no cache in CPU exit immediately */
+ if (!(read_aux_reg(ARC_BCR_DC_BUILD) CACHE_VER_NUM_MASK))
+ return 0;
+
return (read_aux_reg(ARC_AUX_DC_CTRL) DC_CTRL_CACHE_DISABLE) !=
DC_CTRL_CACHE_DISABLE;
}
void dcache_enable(void)
{
+ /* If no cache in CPU exit immediately */
+ if (!(read_aux_reg(ARC_BCR_DC_BUILD) CACHE_VER_NUM_MASK))
+ return;
+
write_aux_reg(ARC_AUX_DC_CTRL, read_aux_reg(ARC_AUX_DC_CTRL)
~(DC_CTRL_INV_MODE_FLUSH | DC_CTRL_CACHE_DISABLE));
}
void dcache_disable(void)
{
+ /* If no cache in CPU exit immediately */
+ if (!(read_aux_reg(ARC_BCR_DC_BUILD) CACHE_VER_NUM_MASK))
+ return;
+
write_aux_reg(ARC_AUX_DC_CTRL, read_aux_reg(ARC_AUX_DC_CTRL) |
DC_CTRL_CACHE_DISABLE);
}
void flush_dcache_all(void)
{
+ /* If no cache in CPU exit immediately */
+ if (!(read_aux_reg(ARC_BCR_DC_BUILD) CACHE_VER_NUM_MASK))
+ return;
+
/* Do flush of entire cache */
write_aux_reg(ARC_AUX_DC_FLSH, 1);
diff --git a/arch/arc/include/asm/arcregs.h b/arch/arc/include/asm/arcregs.h
index 5d48d11..8ace87f 100644
--- a/arch/arc/include/asm/arcregs.h
+++ b/arch/arc/include/asm/arcregs.h
@@ -24,6 +24,7 @@
#if (CONFIG_ARC_MMU_VER 2)
#define ARC_AUX_IC_PTAG0x1E
#endif
+#define ARC_BCR_IC_BUILD 0x77
/* Timer related auxiliary registers */
#define ARC_AUX_TIMER0_CNT 0x21/* Timer 0 count */
@@ -42,6 +43,7 @@
#if (CONFIG_ARC_MMU_VER 2)
#define ARC_AUX_DC_PTAG0x5C
#endif
+#define ARC_BCR_DC_BUILD 0x72
#ifndef __ASSEMBLY__
/* Accessors for auxiliary registers */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/10] ARC: updates, fixes preparation to ARCv2 submission
This series is focused on fixes and clean-up in ARC-related code.
The most visible changes are:
1. Move lots of sources in lib folder because they are arch-independent
2. Rename (generalize) arc700 - arcv1 because we'll have another type of
ARC CPUs soon as well as more flavours of existing family
3. Interrupt vector table is separated in its own section which is required
for upcoing submission of ARCv2 support
Also some minor fixes were done to existing code.
Alexey Brodkin (6):
arc: add dependences on MMU presence
arc: relocate - minor refactoring and clean-up
arc: move linker script in arch/arc/cpu folder
arc: move common sources in library
board/synopsys: remove selection of CPU from the board
arc: rename arc700 in arcv1
Igor Guryanov (4):
arc: check caches existence before use
arc: add ECR (exception cause register) output
arc: interrupts - fix mask setup
arc: introduce separate section for interrupt vector table
arch/arc/Kconfig | 3 +
arch/arc/Makefile | 2 -
arch/arc/config.mk| 4 ++
arch/arc/cpu/arc700/Makefile | 13
arch/arc/cpu/{arc700/config.mk = arcv1/Makefile} | 2 +-
arch/arc/cpu/{arc700 = arcv1}/config.mk | 0
arch/arc/cpu/{arc700 = arcv1}/start.S| 77 +--
arch/arc/cpu/{arc700 = }/u-boot.lds | 15 -
arch/arc/include/asm/arcregs.h| 2 +
arch/arc/include/asm/sections.h | 3 +
arch/arc/lib/Makefile | 6 ++
arch/arc/{cpu/arc700 = lib}/cache.c | 29 +
arch/arc/{cpu/arc700 = lib}/cpu.c| 0
arch/arc/{cpu/arc700 = lib}/interrupts.c | 3 +-
arch/arc/lib/relocate.c | 19 ++
arch/arc/{cpu/arc700 = lib}/reset.c | 0
arch/arc/lib/sections.c | 2 +
arch/arc/{cpu/arc700 = lib}/timer.c | 0
board/synopsys/Kconfig| 6 --
board/synopsys/axs101/Kconfig | 3 -
20 files changed, 117 insertions(+), 72 deletions(-)
delete mode 100644 arch/arc/cpu/arc700/Makefile
copy arch/arc/cpu/{arc700/config.mk = arcv1/Makefile} (80%)
rename arch/arc/cpu/{arc700 = arcv1}/config.mk (100%)
rename arch/arc/cpu/{arc700 = arcv1}/start.S (87%)
rename arch/arc/cpu/{arc700 = }/u-boot.lds (88%)
rename arch/arc/{cpu/arc700 = lib}/cache.c (79%)
rename arch/arc/{cpu/arc700 = lib}/cpu.c (100%)
rename arch/arc/{cpu/arc700 = lib}/interrupts.c (97%)
rename arch/arc/{cpu/arc700 = lib}/reset.c (100%)
rename arch/arc/{cpu/arc700 = lib}/timer.c (100%)
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/10] arc: rename arc700 in arcv1
As a preparation to ARCv2 port submission we rename arc700 folder to
arcv1 which stands for ARCv1 ISA also known as ARCompact.
This will allow us to add more flavours of binary-compatible ARCv1 CPUs
like ARC600 if needed later on and all required ARCv2 CPUs (which are
binary incompatible with ARCv1) in arcv2 folder in subsequent commits.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Signed-off-by: Igor Guryanov gurya...@synopsys.com
---
arch/arc/Kconfig | 2 +-
arch/arc/cpu/{arc700 = arcv1}/Makefile | 0
arch/arc/cpu/{arc700 = arcv1}/config.mk | 0
arch/arc/cpu/{arc700 = arcv1}/start.S | 0
4 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arc/cpu/{arc700 = arcv1}/Makefile (100%)
rename arch/arc/cpu/{arc700 = arcv1}/config.mk (100%)
rename arch/arc/cpu/{arc700 = arcv1}/start.S (100%)
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 6a77b8f..c6b1efe 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -5,7 +5,7 @@ config SYS_ARCH
default arc
config SYS_CPU
- default arc700
+ default arcv1
choice
prompt Target select
diff --git a/arch/arc/cpu/arc700/Makefile b/arch/arc/cpu/arcv1/Makefile
similarity index 100%
rename from arch/arc/cpu/arc700/Makefile
rename to arch/arc/cpu/arcv1/Makefile
diff --git a/arch/arc/cpu/arc700/config.mk b/arch/arc/cpu/arcv1/config.mk
similarity index 100%
rename from arch/arc/cpu/arc700/config.mk
rename to arch/arc/cpu/arcv1/config.mk
diff --git a/arch/arc/cpu/arc700/start.S b/arch/arc/cpu/arcv1/start.S
similarity index 100%
rename from arch/arc/cpu/arc700/start.S
rename to arch/arc/cpu/arcv1/start.S
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
Sorry for the lateness -- I was just pinged about these regression fixes that should go in the forthcoming release. The following changes since commit b188067f39627d977bb1db67c8456e9aaab90743: arm: vf610: fix boot from SD-card (2015-01-09 10:27:51 -0500) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git for you to fetch changes up to ab37b76d5d7879009565d1d1a2be6de63f86a674: mtd: nand: do not scan BBT after scrub (2015-01-09 12:19:06 -0600) Masahiro Yamada (3): mtd: nand: revive nand scrub command mtd: nand: Mark the BBT as scanned prior to calling scan_bbt again mtd: nand: do not scan BBT after scrub drivers/mtd/nand/nand_base.c | 11 --- drivers/mtd/nand/nand_util.c | 4 +--- 2 files changed, 5 insertions(+), 10 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please pull u-boot-arc master
Dear Tom, The following changes since commit b188067f39627d977bb1db67c8456e9aaab90743: arm: vf610: fix boot from SD-card (2015-01-09 10:27:51 -0500) are available in the git repository at: git://git.denx.de/u-boot-arc.git for you to fetch changes up to 4c8c485ad9249e1ca1822474954b78799ca937e9: arc: introduce mdbtrick target (2015-01-09 23:59:54 +0300) Alexey Brodkin (1): arc: introduce mdbtrick target arch/arc/Makefile | 15 +++ 1 file changed, 15 insertions(+) -- Best regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] config_cmd_default.h: wrap each definition in ifndef
Hi all, On Sat, 2015-01-03 at 16:20 +0300, Alexey Brodkin wrote: Now with switch to Kconfig it's possible to select commands via menuconfig or defconfigs. Moreover some commands are enabled by default in both config_cmd_default.h as a legacy way and in common/Kconfig. And on attempt to build U-Boot following warnings are printed for definitions made in both: -- In file included from include/configs/arcangel4.h:45:0, from include/config.h:4, from include/common.h:18, from examples/standalone/stubs.c:1: include/config_cmd_default.h:20:0: warning: CONFIG_CMD_BDI redefined [enabled by default] #define CONFIG_CMD_BDI /* bdinfo */ ^ In file included from ././include/linux/kconfig.h:4:0, from command-line:0: include/generated/autoconf.h:10:0: note: this is the location of the previous definition #define CONFIG_CMD_BDI 1 ^ -- An obvious fix is to wrap all definitions in config_cmd_default.h since we still have to keep it util we're done with complete switch to Kconfig. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Tom Rini tr...@ti.com --- include/config_cmd_default.h | 42 ++ 1 file changed, 42 insertions(+) diff --git a/include/config_cmd_default.h b/include/config_cmd_default.h index 73c9544..b33f21b 100644 --- a/include/config_cmd_default.h +++ b/include/config_cmd_default.h @@ -16,28 +16,70 @@ * hardware, not fully tested, etc.). */ +#ifndef CONFIG_CMD_BDI #define CONFIG_CMD_BDI /* bdinfo */ +#endif +#ifndef CONFIG_CMD_BOOTD #define CONFIG_CMD_BOOTD /* bootd*/ +#endif +#ifndef CONFIG_CMD_CONSOLE #define CONFIG_CMD_CONSOLE /* coninfo */ +#endif +#ifndef CONFIG_CMD_ECHO #define CONFIG_CMD_ECHO /* echo arguments */ +#endif +#ifndef CONFIG_CMD_EDITENV #define CONFIG_CMD_EDITENV /* editenv */ +#endif +#ifndef CONFIG_CMD_FPGA #define CONFIG_CMD_FPGA /* FPGA configuration Support */ +#endif +#ifndef CONFIG_CMD_IMI #define CONFIG_CMD_IMI /* iminfo */ +#endif +#ifndef CONFIG_CMD_ITEST #define CONFIG_CMD_ITEST /* Integer (and string) test*/ +#endif #ifndef CONFIG_SYS_NO_FLASH +#ifndef CONFIG_CMD_FLASH #define CONFIG_CMD_FLASH /* flinfo, erase, protect */ +#endif +#ifndef CONFIG_CMD_IMLS #define CONFIG_CMD_IMLS /* List all found images*/ #endif +#endif /* CONFIG_SYS_NO_FLASH */ +#ifndef CONFIG_CMD_LOADB #define CONFIG_CMD_LOADB /* loadb*/ +#endif +#ifndef CONFIG_CMD_LOADS #define CONFIG_CMD_LOADS /* loads*/ +#endif +#ifndef CONFIG_CMD_MEMORY #define CONFIG_CMD_MEMORY/* md mm nm mw cp cmp crc base loop */ +#endif +#ifndef CONFIG_CMD_MISC #define CONFIG_CMD_MISC /* Misc functions like sleep etc*/ +#endif +#ifndef CONFIG_CMD_NET #define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/ +#endif +#ifndef CONFIG_CMD_NFS #define CONFIG_CMD_NFS /* NFS support */ +#endif +#ifndef CONFIG_CMD_RUN #define CONFIG_CMD_RUN /* run command in env variable */ +#endif +#ifndef CONFIG_CMD_SAVEENV #define CONFIG_CMD_SAVEENV /* saveenv */ +#endif +#ifndef CONFIG_CMD_SETGETDCR #define CONFIG_CMD_SETGETDCR /* DCR support on 4xx */ +#endif +#ifndef CONFIG_CMD_SOURCE #define CONFIG_CMD_SOURCE/* source command support */ +#endif +#ifndef CONFIG_CMD_XIMG #define CONFIG_CMD_XIMG /* Load part of Multi Image */ +#endif #endif /* _CONFIG_CMD_DEFAULT_H */ Looks like the first patch from this series is not yet ready for a prime-time (look at discussion here http://patchwork.ozlabs.org/patch/425106/) I still think this particular patch makes sense because users may select command via Kconfig now and once one of the commands listed in config_cmd_default.h is selected inevitably warnings will appear in build console. So if there're no comment and objections I'll re-send this patch separately. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/18] exynos5: config: prepare for dm i2c support
Hello Heiko Schocher, Sorry, I missed this message this morning. On 01/09/2015 07:37 AM, Heiko Schocher wrote: Hello Przemyslaw Marczak, Am 08.01.2015 12:33, schrieb Przemyslaw Marczak: This commit allows for test i2c drivers with new i2c api on Exynos5xxx based boards. The S3C24X0 I2C driver supports driver model I2C api, but i2c peripherials drivers on exynos5 boards doesn't. So this commit allows for test ported driver before switch the Exynos5 boards to DM I2C at all. Hmm... so this is just a patch for test purposes not for mainline? This patch is for the mainline, but I left the if 0 just for the developers, who want to port the required i2c drivers. I will remove the if 0. There are some i2c drivers for Exynos based boards, which should be ported to the new i2c api. At present I'm not able to do this at once and as I know someone needs the i2c driver for the present work. I required the i2c bus driver for the pmic framework, on which now I'm working. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Akshay Saraswat aksha...@samsung.com Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com --- include/configs/exynos5-common.h | 29 ++--- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index ad63f3c..b7af8a5 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -54,13 +54,6 @@ #define CONFIG_CMD_DTT #define CONFIG_TMU_CMD_DTT -/* TPM */ -#define CONFIG_TPM -#define CONFIG_CMD_TPM -#define CONFIG_TPM_TIS_I2C -#define CONFIG_TPM_TIS_I2C_BUS_NUMBER3 -#define CONFIG_TPM_TIS_I2C_SLAVE_ADDR0x20 - /* MMC SPL */ #define COPY_BL2_FNPTR_ADDR0x02020030 #define CONFIG_SUPPORT_EMMC_BOOT @@ -126,15 +119,29 @@ #define SPI_FLASH_UBOOT_POS(CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE) /* I2C */ -#define CONFIG_SYS_I2C_INIT_BOARD -#define CONFIG_SYS_I2C +#if 0 /* For test */ +#define CONFIG_DM_I2C +#endif Hmm.. no, please no dead code in mainline ... maybe you enable CONFIG_DM_I2C if CONFIG_DM is set? bye, Heiko Yes, will be removed. I can't use the CONFIG_DM because of the rest of the i2c drivers, which are waiting for the adjust to new i2c api. #define CONFIG_CMD_I2C -#define CONFIG_SYS_I2C_S3C24X0_SPEED10/* 100 Kbps */ #define CONFIG_SYS_I2C_S3C24X0 -#define CONFIG_I2C_MULTI_BUS +#define CONFIG_SYS_I2C_S3C24X0_SPEED10/* 100 Kbps */ #define CONFIG_SYS_I2C_S3C24X0_SLAVE0x0 +#ifndef CONFIG_DM_I2C +#define CONFIG_SYS_I2C_INIT_BOARD +#define CONFIG_SYS_I2C +#define CONFIG_I2C_MULTI_BUS +#endif /* ifndef CONFIG_DM_I2C */ #define CONFIG_I2C_EDID +/* TPM */ +#ifndef CONFIG_DM_I2C +#define CONFIG_TPM +#define CONFIG_CMD_TPM +#define CONFIG_TPM_TIS_I2C +#define CONFIG_TPM_TIS_I2C_BUS_NUMBER3 +#define CONFIG_TPM_TIS_I2C_SLAVE_ADDR0x20 +#endif + /* SPI */ #ifdef CONFIG_SPI_FLASH #define CONFIG_EXYNOS_SPI Also I'm not going to move the current pmic framework/drivers to the new i2c api, since I hope to send the new framework soon. Thank you and best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/12] imx:mx6 update mxc_ccm_reg
Add more register for structure mxc_ccm_reg.
Signed-off-by: Peng Fan peng@freescale.com
---
arch/arm/include/asm/arch-mx6/crm_regs.h | 87
1 file changed, 87 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 39f3c07..55e1287 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -103,6 +103,93 @@ struct mxc_ccm_reg {
u32 analog_pfd_528_set;
u32 analog_pfd_528_clr;
u32 analog_pfd_528_tog;
+ u32 reg_1p1;/* 0x4110 */
+ u32 reg_1p1_set;/* 0x4114 */
+ u32 reg_1p1_clr;/* 0x4118 */
+ u32 reg_1p1_tog;/* 0x411c */
+ u32 reg_3p0;/* 0x4120 */
+ u32 reg_3p0_set;/* 0x4124 */
+ u32 reg_3p0_clr;/* 0x4128 */
+ u32 reg_3p0_tog;/* 0x412c */
+ u32 reg_2p5;/* 0x4130 */
+ u32 reg_2p5_set;/* 0x4134 */
+ u32 reg_2p5_clr;/* 0x4138 */
+ u32 reg_2p5_tog;/* 0x413c */
+ u32 reg_core; /* 0x4140 */
+ u32 reg_core_set; /* 0x4144 */
+ u32 reg_core_clr; /* 0x4148 */
+ u32 reg_core_tog; /* 0x414c */
+ u32 ana_misc0; /* 0x4150 */
+ u32 ana_misc0_set; /* 0x4154 */
+ u32 ana_misc0_clr; /* 0x4158 */
+ u32 ana_misc0_tog; /* 0x415c */
+ u32 ana_misc1; /* 0x4160 */
+ u32 ana_misc1_set; /* 0x4164 */
+ u32 ana_misc1_clr; /* 0x4168 */
+ u32 ana_misc1_tog; /* 0x416c */
+ u32 ana_misc2; /* 0x4170 */
+ u32 ana_misc2_set; /* 0x4174 */
+ u32 ana_misc2_clr; /* 0x4178 */
+ u32 ana_misc2_tog; /* 0x417c */
+ u32 tempsense0; /* 0x4180 */
+ u32 tempsense0_set; /* 0x4184 */
+ u32 tempsense0_clr; /* 0x4188 */
+ u32 tempsense0_tog; /* 0x418c */
+ u32 tempsense1; /* 0x4190 */
+ u32 tempsense1_set; /* 0x4194 */
+ u32 tempsense1_clr; /* 0x4198 */
+ u32 tempsense1_tog; /* 0x419c */
+ u32 usb1_vbus_detect; /* 0x41a0 */
+ u32 usb1_vbus_detect_set; /* 0x41a4 */
+ u32 usb1_vbus_detect_clr; /* 0x41a8 */
+ u32 usb1_vbus_detect_tog; /* 0x41ac */
+ u32 usb1_chrg_detect; /* 0x41b0 */
+ u32 usb1_chrg_detect_set; /* 0x41b4 */
+ u32 usb1_chrg_detect_clr; /* 0x41b8 */
+ u32 usb1_chrg_detect_tog; /* 0x41bc */
+ u32 usb1_vbus_det_stat; /* 0x41c0 */
+ u32 usb1_vbus_det_stat_set; /* 0x41c4 */
+ u32 usb1_vbus_det_stat_clr; /* 0x41c8 */
+ u32 usb1_vbus_det_stat_tog; /* 0x41cc */
+ u32 usb1_chrg_det_stat; /* 0x41d0 */
+ u32 usb1_chrg_det_stat_set; /* 0x41d4 */
+ u32 usb1_chrg_det_stat_clr; /* 0x41d8 */
+ u32 usb1_chrg_det_stat_tog; /* 0x41dc */
+ u32 usb1_loopback; /* 0x41e0 */
+ u32 usb1_loopback_set; /* 0x41e4 */
+ u32 usb1_loopback_clr; /* 0x41e8 */
+ u32 usb1_loopback_tog; /* 0x41ec */
+ u32 usb1_misc; /* 0x41f0 */
+ u32 usb1_misc_set; /* 0x41f4 */
+ u32 usb1_misc_clr; /* 0x41f8 */
+ u32 usb1_misc_tog; /* 0x41fc */
+ u32 usb2_vbus_detect; /* 0x4200 */
+ u32 usb2_vbus_detect_set; /* 0x4204 */
+ u32 usb2_vbus_detect_clr; /* 0x4208 */
+ u32 usb2_vbus_detect_tog; /* 0x420c */
+ u32 usb2_chrg_detect; /* 0x4210 */
+ u32 usb2_chrg_detect_set; /* 0x4214 */
+ u32 usb2_chrg_detect_clr; /* 0x4218 */
+ u32 usb2_chrg_detect_tog; /* 0x421c */
+ u32 usb2_vbus_det_stat; /* 0x4220 */
+ u32 usb2_vbus_det_stat_set; /* 0x4224 */
+ u32 usb2_vbus_det_stat_clr; /* 0x4228 */
+ u32 usb2_vbus_det_stat_tog; /* 0x422c */
+ u32 usb2_chrg_det_stat;
[U-Boot] dm: device_id info
Hi, I'm exploring internals of dm where I'm just comparing udevice with Linux model especially on device_id scenarios. udevice_id - u-boot Linux: platform_device_id of_device_id spi_device_id input_device_id .. ... pci_device_id 1. Does this udevice_id is a generic model in u-boot for all variant of devices? Bcz Linux defines each devices have own device_id entries. 2. diff of of_device_id vs udevice_id 3. udevice_id vs fdt function calls, suppose If I write a dm driver where my board doesn't have fdt support, is this a valid scenario. 4. Pls- add any info which I haven't covered. thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: vf610: fix boot from SD-card
Hi Bill, On 2015-01-08 18:32, Bill Pringlemeir wrote: On 8 Jan 2015, ste...@agner.ch wrote: Boot from SD-card (and probably also from NAND) was broken since commit d6d07a9bec (arm: vf610: add NAND support for vf610twr). It looks like the increased size of U-Boot lead to a situation where the boot ROM overwrote its own stack/heap while loading U-Boot from the SD-card to the SRAM. However, U-Boot worked fine when loaded through USB serial loader directly into SRAM. It looks like loading from SD-card uses other stack/heap location then the serial loader (or maybe no stack or heap at all). This fix moves U-Boot to gfxRAM, which is 512kB in size and is not used by the boot ROM nor the SD-card loader of it. Signed-off-by: Stefan Agner ste...@agner.ch --- We use U-Boot from gfxRAM on Vybrid since quite a while for the Colibri VF50/VF61 modules in our downstream U-Boot branch. Hence this is quite well tested. Just today I discovered that this is broken on the Tower module. Back then, when I made the offending change, I only tested on the Tower board using the serial loader, since I thought the behaviour should be exactly the same. But now, I know better... :-) If still possible, it would be great to get this into v2015.01... include/configs/vf610twr.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h index 6fd0b17..bd79e81 100644 --- a/include/configs/vf610twr.h +++ b/include/configs/vf610twr.h @@ -125,7 +125,10 @@ #define CONFIG_BOOTDELAY 3 #define CONFIG_LOADADDR 0x8200 -#define CONFIG_SYS_TEXT_BASE0x3f008000 + +/* We boot from the gfxRAM area of the OCRAM. */ +#define CONFIG_SYS_TEXT_BASE0x3f408000 +#define CONFIG_BOARD_SIZE_LIMIT 524288 #define CONFIG_EXTRA_ENV_SETTINGS \ script=boot.scr\0 \ Acked-by: Bill Pringlemeir bpringlem...@nbsps.com Thx! See also: http://lists.denx.de/pipermail/u-boot/2014-December/197641.html Oh, I even gave my Ack for that, but I did not remember it! Oh dear! It seems since v2014.04 u-boot on the Vybrid Tower SD card has not booted. Most users will probably boot this way. https://community.freescale.com/docs/DOC-95248 Yes I agree, hence it would be nice to have that working again in 2015.1... I also think that meta-fsl-arm creates a SD-card boot-able image by default, but not sure whether mainline U-boot is in use there or not. Added Otavio for that matter... Albert, any chance that can make it into 2015.1 too? -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: vf610: fix boot from SD-card
On Fri, Jan 9, 2015 at 12:13 PM, Stefan Agner ste...@agner.ch wrote: ... I also think that meta-fsl-arm creates a SD-card boot-able image by default, but not sure whether mainline U-boot is in use there or not. Added Otavio for that matter... Yes we generate and use U-Boot mainline. So I think we ought to backport this fix for 2014.10 there as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx25: Fix boot hang by avoiding vector relocation
On Thu, Jan 08, 2015 at 10:10:45AM -0500, Bill Pringlemeir wrote: On Tue, Jan 06, 2015 at 01:06:48PM -0200, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Since commit 3ff46cc42b9d73d0 (arm: relocate the exception vectors) mx25pdk hangs like this: CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: WDOG Board: MX25PDK I2C: ready DRAM: 64 MiB (hangs) Add a specific relocate_vectors macro that skips the vector relocation, as the i.MX25 SoC does not provide RAM at the high vectors address (0x), and (0x) maps to ROM. This allows mx25 to boot again. Signed-off-by: Fabio Estevam fabio.este...@freescale.com On 8 Jan 2015, tr...@ti.com wrote: I'd like to pull this in for the release. I'd also really like someone else to ack or otherwise comment on this (and why this is more right than not just relocating the vectors as v1 did, I see both boot to a U-Boot prompt but shouldn't we do a bit more testing to confirm that we don't need to relocate these exception vectors or have we now introduced some subtle breakage (or perhaps not so subtle once you hit it) in these cases? Thanks! Acked-By: Bill Pringlemeir bpringlem...@nbsps.com Applied to u-boot/master and thanks for the details! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-spi/master
On Fri, Jan 09, 2015 at 12:10:35AM +0530, Jagannadha Sutradharudu Teki wrote: Hi Tom, Please pull this PR. thanks! Jagan. The following changes since commit d622ac39274a949b6445f1bfd92dc1644014388b: powerpc: mpc824x: remove MPC824X cpu support (2015-01-05 12:08:55 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to adc0fabfd9662fa690e866332cd4277351f991c4: imx:mx6sxsabresd support qspi AHB read (2015-01-09 00:03:28 +0530) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i2c:mxc fix array size of i2c_data
On Tue, Jan 06, 2015 at 02:12:51PM +0800, Peng Fan wrote: We should not hardcode array size of i2c_data to 3. To CONFIG_FSL_LSCH3, there are 4 i2c interface, but not 3. So the size of i2c_data array should be calculated using ARRAY_SIZE(i2c_bases). To avoid compile error, move i2c_bases before sram_data structure which contains i2c_data array. Signed-off-by: Peng Fan peng@freescale.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx25: Remove empty line after printing the reset cause
On Tue, Jan 06, 2015 at 02:10:05PM -0200, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Currently there is an unneeded empty line after printing the reset cause: U-Boot 2015.01-rc4-00080-g0551a93 (Jan 06 2015 - 13:04:19) CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: POR Board: MX25PDK I2C: ready DRAM: 64 MiB MMC: FSL_SDHC: 0 Remove the extra \n when printing the reset cause. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_sf: Fix problem with sf update and unaligned length
On SoCFPGA, using sf update with an non-4byte aligned length leads
to a hangup (and reboot via watchdog). This is because of the unaligned
access in the cadence QSPI driver which is hard to prevent since the
data is written into a 4-byte wide FIFO. This patch fixes this problem
by changing the behavior of the last sector write (not sector aligned).
The new code is even simpler and copies the source data into the temp
buffer and now uses the temp buffer to write the complete sector. So
only one SPI sector write is used now instead of 2 in the old version.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Gerlando Falauto gerlando.fala...@keymile.com
Cc: Valentin Longchamp valentin.longch...@keymile.com
Cc: Holger Brunck holger.bru...@keymile.com
Cc: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
common/cmd_sf.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 5c788e9..dd82290 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -163,6 +163,8 @@ static int do_spi_flash_probe(int argc, char * const argv[])
static const char *spi_flash_update_block(struct spi_flash *flash, u32 offset,
size_t len, const char *buf, char *cmp_buf, size_t *skipped)
{
+ char *ptr = (char *)buf;
+
debug(offset=%#x, sector_size=%#x, len=%#zx\n,
offset, flash-sector_size, len);
/* Read the entire sector so to allow for rewriting */
@@ -178,16 +180,14 @@ static const char *spi_flash_update_block(struct
spi_flash *flash, u32 offset,
/* Erase the entire sector */
if (spi_flash_erase(flash, offset, flash-sector_size))
return erase;
- /* Write the initial part of the block from the source */
- if (spi_flash_write(flash, offset, len, buf))
- return write;
- /* If it's a partial sector, rewrite the existing part */
+ /* If it's a partial sector, copy the data into the temp-buffer */
if (len != flash-sector_size) {
- /* Rewrite the original data to the end of the sector */
- if (spi_flash_write(flash, offset + len,
- flash-sector_size - len, cmp_buf[len]))
- return write;
+ memcpy(cmp_buf, buf, len);
+ ptr = cmp_buf;
}
+ /* Write one complete sector */
+ if (spi_flash_write(flash, offset, flash-sector_size, ptr))
+ return write;
return NULL;
}
--
2.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] usb: gadget: composite: Fix NULL pointer crash in USB compliance test
On the DXR2 board (AM335x using MUSB) the USB compliance test suite (USB 2.0 Command Verifier) will cause the board to crash and reset upon the BOS Descriptor Test - Addressed state. Here the output from the DRX2 while running this test: GADGET DRIVER: usb_dnl_dfu musb-hdrc: peripheral reset irq lost! composite_setup (776) data abort pc : [87f693ac] lr : [87f6911c] sp : 86f33a58 ip : fp : 86f3bbac r10: 0f00 r9 : 86f33ef4 r8 : 86f37da8 r7 : 0005 r6 : 86f33a90 r5 : r4 : 86f37e30 r3 : r2 : r1 : 87f9c888 r0 : 0016 Flags: Nzcv IRQs off FIQs on Mode SVC_32 Resetting CPU ... resetting ... By adding the case statement for USB_DT_BOS and therefore not running into the default case (jump to unkown label) this crash is fixed. Signed-off-by: Stefan Roese s...@denx.de Cc: Roger Meier r.me...@siemens.com Cc: Samuel Egli samuel.e...@siemens.com Cc: Enrico Leto enrico.l...@siemens.com Cc: Heiko Schocher h...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de --- drivers/usb/gadget/composite.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index a4c5606..98c2da6 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -761,6 +761,14 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) if (value = 0) value = min(w_length, (u16) value); break; + case USB_DT_BOS: + /* +* The USB compliance test (USB 2.0 Command Verifier) +* issues this request. We should not run into the +* default path here. But return for now until +* the superspeed support is added. +*/ + break; default: goto unknown; } -- 2.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] usb: gadget: f_dfu: Add get_alt function to pass the USB compliance test
Without this function the USB compliance test (USB 2.0 Command Verifier) will
fail in the Interface Descriptor Test with this error message:
FAIL
(1.2.51) A successful GetInterface request must return the alternate setting
set by a prior call to SetInterface.
Lets add this function to read back the value so that the DFU device fully
passes the USB compliance test.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Roger Meier r.me...@siemens.com
Cc: Samuel Egli samuel.e...@siemens.com
Cc: Enrico Leto enrico.l...@siemens.com
Cc: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
drivers/usb/gadget/f_dfu.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index ead71eb..77a1567 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -780,6 +780,13 @@ static int dfu_set_alt(struct usb_function *f, unsigned
intf, unsigned alt)
return 0;
}
+static int __dfu_get_alt(struct usb_function *f, unsigned intf)
+{
+ struct f_dfu *f_dfu = func_to_dfu(f);
+
+ return f_dfu-altsetting;
+}
+
/* TODO: is this really what we need here? */
static void dfu_disable(struct usb_function *f)
{
@@ -806,6 +813,7 @@ static int dfu_bind_config(struct usb_configuration *c)
f_dfu-usb_function.bind = dfu_bind;
f_dfu-usb_function.unbind = dfu_unbind;
f_dfu-usb_function.set_alt = dfu_set_alt;
+ f_dfu-usb_function.get_alt = __dfu_get_alt;
f_dfu-usb_function.disable = dfu_disable;
f_dfu-usb_function.strings = dfu_generic_strings;
f_dfu-usb_function.setup = dfu_handle;
--
2.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: gadget: composite: Fix NULL pointer crash in USB compliance test
Hello Stefan, Am 09.01.2015 14:54, schrieb Stefan Roese: On the DXR2 board (AM335x using MUSB) the USB compliance test suite (USB 2.0 Command Verifier) will cause the board to crash and reset upon the BOS Descriptor Test - Addressed state. Here the output from the DRX2 while running this test: GADGET DRIVER: usb_dnl_dfu musb-hdrc: peripheral reset irq lost! composite_setup (776) data abort pc : [87f693ac] lr : [87f6911c] sp : 86f33a58 ip : fp : 86f3bbac r10: 0f00 r9 : 86f33ef4 r8 : 86f37da8 r7 : 0005 r6 : 86f33a90 r5 : r4 : 86f37e30 r3 : r2 : r1 : 87f9c888 r0 : 0016 Flags: Nzcv IRQs off FIQs on Mode SVC_32 Resetting CPU ... resetting ... By adding the case statement for USB_DT_BOS and therefore not running into the default case (jump to unkown label) this crash is fixed. Signed-off-by: Stefan Roese s...@denx.de Cc: Roger Meier r.me...@siemens.com Cc: Samuel Egli samuel.e...@siemens.com Cc: Enrico Leto enrico.l...@siemens.com Cc: Heiko Schocher h...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de --- drivers/usb/gadget/composite.c | 8 1 file changed, 8 insertions(+) Thanks! Acked-by: Heiko Schocher h...@denx.de bye, Heiko diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index a4c5606..98c2da6 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -761,6 +761,14 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) if (value = 0) value = min(w_length, (u16) value); break; + case USB_DT_BOS: + /* +* The USB compliance test (USB 2.0 Command Verifier) +* issues this request. We should not run into the +* default path here. But return for now until +* the superspeed support is added. +*/ + break; default: goto unknown; } -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: gadget: f_dfu: Add get_alt function to pass the USB compliance test
Hello Stefan, Am 09.01.2015 14:54, schrieb Stefan Roese: Without this function the USB compliance test (USB 2.0 Command Verifier) will fail in the Interface Descriptor Test with this error message: FAIL (1.2.51) A successful GetInterface request must return the alternate setting set by a prior call to SetInterface. Lets add this function to read back the value so that the DFU device fully passes the USB compliance test. Signed-off-by: Stefan Roese s...@denx.de Cc: Roger Meier r.me...@siemens.com Cc: Samuel Egli samuel.e...@siemens.com Cc: Enrico Leto enrico.l...@siemens.com Cc: Heiko Schocher h...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de --- drivers/usb/gadget/f_dfu.c | 8 1 file changed, 8 insertions(+) Thanks! Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc: fix spelling errors in am335x/README
On Tue, Jan 06, 2015 at 04:40:28PM -0800, Jeremiah Mahler wrote: Fix several spelling errors and replace the invalid word architectured with designed. Signed-off-by: Jeremiah Mahler jmmah...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpt: Fix the protective MBR partition size
On Thu, Jan 08, 2015 at 12:26:44PM +0100, Maxime Ripard wrote: According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-uniphier
On Thu, Jan 08, 2015 at 11:08:45PM +0900, Masahiro YAMADA wrote: Hi Tom, Please pull some Panasonic SoC specific updates. The following changes since commit 40ad4c4b1fea2497bc019ee82163b76d4b076730: Kconfig: move EXPERT option under General setup menu (2015-01-07 14:48:47 -0500) are available in the git repository at: git://git.denx.de/u-boot-uniphier.git master for you to fetch changes up to b4ad44baab713af371b1113dd63dd222ba73ba13: ARM: UniPhier: add UART initialization routine for low-level debug (2015-01-08 23:01:56 +0900) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc/gitmail-rc: fix whitespaces
On Wed, Jan 07, 2015 at 11:32:36PM +, Luka Perkov wrote: Signed-off-by: Luka Perkov luka.per...@sartura.hr Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MAINTAINERS: add me as a co-maintainer of KIRKWOOD
On Wed, Jan 07, 2015 at 11:32:06PM +, Luka Perkov wrote: Signed-off-by: Luka Perkov luka.per...@sartura.hr CC: Prafulla Wadaskar prafu...@marvell.com CC: Wolfgang Denk w...@denx.de Acked-by: Stefan Roese s...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] scripts: fix binutils-version.sh for 'as' without a package.
On Wed, Jan 07, 2015 at 10:34:15AM -0500, Bill Pringlemeir wrote: Commit 73c25753 fixed the common issue that binutil packages (tool/organization that packaged or built the bin-utils) are included in brackets and this may falsely be recognized as a version. However, some tools do not provide a 'package' and previously we add the 'Gnu assembler..' to the version. Strip out the '(package version text)' and then look for a ##.## string. Signed-off-by: Bill Pringlemeir bpringlem...@nbsps.com Tested-by: Masahiro Yamada yamad...@jp.panasonic.com Tested-by: Hans de Goede hdego...@redhat.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
On 01/09/2015 04:31 PM, Joonyoung Shim wrote:
+Cc Jaehoon,
On 01/09/2015 03:18 AM, Simon Glass wrote:
Hi Joonyoung,
On 7 January 2015 at 22:44, Joonyoung Shim jy0922.s...@samsung.com wrote:
Some exynos boards require special handling of SD4_nRESET_OUT line for
eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards.
This will support eMMC reset using DT from reset_misc of samsung common
board file and each board files can support eMMC reset on non DT case.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
board/samsung/common/board.c | 27
++
board/samsung/odroid/odroid.c | 2 +-
doc/device-tree-bindings/exynos/emmc-reset.txt | 15 ++
3 files changed, 43 insertions(+), 1 deletion(-)
create mode 100644 doc/device-tree-bindings/exynos/emmc-reset.txt
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index c04ab3c..3218463 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -40,6 +40,8 @@ __weak int exynos_power_init(void)
return 0;
}
+__weak void exynos_reset_misc(void) {}
+
#if defined CONFIG_EXYNOS_TMU
/* Boot Time Thermal Analysis for SoC temperature threshold breach */
static void boot_temp_check(void)
@@ -400,3 +402,28 @@ int misc_init_r(void)
return 0;
}
#endif
+
+void reset_misc(void)
+{
+#ifdef CONFIG_OF_CONTROL
I think all Samsung boards have this defined, so this #ifdef can be removed.
OK, if it is true, we can remove this and i will not to support non DT case.
+ struct gpio_desc gpio = {};
+ int node;
+
+ node = fdt_node_offset_by_compatible(gd-fdt_blob, 0,
+ samsung,emmc-reset);
+ if (node 0)
+ return;
+
+ gpio_request_by_name_nodev(gd-fdt_blob, node, reset-gpio, 0,
gpio,
+ GPIOD_IS_OUT);
+
+ if (dm_gpio_is_valid(gpio)) {
+ /* Reset eMMC*/
+ dm_gpio_set_value(gpio, 0);
+ mdelay(10);
That's a very long reset! Is that what it needs?
Jaehoon, is there any guide about wait time of reset at eMMC spec?
Well, I'm not sure, but as Simon's comments, it's long time.
(Minimum is 1us...Maximum isn't defined.)
Best Regards,
Jaehoon Chung
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: Enable pre-console buffer
On Thu, 08 Jan 2015 08:49:54 + Ian Campbell i...@hellion.org.uk wrote: On Thu, 2015-01-08 at 09:02 +0200, Siarhei Siamashka wrote: This allows to always have a complete log on the VGA/HDMI/LCD console. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com --- include/configs/sunxi-common.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index b4324ee..5ddcc42 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -272,10 +272,15 @@ #ifndef CONFIG_SPL_BUILD #include config_distro_defaults.h +/* Enable pre-console buffer to get complete log on the VGA console */ +#define CONFIG_PRE_CONSOLE_BUFFER +#define CONFIG_PRE_CON_BUF_SZ (1024 * 1024) +#define CONFIG_PRE_CON_BUF_ADDR(0x4300 - CONFIG_PRE_CON_BUF_SZ) + /* * 240M RAM (256M minimum minus space for the framebuffer), - * 32M uncompressed kernel, 16M compressed kernel, 1M fdt, - * 1M script, 1M pxe and the ramdisk at the end. + * 32M uncompressed kernel, 15M compressed kernel, 1M pre-console + * buffer, 1M fdt, 1M script, 1M pxe and the ramdisk at the end. Am I correct in thinking that the pre-console buffer is long gone (replaced by the actual console) by the time any of these mem layout choices come into play (i.e. long before anything might load a kernel, initrd or fdt)? Yes, my understanding is that it should be already gone, but not too long ago. Logging in the patched pre-console buffer ends at the time when the following messages get displayed: In:serial Out: vga Err: vga Now that you mentioned it, the patch is indeed extending the life time of the pre-console buffer, and this might be an unwanted side effect. Maybe Simon has some opinion. If yes then I think it is confusing to modify this comment, and the comment before the pre-console #defines should mention that the buffer is boottime only/short lived etc. Just in case if something goes really wrong (in theory it shouldn't, but in practice you know...) it is still somewhat safer to keep the buffer in its own dedicated area and keep everything else out. If no then I'm not sure putting a u-boot managed buffer in the middle of the user managed load space is a good idea, since it could lead to odd/hard to debug corruptions etc if the kernel was 15M. Either way I think it would be better to put this buffer somewhere else entirely since it isn't really the same as these things. In a hypothetical scenario of having neither serial console nor hdmi/lcd/vga console available, the user managed code could probably dump the pre-console buffer to the SD card and provide some rudimentary debugging aid. Yes, hardly anyone would ever do this. If the u-boot log could be somehow passed to the kernel and show in dmesg, that would be in fact quite useful in my opinion. But this is well out of scope of discussing the current patch. */ #define MEM_LAYOUT_ENV_SETTINGS \ bootm_size=0xf00\0 \ Both u-boot-sunxi#master and #next still have 0x1000 here, which tree is this patch on? Some branch of Hans' tree (with sunxi: sunxi-common.h: Reduce bootm_size to take the framebuffer into account in it) I suppose? Now the u-boot-sunxi#next branch has bootm_size=0xf00 too. Yes, I was using the Hans' branch with the pending lcd patches, because I was working with this stuff too. Perhaps a better place for the pre-console buffer would be right before the framebuffer (or at the top of RAM if no video on the board), with modifications to bootm_size or not depending on the answer to the original question above. If this needs any kind of runtime address calculations instead of compile time constants, then IMHO it becomes unnecessarily complicated. Anyway. The sunxi part of these changes just needs to assign some memory area to the pre-console buffer. In the end it does not really matter which one. The size also does not need to be too large. For example 1920 * 1080 / (8 * 16) = 16200. It means that only ~16K of the log buffer can fully cover the FullHD display using the 8x16 font. And this is even assuming no line breaks. I picked 1M only because it was the smallest unit of the address space allocation in sunxi-common.h :-) -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: vf610: fix boot from SD-card
Hi Tom, hi Stefan, On 09/01/2015 15:13, Stefan Agner wrote: Hi Bill, On 2015-01-08 18:32, Bill Pringlemeir wrote: On 8 Jan 2015, ste...@agner.ch wrote: Boot from SD-card (and probably also from NAND) was broken since commit d6d07a9bec (arm: vf610: add NAND support for vf610twr). It looks like the increased size of U-Boot lead to a situation where the boot ROM overwrote its own stack/heap while loading U-Boot from the SD-card to the SRAM. However, U-Boot worked fine when loaded through USB serial loader directly into SRAM. It looks like loading from SD-card uses other stack/heap location then the serial loader (or maybe no stack or heap at all). This fix moves U-Boot to gfxRAM, which is 512kB in size and is not used by the boot ROM nor the SD-card loader of it. Signed-off-by: Stefan Agner ste...@agner.ch --- We use U-Boot from gfxRAM on Vybrid since quite a while for the Colibri VF50/VF61 modules in our downstream U-Boot branch. Hence this is quite well tested. Just today I discovered that this is broken on the Tower module. Back then, when I made the offending change, I only tested on the Tower board using the serial loader, since I thought the behaviour should be exactly the same. But now, I know better... :-) If still possible, it would be great to get this into v2015.01... include/configs/vf610twr.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h index 6fd0b17..bd79e81 100644 --- a/include/configs/vf610twr.h +++ b/include/configs/vf610twr.h @@ -125,7 +125,10 @@ #define CONFIG_BOOTDELAY3 #define CONFIG_LOADADDR 0x8200 -#define CONFIG_SYS_TEXT_BASE 0x3f008000 + +/* We boot from the gfxRAM area of the OCRAM. */ +#define CONFIG_SYS_TEXT_BASE 0x3f408000 +#define CONFIG_BOARD_SIZE_LIMIT524288 #define CONFIG_EXTRA_ENV_SETTINGS \ script=boot.scr\0 \ Acked-by: Bill Pringlemeir bpringlem...@nbsps.com Thx! See also: http://lists.denx.de/pipermail/u-boot/2014-December/197641.html Oh, I even gave my Ack for that, but I did not remember it! Oh dear! It seems since v2014.04 u-boot on the Vybrid Tower SD card has not booted. Most users will probably boot this way. https://community.freescale.com/docs/DOC-95248 Yes I agree, hence it would be nice to have that working again in 2015.1... I also think that meta-fsl-arm creates a SD-card boot-able image by default, but not sure whether mainline U-boot is in use there or not. Added Otavio for that matter... Albert, any chance that can make it into 2015.1 too? Maybe it is better if Tom can pick it up directly into his tree, avoiding to go through custodian's tree. Release is coming soon :-). Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
