Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE
Hello Peng, On Mon, 19 Oct 2015 13:40:51 +0800, Peng Fan wrote: > On Tue, Oct 06, 2015 at 05:13:24PM -0500, Frank Li wrote: > >When added above configuration, iram fix up plus relocate offset may locate > >in invalidate space. Write back fix up value will cause data abort. > > > >Add address check, skip psci code. > > > >Signed-off-by: Frank Li > >--- > > arch/arm/lib/relocate.S | 4 > > 1 file changed, 4 insertions(+) > > > >diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S > >index 475d503..6795a1b 100644 > >--- a/arch/arm/lib/relocate.S > >+++ b/arch/arm/lib/relocate.S > >@@ -99,6 +99,10 @@ fixloop: > > cmp r1, #23 /* relative fixup? */ > > bne fixnext > > > >+ldr r1, =__image_copy_start > >+cmp r0, r1 > >+blo fixnext > >+ > > Hi Tom, Albert, > > This is a bug fix, please consider to apply this patch. Sorry for not spotting your patch earlier. Took me some time to understand the commit summary. Let me see if I'm getting this right by paraphrasing it: If CONFIG_ARMV7_SECURE_BASE is defined and if there is a fixup to the location at __image_copy_start, then U-Boot will try to fix that location and since it is write-protected, it will result in a data abort. If I got this right, then this raises the following questions: 1) if this location cannot be written into for relocation fixup, then how could it be written into for the copying which precedes relocation? 2) if there is a fixup to the location, it means that either this location will not work properly without a fix, or the compiler emitted an erroneous relocation record. In either case, just ignoring the fixup seems like papering over the issue. Besides, this patch will prevent image base fixups on all targets, even those for which CONFIG_ARMV7_SECURE_BASE is not defined. So, for now, I would NAK it. Now, assuming the answers to the two questions above do make a valid point that the fix above should indeed be implemented, then: > The secure code such as PSCI is not relocated, so there is no need to fix the > code > which generate relocate entry in rel.dyn section. We should only need take > code from __image_copy_start to __image_copy_end into consideration. If some part of an image needs copying but not relocating, then the right solution is not to hard-code some arbitrary location as 'not relocatable' in the relocation routine; the right solution is to put in place a generic mechanism to allow the linker script to define which part of the image is relocatable. This can be done as follows: - in the linker script, border the non-relocatable part of the image with two symbols, say 'relocatable_image_start' and '..._end', and ensure that text (code) which should *not* be relocated is mapped either before '..._start' or '..._end'. Not-to-be-relocated code would be recognized by its text section name, e.g. '.nonreloc.text*'. - in the relocation routine, only fix up those locations which lie between the 'relocatable_image_start' and '..._end' symbols. - in the relevant makefile(s), make the non-relocatable object files use a test section name of the for defined in the first step (e.g. '.nonreloc.text*'). Again, this is suggested *only* if it is shown that the data abort cannot be avoided some other way. > Regards, > Peng. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (CORRECTED last minute) pull request: u-boot-arm/master
On Mon, 19 Oct 2015 08:11:25 +0200, Albert ARIBAUD wrote: > Hello Tom, > > A last-minute fix, maybe it can go in 2015.10 since this is a > single-target bugfix by the maintainer? Actually, two bug-fixes: The following changes since commit ac6a53219a1bf5bd30b754d6d3f04f26e3921d15: Merge git://git.denx.de/u-boot-socfpga (2015-10-16 20:21:04 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 79ad5cef151fff32432a31ce7fe92e170d8a95ae: ARM: rpi: add another revision of Raspberry Pi A+ (2015-10-19 08:12:25 +0200) Eric Cooper (1): ARM: dockstar: move start of environment area Lubomir Rintel (1): ARM: rpi: add another revision of Raspberry Pi A+ arch/arm/mach-bcm283x/include/mach/mbox.h | 1 + board/raspberrypi/rpi/rpi.c | 5 + include/configs/dockstar.h| 4 ++-- 3 files changed, 8 insertions(+), 2 deletions(-) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (last minute) pull request: u-boot-arm/master
Hello Tom, A last-minute fix, maybe it can go in 2015.10 since this is a single-target bugfix by the maintainer? The following changes since commit ac6a53219a1bf5bd30b754d6d3f04f26e3921d15: Merge git://git.denx.de/u-boot-socfpga (2015-10-16 20:21:04 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to d1a2f32fca16ce0ec01b3447cc4755a17aca7f0f: ARM: dockstar: move start of environment area (2015-10-19 07:28:54 +0200) Eric Cooper (1): ARM: dockstar: move start of environment area include/configs/dockstar.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nios2: add README.nios2
Add README.nios2 about how to add nios2 boards to u-boot. Signed-off-by: Thomas Chou --- doc/README.nios2 | 86 1 file changed, 86 insertions(+) create mode 100644 doc/README.nios2 diff --git a/doc/README.nios2 b/doc/README.nios2 new file mode 100644 index 000..9f248ac --- /dev/null +++ b/doc/README.nios2 @@ -0,0 +1,86 @@ +Nios II is a 32-bit embedded-processor architecture designed +specifically for the Altera family of FPGAs. + +Please refer to the link for more information on Nios II, +https://www.altera.com/products/processors/overview.html + +Please refer to the link for Linux port and toolchains, +http://rocketboards.org/foswiki/view/Documentation/NiosIILinuxUserManual + +The Nios II port of u-boot is controlled by device tree. To add a new +board/configuration (eg, mysystem) to u-boot, you will need three files. + +1. The device tree source which descibe the hardware, dts file. +arch/nios2/dts/mysystem.dts + +2. Default configuration of Kconfig, defconfig file. +configs/mysystem_defconfig + +3. The legacy board header file. +include/configs/mysystem.h + +The device tree source must be generated from your qsys/sopc design file +using the sopc2dts tool. Then modified to fit your configuration. Please +find the sopc2dts download and usage at the wiki, +http://www.alterawiki.com/wiki/Sopc2dts + +java -jar sopc2dts.jar --force-altr -i mysystem.sopcinfo -o mysystem.dts + +You will need to add additional properties to the dts. Please find an +example at, arch/nios2/dts/3c120_devboard.dts. + +1. Add "u-boot,dm-pre-reloc" property to the cpu and the serial node +which you will use for console. + +2. Add "stdout-path=..." property with your serial path to the chosen +node. + +Next, you will need a default config file. You may start with +nios2-generic_defconfig, modify the options and save it. + +make nios2-generic_defconfig +make menuconfig +make savedefconfig +cp defconfig configs/mysystem_defconfig + +You will need to change the names of board header file and device tree, +and select the drivers. + +Nios II architecture ---> + (mysystem) Board header file +Device Tree Control ---> + (mysystem) Default Device Tree for DT control + +There is a selection of "Provider of DTB for DT control" in the Device +Tree Control menu. + +( ) Separate DTB for DT control, will cat the dtb to end of u-boot +binary, output u-boot-dtb.bin. This should be used for production. +If you use boot copier, like epcs boot copier, make sure the copier +copies all the u-boot-dtb.bin, not just u-boot.bin. + +( ) Embedded DTB for DT control, will include the dtb inside the u-boot +binary. This is handy for development, eg, using gdb or nios2-download. + +The last thing, legacy board header file describes those config options +not covered in Kconfig yet. You may copy it from nios2-generic.h. + +cp include/configs/nios2-generic.h include/configs/mysystem.h + +Please change the sdram base and size to your board. The base should be +cached virtual address, for nios2 with mmu it is 0xCxxx- to +0xDxxx-. + +#define CONFIG_SYS_SDRAM_BASE 0xD000 +#define CONFIG_SYS_SDRAM_SIZE 0x0800 + +You will need to change the environment variables location and setting, +too. You may change other configs to fit your board. + +After all these changes, you may build and test. + +export CROSS_COMPILE=nios2-elf- (or nios2-linux-gnu-) +make mysystem_defconfig +make + +Enjoy! -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] arm: fix compile warnings when semihosting is enabled on ARMv7M target.
Hello Vadzim,
On Mon, 19 Oct 2015 00:13:29 +0300, Vadzim Dambrouski
wrote:
> Signed-off-by: Vadzim Dambrouski
> ---
>
> arch/arm/lib/semihosting.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
> index ed5e8e4..6541cb4 100644
> --- a/arch/arm/lib/semihosting.c
> +++ b/arch/arm/lib/semihosting.c
> @@ -92,7 +92,7 @@ static long smh_read(long fd, void *memp, size_t len)
> size_t len;
> } read;
>
> - debug("%s: fd %ld, memp %p, len %lu\n", __func__, fd, memp, len);
> + debug("%s: fd %ld, memp %p, len %lu\n", __func__, fd, memp, (ulong)len);
>
> read.fd = fd;
> read.memp = memp;
> @@ -107,7 +107,7 @@ static long smh_read(long fd, void *memp, size_t len)
>* with an error message.
>*/
> printf("%s: ERROR ret %ld, fd %ld, len %lu memp %p\n",
> -__func__, ret, fd, len, memp);
> +__func__, ret, fd, (ulong)len, memp);
> return -1;
> }
len is a size_t; it should not be force-converted into a long, it
should be printed using a 'z' qualifier.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm: add support for semihosting for ARMv7M targets
Hello Vadzim,
On Mon, 19 Oct 2015 00:13:28 +0300, Vadzim Dambrouski
wrote:
> It is possible to enable CONFIG_SEMIHOSTING for STM32F429 target, but it
> would result in compile error. This patch adds support for semihosting for
> STM32F429 or any other ARMv7M target. Tested on STM32F429-DISCOVERY board.
You should give some more indication of the reason for the compile
error and the nature of the fix. For instance, you could quote the
essential part of the error message (so that people googling for the
error message may find this commit and mail thread) and a very short
analysis (so that they can test if 'their' error is the same and can
be solved the same way).
> Signed-off-by: Vadzim Dambrouski
> ---
>
> arch/arm/lib/semihosting.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
> index c3e964e..ed5e8e4 100644
> --- a/arch/arm/lib/semihosting.c
> +++ b/arch/arm/lib/semihosting.c
> @@ -31,6 +31,8 @@ static noinline long smh_trap(unsigned int sysnum, void
> *addr)
> register long result asm("r0");
> #if defined(CONFIG_ARM64)
> asm volatile ("hlt #0xf000" : "=r" (result) : "0"(sysnum), "r"(addr));
> +#elif defined(CONFIG_CPU_V7M)
> + asm volatile ("bkpt #0xAB" : "=r" (result) : "0"(sysnum), "r"(addr));
> #else
> /* Note - untested placeholder */
> asm volatile ("svc #0x123456" : "=r" (result) : "0"(sysnum), "r"(addr));
> --
> 2.6.1
>
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] nios2: convert dma_alloc_coherent to use malloc_cache_aligned
Hello Thomas, On Mon, 12 Oct 2015 20:55:03 +0800, Thomas Chou wrote: > Hi Marek, > > On 10/12/2015 06:32 PM, Marek Vasut wrote: > > Wouldn't invalidate_dcache_range() be enough here ? You don't care about the > > data in the newly allocated area at this point I guess -- either you fill > > them > > in and then flush, for DMA from CPU to device OR you receive data from > > device > > to CPU and then you invalidate this buffer again. > > No. We cannot use invalidate cache here. This is related to cache design > of nios2, kind of direct mapped cache. Not sure I'm getting this, so for my own education: what prevents from invalidating the cache, or IOW, what would happen if it was invalidated at this point rather than flushed? > Best regards, > Thomas Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: rpi: add another revision of Raspberry Pi A+
Hello Lubomir,
On Wed, 14 Oct 2015 17:17:54 +0200, Lubomir Rintel wrote:
> Seen this one in the wild. Is labelled "Raspberry Pi Model A+ V1.1,
> (C) Raspberry Pi 2014". A standard A+ board, much like the one with
> version 0x12, didn't notice any differencies.
>
> Signed-off-by: Lubomir Rintel
> ---
> arch/arm/mach-bcm283x/include/mach/mbox.h | 1 +
> board/raspberrypi/rpi/rpi.c | 5 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
> b/arch/arm/mach-bcm283x/include/mach/mbox.h
> index ff959c8..9260ee2 100644
> --- a/arch/arm/mach-bcm283x/include/mach/mbox.h
> +++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
> @@ -150,6 +150,7 @@ struct bcm2835_mbox_tag_hdr {
> #define BCM2835_BOARD_REV_A_PLUS 0x12
> #define BCM2835_BOARD_REV_B_PLUS_13 0x13
> #define BCM2835_BOARD_REV_CM_14 0x14
> +#define BCM2835_BOARD_REV_A_PLUS_15 0x15
> #endif
>
> struct bcm2835_mbox_tag_get_board_rev {
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 6d7be11..942badb 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -176,6 +176,11 @@ static const struct {
> "bcm2835-rpi-cm.dtb",
> false,
> },
> + [BCM2835_BOARD_REV_A_PLUS_15] = {
> + "Model A+",
> + "bcm2835-rpi-a-plus.dtb",
> + false,
> + },
> #endif
> };
>
> --
> 2.4.3
>
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch V5 11/17] armv8/fsl_lsch3: Change arch to fsl-layerscape
> -Original Message-
> From: Gong Qianyu-B52263
> Sent: Friday, October 16, 2015 2:15 PM
> To: Kushwaha Prabhakar-B32579 ; u-
> b...@lists.denx.de
> Cc: Hu Mingkai-B21284 ; Sun York-R58495
> ; Hou Zhiqiang-B48286 ;
> Xie Shaohui-B21989 ; Song Wenbin-B53747
> ; Wood Scott-B07421
> ; Wang Huan-B18965
>
> Subject: RE: [Patch V5 11/17] armv8/fsl_lsch3: Change arch to fsl-layerscape
>
>
> > -Original Message-
> > From: Prabhakar [mailto:prabha...@freescale.com]
> > Sent: Friday, October 16, 2015 2:20 PM
> > To: Gong Qianyu-B52263; u-boot@lists.denx.de
> > Cc: Hu Mingkai-B21284; Sun York-R58495; Hou Zhiqiang-B48286; Xie
> > Shaohui- B21989; Song Wenbin-B53747; Wood Scott-B07421; Wang
> > Huan-B18965
> > Subject: Re: [Patch V5 11/17] armv8/fsl_lsch3: Change arch to fsl-
> > layerscape
> >
> >
> >
> > On 10/15/2015 6:32 PM, Gong Qianyu wrote:
> > > From: Mingkai Hu
> > >
> > > There are two LS series processors are built on ARMv8 Layersacpe
> > > architecture currently, LS2085A and LS1043A. They are based on
> > > ARMv8 core although use different chassis, so create fsl-layerscape
> > > to refactor the common code for the LS series processors which also
> > > paves the way for adding LS1043A platform.
> > >
> > > Signed-off-by: Mingkai Hu
> > > Signed-off-by: Gong Qianyu
> > > ---
> > > V5:
> > > - Move LS2085A ddr macros out of soc #ifdef.
> > > - Move macros and structs from cpu.c to cpu.h.
> > > - Wrap le32 and be32 functions for ccsr gur and scfg. Defined in
> > soc.h
> > > - Modify fsl-layerscape/Makefile.
> > > V4:
> > > - New patch.
> > >
> > > arch/arm/cpu/armv8/Makefile| 2 +-
> > > arch/arm/cpu/armv8/fsl-layerscape/Makefile | 21 ++
> > > .../README => fsl-layerscape/README.lsch3} | 0
> > > .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/cpu.c | 249
> > > ++--
> > -
> > > .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/cpu.h | 2 +-
> > > .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/fdt.c | 17 +-
> > > .../fsl_lsch3_serdes.c | 8 +-
> > > .../speed.c => fsl-layerscape/fsl_lsch3_speed.c} | 12 +-
> > > .../armv8/{fsl-lsch3 => fsl-layerscape}/lowlevel.S | 14 +-
> > > .../{fsl-lsch3 => fsl-layerscape}/ls2085a_serdes.c | 3 +-
> > > .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/mp.c | 15 +-
> > > .../cpu/armv8/{fsl-lsch3 => fsl-layerscape}/soc.c | 35 +--
> > > arch/arm/cpu/armv8/fsl-layerscape/spl.c| 76 +++
> > > arch/arm/cpu/armv8/fsl-lsch3/Makefile | 13 --
> > > arch/arm/cpu/armv8/fsl-lsch3/speed.h | 7 -
> > > .../clock.h| 8 +-
> > > arch/arm/include/asm/arch-fsl-layerscape/config.h | 59 +
> > > arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 165
> > ++
> > > .../{arch-fsl-lsch3 => arch-fsl-layerscape}/fdt.h | 4 +
> > > .../fsl_serdes.h | 11 +-
> > > .../immap_lsch3.h | 119 --
> > > .../arm/include/asm/arch-fsl-layerscape/imx-regs.h | 55 +
> > > .../ls2085a_stream_id.h| 0
> > > arch/arm/include/asm/arch-fsl-layerscape/mmu.h | 10 +
> > > .../asm/arch-fsl-layerscape}/mp.h | 10 +-
> > > .../{arch-fsl-lsch3 => arch-fsl-layerscape}/soc.h | 21 +-
> > > arch/arm/include/asm/arch-fsl-layerscape/speed.h | 10 +
> > > arch/arm/include/asm/arch-fsl-lsch3/config.h | 185
> > ---
> > > arch/arm/include/asm/arch-fsl-lsch3/gpio.h | 9 -
> > > arch/arm/include/asm/arch-fsl-lsch3/imx-regs.h | 13 --
> > > arch/arm/include/asm/config.h | 7 +-
> > > arch/arm/include/asm/global_data.h | 2 +-
> > > board/freescale/ls2085aqds/Kconfig | 2 +-
> > > board/freescale/ls2085aqds/eth.c | 1 -
> > > board/freescale/ls2085aqds/ls2085aqds.c| 2 +-
> > > board/freescale/ls2085ardb/Kconfig | 2 +-
> > > board/freescale/ls2085ardb/eth_ls2085rdb.c | 1 -
> > > board/freescale/ls2085ardb/ls2085ardb.c| 2 +-
> > > drivers/i2c/mxc_i2c.c | 4 +-
> > > drivers/misc/fsl_debug_server.c| 1 -
> > > drivers/net/ldpaa_eth/ls2085a.c| 2 -
> > > drivers/pci/pcie_layerscape.c | 4 +-
> > > include/common.h | 3 +
> > > include/configs/ls2085a_common.h | 47 +++-
> > > 44 files changed, 712 insertions(+), 521 deletions(-)
> > >
> > > diff --git a/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > similarity index 94%
> > > rename from arch/arm/cpu/armv8/fsl-lsch3/fdt.c
> > > rename to arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > index 567c419..aa88d34 100644
Re: [U-Boot] [PATCH 1/3] ARM: relocate: fix hang when CONFIG_ARMV7_SECURE_BASE
On Tue, Oct 06, 2015 at 05:13:24PM -0500, Frank Li wrote: >When added above configuration, iram fix up plus relocate offset may locate >in invalidate space. Write back fix up value will cause data abort. > >Add address check, skip psci code. > >Signed-off-by: Frank Li >--- > arch/arm/lib/relocate.S | 4 > 1 file changed, 4 insertions(+) > >diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S >index 475d503..6795a1b 100644 >--- a/arch/arm/lib/relocate.S >+++ b/arch/arm/lib/relocate.S >@@ -99,6 +99,10 @@ fixloop: > cmp r1, #23 /* relative fixup? */ > bne fixnext > >+ ldr r1, =__image_copy_start >+ cmp r0, r1 >+ blo fixnext >+ Hi Tom, Albert, This is a bug fix, please consider to apply this patch. The secure code such as PSCI is not relocated, so there is no need to fix the code which generate relocate entry in rel.dyn section. We should only need take code from __image_copy_start to __image_copy_end into consideration. Regards, Peng. > /* relative fix: increase location by offset */ > add r0, r0, r4 > ldr r1, [r0] >-- >2.5.2 > >___ >U-Boot mailing list >U-Boot@lists.denx.de >http://lists.denx.de/mailman/listinfo/u-boot -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Doubt in USB driver for Vybrid vf610
Hello Marek, On 15-10-17 21:59:07, maitysancha...@gmail.com wrote: > Hello, > > On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote: > > Hi All, > > I am working on USB part for vybrid vf-610 processor, We have two ports in > > the board > > > > when I type usb start in uboot command prompt, It returns as ENODEV for > > USB0 and when analyzed, It is returning from the below code in > > ehci-hcd_init function(in ehci-vf.c) > > > > if (init == USB_INIT_HOST && index == 0) > > return -ENODEV; > > Along with the above if (init == USB_INIT_DEVICE && index == 1) return -ENODEV; In the ehci-vf USB driver for Vybrid, currently we have two "if" cases as above which basically serve the purpose of preventing one of the USB ports from being configured as host, which we did like to keep as client. So for us, USB0 is client and USB1 is host and the above was put in with that intention to prevent USB0 from being configured as host, when usb start is called. However this is bad for other users out there, sorry about that. I checked and it seems even without the above, if both ports are configured as host with usb start and later dfu is called to used the intended as client for upgrade purposes, things still seem to work. Not sure if there are cases where this can break which I am missing. Not being that well versed with USB I wanted to ask is this ok or this is completely wrong? If it is ok, I guess we can go ahead and nuke the above checks? OR will be it be a better approach to introduce something like board_ehci_hch_init_with_type(int index, enum usb_init_type type) which will be a weak function and then have the board specific code hook call it? - Sanchayan. > > If these two lines are commented, the usb start is working and device is > > found on USB0. > > Why is this check kept in the code? > > I am the author of the ehci-vf USB driver which is based on iMX6 > implementation. > The implementation was done as per our requirements where we have one port as > host and another as client. In hindsight my implementation is severely > restricting > and at that time I missed thinking of it and did not had other boards to test. > > I will fix this up and send a patch. However I need to look a bit. The ideal > way > would be to fix it up in board_ehci_hcd_init call however that does not > provide > the init parameter to distinguish between USB_INIT_DEVICE and USB_INIT_HOST. > > May I ask are you using some module or you have your custom setup around the > Vybrid? Sorry for the trouble. Thanks for reporting. > > - Sanchayan. > > > > > Regards, > > Santhosh > > > > > > ::DISCLAIMER:: > > > > > > The contents of this e-mail and any attachment(s) are confidential and > > intended for the named recipient(s) only. > > E-mail transmission is not guaranteed to be secure or error-free as > > information could be intercepted, corrupted, > > lost, destroyed, arrive late or incomplete, or may contain viruses in > > transmission. The e mail and its contents > > (with or without referred errors) shall therefore not attach any liability > > on the originator or HCL or its affiliates. > > Views or opinions, if any, presented in this email are solely those of the > > author and may not necessarily reflect the > > views or opinions of HCL or its affiliates. Any form of reproduction, > > dissemination, copying, disclosure, modification, > > distribution and / or publication of this message without the prior written > > consent of authorized representative of > > HCL is strictly prohibited. If you have received this email in error please > > delete it and notify the sender immediately. > > Before opening any email and/or attachments, please check them for viruses > > and other defects. > > > > > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: dockstar: move start of environment area
Hello Eric, On Mon, 12 Oct 2015 19:18:52 -0400, Eric Cooper wrote: > The default dockstar configuration for U-Boot currently causes it to > overrun the environment area, so that a "saveenv" command bricks the > device. This patch moves the environment to a higher address to avoid > that. > > Signed-off-by: Eric Cooper > --- > include/configs/dockstar.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/configs/dockstar.h b/include/configs/dockstar.h > index b27b202..d0d9d53 100644 > --- a/include/configs/dockstar.h > +++ b/include/configs/dockstar.h > @@ -60,8 +60,8 @@ > * it has to be rounded to sector size > */ > #define CONFIG_ENV_SIZE 0x2 /* 128k */ > -#define CONFIG_ENV_ADDR 0x6 > -#define CONFIG_ENV_OFFSET0x6 /* env starts here */ > +#define CONFIG_ENV_ADDR 0x8 > +#define CONFIG_ENV_OFFSET0x8 /* env starts here */ > > /* > * Default environment variables > -- > 2.6.1 Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/8] board_init_f_mem(): Don't require memset()
Hello Simon,
On Sun, 18 Oct 2015 14:38:06 -0600, Simon Glass
wrote:
> Hi Albert,
>
> On 18 October 2015 at 10:28, Albert ARIBAUD wrote:
> > Hello Simon,
> >
> > On Sat, 17 Oct 2015 15:06:55 -0600, Simon Glass
> > wrote:
> >> Unfortunately memset() is not always available, so provide a substitute
> >> when
> >> needed.
> >>
> >> Signed-off-by: Simon Glass
> >> ---
> >>
> >> Changes in v3: None
> >> Changes in v2:
> >> - Add comments as to why this is needed, deal with arch-specific memset()
> >>
> >> common/init/board_init.c | 18 ++
> >> 1 file changed, 18 insertions(+)
> >>
> >> diff --git a/common/init/board_init.c b/common/init/board_init.c
> >> index e7ebca7..c113a80 100644
> >> --- a/common/init/board_init.c
> >> +++ b/common/init/board_init.c
> >> @@ -11,6 +11,16 @@
> >>
> >> DECLARE_GLOBAL_DATA_PTR;
> >>
> >> +/*
> >> + * It isn't trivial to figure out whether memcpy() exists. The
> >> arch-specific
> >> + * memcpy() is not normally available in SPL due to code size.
> >> + */
> >> +#if !defined(CONFIG_SPL_BUILD) || \
> >> + (defined(CONFIG_SPL_LIBGENERIC_SUPPORT) && \
> >> + !defined(CONFIG_USE_ARCH_MEMSET))
> >> +#define _USE_MEMCPY
> >> +#endif
> >> +
> >> /* Unfortunately x86 can't compile this code as gd cannot be assigned */
> >> #ifndef CONFIG_X86
> >> __weak void arch_setup_gd(struct global_data *gd_ptr)
> >> @@ -22,6 +32,9 @@ __weak void arch_setup_gd(struct global_data *gd_ptr)
> >> ulong board_init_f_mem(ulong top)
> >> {
> >> struct global_data *gd_ptr;
> >> +#ifndef _USE_MEMCPY
> >> + int *ptr, *end;
> >> +#endif
> >>
> >> /* Leave space for the stack we are running with now */
> >> top -= 0x40;
> >> @@ -29,7 +42,12 @@ ulong board_init_f_mem(ulong top)
> >> top -= sizeof(struct global_data);
> >> top = ALIGN(top, 16);
> >> gd_ptr = (struct global_data *)top;
> >> +#ifdef _USE_MEMCPY
> >> memset(gd_ptr, '\0', sizeof(*gd));
> >> +#else
> >> + for (ptr = (int *)gd_ptr, end = (int *)(gd_ptr + 1); ptr < end; )
> >
> > Nitpick here: There is little point in naming a variable just for
> > it to be set and used once. Without 'end', the compiler will be just as
> > fine if ptr is directly tested against (int *)(gd_ptr + 1), and human
> > readers won't wonder why 'end' was created.
>
> Well it makes it clear that the ptr goes from the start to the end.
> But it's probably clear enough just doing what you suggest, so I can
> change it.
Please do, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting UBI fixes (specially fastmap's) to U-Boot
Hello Ezequiel,
Am 17.10.2015 um 20:07 schrieb Ezequiel Garcia:
Hi Heiko,
On 9 October 2015 at 09:30, Heiko Schocher wrote:
[..]
I just updated the "ubi_sync_with_linux" branch on u-boot-ubi.
It seems UBI/UBIFS now work with the NAND on the aristainetos2
board, but my stomach says, there are some subtile issues ...
Still needs more testing, also not tested yet UBI on the SPI NOR on
this board.
If I "nand erase" the mtd device, and try "ubi part ..." it fails
:-(
But If I flash_eraseall under linux the device, and then make
"ubi part..." in U-Boot, commmand succeeds ...
Tested it on my custom AM335x board. Haven't used mainline U-Boot
but cherry-picked the following commits:
linux, compat: add missing definitions for ubi
ubi/ubifs: some bugfixes
ubi,ubifs: sync with linux v4.2
ubi: reset mtd_devs when ubi part fail
Commits apply cleanly except for "linux, compat: add missing
definitions for ubi"
which was trivial to backport anyway.
U-Boot built fine, but there was a warning:
drivers/mtd/ubi/fastmap.c: In function 'ubi_attach_fastmap':
drivers/mtd/ubi/fastmap.c:816:2: warning: pointer targets in passing
argument 3 of 'scan_pool' differ in signedness [-Wpointer-sign]
ret = scan_pool(ubi, ai, fmpl->pebs, pool_size, &max_sqnum, &free);
Just sent this patch which should fix it:
http://patchwork.ozlabs.org/patch/531842/
Thanks for fixing. With it, I see no compiler warning anymore.
Applied to u-boot-ubi.git ubi_sync_with_linux
Tried this branch on the aristainetos2 board with ubi/ubifs on nand and
spi nor flash, worked fine, see log:
http://xeidos.ddns.net/buildbot/builders/ari_ubi/builds/7
http://xeidos.ddns.net/buildbot/builders/ari_ubi/builds/7/steps/shell/logs/tbotlog
The board seems to work fine, and I can even to "nand erase" and "ubi
part" without
any problem.
Did you tried "ubi part" more than once in a row?
However, I'm still seeing the same warning I had before, when my partition
is attached:
ubi0: default fastmap pool size: 200
ubi0: default fastmap WL pool size: 100
ubi0: attaching mtd1
WARNING in drivers/mtd/ubi/fastmap.c line 846
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=7", size 509 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 4072, bad PEBs: 4, corrupted PEBs: 0
ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 5/3, WL threshold: 4096, image sequence
number: 2068197800
ubi0: available PEBs: 3504, total reserved PEBs: 568, PEBs reserved
for bad PEB handling: 76
@Richard, any ideas? Do you know which of the fixes should fix that?
Does this warning raise also in linux? I do not see it on the aristainetos2
board.
U-Boot code:
/*
* If fastmap is leaking PEBs (must not happen), raise a
* fat warning and fall back to scanning mode.
* We do this here because in ubi_wl_init() it's too late
* and we cannot fall back to scanning.
*/
#ifndef __UBOOT__
if (WARN_ON(count_fastmap_pebs(ai) != ubi->peb_count -
ai->bad_peb_count - fm->used_blocks))
goto fail_bad;
#else
if (count_fastmap_pebs(ai) != ubi->peb_count -
ai->bad_peb_count - fm->used_blocks) {
WARN_ON(1);
goto fail_bad;
}
#endif
Hmm.. could not remember, why I did this U-Boot specific ...
But that;s a good example, why I like the "#ifndef __UBOOT__"
in Code ... I immediately see, if its linux or u-boot specific
code ... maybe its worth to try the original linux code?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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 v3 7/8] zynq: Move SPL console init out of board_init_f()
Hello Simon, On Sun, 18 Oct 2015 14:37:03 -0600, Simon Glass wrote: > Hi Albert, > > On 18 October 2015 at 10:36, Albert ARIBAUD wrote: > > Hello Simon, > > > > On Sat, 17 Oct 2015 15:07:00 -0600, Simon Glass > > wrote: > >> We should not init the console this early and there is no need to. If we > >> want > >> to do early init it can be done in spl_board_init(). Move the > >> preloader_console_init() call from board_init_f() to board_init_r(). > >> > >> Signed-off-by: Simon Glass > >> Tested-by: Masahiro Yamada > >> Tested-by: Michal Simek > > > > I personally think that we should, almost must in fact, initialize the > > console as early as possible. > > > > What exactly is the drawaback of initializing the console here? > > This is described in the README now for SPL. The console is not > available until driver model is ready, which cannot be before > global_data is ready. Makes sense now. Maybe the commit message could explicitly mention that the cause of the "should not" is the driver model? This commit might be viewed in isolation and the reader may need a clue on how to relate that commit to the driver model or the README. > My second zynq series removes the next few lines from board_init_f(), > so in effect there is very little difference in timing - the console > still is set up very early. It is just that we must not set it up > before driver model is running. > > There is also a debug UART which can be used to make printf() work > before global_data is available. But I'm trying to remove the > global_data hacks that exist in early board code. Then my initial concern is address (and again, maybe a small note in the commit message could remind the reader about the debug UART not being affected by the commit). Thanks! > Regards, > Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] ARM: tegra: rename GPU functions
Rename GPU functions to less generic names to avoid potential name
collisions.
Signed-off-by: Alexandre Courbot
---
arch/arm/include/asm/arch-tegra/gpu.h | 8
arch/arm/mach-tegra/board2.c | 4 ++--
arch/arm/mach-tegra/gpu.c | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/gpu.h
b/arch/arm/include/asm/arch-tegra/gpu.h
index 2fdb2c5049e6..4423386f2805 100644
--- a/arch/arm/include/asm/arch-tegra/gpu.h
+++ b/arch/arm/include/asm/arch-tegra/gpu.h
@@ -10,11 +10,11 @@
#if defined(CONFIG_TEGRA_GPU)
-void config_gpu(void);
+void tegra_gpu_config(void);
#else /* CONFIG_TEGRA_GPU */
-static inline void config_gpu(void)
+static inline void tegra_gpu_config(void)
{
}
@@ -22,11 +22,11 @@ static inline void config_gpu(void)
#if defined(CONFIG_OF_LIBFDT)
-int gpu_enable_node(void *blob, const char *gpupath);
+int tegra_gpu_enable_node(void *blob, const char *gpupath);
#else /* CONFIG_OF_LIBFDT */
-static inline int gpu_enable_node(void *blob, const char *gpupath)
+static inline int tegra_gpu_enable_node(void *blob, const char *gpupath)
{
return 0;
}
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index ff9e77cfa3a3..8ba143d996ca 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -128,7 +128,7 @@ int board_init(void)
clock_init();
clock_verify();
- config_gpu();
+ tegra_gpu_config();
#ifdef CONFIG_TEGRA_SPI
pin_mux_spi();
@@ -419,7 +419,7 @@ int ft_system_setup(void *blob, bd_t *bd)
/* Enable GPU node if GPU setup has been performed */
if (gpu_path != NULL)
- return gpu_enable_node(blob, gpu_path);
+ return tegra_gpu_enable_node(blob, gpu_path);
return 0;
}
diff --git a/arch/arm/mach-tegra/gpu.c b/arch/arm/mach-tegra/gpu.c
index dc29b79e0126..c7d705d8efe9 100644
--- a/arch/arm/mach-tegra/gpu.c
+++ b/arch/arm/mach-tegra/gpu.c
@@ -25,7 +25,7 @@
static bool _configured;
-void config_gpu(void)
+void tegra_gpu_config(void)
{
struct mc_ctlr *mc = (struct mc_ctlr *)NV_PA_MC_BASE;
@@ -43,7 +43,7 @@ void config_gpu(void)
#if defined(CONFIG_OF_LIBFDT)
-int gpu_enable_node(void *blob, const char *gpupath)
+int tegra_gpu_enable_node(void *blob, const char *gpupath)
{
int offset;
--
2.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] ARM: tegra210: gpu: configure WPR region
T210's GPU secure firmware loading requires a write-protected region
to be set up.
This patch reserves the upper 256KB of RAM as the WPR region and locks
it so the kernel can initiate secure firmware loading.
Signed-off-by: Alexandre Courbot
---
arch/arm/include/asm/arch-tegra210/mc.h | 12 +
arch/arm/mach-tegra/board.c | 4 +++
arch/arm/mach-tegra/gpu.c | 47 -
3 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-tegra210/mc.h
b/arch/arm/include/asm/arch-tegra210/mc.h
index 77e9aa51f60f..e6d1758d372f 100644
--- a/arch/arm/include/asm/arch-tegra210/mc.h
+++ b/arch/arm/include/asm/arch-tegra210/mc.h
@@ -62,6 +62,16 @@ struct mc_ctlr {
u32 mc_video_protect_bom; /* offset 0x648 */
u32 mc_video_protect_size_mb; /* offset 0x64c */
u32 mc_video_protect_reg_ctrl; /* offset 0x650 */
+ u32 reserved11[385];/* offset 0x654 - 0xc54 */
+ u32 mc_security_carveout2_cfg0; /* offset 0xc58 */
+ u32 mc_security_carveout2_bom; /* offset 0xc5c */
+ u32 mc_security_carveout2_bom_hi; /* offset 0xc60 */
+ u32 mc_security_carveout2_size_128k;/* offset 0xc64 */
+ u32 reserved12[16]; /* offset 0xc68 - 0xca4 */
+ u32 mc_security_carveout3_cfg0; /* offset 0xca8 */
+ u32 mc_security_carveout3_bom; /* offset 0xcac */
+ u32 mc_security_carveout3_bom_hi; /* offset 0xcb0 */
+ u32 mc_security_carveout3_size_128k;/* offset 0xcb4 */
};
#define TEGRA_MC_SMMU_CONFIG_ENABLE (1 << 0)
@@ -69,4 +79,6 @@ struct mc_ctlr {
#define TEGRA_MC_VIDEO_PROTECT_REG_WRITE_ACCESS_ENABLED(0 << 0)
#define TEGRA_MC_VIDEO_PROTECT_REG_WRITE_ACCESS_DISABLED (1 << 0)
+#define TEGRA_MC_SECURITY_CARVEOUT_CFG_LOCKED (1 << 1)
+
#endif /* _TEGRA210_MC_H_ */
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index b00e4b5c1e25..0bff063b00f4 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -111,6 +111,10 @@ static phys_size_t query_sdram_size(void)
if (size_bytes == SZ_2G)
size_bytes -= SZ_1M;
#endif
+#if defined(CONFIG_TEGRA210)
+ /* Reserve GPU WPR area, 2 * 128KB */
+ size_bytes = round_down(size_bytes - (SZ_128K * 2), SZ_128K);
+#endif
return size_bytes;
}
diff --git a/arch/arm/mach-tegra/gpu.c b/arch/arm/mach-tegra/gpu.c
index c7d705d8efe9..61d734fd5767 100644
--- a/arch/arm/mach-tegra/gpu.c
+++ b/arch/arm/mach-tegra/gpu.c
@@ -23,9 +23,11 @@
#include
+DECLARE_GLOBAL_DATA_PTR;
+
static bool _configured;
-void tegra_gpu_config(void)
+static void config_vpr(void)
{
struct mc_ctlr *mc = (struct mc_ctlr *)NV_PA_MC_BASE;
@@ -37,6 +39,49 @@ void tegra_gpu_config(void)
readl(&mc->mc_video_protect_reg_ctrl);
debug("configured VPR\n");
+}
+
+#if defined(CONFIG_TEGRA210)
+static void config_wpr(void)
+{
+ struct mc_ctlr *mc = (struct mc_ctlr *)NV_PA_MC_BASE;
+ u64 wpr_start = NV_PA_SDRAM_BASE + gd->ram_size;
+ u32 reg;
+
+ /*
+* Carveout2 uses the upper 256KB of upper memory that we reserved as
+* WPR region for secure firmware loading
+*/
+ writel(lower_32_bits(wpr_start), &mc->mc_security_carveout2_bom);
+ writel(upper_32_bits(wpr_start), &mc->mc_security_carveout2_bom_hi);
+ writel(0x2, &mc->mc_security_carveout2_size_128k);
+ reg = readl(&mc->mc_security_carveout2_cfg0);
+ reg |= TEGRA_MC_SECURITY_CARVEOUT_CFG_LOCKED;
+ writel(reg, &mc->mc_security_carveout2_cfg0);
+
+ /* Carveout3 is left empty */
+ writel(0x0, &mc->mc_security_carveout3_bom);
+ writel(0x0, &mc->mc_security_carveout3_bom_hi);
+ writel(0x0, &mc->mc_security_carveout3_size_128k);
+ reg = readl(&mc->mc_security_carveout3_cfg0);
+ reg |= TEGRA_MC_SECURITY_CARVEOUT_CFG_LOCKED;
+ writel(reg, &mc->mc_security_carveout3_cfg0);
+
+ /* read back to ensure the write went through */
+ readl(&mc->mc_security_carveout3_cfg0);
+
+ debug("configured WPR\n");
+}
+#else
+static inline void config_wpr(void)
+{
+}
+#endif
+
+void tegra_gpu_config(void)
+{
+ config_vpr();
+ config_wpr();
_configured = true;
}
--
2.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] ARM: tegra: simplify GPU setup
Enable the GPU node in the system-wide ft_system_setup() hook instead of
the board-specific ft_board_hook(). This allows us to enable GPU per SoC
generation instead of per-board as we did initially.
Reported-by: Stephen Warren
Signed-off-by: Alexandre Courbot
---
arch/arm/mach-tegra/board2.c | 20
board/nvidia/jetson-tk1/jetson-tk1.c | 8
board/nvidia/p2571/p2571.c | 7 ---
board/nvidia/venice2/venice2.c | 8
include/configs/jetson-tk1.h | 2 --
include/configs/p2571.h | 2 --
include/configs/tegra-common.h | 2 ++
include/configs/venice2.h| 2 --
8 files changed, 22 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index 8ecc67459a10..ff9e77cfa3a3 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -403,3 +403,23 @@ ulong board_get_usable_ram_top(ulong total_size)
{
return CONFIG_SYS_SDRAM_BASE + usable_ram_size_below_4g();
}
+
+/*
+ * This function is called right before the kernel is booted. "blob" is the
+ * device tree that will be passed to the kernel.
+ */
+int ft_system_setup(void *blob, bd_t *bd)
+{
+ const char *gpu_path =
+#if defined(CONFIG_TEGRA124) || defined(CONFIG_TEGRA210)
+ "/gpu@0,5700";
+#else
+ NULL;
+#endif
+
+ /* Enable GPU node if GPU setup has been performed */
+ if (gpu_path != NULL)
+ return gpu_enable_node(blob, gpu_path);
+
+ return 0;
+}
diff --git a/board/nvidia/jetson-tk1/jetson-tk1.c
b/board/nvidia/jetson-tk1/jetson-tk1.c
index 3c21767ce4da..52425a8f6dea 100644
--- a/board/nvidia/jetson-tk1/jetson-tk1.c
+++ b/board/nvidia/jetson-tk1/jetson-tk1.c
@@ -11,7 +11,6 @@
#include
#include
-#include
#include "pinmux-config-jetson-tk1.h"
@@ -80,10 +79,3 @@ int board_eth_init(bd_t *bis)
return pci_eth_init(bis);
}
#endif /* PCI */
-
-int ft_board_setup(void *blob, bd_t *bd)
-{
- gpu_enable_node(blob, "/gpu@0,5700");
-
- return 0;
-}
diff --git a/board/nvidia/p2571/p2571.c b/board/nvidia/p2571/p2571.c
index d33e4d12b2fa..d80a7d0d3e31 100644
--- a/board/nvidia/p2571/p2571.c
+++ b/board/nvidia/p2571/p2571.c
@@ -11,7 +11,6 @@
#include
#include
#include "max77620_init.h"
-#include
#include "pinmux-config-p2571.h"
void pin_mux_mmc(void)
@@ -62,9 +61,3 @@ void start_cpu_fan(void)
gpio_request(GPIO_PE4, "FAN_VDD");
gpio_direction_output(GPIO_PE4, 1);
}
-
-int ft_board_setup(void *blob, bd_t *bd)
-{
- gpu_enable_node(blob, "/gpu@0,5700");
- return 0;
-}
diff --git a/board/nvidia/venice2/venice2.c b/board/nvidia/venice2/venice2.c
index 3e2b9a7745e9..c56ef129d6c7 100644
--- a/board/nvidia/venice2/venice2.c
+++ b/board/nvidia/venice2/venice2.c
@@ -8,7 +8,6 @@
#include
#include
#include
-#include
#include "pinmux-config-venice2.h"
/*
@@ -28,10 +27,3 @@ void pinmux_init(void)
pinmux_config_drvgrp_table(venice2_drvgrps,
ARRAY_SIZE(venice2_drvgrps));
}
-
-int ft_board_setup(void *blob, bd_t *bd)
-{
- gpu_enable_node(blob, "/gpu@0,5700");
-
- return 0;
-}
diff --git a/include/configs/jetson-tk1.h b/include/configs/jetson-tk1.h
index e87a01047d30..f63957ab92fd 100644
--- a/include/configs/jetson-tk1.h
+++ b/include/configs/jetson-tk1.h
@@ -78,6 +78,4 @@
#define CONFIG_ARMV7_SECURE_BASE 0xfff0
#define CONFIG_ARMV7_SECURE_RESERVE_SIZE 0x0010
-#define CONFIG_OF_BOARD_SETUP
-
#endif /* __CONFIG_H */
diff --git a/include/configs/p2571.h b/include/configs/p2571.h
index c65d3e5fcbc1..a5de411121b0 100644
--- a/include/configs/p2571.h
+++ b/include/configs/p2571.h
@@ -60,6 +60,4 @@
#include "tegra-common-usb-gadget.h"
#include "tegra-common-post.h"
-#define CONFIG_OF_BOARD_SETUP
-
#endif /* _P2571_H */
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index 1c469d092e8c..9f0d4644431a 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -144,4 +144,6 @@
#define CONFIG_FAT_WRITE
#endif
+#define CONFIG_OF_SYSTEM_SETUP
+
#endif /* _TEGRA_COMMON_H_ */
diff --git a/include/configs/venice2.h b/include/configs/venice2.h
index 0fc8cf7674d1..a374cd948849 100644
--- a/include/configs/venice2.h
+++ b/include/configs/venice2.h
@@ -60,6 +60,4 @@
#include "tegra-common-usb-gadget.h"
#include "tegra-common-post.h"
-#define CONFIG_OF_BOARD_SETUP
-
#endif /* __CONFIG_H */
--
2.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] ARM: tegra: GPU WPR region support
This series makes U-boot program the write-protected (WPR) region of T210 chips, allowing the kernel to perform GPU secure firmware loading. Tegra 210's GPU requires its firmware to be loaded though a write-protected region. An area of physical memory is carved-out, programmed into the corresponding memory controller registers, and locked such as only the GPU can write into it. This area needs to be set up by the bootloader since it cannot be re-claimed for normal use after being locked. The first 3 patches of this series are cleanup patches. Patch 2 implements a suggestion made by Stephen, patch 3 renames GPU-related functions to sound less generic. The last patch adds support for the GPU WPR region. The top 256KB of memory are removed from the available memory, and the corresponding MC registers are programmed to point to it, which allows the kernel to initiate secure firmware loading. Alexandre Courbot (4): ARM: tegra: remove vpr_configured() function ARM: tegra: simplify GPU setup ARM: tegra: rename GPU functions ARM: tegra210: gpu: configure WPR region arch/arm/include/asm/arch-tegra/gpu.h | 14 +++-- arch/arm/include/asm/arch-tegra210/mc.h | 12 arch/arm/mach-tegra/board.c | 4 +++ arch/arm/mach-tegra/board2.c| 22 +- arch/arm/mach-tegra/gpu.c | 52 + board/nvidia/jetson-tk1/jetson-tk1.c| 8 - board/nvidia/p2571/p2571.c | 7 - board/nvidia/venice2/venice2.c | 8 - include/configs/jetson-tk1.h| 2 -- include/configs/p2571.h | 2 -- include/configs/tegra-common.h | 2 ++ include/configs/venice2.h | 2 -- 12 files changed, 89 insertions(+), 46 deletions(-) -- 2.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] ARM: tegra: remove vpr_configured() function
There is no justification for this function, especially in exported
form.
Signed-off-by: Alexandre Courbot
---
arch/arm/include/asm/arch-tegra/gpu.h | 6 --
arch/arm/mach-tegra/gpu.c | 7 +--
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/gpu.h
b/arch/arm/include/asm/arch-tegra/gpu.h
index 52280f40ce31..2fdb2c5049e6 100644
--- a/arch/arm/include/asm/arch-tegra/gpu.h
+++ b/arch/arm/include/asm/arch-tegra/gpu.h
@@ -11,7 +11,6 @@
#if defined(CONFIG_TEGRA_GPU)
void config_gpu(void);
-bool gpu_configured(void);
#else /* CONFIG_TEGRA_GPU */
@@ -19,11 +18,6 @@ static inline void config_gpu(void)
{
}
-static inline bool gpu_configured(void)
-{
- return false;
-}
-
#endif /* CONFIG_TEGRA_GPU */
#if defined(CONFIG_OF_LIBFDT)
diff --git a/arch/arm/mach-tegra/gpu.c b/arch/arm/mach-tegra/gpu.c
index 4ea046d3e5b6..dc29b79e0126 100644
--- a/arch/arm/mach-tegra/gpu.c
+++ b/arch/arm/mach-tegra/gpu.c
@@ -41,18 +41,13 @@ void config_gpu(void)
_configured = true;
}
-bool vpr_configured(void)
-{
- return _configured;
-}
-
#if defined(CONFIG_OF_LIBFDT)
int gpu_enable_node(void *blob, const char *gpupath)
{
int offset;
- if (vpr_configured()) {
+ if (_configured) {
offset = fdt_path_offset(blob, gpupath);
if (offset > 0) {
fdt_status_okay(blob, offset);
--
2.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 24/28] Drop CONFIG_ISA_KEYBOARD
On Mon, Oct 19, 2015 at 1:17 AM, Simon Glass wrote: > + CONFIG_CROS_EC_KEYB > + Enables a Chrome OS keyboard using the CROS_EC interface. > + This uses CROS_EC to communicate with a second microcontroller > + which provides key scans on request. > + See Kconfig help for available keyboard drivers. This looks like an unrelated change. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 20/28] input: Allow updating of keyboard LEDs
Add a function which returns a new keyboard LED value when the LEDs need
updating.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/input.c | 9 +
include/input.h | 14 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 0cb117f..0f3495f 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -247,6 +247,7 @@ static struct input_key_xlate *process_modifier(struct
input_config *config,
if (config->flags & FLAG_SCROLL_LOCK)
leds |= INPUT_LED_SCROLL;
config->leds = leds;
+ config->leds_changed = flip;
}
}
@@ -558,6 +559,14 @@ void input_allow_repeats(struct input_config *config, bool
allow_repeats)
config->allow_repeats = allow_repeats;
}
+int input_leds_changed(struct input_config *config)
+{
+ if (config->leds_changed)
+ return config->leds;
+
+ return -1;
+}
+
int input_add_tables(struct input_config *config, bool german)
{
int ret;
diff --git a/include/input.h b/include/input.h
index c1af259..ad120e4 100644
--- a/include/input.h
+++ b/include/input.h
@@ -43,7 +43,8 @@ struct input_config {
/* Which modifiers are active (1 bit for each MOD_... value) */
uchar modifiers;
uchar flags;/* active state keys (FLAGS_...) */
- uchar leds; /* active LEDS (INPUT_LED_...) */
+ uchar leds; /* active LEDs (INPUT_LED_...) */
+ uchar leds_changed; /* LEDs that just changed */
uchar num_tables; /* number of modifier tables */
int prev_keycodes[INPUT_BUFFER_LEN];/* keys held last time */
int num_prev_keycodes; /* number of prev keys */
@@ -162,6 +163,17 @@ void input_set_delays(struct input_config *config, int
repeat_delay_ms,
void input_allow_repeats(struct input_config *config, bool allow_repeats);
/**
+ * Check if keyboard LEDs need to be updated
+ *
+ * This can be called after input_tstc() to see if keyboard LEDs need
+ * updating.
+ *
+ * @param config Input state
+ * @return -1 if no LEDs need updating, other value if they do
+ */
+int input_leds_changed(struct input_config *config);
+
+/**
* Set up the key map tables
*
* This must be called after input_init() or keycode decoding will not work.
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 18/28] input: Adjust structure of code in process_modifier()
Move all the '!release' code into one block so that it is clear that it only
applies on key release.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/input.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index d0258a9..3120d1e 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -208,7 +208,6 @@ static struct input_key_xlate *process_modifier(struct
input_config *config,
int key, int release)
{
struct input_key_xlate *table;
- int flip = -1;
int i;
/* Start with the main table, and see what modifiers change it */
@@ -223,6 +222,8 @@ static struct input_key_xlate *process_modifier(struct
input_config *config,
/* Handle the lighted keys */
if (!release) {
+ int flip = -1;
+
switch (key) {
case KEY_SCROLLLOCK:
flip = FLAG_SCROLL_LOCK;
@@ -234,19 +235,19 @@ static struct input_key_xlate *process_modifier(struct
input_config *config,
flip = FLAG_CAPS_LOCK;
break;
}
- }
- if (flip != -1) {
- int leds = 0;
-
- config->leds ^= flip;
- if (config->flags & FLAG_NUM_LOCK)
- leds |= INPUT_LED_NUM;
- if (config->flags & FLAG_CAPS_LOCK)
- leds |= INPUT_LED_CAPS;
- if (config->flags & FLAG_SCROLL_LOCK)
- leds |= INPUT_LED_SCROLL;
- config->leds = leds;
+ if (flip != -1) {
+ int leds = 0;
+
+ config->leds ^= flip;
+ if (config->flags & FLAG_NUM_LOCK)
+ leds |= INPUT_LED_NUM;
+ if (config->flags & FLAG_CAPS_LOCK)
+ leds |= INPUT_LED_CAPS;
+ if (config->flags & FLAG_SCROLL_LOCK)
+ leds |= INPUT_LED_SCROLL;
+ config->leds = leds;
+ }
}
return table;
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 21/28] input: i8042: Convert to use the input library
At present the i8042 driver has its own logic and keymaps. In an effort to
unify the code, move it over to use the input library. This changes most of
the keycode-processing logic since it is now in that library. The main
responsibilities of the driver are now to handle the LEDs, deal with the
PS/2 extended keycodes and initialise the the keyboard.
Signed-off-by: Simon Glass
---
Changes in v2:
- Convert two multi-line comments to single-line comments
- Correct call to input_init()
drivers/input/i8042.c | 493 +++---
1 file changed, 69 insertions(+), 424 deletions(-)
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index b1ada86..270805b 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -7,251 +7,18 @@
/* i8042.c - Intel 8042 keyboard driver routines */
-/* includes */
-
#include
-#include
#include
+#include
+#include
/* defines */
#define in8(p) inb(p)
#define out8(p, v) outb(v, p)
/* locals */
-
-static int kbd_input = -1; /* no input yet */
-static int kbd_mapping = KBD_US; /* default US keyboard */
-static int kbd_flags = NORMAL; /* after reset */
-static int kbd_state; /* unshift code */
-
-static unsigned char kbd_fct_map[144] = {
- /* kbd_fct_map table for scan code */
-0, AS, AS, AS, AS, AS, AS, AS, /* scan 00-07 */
- AS, AS, AS, AS, AS, AS, AS, AS, /* scan 08-0F */
- AS, AS, AS, AS, AS, AS, AS, AS, /* scan 10-17 */
- AS, AS, AS, AS, AS, CN, AS, AS, /* scan 18-1F */
- AS, AS, AS, AS, AS, AS, AS, AS, /* scan 20-27 */
- AS, AS, SH, AS, AS, AS, AS, AS, /* scan 28-2F */
- AS, AS, AS, AS, AS, AS, SH, AS, /* scan 30-37 */
- AS, AS, CP, 0, 0, 0, 0, 0, /* scan 38-3F */
-0, 0, 0, 0, 0, NM, ST, ES, /* scan 40-47 */
- ES, ES, ES, ES, ES, ES, ES, ES, /* scan 48-4F */
- ES, ES, ES, ES, 0, 0, AS, 0, /* scan 50-57 */
-0, 0, 0, 0, 0, 0, 0, 0, /* scan 58-5F */
-0, 0, 0, 0, 0, 0, 0, 0, /* scan 60-67 */
-0, 0, 0, 0, 0, 0, 0, 0, /* scan 68-6F */
- AS, 0, 0, AS, 0, 0, AS, 0, /* scan 70-77 */
-0, AS, 0, 0, 0, AS, 0, 0, /* scan 78-7F */
- AS, CN, AS, AS, AK, ST, EX, EX, /* enhanced */
- AS, EX, EX, AS, EX, AS, EX, EX /* enhanced */
- };
-
-static unsigned char kbd_key_map[2][5][144] = {
- { /* US keyboard */
- { /* unshift code */
- 0, 0x1b, '1', '2', '3', '4', '5', '6', /* scan 00-07 */
-'7', '8', '9', '0', '-', '=', 0x08, '\t', /* scan 08-0F */
-'q', 'w', 'e', 'r', 't', 'y', 'u', 'i', /* scan 10-17 */
-'o', 'p', '[', ']', '\r', CN, 'a', 's', /* scan 18-1F */
-'d', 'f', 'g', 'h', 'j', 'k', 'l', ';', /* scan 20-27 */
- '\'', '`', SH, '\\', 'z', 'x', 'c', 'v', /* scan 28-2F */
-'b', 'n', 'm', ',', '.', '/', SH, '*', /* scan 30-37 */
-' ', ' ', CP,0,0,0,0,0, /* scan 38-3F */
- 0,0,0,0,0, NM, ST, '7', /* scan 40-47 */
-'8', '9', '-', '4', '5', '6', '+', '1', /* scan 48-4F */
-'2', '3', '0', '.',0,0,0,0, /* scan 50-57 */
- 0,0,0,0,0,0,0,0, /* scan 58-5F */
- 0,0,0,0,0,0,0,0, /* scan 60-67 */
- 0,0,0,0,0,0,0,0, /* scan 68-6F */
- 0,0,0,0,0,0,0,0, /* scan 70-77 */
- 0,0,0,0,0,0,0,0, /* scan 78-7F */
- '\r', CN, '/', '*', ' ', ST, 'F', 'A', /* extended */
- 0, 'D', 'C',0, 'B',0, '@', 'P' /* extended */
- },
- { /* shift code */
- 0, 0x1b, '!', '@', '#', '$', '%', '^', /* scan 00-07 */
-'&', '*', '(', ')', '_', '+', 0x08, '\t', /* scan 08-0F */
-'Q', 'W', 'E', 'R', 'T', 'Y', 'U', 'I', /* scan 10-17 */
-'O', 'P', '{', '}', '\r', CN, 'A', 'S', /* scan 18-1F */
-'D', 'F', 'G', 'H', 'J', 'K', 'L', ':', /* scan 20-27 */
-'"', '~', SH, '|', 'Z', 'X', 'C', 'V', /* scan 28-2F */
-'B', 'N', 'M', '<', '>', '?', SH, '*', /* scan 30-37 */
-' ', ' ', CP,0,0,0,0,0, /* scan 38-3F */
- 0,0,0,0,0, NM, ST, '7', /* scan 40-47 */
-'8', '9', '-', '4', '5', '6', '+', '1', /* scan 48-4F */
-'2', '3', '0', '.',0,0,0,0, /* scan 50-57 */
- 0,0,0,0,0,0,0,0, /* scan 58-5F */
- 0,0,0,0,0,0,0,0, /* scan 60-67 */
- 0,0,0,0,0,0,0,0, /* scan 68-6F */
-
[U-Boot] [PATCH v2 22/28] input: Add a Kconfig option for the i8042 keyboard
Add a new option CONFIG_I8042_KEYB which will replace the current CONFIG_I8042_KBD. This new name fits better with existing drivers. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- Changes in v2: None drivers/input/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig index 447c4c3..d560328 100644 --- a/drivers/input/Kconfig +++ b/drivers/input/Kconfig @@ -13,3 +13,13 @@ config CROS_EC_KEYB Most ARM Chromebooks use an EC to provide access to the keyboard. Messages are used to request key scans from the EC and these are then decoded into keys by this driver. + +config I8042_KEYB + bool "Enable Intel i8042 keyboard support" + depends on DM_KEYBOARD + help + This adds a driver for the i8042 keyboard controller, allowing the + keyboard to be used on devices which support this controller. The + driver handles English and German keyboards - set the environment + variable 'keymap' to "de" to select German. Keyboard repeat is + handled by the keyboard itself. -- 2.6.0.rc2.230.g3dd15c0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 16/28] input: Allow repeat filtering to be disabled
Generally the input library handles processing of a list of scanned keys.
Repeated keys need to be generated based on a timer in this case, since all
that is provided is a list of keys current depressed.
Keyboards which do their own scanning will resend codes when they want to
inject a repeating key. Provide a function which tells the input library to
accept repeating keys and not to try to second-guess the caller.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/input.c | 9 +++--
include/input.h | 19 +++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 530bf51..fc1c45c 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -413,8 +413,8 @@ static int _input_send_keycodes(struct input_config
*config, int keycode[],
* insert another character if we later realise that we
* have missed a repeat slot.
*/
- is_repeat = config->repeat_rate_ms &&
- (int)get_timer(config->next_repeat_ms) >= 0;
+ is_repeat = config->allow_repeats || (config->repeat_rate_ms &&
+ (int)get_timer(config->next_repeat_ms) >= 0);
if (!is_repeat)
return 0;
}
@@ -495,6 +495,11 @@ void input_set_delays(struct input_config *config, int
repeat_delay_ms,
config->repeat_rate_ms = repeat_rate_ms;
}
+void input_allow_repeats(struct input_config *config, bool allow_repeats)
+{
+ config->allow_repeats = allow_repeats;
+}
+
int input_add_tables(struct input_config *config)
{
int ret;
diff --git a/include/input.h b/include/input.h
index 9942d6f..e56f500 100644
--- a/include/input.h
+++ b/include/input.h
@@ -57,6 +57,7 @@ struct input_config {
* unknown
*/
int (*read_keys)(struct input_config *config);
+ bool allow_repeats; /* Don't filter out repeats */
unsigned int next_repeat_ms;/* Next time we repeat a key */
unsigned int repeat_delay_ms; /* Time before autorepeat starts */
unsigned int repeat_rate_ms;/* Autorepeat rate in ms */
@@ -143,6 +144,24 @@ void input_set_delays(struct input_config *config, int
repeat_delay_ms,
int repeat_rate_ms);
/**
+ * Tell the input layer whether to allow the caller to determine repeats
+ *
+ * Generally the input library handles processing of a list of scanned keys.
+ * Repeated keys need to be generated based on a timer in this case, since all
+ * that is provided is a list of keys current depressed.
+ *
+ * Keyboards which do their own scanning will resend codes when they want to
+ * inject a repeating key. This function can be called at start-up to select
+ * this behaviour.
+ *
+ * @param config Input state
+ * @param allow_repeatstrue to repeat depressed keys every time
+ * input_send_keycodes() is called, false to do normal
+ * keyboard repeat processing with a timer.
+ */
+void input_allow_repeats(struct input_config *config, bool allow_repeats);
+
+/**
* Set up the key map tables
*
* This must be called after input_init() or keycode decoding will not work.
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 24/28] Drop CONFIG_ISA_KEYBOARD
This option is mentioned but does not do anything. Drop it. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- Changes in v2: None README | 11 ++- board/mpl/pip405/README | 4 include/configs/MIP405.h | 5 - include/configs/PIP405.h | 5 - 4 files changed, 6 insertions(+), 19 deletions(-) diff --git a/README b/README index 99f2b97..6cdf2f0 100644 --- a/README +++ b/README @@ -1775,17 +1775,18 @@ CBFS (Coreboot Filesystem) support a default value of 65536 will be defined. - Keyboard Support: - CONFIG_ISA_KEYBOARD - - Define this to enable standard (PC-Style) keyboard - support - CONFIG_I8042_KBD Standard PC keyboard driver with US (is default) and GERMAN key layout (switch via environment 'keymap=de') support. Export function i8042_kbd_init, i8042_tstc and i8042_getc for cfb_console. Supports cursor blinking. + CONFIG_CROS_EC_KEYB + Enables a Chrome OS keyboard using the CROS_EC interface. + This uses CROS_EC to communicate with a second microcontroller + which provides key scans on request. + See Kconfig help for available keyboard drivers. + - Video support: CONFIG_VIDEO diff --git a/board/mpl/pip405/README b/board/mpl/pip405/README index 012db1c..1b73dbe 100644 --- a/board/mpl/pip405/README +++ b/board/mpl/pip405/README @@ -114,10 +114,6 @@ RTC CONFIG_RTC_MC146818MC146818 RTC support -Keyboard: -- -CONFIG_ISA_KEYBOARDStandard (PC-Style) Keyboard support - Video: -- CONFIG_VIDEO_CT69000 Enable Chips & Technologies 69000 Video chip diff --git a/include/configs/MIP405.h b/include/configs/MIP405.h index cb21b73..5bbc0de 100644 --- a/include/configs/MIP405.h +++ b/include/configs/MIP405.h @@ -364,11 +364,6 @@ #define CONFIG_ISO_PARTITION /* Experimental */ / - * Keyboard support - / -#undef CONFIG_ISA_KEYBOARD - -/ * Video support / #define CONFIG_VIDEO /*To enable video controller support */ diff --git a/include/configs/PIP405.h b/include/configs/PIP405.h index c9d08e6..265fa12 100644 --- a/include/configs/PIP405.h +++ b/include/configs/PIP405.h @@ -321,11 +321,6 @@ #define CONFIG_ISO_PARTITION /* Experimental */ / - * Keyboard support - / -#define CONFIG_ISA_KEYBOARD - -/ * Video support / #define CONFIG_VIDEO /*To enable video controller support */ -- 2.6.0.rc2.230.g3dd15c0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 26/28] i8042: Handle a duplicate power-on-reset response
Sometimes we seem to get 0xaa twice which causes the config read to fail.
This causes chromebook_link to fail to set up the keyboard.
Add a check for this and read the config again when detected.
Signed-off-by: Simon Glass
---
Changes in v2:
- Use device tree to handle this quirk
drivers/input/i8042.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index e5e2926..6d358b7 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -15,13 +15,20 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
/* defines */
#define in8(p) inb(p)
#define out8(p, v) outb(v, p)
+enum {
+ QUICK_DUP_POR = 1 << 0,
+};
+
/* locals */
struct i8042_kbd_priv {
bool extended; /* true if an extended keycode is expected next */
+ int quirks; /* quirks that we support */
};
static unsigned char ext_key_map[] = {
@@ -113,7 +120,7 @@ static int kbd_cmd_write(int cmd, int data)
return kbd_write(I8042_DATA_REG, data);
}
-static int kbd_reset(void)
+static int kbd_reset(int quirk)
{
int config;
@@ -132,6 +139,10 @@ static int kbd_reset(void)
if (config == -1)
goto err;
+ /* Sometimes get a second byte */
+ else if ((quirk & QUICK_DUP_POR) && config == KBD_POR)
+ config = kbd_cmd_read(CMD_RD_CONFIG);
+
config |= CONFIG_AT_TRANS;
config &= ~(CONFIG_KIRQ_EN | CONFIG_MIRQ_EN);
if (kbd_cmd_write(CMD_WR_CONFIG, config))
@@ -246,6 +257,7 @@ static int i8042_kbd_check(struct input_config *input)
static int i8042_start(struct udevice *dev)
{
struct keyboard_priv *uc_priv = dev_get_uclass_priv(dev);
+ struct i8042_kbd_priv *priv = dev_get_priv(dev);
struct input_config *input = &uc_priv->input;
int keymap, try;
char *penv;
@@ -264,7 +276,7 @@ static int i8042_start(struct udevice *dev)
keymap = KBD_GER;
}
- for (try = 0; kbd_reset() != 0; try++) {
+ for (try = 0; kbd_reset(priv->quirks) != 0; try++) {
if (try >= KBD_RESET_TRIES)
return -1;
}
@@ -294,10 +306,15 @@ static int i8042_start(struct udevice *dev)
static int i8042_kbd_probe(struct udevice *dev)
{
struct keyboard_priv *uc_priv = dev_get_uclass_priv(dev);
+ struct i8042_kbd_priv *priv = dev_get_priv(dev);
struct stdio_dev *sdev = &uc_priv->sdev;
struct input_config *input = &uc_priv->input;
int ret;
+ if (fdtdec_get_bool(gd->fdt_blob, dev->of_offset,
+ "intel,duplicate-por"))
+ priv->quirks |= QUICK_DUP_POR;
+
/* Register the device. i8042_start() will be called soon */
input->dev = dev;
input->read_keys = i8042_kbd_check;
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 25/28] input: Convert i8042 to driver model
Adjust this driver to support driver model. The only users are x86 boards
so this should be safe.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/Makefile | 2 +-
drivers/input/i8042.c | 109 ++---
include/i8042.h| 6 ---
3 files changed, 76 insertions(+), 41 deletions(-)
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 9388dfe..5f15265 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -7,7 +7,7 @@
obj-$(CONFIG_DM_KEYBOARD) += keyboard-uclass.o
-obj-$(CONFIG_I8042_KBD) += i8042.o
+obj-$(CONFIG_I8042_KEYB) += i8042.o
obj-$(CONFIG_TEGRA_KEYBOARD) += tegra-kbc.o
obj-$(CONFIG_TWL4030_INPUT) += twl4030.o
obj-$(CONFIG_CROS_EC_KEYB) += cros_ec_keyb.o
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 270805b..e5e2926 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -8,8 +8,11 @@
/* i8042.c - Intel 8042 keyboard driver routines */
#include
+#include
+#include
#include
#include
+#include
#include
/* defines */
@@ -17,8 +20,9 @@
#define out8(p, v) outb(v, p)
/* locals */
-static struct input_config config;
-static bool extended;
+struct i8042_kbd_priv {
+ bool extended; /* true if an extended keycode is expected next */
+};
static unsigned char ext_key_map[] = {
0x1c, /* keypad enter */
@@ -60,12 +64,20 @@ static int kbd_output_full(void)
return kbd_timeout != -1;
}
-static void kbd_led_set(int flags)
+/**
+ * check_leds() - Check the keyboard LEDs and update them it needed
+ *
+ * @ret: Value to return
+ * @return value of @ret
+ */
+static int i8042_kbd_update_leds(struct udevice *dev, int leds)
{
kbd_input_empty();
out8(I8042_DATA_REG, CMD_SET_KBD_LED);
kbd_input_empty();
- out8(I8042_DATA_REG, flags & 0x7);
+ out8(I8042_DATA_REG, leds & 0x7);
+
+ return 0;
}
static int kbd_write(int reg, int value)
@@ -144,6 +156,8 @@ static int kbd_controller_present(void)
/*
* Implement a weak default function for boards that optionally
* need to skip the i8042 initialization.
+ *
+ * TODO(s...@chromium.org): Use device tree for this?
*/
int __weak board_i8042_skip(void)
{
@@ -190,6 +204,8 @@ int i8042_disable(void)
static int i8042_kbd_check(struct input_config *input)
{
+ struct i8042_kbd_priv *priv = dev_get_priv(input->dev);
+
if ((in8(I8042_STS_REG) & STATUS_OBF) == 0) {
return 0;
} else {
@@ -201,15 +217,15 @@ static int i8042_kbd_check(struct input_config *input)
if (scan_code == 0xfa) {
return 0;
} else if (scan_code == 0xe0) {
- extended = true;
+ priv->extended = true;
return 0;
}
if (scan_code & 0x80) {
scan_code &= 0x7f;
release = true;
}
- if (extended) {
- extended = false;
+ if (priv->extended) {
+ priv->extended = false;
for (i = 0; ext_key_map[i]; i++) {
if (ext_key_map[i] == scan_code) {
scan_code = 0x60 + i;
@@ -221,21 +237,23 @@ static int i8042_kbd_check(struct input_config *input)
return 0;
}
- input_add_keycode(&config, scan_code, release);
+ input_add_keycode(input, scan_code, release);
return 1;
}
}
/* i8042_kbd_init - reset keyboard and init state flags */
-int i8042_kbd_init(void)
+static int i8042_start(struct udevice *dev)
{
+ struct keyboard_priv *uc_priv = dev_get_uclass_priv(dev);
+ struct input_config *input = &uc_priv->input;
int keymap, try;
char *penv;
int ret;
if (!kbd_controller_present() || board_i8042_skip()) {
debug("i8042 keyboard controller is not present\n");
- return -1;
+ return -ENOENT;
}
/* Init keyboard device (default US layout) */
@@ -251,42 +269,65 @@ int i8042_kbd_init(void)
return -1;
}
- ret = input_init(&config, keymap == KBD_GER);
+ ret = input_add_tables(input, keymap == KBD_GER);
if (ret)
return ret;
- config.read_keys = i8042_kbd_check;
- input_allow_repeats(&config, true);
- kbd_led_set(NORMAL);
+ i8042_kbd_update_leds(dev, NORMAL);
+ debug("%s: started\n", __func__);
return 0;
}
/**
- * check_leds() - Check the keyboard LEDs and update them it needed
+ * Set up the i8042 keyboard. This is called by the stdio device handler
*
- * @ret: Value to return
- * @return value of @ret
+ * We want to do this init when the keyboard is actually used rather t
Re: [U-Boot] [PATCH v2 5/5] x86: chromebook_link: Enable the debug UART
On Mon, Oct 19, 2015 at 9:51 AM, Simon Glass wrote:
> Add support for the debug UART on link. This is useful for early debugging.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/ivybridge/cpu.c | 7 +++
> configs/chromebook_link_defconfig | 4
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
> index cce5923..0e6512c 100644
> --- a/arch/x86/cpu/ivybridge/cpu.c
> +++ b/arch/x86/cpu/ivybridge/cpu.c
> @@ -340,3 +340,10 @@ int print_cpuinfo(void)
>
> return 0;
> }
> +
> +void board_debug_uart_init(void)
> +{
> + /* This enables the debug UART */
> + pci_x86_write_config(NULL, PCH_LPC_DEV, LPC_EN, COMA_LPC_EN,
> +PCI_SIZE_16);
> +}
> diff --git a/configs/chromebook_link_defconfig
> b/configs/chromebook_link_defconfig
> index fbecf8b..78a9470 100644
> --- a/configs/chromebook_link_defconfig
> +++ b/configs/chromebook_link_defconfig
> @@ -22,6 +22,10 @@ CONFIG_CROS_EC_LPC=y
> CONFIG_SPI_FLASH=y
> CONFIG_DM_PCI=y
> CONFIG_DM_RTC=y
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEBUG_UART_BASE=0x3f8
> +CONFIG_DEBUG_UART_CLOCK=1843200
> +CONFIG_DEBUG_UART_BOARD_INIT=y
> CONFIG_DM_TPM=y
> CONFIG_TPM_TIS_LPC=y
> CONFIG_VIDEO_VESA=y
> --
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 19/28] input: Handle caps lock
When caps lock is enabled we should convert lower case to upper case. Add
this to the input key processing so that caps lock works correctly.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/input.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 3120d1e..0cb117f 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -424,16 +424,19 @@ static int input_keycodes_to_ascii(struct input_config
*config,
/* Start conversion by looking for the first new keycode (by same). */
for (i = same; i < num_keycodes; i++) {
int key = keycode[i];
- int ch = (key < table->num_entries) ? table->xlate[key] : 0xff;
+ int ch;
/*
* For a normal key (with an ASCII value), add it; otherwise
* translate special key to escape sequence if possible.
*/
- if (ch != 0xff) {
- if (ch_count < max_chars)
- output_ch[ch_count] = (uchar)ch;
- ch_count++;
+ if (key < table->num_entries) {
+ ch = table->xlate[key];
+ if ((config->flags & FLAG_CAPS_LOCK) &&
+ ch >= 'a' && ch <= 'z')
+ ch -= 'a' - 'A';
+ if (ch_count < max_chars && ch != 0xff)
+ output_ch[ch_count++] = (uchar)ch;
} else {
ch_count += input_keycode_to_ansi364(config, key,
output_ch, max_chars);
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 28/28] input: Convert 'keyboard' driver to use input library
This has duplicated scan code tables and logic. We can use the input
library to implement most of the features here.
This needs testing. The only supported board appears to be TQM5200.
Unfortunately no maintainer is listed for this board.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/keyboard.c | 290 +++
include/keyboard.h | 5 +
2 files changed, 43 insertions(+), 252 deletions(-)
diff --git a/drivers/input/keyboard.c b/drivers/input/keyboard.c
index be0f333..0836c63 100644
--- a/drivers/input/keyboard.c
+++ b/drivers/input/keyboard.c
@@ -9,290 +9,76 @@
***/
#include
-
-#include
+#include
#include
+#include
-#undef KBG_DEBUG
-
-#ifdef KBG_DEBUG
-#definePRINTF(fmt,args...) printf (fmt ,##args)
-#else
-#define PRINTF(fmt,args...)
-#endif
-
-
-#defineDEVNAME "kbd"
-
-#defineLED_SCR 0x01/* scroll lock led */
-#defineLED_CAP 0x04/* caps lock led */
-#defineLED_NUM 0x02/* num lock led */
-
-#defineKBD_BUFFER_LEN 0x20 /* size of the keyboardbuffer */
+static struct input_config config;
-#if defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC8540) ||
defined(CONFIG_MPC8541) || defined(CONFIG_MPC8555)
-int ps2ser_check(void);
+static int kbd_read_keys(struct input_config *config)
+{
+#if defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC8540) || \
+ defined(CONFIG_MPC8541) || defined(CONFIG_MPC8555)
+ /* no ISR is used, so received chars must be polled */
+ ps2ser_check();
#endif
-static volatile char kbd_buffer[KBD_BUFFER_LEN];
-static volatile int in_pointer = 0;
-static volatile int out_pointer = 0;
+ return 1;
+}
-static unsigned char leds = 0;
-static unsigned char num_lock = 0;
-static unsigned char caps_lock = 0;
-static unsigned char scroll_lock = 0;
-static unsigned char shift = 0;
-static unsigned char ctrl = 0;
-static unsigned char alt = 0;
-static unsigned char e0 = 0;
+static int check_leds(int ret)
+{
+ int leds;
-/**
- * Queue handling
- **/
+ leds = input_leds_changed(&config);
+ if (leds >= 0)
+ pckbd_leds(leds);
-/* puts character in the queue and sets up the in and out pointer */
-static void kbd_put_queue(char data)
-{
- if((in_pointer+1)==KBD_BUFFER_LEN) {
- if(out_pointer==0) {
- return; /* buffer full */
- } else{
- in_pointer=0;
- }
- } else {
- if((in_pointer+1)==out_pointer)
- return; /* buffer full */
- in_pointer++;
- }
- kbd_buffer[in_pointer]=data;
- return;
+ return ret;
}
/* test if a character is in the queue */
static int kbd_testc(struct stdio_dev *dev)
{
-#if defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC8540) ||
defined(CONFIG_MPC8541) || defined(CONFIG_MPC8555)
- /* no ISR is used, so received chars must be polled */
- ps2ser_check();
-#endif
- if(in_pointer==out_pointer)
- return(0); /* no data */
- else
- return(1);
+ return check_leds(input_tstc(&config));
}
/* gets the character from the queue */
static int kbd_getc(struct stdio_dev *dev)
{
- char c;
- while(in_pointer==out_pointer) {
-#if defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC8540) ||
defined(CONFIG_MPC8541) || defined(CONFIG_MPC8555)
- /* no ISR is used, so received chars must be polled */
- ps2ser_check();
-#endif
- ;}
- if((out_pointer+1)==KBD_BUFFER_LEN)
- out_pointer=0;
- else
- out_pointer++;
- c=kbd_buffer[out_pointer];
- return (int)c;
-
+ return check_leds(input_getc(&config));
}
-/* Simple translation table for the keys */
-
-static unsigned char kbd_plain_xlate[] = {
- 0xff,0x1b, '1', '2', '3', '4', '5', '6', '7', '8', '9', '0', '-',
'=','\b','\t',/* 0x00 - 0x0f */
-'q', 'w', 'e', 'r', 't', 'y', 'u', 'i', 'o', 'p', '[', ']','\r',0xff,
'a', 's',/* 0x10 - 0x1f */
-'d', 'f', 'g', 'h', 'j', 'k', 'l', ';','\'', '`',0xff,'\\', 'z', 'x',
'c', 'v',/* 0x20 - 0x2f */
-'b', 'n', 'm', ',', '.', '/',0xff,0xff,0xff, '
',0xff,0xff,0xff,0xff,0xff,0xff,/* 0x30 - 0x3f */
- 0xff,0xff,0xff,0xff,0xff,0xff,0xff, '7', '8', '9', '-', '4', '5', '6',
'+', '1',/* 0x40 - 0x4f */
-'2', '3', '0',
'.',0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff, /* 0x50 -
0x5F */
- '\r',0xff,0xff
- };
-
-static unsigned char kbd_shift_xlate[] = {
- 0xff,0x1b, '!', '@', '#', '$', '%', '^', '&', '*', '(', ')', '_',
'+',
[U-Boot] [PATCH v2 27/28] video: input: Clean up after i8042 conversion
Now that i8042 uses driver model, adjust other mentions of it and remove old code that is no-longer used. Update the README and unify the keyboard text into one place. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- Changes in v2: None README | 33 +++-- drivers/video/cfb_console.c | 20 2 files changed, 15 insertions(+), 38 deletions(-) diff --git a/README b/README index 6cdf2f0..6436fa4 100644 --- a/README +++ b/README @@ -875,11 +875,11 @@ The following options need to be configured: (0-5, cf. cfb_console.c) VIDEO_FB_ADRS framebuffer address VIDEO_KBD_INIT_FCT keyboard int fct - (i.e. i8042_kbd_init()) + (i.e. rx51_kp_init()) VIDEO_TSTC_FCT test char fct - (i.e. i8042_tstc) + (i.e. rx51_kp_tstc) VIDEO_GETC_FCT get char fct - (i.e. i8042_getc) + (i.e. rx51_kp_getc) CONFIG_VIDEO_LOGO display Linux logo in upper left corner CONFIG_VIDEO_BMP_LOGO use bmp_logo.h instead of @@ -1775,18 +1775,16 @@ CBFS (Coreboot Filesystem) support a default value of 65536 will be defined. - Keyboard Support: - CONFIG_I8042_KBD - Standard PC keyboard driver with US (is default) and - GERMAN key layout (switch via environment 'keymap=de') support. - Export function i8042_kbd_init, i8042_tstc and i8042_getc - for cfb_console. Supports cursor blinking. - - CONFIG_CROS_EC_KEYB - Enables a Chrome OS keyboard using the CROS_EC interface. - This uses CROS_EC to communicate with a second microcontroller - which provides key scans on request. See Kconfig help for available keyboard drivers. + CONFIG_KEYBOARD + + Define this to enable a custom keyboard support. + This simply calls drv_keyboard_init() which must be + defined in your board-specific files. This option is deprecated + and is only used by novena. For new boards, driver model + instead. + - Video support: CONFIG_VIDEO @@ -1846,15 +1844,6 @@ CBFS (Coreboot Filesystem) support boot. See the documentation file README.video for a description of this variable. - -- Keyboard Support: - CONFIG_KEYBOARD - - Define this to enable a custom keyboard support. - This simply calls drv_keyboard_init() which must be - defined in your board-specific files. - The only board using this so far is RBC823. - - LCD Support: CONFIG_LCD Define this to enable LCD support (for output to LCD diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c index 1b5c3e0..fde0bd4 100644 --- a/drivers/video/cfb_console.c +++ b/drivers/video/cfb_console.c @@ -15,8 +15,10 @@ * logo can be placed in the upper left corner and additional board * information strings (that normally goes to serial port) can be drawn. * - * The console driver can use the standard PC keyboard interface (i8042) - * for character input. Character output goes to a memory mapped video + * The console driver can use a keyboard interface for character input + * but this is deprecated. Only rk51 uses it. + * + * Character output goes to a memory-mapped video * framebuffer with little or big-endian organisation. * With environment setting 'console=serial' the console i/o can be * forced to serial port. @@ -38,7 +40,6 @@ * VIDEO_DATA_FORMAT - graphical data format GDF * VIDEO_FB_ADRS - start of video memory * - * CONFIG_I8042_KBD - AT Keyboard driver for i8042 * VIDEO_KBD_INIT_FCT- init function for keyboard * VIDEO_TSTC_FCT- keyboard_tstc function * VIDEO_GETC_FCT- keyboard_getc function @@ -158,19 +159,6 @@ #define VIDEO_FB_ADRS (pGD->frameAdrs) /* - * Console device defines with i8042 keyboard controller - * Any other keyboard controller must change this section - */ - -#ifdef CONFIG_I8042_KBD -#include - -#define VIDEO_KBD_INIT_FCT i8042_kbd_init() -#define VIDEO_TSTC_FCT i8042_tstc -#define VIDEO_GETC_FCT i8042_getc -#endif - -/* * Console device */ -- 2.6.0.rc2.230.g3dd15c0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listi
Re: [U-Boot] [PATCH v2 4/5] x86: Init the debug UART if enabled
On Mon, Oct 19, 2015 at 9:51 AM, Simon Glass wrote: > If the debug UART is enabled, get it ready for use at the earliest possible > opportunity. This is not actually very early, but until we have a stack it > is difficult to make it work. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Remove comment block since we now always enable the debug UART > - Use a tab after the 'call' instruction > > arch/x86/cpu/start.S | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S > index d072825..5b4ee79 100644 > --- a/arch/x86/cpu/start.S > +++ b/arch/x86/cpu/start.S > @@ -126,14 +126,9 @@ car_init_ret: > callboard_init_f_mem > mov %eax, %esp > > - /* > -* Debug UART is available here although it may not be plumbed out > -* to pins depending on the board. To use it: > -* > -* call debug_uart_init > -* mov $'a', %eax > -* call printch > -*/ > +#ifdef CONFIG_DEBUG_UART > + calldebug_uart_init > +#endif > > /* Get address of global_data */ > mov %fs:0, %edx > -- Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 17/28] input: Support the German keymap
Add support for the German keymap, taken from i8042.c. This can be selected
when the input library it initialised.
Signed-off-by: Simon Glass
---
Changes in v2:
- Update input_add_tables() to add error checking
board/kosagi/novena/novena.c | 2 +-
drivers/input/cros_ec_keyb.c | 2 +-
drivers/input/input.c| 107 ++-
drivers/input/tegra-kbc.c| 2 +-
include/input.h | 3 +-
5 files changed, 100 insertions(+), 16 deletions(-)
diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
index 48cbb0f..0b61365 100644
--- a/board/kosagi/novena/novena.c
+++ b/board/kosagi/novena/novena.c
@@ -88,7 +88,7 @@ int drv_keyboard_init(void)
debug("%s: Cannot set up input\n", __func__);
return -1;
}
- input_add_tables(&button_input);
+ input_add_tables(&button_input, false);
button_input.read_keys = novena_gpio_button_read_keys;
error = input_stdio_register(&dev);
diff --git a/drivers/input/cros_ec_keyb.c b/drivers/input/cros_ec_keyb.c
index fe5caea..9bc4555 100644
--- a/drivers/input/cros_ec_keyb.c
+++ b/drivers/input/cros_ec_keyb.c
@@ -211,7 +211,7 @@ static int cros_ec_kbd_probe(struct udevice *dev)
priv->input = input;
input->dev = dev;
- input_add_tables(input);
+ input_add_tables(input, false);
input->read_keys = cros_ec_kbc_check;
strcpy(sdev->name, "cros-ec-keyb");
diff --git a/drivers/input/input.c b/drivers/input/input.c
index fc1c45c..d0258a9 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -78,6 +78,60 @@ static unsigned char kbd_ctrl_xlate[] = {
'\r', 0xff, '/', '*',
};
+static const uchar kbd_plain_xlate_german[] = {
+ 0xff, 0x1b, '1', '2', '3', '4', '5', '6', /* scan 00-07 */
+'7', '8', '9', '0', 0xe1, '\'', 0x08, '\t', /* scan 08-0F */
+'q', 'w', 'e', 'r', 't', 'z', 'u', 'i', /* scan 10-17 */
+'o', 'p', 0x81, '+', '\r', 0xff, 'a', 's', /* scan 18-1F */
+'d', 'f', 'g', 'h', 'j', 'k', 'l', 0x94, /* scan 20-27 */
+ 0x84, '^', 0xff, '#', 'y', 'x', 'c', 'v', /* scan 28-2F */
+'b', 'n', 'm', ',', '.', '-', 0xff, '*', /* scan 30-37 */
+' ', ' ', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 38-3F */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, '7', /* scan 40-47 */
+'8', '9', '-', '4', '5', '6', '+', '1', /* scan 48-4F */
+'2', '3', '0', ',', 0xff, 0xff, '<', 0xff, /* scan 50-57 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 58-5F */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 60-67 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 68-6F */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 70-77 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 78-7F */
+ '\r', 0xff, '/', '*',
+};
+
+static unsigned char kbd_shift_xlate_german[] = {
+ 0xff, 0x1b, '!', '"', 0x15, '$', '%', '&', /* scan 00-07 */
+'/', '(', ')', '=', '?', '`', 0x08, '\t', /* scan 08-0F */
+'Q', 'W', 'E', 'R', 'T', 'Z', 'U', 'I', /* scan 10-17 */
+'O', 'P', 0x9a, '*', '\r', 0xff, 'A', 'S', /* scan 18-1F */
+'D', 'F', 'G', 'H', 'J', 'K', 'L', 0x99, /* scan 20-27 */
+ 0x8e, 0xf8, 0xff, '\'', 'Y', 'X', 'C', 'V', /* scan 28-2F */
+'B', 'N', 'M', ';', ':', '_', 0xff, '*', /* scan 30-37 */
+' ', ' ', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 38-3F */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, '7', /* scan 40-47 */
+'8', '9', '-', '4', '5', '6', '+', '1', /* scan 48-4F */
+'2', '3', '0', ',', 0xff, 0xff, '>', 0xff, /* scan 50-57 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 58-5F */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 60-67 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 68-6F */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 70-77 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 78-7F */
+ '\r', 0xff, '/', '*',
+};
+
+static unsigned char kbd_right_alt_xlate_german[] = {
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 00-07 */
+'{', '[', ']', '}', '\\', 0xff, 0xff, 0xff, /* scan 08-0F */
+'@', 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 10-17 */
+ 0xff, 0xff, 0xff, '~', 0xff, 0xff, 0xff, 0xff, /* scan 18-1F */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 20-27 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 28-2F */
+ 0xff, 0xff, 0xe6, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 30-37 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 38-3F */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* scan 40-47 */
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
[U-Boot] [PATCH v2 07/28] dm: tegra: Convert keyboard driver to driver model
Adjust the tegra keyboard driver to support driver model, using the new
uclass. Make this the default for all Tegra boards so that those that use
a keyboard will build correctly with this driver.
Signed-off-by: Simon Glass
---
Changes in v2: None
arch/arm/mach-tegra/Kconfig | 1 +
drivers/input/tegra-kbc.c | 243
include/fdtdec.h| 1 -
lib/fdtdec.c| 1 -
4 files changed, 112 insertions(+), 134 deletions(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index a5b7e0d..de2454e 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -12,6 +12,7 @@ config TEGRA_ARMV7_COMMON
select DM_I2C
select DM_SPI
select DM_GPIO
+ select DM_KEYBOARD
choice
prompt "Tegra SoC select"
diff --git a/drivers/input/tegra-kbc.c b/drivers/input/tegra-kbc.c
index 3310f84..a7137f1 100644
--- a/drivers/input/tegra-kbc.c
+++ b/drivers/input/tegra-kbc.c
@@ -6,8 +6,10 @@
*/
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -40,14 +42,13 @@ enum {
};
/* keyboard controller config and state */
-static struct keyb {
- struct input_config input; /* The input layer */
+struct tegra_kbd_priv {
+ struct input_config *input; /* The input layer */
struct key_matrix matrix; /* The key matrix layer */
struct kbc_tegra *kbc; /* tegra keyboard controller */
unsigned char inited; /* 1 if keyboard has been inited */
unsigned char first_scan; /* 1 if this is our first key scan */
- unsigned char created; /* 1 if driver has been created */
/*
* After init we must wait a short time before polling the keyboard.
@@ -58,17 +59,17 @@ static struct keyb {
unsigned int start_time_ms; /* Time that we inited (in ms) */
unsigned int last_poll_ms; /* Time we should last polled */
unsigned int next_repeat_ms;/* Next time we repeat a key */
-} config;
+};
/**
* reads the keyboard fifo for current keypresses
*
- * @param config Keyboard config
+ * @param priv Keyboard private data
* @param fifo Place to put fifo results
* @param max_keycodes Maximum number of key codes to put in the fifo
* @return number of items put into fifo
*/
-static int tegra_kbc_find_keys(struct keyb *config, int *fifo,
+static int tegra_kbc_find_keys(struct tegra_kbd_priv *priv, int *fifo,
int max_keycodes)
{
struct key_matrix_key keys[KBC_MAX_KPENT], *key;
@@ -78,7 +79,7 @@ static int tegra_kbc_find_keys(struct keyb *config, int *fifo,
for (key = keys, i = 0; i < KBC_MAX_KPENT; i++, key++) {
/* Get next word */
if (!(i & 3))
- kp_ent = readl(&config->kbc->kp_ent[i / 4]);
+ kp_ent = readl(&priv->kbc->kp_ent[i / 4]);
key->valid = (kp_ent & KBC_KPENT_VALID) != 0;
key->row = (kp_ent >> 3) & 0xf;
@@ -87,7 +88,7 @@ static int tegra_kbc_find_keys(struct keyb *config, int *fifo,
/* Shift to get next entry */
kp_ent >>= 8;
}
- return key_matrix_decode(&config->matrix, keys, KBC_MAX_KPENT, fifo,
+ return key_matrix_decode(&priv->matrix, keys, KBC_MAX_KPENT, fifo,
max_keycodes);
}
@@ -106,10 +107,10 @@ static int tegra_kbc_find_keys(struct keyb *config, int
*fifo,
* Note: if fifo_cnt is 0, we will tell the input layer that no keys are
* pressed.
*
- * @param config Keyboard config
+ * @param priv Keyboard private data
* @param fifo_cnt Number of entries in the keyboard fifo
*/
-static void process_fifo(struct keyb *config, int fifo_cnt)
+static void process_fifo(struct tegra_kbd_priv *priv, int fifo_cnt)
{
int fifo[KBC_MAX_KPENT];
int cnt = 0;
@@ -117,9 +118,9 @@ static void process_fifo(struct keyb *config, int fifo_cnt)
/* Always call input_send_keycodes() at least once */
do {
if (fifo_cnt)
- cnt = tegra_kbc_find_keys(config, fifo, KBC_MAX_KPENT);
+ cnt = tegra_kbc_find_keys(priv, fifo, KBC_MAX_KPENT);
- input_send_keycodes(&config->input, fifo, cnt);
+ input_send_keycodes(priv->input, fifo, cnt);
} while (--fifo_cnt > 0);
}
@@ -127,24 +128,24 @@ static void process_fifo(struct keyb *config, int
fifo_cnt)
* Check the keyboard controller and emit ASCII characters for any keys that
* are pressed.
*
- * @param config Keyboard config
+ * @param priv Keyboard private data
*/
-static void check_for_keys(struct keyb *config)
+static void check_for_keys(struct tegra_kbd_priv *priv)
{
int fifo_cnt;
- if (!config->first_scan &&
- get_timer(
[U-Boot] [PATCH v2 23/28] x86: Add an i8042 device for boards that have it
Some boards have an i8042 device. Enable the driver for all x86 boards, and
add a device tree node for those which may have this keyboard.
Also adjust the configuration so that i8042 is always separate from the VGA,
and rename the stdin driver accordingly. With this commit the keyboard will
not work, but it is fixed in the next commit.
Signed-off-by: Simon Glass
---
Changes in v2:
- Drop CONFIG_VGA_AS_SINGLE_DEVICE from all x86 board config files
arch/x86/Kconfig | 6 ++
arch/x86/dts/bayleybay.dts | 1 +
arch/x86/dts/chromebook_link.dts | 5 +
arch/x86/dts/keyboard.dtsi | 5 +
doc/device-tree-bindings/input/i8042.txt | 10 ++
include/configs/bayleybay.h | 3 ---
include/configs/chromebox_panther.h | 2 --
include/configs/minnowmax.h | 1 -
include/configs/x86-chromebook.h | 2 +-
include/configs/x86-common.h | 2 +-
10 files changed, 29 insertions(+), 8 deletions(-)
create mode 100644 arch/x86/dts/keyboard.dtsi
create mode 100644 doc/device-tree-bindings/input/i8042.txt
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5e42d7d..72a66ea 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -401,6 +401,12 @@ config PCIE_ECAM_SIZE
so a default 0x1000 size covers all of the 256 buses which is the
maximum number of PCI buses as defined by the PCI specification.
+config I8042_KEYB
+ default y
+
+config DM_KEYBOARD
+ default y
+
source "arch/x86/lib/efi/Kconfig"
endmenu
diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index d646987..58d97c8 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -10,6 +10,7 @@
#include
/include/ "skeleton.dtsi"
+/include/ "keyboard.dtsi"
/include/ "serial.dtsi"
/include/ "rtc.dtsi"
diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts
index 4291141..f09868b 100644
--- a/arch/x86/dts/chromebook_link.dts
+++ b/arch/x86/dts/chromebook_link.dts
@@ -1,6 +1,7 @@
/dts-v1/;
/include/ "skeleton.dtsi"
+/include/ "keyboard.dtsi"
/include/ "serial.dtsi"
/include/ "rtc.dtsi"
@@ -41,6 +42,10 @@
stdout-path = "/serial";
};
+ keyboard {
+ intel,duplicate-por;
+ };
+
spd {
compatible = "memory-spd";
#address-cells = <1>;
diff --git a/arch/x86/dts/keyboard.dtsi b/arch/x86/dts/keyboard.dtsi
new file mode 100644
index 000..000751b
--- /dev/null
+++ b/arch/x86/dts/keyboard.dtsi
@@ -0,0 +1,5 @@
+/ {
+ keyboard {
+ compatible = "intel,i8042-keyboard";
+ };
+};
diff --git a/doc/device-tree-bindings/input/i8042.txt
b/doc/device-tree-bindings/input/i8042.txt
new file mode 100644
index 000..cd079c2
--- /dev/null
+++ b/doc/device-tree-bindings/input/i8042.txt
@@ -0,0 +1,10 @@
+i8042 Keyboard
+
+The Intel i8042 is a keyboard controller used on many x86 PCs.
+
+Required properties:
+- compatible: "intel,i8042-keyboard"
+
+Optional properties:
+- intel,duplicate-por: Indicates that a keyboard reset may result in a
+ duplicate POR byte, which should be ignored.
diff --git a/include/configs/bayleybay.h b/include/configs/bayleybay.h
index 1ba2998..ac6b45b 100644
--- a/include/configs/bayleybay.h
+++ b/include/configs/bayleybay.h
@@ -33,9 +33,6 @@
#define CONFIG_MMC_SDMA
#define CONFIG_CMD_MMC
-/* BayTrail IGD support */
-#define CONFIG_VGA_AS_SINGLE_DEVICE
-
/* Environment configuration */
#define CONFIG_ENV_SECT_SIZE 0x1000
#define CONFIG_ENV_OFFSET 0x006ff000
diff --git a/include/configs/chromebox_panther.h
b/include/configs/chromebox_panther.h
index dc732b8..00fe26d 100644
--- a/include/configs/chromebox_panther.h
+++ b/include/configs/chromebox_panther.h
@@ -14,6 +14,4 @@
/* Avoid a warning in the Realtek Ethernet driver */
#define CONFIG_SYS_CACHELINE_SIZE 16
-#define CONFIG_VGA_AS_SINGLE_DEVICE
-
#endif /* __CONFIG_H */
diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
index 53d86a2..c90af40 100644
--- a/include/configs/minnowmax.h
+++ b/include/configs/minnowmax.h
@@ -43,7 +43,6 @@
#define VIDEO_IO_OFFSET0
#define CONFIG_X86EMU_RAW_IO
-#define CONFIG_VGA_AS_SINGLE_DEVICE
#define CONFIG_FIT_SIGNATURE
#define CONFIG_RSA
diff --git a/include/configs/x86-chromebook.h b/include/configs/x86-chromebook.h
index 2be8850..4ff8b94 100644
--- a/include/configs/x86-chromebook.h
+++ b/include/configs/x86-chromebook.h
@@ -51,7 +51,7 @@
#define CONFIG_ENV_IS_IN_SPI_FLASH
#define CONFIG_ENV_OFFSET 0x003f8000
-#define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,vga,serial\0" \
+#define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,i8042-kbd,serial\0" \
"stdout=vga,serial\0" \
"stderr=vga,serial\0"
diff --git a/include/configs/x
Re: [U-Boot] [PATCH v2 3/5] debug_uart: Add an option to announce the debug UART
On Mon, Oct 19, 2015 at 9:51 AM, Simon Glass wrote:
> It is useful to see a message from the debug UART early during boot so that
> you know things are working. Add an option to enable this. The message will
> be displayed as soon as debug_uart_init() is called.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> drivers/serial/Kconfig | 10 ++
> include/debug_uart.h | 7 +++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index 39f6500..ac5920a 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -120,6 +120,16 @@ config DEBUG_UART_BOARD_INIT
> here that is needed to set up the UART ready for use, such as set
> pin multiplexing or enable clocks.
>
> +config DEBUG_UART_ANNOUNCE
> + bool "Show a message when the debug UART starts up"
> + depends on DEBUG_UART
> + help
> + Enable this option to show a message when the debug UART is ready
> + for use. You will see a message like " " as soon as
> + U-Boot has the UART ready for use (i.e. your code calls
> + debug_uart_init()). This can be useful just as a check that
> + everything is working.
> +
> config ROCKCHIP_SERIAL
> bool "Rockchip on-chip UART support"
> depends on ARCH_ROCKCHIP && DM_SERIAL
> diff --git a/include/debug_uart.h b/include/debug_uart.h
> index a6b7ce8..5d5349b 100644
> --- a/include/debug_uart.h
> +++ b/include/debug_uart.h
> @@ -105,6 +105,12 @@ void printhex4(uint value);
> */
> void printhex8(uint value);
>
> +#ifdef CONFIG_DEBUG_UART_ANNOUNCE
> +#define _DEBUG_UART_ANNOUNCE printascii(" ");
> +#else
> +#define _DEBUG_UART_ANNOUNCE
> +#endif
> +
> /*
> * Now define some functions - this should be inserted into the serial driver
> */
> @@ -151,6 +157,7 @@ void printhex8(uint value);
> { \
> board_debug_uart_init(); \
> _debug_uart_init(); \
> + _DEBUG_UART_ANNOUNCE \
> } \
>
> #endif
> --
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 13/28] input: Correct keycode for Ctrl-Y
This code is currently incorrect, perhaps due to a typo. Fix it.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 82e8381..a6834cf 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -65,7 +65,7 @@ static unsigned char kbd_shift_xlate[] = {
static unsigned char kbd_ctrl_xlate[] = {
0xff, 0x1b, '1', 0x00, '3', '4', '5', 0x1E,
'7', '8', '9', '0', 0x1F, '=', '\b', '\t', /* 0x00 - 0x0f */
- 0x11, 0x17, 0x05, 0x12, 0x14, 0x18, 0x15, 0x09,
+ 0x11, 0x17, 0x05, 0x12, 0x14, 0x19, 0x15, 0x09,
0x0f, 0x10, 0x1b, 0x1d, '\n', 0xff, 0x01, 0x13, /* 0x10 - 0x1f */
0x04, 0x06, 0x08, 0x09, 0x0a, 0x0b, 0x0c, ';',
'\'', '~', 0x00, 0x1c, 0x1a, 0x18, 0x03, 0x16, /* 0x20 - 0x2f */
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 14/28] input: Add a few more keyboard keycodes
The slash and * are missing from the keycode tables. Add these so that
these keypad keys can be used.
Signed-off-by: Simon Glass
---
Changes in v2:
- Fix extra space in commit message
drivers/input/input.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index a6834cf..e65942e 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -43,7 +43,7 @@ static const uchar kbd_plain_xlate[] = {
'8', '9', '-', '4', '5', '6', '+', '1', /* 0x40 - 0x4f */
'2', '3', '0', '.', 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 0x50 - 0x5F */
- '\r', 0xff, 0xff
+ '\r', 0xff, '/', '*',
};
static unsigned char kbd_shift_xlate[] = {
@@ -59,7 +59,7 @@ static unsigned char kbd_shift_xlate[] = {
'8', '9', '-', '4', '5', '6', '+', '1', /* 0x40 - 0x4f */
'2', '3', '0', '.', 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 0x50 - 0x5F */
- '\r', 0xff, 0xff
+ '\r', 0xff, '/', '*',
};
static unsigned char kbd_ctrl_xlate[] = {
@@ -75,7 +75,7 @@ static unsigned char kbd_ctrl_xlate[] = {
'8', '9', '-', '4', '5', '6', '+', '1', /* 0x40 - 0x4f */
'2', '3', '0', '.', 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 0x50 - 0x5F */
- '\r', 0xff, 0xff
+ '\r', 0xff, '/', '*',
};
/*
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 09/28] video: Drop unused console functions
CONFIG_CONSOLE_CURSOR, CONFIG_SYS_CONSOLE_BLINK_COUNT and
CONFIG_CONSOLE_TIME are not used by any board. The implementation is not
great and stands in the way of a refactor of i8042. Drop these for now.
They can be re-introduced quite easily later, perhaps with driver-model
real-time-clock (RTC) support.
When reintroducing, it might be useful to make a few changes:
- Blink time would be more useful than blink count
- The confusing #ifdefs should be avoided
- The time functions should support driver model
- It would be best keyed off console_tstc() or some similar idle loop
rather than a particular input driver (i8042 in this case)
Signed-off-by: Simon Glass
---
Changes in v2:
- Update commit message to explain what RTC means
README| 7 -
drivers/input/i8042.c | 23
drivers/video/cfb_console.c | 62 +++
include/configs/MPC8536DS.h | 1 -
include/configs/MPC8544DS.h | 1 -
include/configs/MPC8572DS.h | 1 -
include/configs/MPC8641HPCN.h | 1 -
7 files changed, 9 insertions(+), 87 deletions(-)
diff --git a/README b/README
index d381422..99f2b97 100644
--- a/README
+++ b/README
@@ -880,13 +880,6 @@ The following options need to be configured:
(i.e. i8042_tstc)
VIDEO_GETC_FCT get char fct
(i.e. i8042_getc)
- CONFIG_CONSOLE_CURSOR cursor drawing on/off
- (requires blink timer
- cf. i8042.c)
- CONFIG_SYS_CONSOLE_BLINK_COUNT blink interval (cf.
i8042.c)
- CONFIG_CONSOLE_TIME display time/date info in
- upper right corner
- (requires CONFIG_CMD_DATE)
CONFIG_VIDEO_LOGO display Linux logo in
upper left corner
CONFIG_VIDEO_BMP_LOGO use bmp_logo.h instead of
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 9b5fa32..7b95b21 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -17,12 +17,6 @@
#define in8(p) inb(p)
#define out8(p, v) outb(v, p)
-#ifdef CONFIG_CONSOLE_CURSOR
-extern void console_cursor(int state);
-static int blink_count = CONFIG_SYS_CONSOLE_BLINK_COUNT;
-static int cursor_state;
-#endif
-
/* locals */
static int kbd_input = -1; /* no input yet */
@@ -598,15 +592,6 @@ int i8042_tstc(struct stdio_dev *dev)
{
unsigned char scan_code = 0;
-#ifdef CONFIG_CONSOLE_CURSOR
- if (--blink_count == 0) {
- cursor_state ^= 1;
- console_cursor(cursor_state);
- blink_count = CONFIG_SYS_CONSOLE_BLINK_COUNT;
- udelay(10);
- }
-#endif
-
if ((in8(I8042_STS_REG) & STATUS_OBF) == 0) {
return 0;
} else {
@@ -635,14 +620,6 @@ int i8042_getc(struct stdio_dev *dev)
while (kbd_input == -1) {
while ((in8(I8042_STS_REG) & STATUS_OBF) == 0) {
-#ifdef CONFIG_CONSOLE_CURSOR
- if (--blink_count == 0) {
- cursor_state ^= 1;
- console_cursor(cursor_state);
- blink_count = CONFIG_SYS_CONSOLE_BLINK_COUNT;
- }
- udelay(10);
-#endif
}
scan_code = in8(I8042_DATA_REG);
if (scan_code != 0xfa)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index aa7ca86..1b5c3e0 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -43,13 +43,6 @@
* VIDEO_TSTC_FCT- keyboard_tstc function
* VIDEO_GETC_FCT- keyboard_getc function
*
- * CONFIG_CONSOLE_CURSOR - on/off drawing cursor is done with
- * delay loop in VIDEO_TSTC_FCT (i8042)
- *
- * CONFIG_SYS_CONSOLE_BLINK_COUNT - value for delay loop - blink rate
- * CONFIG_CONSOLE_TIME - display time/date in upper right
- * corner, needs CONFIG_CMD_DATE and
- * CONFIG_CONSOLE_CURSOR
* CONFIG_VIDEO_LOGO - display Linux Logo in upper left corner.
* Use CONFIG_SPLASH_SCREEN_ALIGN with
* environment variable "splashpos" to place
@@ -198,9 +191,6 @@
/*
* Cursor definition:
- * CONFIG_CONSOLE_CURSOR: Uses a timer function (see drivers/input/i8042.c)
- *to let the cursor blink. Uses the macros
- *CURSOR_OFF and CURSOR_ON.
* CONFIG_VIDEO_SW_CURSOR: Draws a cursor after the last character. No
*blinking is provided. Uses t
[U-Boot] [PATCH v2 15/28] input: Add a function to add a keycode to the existing set
Most keyboards can be scanned to produce a list of the keycodes which are
depressed. With the i8042 keyboard this scanning is done internally and
only the processed results are returned.
In this case, when a key is pressed, a 'make' code is sent. When the key
is released an 'unmake' code is sent. This means that the driver needs to
keep track of which keys are pressed. It also means that any protocol error
can lead to stuck keys.
In order to support this type of keyboard, add a function when can be used
to provide a single keycode and either add it to the list of what is pressed
or remove it from the list. Then the normal input_send_keycodes() function
can be used to actually do the decoding work.
Add debugging to display the ASCII characters written to the input queue
also.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/input.c | 46 ++
include/input.h | 20
2 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index e65942e..530bf51 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -107,6 +107,7 @@ static int input_queue_ascii(struct input_config *config,
int ch)
return -1; /* buffer full */
config->fifo_in++;
}
+ debug(" {%02x} ", ch);
config->fifo[config->fifo_in] = (uchar)ch;
return 0;
@@ -394,8 +395,8 @@ static int input_keycodes_to_ascii(struct input_config
*config,
return ch_count;
}
-int input_send_keycodes(struct input_config *config,
- int keycode[], int num_keycodes)
+static int _input_send_keycodes(struct input_config *config, int keycode[],
+ int num_keycodes, bool do_send)
{
char ch[num_keycodes * ANSI_CHAR_MAX];
int count, i, same = 0;
@@ -420,8 +421,10 @@ int input_send_keycodes(struct input_config *config,
count = input_keycodes_to_ascii(config, keycode, num_keycodes,
ch, sizeof(ch), is_repeat ? 0 : same);
- for (i = 0; i < count; i++)
- input_queue_ascii(config, ch[i]);
+ if (do_send) {
+ for (i = 0; i < count; i++)
+ input_queue_ascii(config, ch[i]);
+ }
delay_ms = is_repeat ?
config->repeat_rate_ms :
config->repeat_delay_ms;
@@ -431,6 +434,41 @@ int input_send_keycodes(struct input_config *config,
return count;
}
+int input_send_keycodes(struct input_config *config, int keycode[],
+ int num_keycodes)
+{
+ return _input_send_keycodes(config, keycode, num_keycodes, true);
+}
+
+int input_add_keycode(struct input_config *config, int new_keycode,
+ bool release)
+{
+ int keycode[INPUT_MAX_MODIFIERS + 1];
+ int count, i;
+
+ /* Add the old keycodes which are not removed by this new one */
+ for (i = 0, count = 0; i < config->num_prev_keycodes; i++) {
+ int code = config->prev_keycodes[i];
+
+ if (new_keycode == code) {
+ if (release)
+ continue;
+ new_keycode = -1;
+ }
+ keycode[count++] = code;
+ }
+
+ if (!release && new_keycode != -1)
+ keycode[count++] = new_keycode;
+ debug("\ncodes for %02x/%d: ", new_keycode, release);
+ for (i = 0; i < count; i++)
+ debug("%02x ", keycode[i]);
+ debug("\n");
+
+ /* Don't output any ASCII characters if this is a key release */
+ return _input_send_keycodes(config, keycode, count, !release);
+}
+
int input_add_table(struct input_config *config, int left_keycode,
int right_keycode, const uchar *xlate, int num_entries)
{
diff --git a/include/input.h b/include/input.h
index 71f3538..9942d6f 100644
--- a/include/input.h
+++ b/include/input.h
@@ -76,6 +76,26 @@ struct stdio_dev;
int input_send_keycodes(struct input_config *config, int keycode[], int count);
/**
+ * Add a new keycode to an existing list of keycodes
+ *
+ * This can be used to handle keyboards which do their own scanning. An
+ * internal list of depressed keys is maintained by the input library. Then
+ * this function is called to add a new key to the list (when a 'make code' is
+ * received), or remove a key (when a 'break code' is received).
+ *
+ * This function looks after maintenance of the list of active keys, and calls
+ * input_send_keycodes() with its updated list.
+ *
+ * @param config Input state
+ * @param new_keycode New keycode to add/remove
+ * @param release true if this key was released, false if depressed
+ * @return number of ascii characters sent, or 0 if none, or -1 for an
+ * internal error
+ */
+int input_add_keycode(struct input_config *config, int new_keycode,
[U-Boot] [PATCH v2 10/28] i8042: Use functions to handle register access
At present the register access in kbd_reset() is quite primitive. This makes
it hard to follow.
Create functions to read and write data, both to a single register, and via
the command/data approach.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
Tested-on: Intel Crown Bay and QEMU
Tested-by: Bin Meng
---
Changes in v2: None
drivers/input/i8042.c | 75 ++-
1 file changed, 44 insertions(+), 31 deletions(-)
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 7b95b21..dbd4b00 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -446,53 +446,66 @@ static void kbd_conv_char(unsigned char scan_code)
return;
}
-static int kbd_reset(void)
+static int kbd_write(int reg, int value)
{
- u8 config;
-
- /* controller self test */
- if (kbd_input_empty() == 0)
- return -1;
- out8(I8042_CMD_REG, CMD_SELF_TEST);
- if (kbd_output_full() == 0)
- return -1;
- if (in8(I8042_DATA_REG) != KBC_TEST_OK)
+ if (!kbd_input_empty())
return -1;
+ out8(reg, value);
- /* keyboard reset */
- if (kbd_input_empty() == 0)
+ return 0;
+}
+
+static int kbd_read(int reg)
+{
+ if (!kbd_output_full())
return -1;
- out8(I8042_DATA_REG, CMD_RESET_KBD);
- if (kbd_output_full() == 0)
+
+ return in8(reg);
+}
+
+static int kbd_cmd_read(int cmd)
+{
+ if (kbd_write(I8042_CMD_REG, cmd))
return -1;
- if (in8(I8042_DATA_REG) != KBD_ACK)
+
+ return kbd_read(I8042_DATA_REG);
+}
+
+static int kbd_cmd_write(int cmd, int data)
+{
+ if (kbd_write(I8042_CMD_REG, cmd))
return -1;
- if (kbd_output_full() == 0)
+
+ return kbd_write(I8042_DATA_REG, data);
+}
+
+static int kbd_reset(void)
+{
+ int config;
+
+ /* controller self test */
+ if (kbd_cmd_read(CMD_SELF_TEST) != KBC_TEST_OK)
return -1;
- if (in8(I8042_DATA_REG) != KBD_POR)
+
+ /* keyboard reset */
+ if (kbd_write(I8042_DATA_REG, CMD_RESET_KBD) ||
+ kbd_read(I8042_DATA_REG) != KBD_ACK ||
+ kbd_read(I8042_DATA_REG) != KBD_POR)
return -1;
/* set AT translation and disable irq */
- if (kbd_input_empty() == 0)
- return -1;
- out8(I8042_CMD_REG, CMD_RD_CONFIG);
- if (kbd_output_full() == 0)
+ config = kbd_cmd_read(CMD_RD_CONFIG);
+ if (config == -1)
return -1;
- config = in8(I8042_DATA_REG);
+
config |= CONFIG_AT_TRANS;
config &= ~(CONFIG_KIRQ_EN | CONFIG_MIRQ_EN);
- if (kbd_input_empty() == 0)
+ if (kbd_cmd_write(CMD_WR_CONFIG, config))
return -1;
- out8(I8042_CMD_REG, CMD_WR_CONFIG);
- if (kbd_input_empty() == 0)
- return -1;
- out8(I8042_DATA_REG, config);
/* enable keyboard */
- if (kbd_input_empty() == 0)
- return -1;
- out8(I8042_CMD_REG, CMD_KBD_EN);
- if (kbd_input_empty() == 0)
+ if (kbd_write(I8042_CMD_REG, CMD_KBD_EN) ||
+ !kbd_input_empty())
return -1;
return 0;
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 06/28] dm: stdio: Plumb in the new keyboard uclass
When driver model is used for keyboards we must scan the available keyboards
and register them with stdio. Add code to do this.
At some point (once LCD/video is converted) we should be able to convert
stdio to driver model and avoid these dual data structures.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
common/stdio.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/common/stdio.c b/common/stdio.c
index adbfc89..71cc32e 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,8 @@
#include
#endif
+#include
+
DECLARE_GLOBAL_DATA_PTR;
static struct stdio_dev devs;
@@ -245,6 +248,32 @@ int stdio_init_tables(void)
int stdio_add_devices(void)
{
+#ifdef CONFIG_DM_KEYBOARD
+ struct udevice *dev;
+ struct uclass *uc;
+ int ret;
+
+ /*
+* For now we probe all the devices here. At some point this should be
+* done only when the devices are required - e.g. we have a list of
+* input devices to start up in the stdin environment variable. That
+* work probably makes more sense when stdio itself is converted to
+* driver model.
+*
+* TODO(s...@chromium.org): Convert changing uclass_first_device() etc.
+* to return the device even on error. Then we could use that here.
+*/
+ ret = uclass_get(UCLASS_KEYBOARD, &uc);
+ if (ret)
+ return ret;
+
+ /* Don't report errors to the caller - assume that they are non-fatal */
+ uclass_foreach_dev(dev, uc) {
+ ret = device_probe(dev);
+ if (ret)
+ printf("Failed to probe keyboard '%s'\n", dev->name);
+ }
+#endif
#ifdef CONFIG_SYS_I2C
i2c_init_all();
#else
@@ -258,7 +287,7 @@ int stdio_add_devices(void)
#if defined(CONFIG_VIDEO) || defined(CONFIG_CFB_CONSOLE)
drv_video_init ();
#endif
-#ifdef CONFIG_KEYBOARD
+#if defined(CONFIG_KEYBOARD) && !defined(CONFIG_DM_KEYBOARD)
drv_keyboard_init ();
#endif
#ifdef CONFIG_LOGBUFFER
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 12/28] i8042: Adjust keyboard init to assume success
Modify i8042_kbd_init() so that the normal pass is sucessful init and
failure exits early. This will make the code easier to extend and is easier
to read.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
drivers/input/i8042.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 4c887f4..b1ada86 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -585,18 +585,17 @@ int i8042_kbd_init(void)
keymap = KBD_GER;
}
- for (try = 0; try < KBD_RESET_TRIES; try++) {
- if (kbd_reset() == 0) {
- kbd_mapping = keymap;
- kbd_flags = NORMAL;
- kbd_state = 0;
- kbd_led_set();
-
- return 0;
- }
+ for (try = 0; kbd_reset() != 0; try++) {
+ if (try >= KBD_RESET_TRIES)
+ return -1;
}
- return -1;
+ kbd_mapping = keymap;
+ kbd_flags = NORMAL;
+ kbd_state = 0;
+ kbd_led_set();
+
+ return 0;
}
/*
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] debug_uart: Support board-specific UART initialisation
On Mon, Oct 19, 2015 at 9:51 AM, Simon Glass wrote:
> Some boards need to set things up before the debug UART can be used. On
> these boards a call to debug_uart_init() is insufficient. When this option
> is enabled, the function board_debug_uart_init() will be called when
> debug_uart_init() is called. You can put any code here that is needed to
> set up the UART ready for use, such as set pin multiplexing or enable
> clocks.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> drivers/serial/Kconfig | 11 +++
> include/debug_uart.h | 14 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index ddb725d..39f6500 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -109,6 +109,17 @@ config DEBUG_UART_SHIFT
> value. Use this value to specify the shift to use, where 0=byte
> registers, 2=32-bit word registers, etc.
>
> +config DEBUG_UART_BOARD_INIT
> + bool "Enable board-specific debug UART init"
> + depends on DEBUG_UART
> + help
> + Some boards need to set things up before the debug UART can be used.
> + On these boards a call to debug_uart_init() is insufficient. When
> + this option is enabled, the function board_debug_uart_init() will
> + be called when debug_uart_init() is called. You can put any code
> + here that is needed to set up the UART ready for use, such as set
> + pin multiplexing or enable clocks.
> +
> config ROCKCHIP_SERIAL
> bool "Rockchip on-chip UART support"
> depends on ARCH_ROCKCHIP && DM_SERIAL
> diff --git a/include/debug_uart.h b/include/debug_uart.h
> index 257ba00..a6b7ce8 100644
> --- a/include/debug_uart.h
> +++ b/include/debug_uart.h
> @@ -42,6 +42,11 @@
> * - Define _debug_uart_putc() as static inline (avoiding stack usage)
> * - Immediately afterwards, add DEBUG_UART_FUNCS to define the rest of the
> * functionality (printch(), etc.)
> + *
> + * If your board needs additional init for the UART to work, enable
> + * CONFIG_DEBUG_UART_BOARD_INIT and write a function called
> + * board_debug_uart_init() to perform that init. When debug_uart_init() is
> + * called, the init will happen automatically.
> */
>
> /**
> @@ -57,6 +62,14 @@
> */
> void debug_uart_init(void);
>
> +#ifdef CONFIG_DEBUG_UART_BOARD_INIT
> +void board_debug_uart_init(void);
> +#else
> +static inline void board_debug_uart_init(void)
> +{
> +}
> +#endif
> +
> /**
> * printch() - Output a character to the debug UART
> *
> @@ -136,6 +149,7 @@ void printhex8(uint value);
> \
> void debug_uart_init(void) \
> { \
> + board_debug_uart_init(); \
> _debug_uart_init(); \
> } \
>
> --
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 11/28] i8042: Adjust kbd_reset() to collect all failures
Rather than lots of 'return' statements, use goto to a single return.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
drivers/input/i8042.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index dbd4b00..4c887f4 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -485,30 +485,33 @@ static int kbd_reset(void)
/* controller self test */
if (kbd_cmd_read(CMD_SELF_TEST) != KBC_TEST_OK)
- return -1;
+ goto err;
/* keyboard reset */
if (kbd_write(I8042_DATA_REG, CMD_RESET_KBD) ||
kbd_read(I8042_DATA_REG) != KBD_ACK ||
kbd_read(I8042_DATA_REG) != KBD_POR)
- return -1;
+ goto err;
/* set AT translation and disable irq */
config = kbd_cmd_read(CMD_RD_CONFIG);
if (config == -1)
- return -1;
+ goto err;
config |= CONFIG_AT_TRANS;
config &= ~(CONFIG_KIRQ_EN | CONFIG_MIRQ_EN);
if (kbd_cmd_write(CMD_WR_CONFIG, config))
- return -1;
+ goto err;
/* enable keyboard */
if (kbd_write(I8042_CMD_REG, CMD_KBD_EN) ||
!kbd_input_empty())
- return -1;
+ goto err;
return 0;
+err:
+ debug("%s: Keyboard failure\n", __func__);
+ return -1;
}
static int kbd_controller_present(void)
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 03/28] input: Return -ENOSPC when there is not space
Return a useful error instead of -1 when something goes wrong.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
drivers/input/input.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 007b855..9033935 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -467,7 +468,7 @@ int input_init(struct input_config *config, int leds)
input_add_table(config, KEY_LEFTCTRL, KEY_RIGHTCTRL,
kbd_ctrl_xlate, ARRAY_SIZE(kbd_ctrl_xlate))) {
debug("%s: Could not add modifier tables\n", __func__);
- return -1;
+ return -ENOSPC;
}
return 0;
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 08/28] dm: cros_ec: Convert cros_ec keyboard driver to driver model
Adjust the cros_ec keyboard driver to support driver model. Make this the
default for all Exynos boards so that those that use a keyboard will build
correctly with this driver.
Signed-off-by: Simon Glass
---
Changes in v2: None
README | 5 --
arch/arm/Kconfig | 1 +
arch/sandbox/Kconfig | 3 +
drivers/input/cros_ec_keyb.c | 148 +--
4 files changed, 62 insertions(+), 95 deletions(-)
diff --git a/README b/README
index ca49225..d381422 100644
--- a/README
+++ b/README
@@ -1793,11 +1793,6 @@ CBFS (Coreboot Filesystem) support
Export function i8042_kbd_init, i8042_tstc and i8042_getc
for cfb_console. Supports cursor blinking.
- CONFIG_CROS_EC_KEYB
- Enables a Chrome OS keyboard using the CROS_EC interface.
- This uses CROS_EC to communicate with a second microcontroller
- which provides key scans on request.
-
- Video support:
CONFIG_VIDEO
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7981355..f29febe 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -420,6 +420,7 @@ config ARCH_EXYNOS
select DM_SERIAL
select DM_SPI
select DM_GPIO
+ select DM_KEYBOARD
config ARCH_S5PC1XX
bool "Samsung S5PC1XX"
diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
index f078c9e..25e316c 100644
--- a/arch/sandbox/Kconfig
+++ b/arch/sandbox/Kconfig
@@ -17,4 +17,7 @@ config PCI
used on some devices to allow the CPU to communicate with its
peripherals.
+config DM_KEYBOARD
+ default y
+
endmenu
diff --git a/drivers/input/cros_ec_keyb.c b/drivers/input/cros_ec_keyb.c
index 88397b0..fe5caea 100644
--- a/drivers/input/cros_ec_keyb.c
+++ b/drivers/input/cros_ec_keyb.c
@@ -8,9 +8,11 @@
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
@@ -22,31 +24,29 @@ enum {
KBC_REPEAT_DELAY_MS = 240,
};
-static struct keyb {
- struct cros_ec_dev *dev;/* The CROS_EC device */
- struct input_config input; /* The input layer */
+struct cros_ec_keyb_priv {
+ struct input_config *input; /* The input layer */
struct key_matrix matrix; /* The key matrix layer */
int key_rows; /* Number of keyboard rows */
int key_cols; /* Number of keyboard columns */
int ghost_filter; /* 1 to enable ghost filter, else 0 */
- int inited; /* 1 if keyboard is ready */
-} config;
+};
/**
* Check the keyboard controller and return a list of key matrix positions
* for which a key is pressed
*
- * @param config Keyboard config
+ * @param dev Keyboard device
* @param keys List of keys that we have detected
* @param max_countMaximum number of keys to return
* @param samepSet to true if this scan repeats the last, else
false
* @return number of pressed keys, 0 for none, -EIO on error
*/
-static int check_for_keys(struct keyb *config,
- struct key_matrix_key *keys, int max_count,
- bool *samep)
+static int check_for_keys(struct udevice *dev, struct key_matrix_key *keys,
+ int max_count, bool *samep)
{
+ struct cros_ec_keyb_priv *priv = dev_get_priv(dev);
struct key_matrix_key *key;
static struct mbkp_keyscan last_scan;
static bool last_scan_valid;
@@ -54,7 +54,7 @@ static int check_for_keys(struct keyb *config,
unsigned int row, col, bit, data;
int num_keys;
- if (cros_ec_scan_keyboard(config->dev->dev, &scan)) {
+ if (cros_ec_scan_keyboard(dev->parent, &scan)) {
debug("%s: keyboard scan failed\n", __func__);
return -EIO;
}
@@ -69,9 +69,9 @@ static int check_for_keys(struct keyb *config,
last_scan_valid = true;
memcpy(&last_scan, &scan, sizeof(last_scan));
- for (col = num_keys = bit = 0; col < config->matrix.num_cols;
+ for (col = num_keys = bit = 0; col < priv->matrix.num_cols;
col++) {
- for (row = 0; row < config->matrix.num_rows; row++) {
+ for (row = 0; row < priv->matrix.num_rows; row++) {
unsigned int mask = 1 << (bit & 7);
data = scan.data[bit / 8];
@@ -89,28 +89,6 @@ static int check_for_keys(struct keyb *config,
}
/**
- * Test if keys are available to be read
- *
- * @return 0 if no keys available, 1 if keys are available
- */
-static int kbd_tstc(struct stdio_dev *dev)
-{
- /* Just get input to do this for us */
- return config.inited ? input_tstc(&config.input) : 0;
-}
-
-/**
- * Read a key
- *
- * @return ASCII key code, or 0 if no key, or -1 if error
- */
-static int kbd_getc(struct
[U-Boot] [PATCH v2 05/28] cros_ec: Use udevice instead of cros_ec_dev for keyboard functions
In preparation for converting the cros_ec keyboard driver to driver model,
adjust the cros_ec functions it will use to use a normal struct udevice.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/input/cros_ec_keyb.c | 4 ++--
drivers/misc/cros_ec.c | 14 +-
include/cros_ec.h| 4 ++--
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/input/cros_ec_keyb.c b/drivers/input/cros_ec_keyb.c
index eaab86f..88397b0 100644
--- a/drivers/input/cros_ec_keyb.c
+++ b/drivers/input/cros_ec_keyb.c
@@ -54,7 +54,7 @@ static int check_for_keys(struct keyb *config,
unsigned int row, col, bit, data;
int num_keys;
- if (cros_ec_scan_keyboard(config->dev, &scan)) {
+ if (cros_ec_scan_keyboard(config->dev->dev, &scan)) {
debug("%s: keyboard scan failed\n", __func__);
return -EIO;
}
@@ -139,7 +139,7 @@ int cros_ec_kbc_check(struct input_config *input)
* may return 0 before all keys have been read from the EC.
*/
do {
- irq_pending = cros_ec_interrupt_pending(config.dev);
+ irq_pending = cros_ec_interrupt_pending(config.dev->dev);
if (irq_pending) {
num_keys = check_for_keys(&config, keys, KBC_MAX_KEYS,
&same);
diff --git a/drivers/misc/cros_ec.c b/drivers/misc/cros_ec.c
index ba36795..e3229ef 100644
--- a/drivers/misc/cros_ec.c
+++ b/drivers/misc/cros_ec.c
@@ -358,9 +358,11 @@ static int ec_command(struct cros_ec_dev *dev, uint8_t
cmd, int cmd_version,
return len;
}
-int cros_ec_scan_keyboard(struct cros_ec_dev *dev, struct mbkp_keyscan *scan)
+int cros_ec_scan_keyboard(struct udevice *dev, struct mbkp_keyscan *scan)
{
- if (ec_command(dev, EC_CMD_MKBP_STATE, 0, NULL, 0, scan,
+ struct cros_ec_dev *cdev = dev_get_uclass_priv(dev);
+
+ if (ec_command(cdev, EC_CMD_MKBP_STATE, 0, NULL, 0, scan,
sizeof(scan->data)) != sizeof(scan->data))
return -1;
@@ -549,13 +551,15 @@ int cros_ec_reboot(struct cros_ec_dev *dev, enum
ec_reboot_cmd cmd,
return 0;
}
-int cros_ec_interrupt_pending(struct cros_ec_dev *dev)
+int cros_ec_interrupt_pending(struct udevice *dev)
{
+ struct cros_ec_dev *cdev = dev_get_uclass_priv(dev);
+
/* no interrupt support : always poll */
- if (!dm_gpio_is_valid(&dev->ec_int))
+ if (!dm_gpio_is_valid(&cdev->ec_int))
return -ENOENT;
- return dm_gpio_get_value(&dev->ec_int);
+ return dm_gpio_get_value(&cdev->ec_int);
}
int cros_ec_info(struct cros_ec_dev *dev, struct ec_response_mkbp_info *info)
diff --git a/include/cros_ec.h b/include/cros_ec.h
index b926934..5fa5f6f 100644
--- a/include/cros_ec.h
+++ b/include/cros_ec.h
@@ -81,7 +81,7 @@ int cros_ec_read_id(struct cros_ec_dev *dev, char *id, int
maxlen);
* @param scan Place to put the scan results
* @return 0 if ok, -1 on error
*/
-int cros_ec_scan_keyboard(struct cros_ec_dev *dev, struct mbkp_keyscan *scan);
+int cros_ec_scan_keyboard(struct udevice *dev, struct mbkp_keyscan *scan);
/**
* Read which image is currently running on the CROS-EC device.
@@ -125,7 +125,7 @@ int cros_ec_reboot(struct cros_ec_dev *dev, enum
ec_reboot_cmd cmd,
* @param dev CROS-EC device
* @return 0 if no interrupt is pending
*/
-int cros_ec_interrupt_pending(struct cros_ec_dev *dev);
+int cros_ec_interrupt_pending(struct udevice *dev);
enum {
CROS_EC_OK,
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 00/28] dm: input: Move keyboard drivers to driver model
This series adds a new uclass for keyboards and converts some drivers over to use it. This series includes some work to remove code duplication in the keyboard drivers by updating them to use the input library (input.c). This unifies the keycode decoding logic in one place. In order to do this some enhancements are needed to the input library and these are also included. The cros_ec and tegra_kbc drivers are converted to use driver model. The i8042 driver is converted also, after various tidy-ups. The driver has some strange interactions with the cfb_console driver. This is removed in this series which is possible because the only user is x86. Some i8042 features have been dropped (the only deliberate one is the flashing cursor which does not seem to be used by any board). Also the i8042 driver currently has its own keycode-decoding logic. This series removes it in favour of the input library. Therefore testing of this new driver would be appreciated. So far I have only been able to test on link, which does not have a full keyboard. Also, while German keyboard support is implemented, I am unable to test that either. These changes can be considered the first step towards moving stdio to driver model. For that to be useful we need to convert LCD and video also. Note: This series is missing the code to call the update_leds() method when the LEDs change. This needs to be added to keyboard_tstc() and keyboard_getc(). If someone is able to test this I can send a patch for that also. This series is available at u-boot-dm branch input-working. Changes in v2: - Add more debug info to input_init() for when it fails - Support driver's tstc() and getc() methods in the uclass - Update the comment for the tstc() method to indicate that an error can occur - Add error checking to input_add_tables() - Update commit message to explain what RTC means - Fix extra space in commit message - Update input_add_tables() to add error checking - Convert two multi-line comments to single-line comments - Correct call to input_init() - Drop CONFIG_VGA_AS_SINGLE_DEVICE from all x86 board config files - Use device tree to handle this quirk Simon Glass (28): dm: input: Create a keyboard uclass input: Add a device pointer to the input config input: Return -ENOSPC when there is not space input: Add the keycode translation tables separately cros_ec: Use udevice instead of cros_ec_dev for keyboard functions dm: stdio: Plumb in the new keyboard uclass dm: tegra: Convert keyboard driver to driver model dm: cros_ec: Convert cros_ec keyboard driver to driver model video: Drop unused console functions i8042: Use functions to handle register access i8042: Adjust kbd_reset() to collect all failures i8042: Adjust keyboard init to assume success input: Correct keycode for Ctrl-Y input: Add a few more keyboard keycodes input: Add a function to add a keycode to the existing set input: Allow repeat filtering to be disabled input: Support the German keymap input: Adjust structure of code in process_modifier() input: Handle caps lock input: Allow updating of keyboard LEDs input: i8042: Convert to use the input library input: Add a Kconfig option for the i8042 keyboard x86: Add an i8042 device for boards that have it Drop CONFIG_ISA_KEYBOARD input: Convert i8042 to driver model i8042: Handle a duplicate power-on-reset response video: input: Clean up after i8042 conversion input: Convert 'keyboard' driver to use input library README | 42 +- arch/arm/Kconfig | 1 + arch/arm/mach-tegra/Kconfig | 1 + arch/sandbox/Kconfig | 3 + arch/x86/Kconfig | 6 + arch/x86/dts/bayleybay.dts | 1 + arch/x86/dts/chromebook_link.dts | 5 + arch/x86/dts/keyboard.dtsi | 5 + board/kosagi/novena/novena.c | 1 + board/mpl/pip405/README | 4 - common/stdio.c | 31 +- common/usb_kbd.c | 6 - doc/device-tree-bindings/input/i8042.txt | 10 + drivers/input/Kconfig| 19 + drivers/input/Makefile | 4 +- drivers/input/cros_ec_keyb.c | 147 +++ drivers/input/i8042.c| 647 --- drivers/input/input.c| 222 +-- drivers/input/keyboard-uclass.c | 91 + drivers/input/keyboard.c | 290 ++ drivers/input/tegra-kbc.c| 242 ++-- drivers/misc/cros_ec.c | 14 +- drivers/video/cfb_console.c | 82 +--- include/configs/MIP405.h | 5 - include/configs/MPC8536DS.h | 1 - include/configs/MPC8544DS.h | 1 - include/configs/MPC8572DS.h | 1 - include/configs/MPC8641HPCN.h| 1 - include/configs
[U-Boot] [PATCH v2 04/28] input: Add the keycode translation tables separately
Require the caller to add the keycode translation tables separately so that
it can select which ones to use. In a later patch we will add the option to
add German tables.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add error checking to input_add_tables()
board/kosagi/novena/novena.c | 1 +
drivers/input/cros_ec_keyb.c | 1 +
drivers/input/input.c| 26 +-
drivers/input/tegra-kbc.c| 1 +
include/input.h | 10 ++
5 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
index 69f5be3..48cbb0f 100644
--- a/board/kosagi/novena/novena.c
+++ b/board/kosagi/novena/novena.c
@@ -88,6 +88,7 @@ int drv_keyboard_init(void)
debug("%s: Cannot set up input\n", __func__);
return -1;
}
+ input_add_tables(&button_input);
button_input.read_keys = novena_gpio_button_read_keys;
error = input_stdio_register(&dev);
diff --git a/drivers/input/cros_ec_keyb.c b/drivers/input/cros_ec_keyb.c
index a31aa77..eaab86f 100644
--- a/drivers/input/cros_ec_keyb.c
+++ b/drivers/input/cros_ec_keyb.c
@@ -255,6 +255,7 @@ int drv_keyboard_init(void)
return -1;
}
config.input.read_keys = cros_ec_kbc_check;
+ input_add_tables(&config.input);
memset(&dev, '\0', sizeof(dev));
strcpy(dev.name, "cros-ec-keyb");
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 9033935..82e8381 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -457,19 +457,27 @@ void input_set_delays(struct input_config *config, int
repeat_delay_ms,
config->repeat_rate_ms = repeat_rate_ms;
}
+int input_add_tables(struct input_config *config)
+{
+ int ret;
+
+ ret = input_add_table(config, -1, -1,
+ kbd_plain_xlate, ARRAY_SIZE(kbd_plain_xlate));
+ if (ret)
+ return ret;
+ ret = input_add_table(config, KEY_LEFTSHIFT, KEY_RIGHTSHIFT,
+ kbd_shift_xlate, ARRAY_SIZE(kbd_shift_xlate));
+ if (ret)
+ return ret;
+
+ return input_add_table(config, KEY_LEFTCTRL, KEY_RIGHTCTRL,
+ kbd_ctrl_xlate, ARRAY_SIZE(kbd_ctrl_xlate));
+}
+
int input_init(struct input_config *config, int leds)
{
memset(config, '\0', sizeof(*config));
config->leds = leds;
- if (input_add_table(config, -1, -1,
- kbd_plain_xlate, ARRAY_SIZE(kbd_plain_xlate)) ||
- input_add_table(config, KEY_LEFTSHIFT, KEY_RIGHTSHIFT,
- kbd_shift_xlate, ARRAY_SIZE(kbd_shift_xlate)) ||
- input_add_table(config, KEY_LEFTCTRL, KEY_RIGHTCTRL,
- kbd_ctrl_xlate, ARRAY_SIZE(kbd_ctrl_xlate))) {
- debug("%s: Could not add modifier tables\n", __func__);
- return -ENOSPC;
- }
return 0;
}
diff --git a/drivers/input/tegra-kbc.c b/drivers/input/tegra-kbc.c
index c9c9fac..3310f84 100644
--- a/drivers/input/tegra-kbc.c
+++ b/drivers/input/tegra-kbc.c
@@ -355,6 +355,7 @@ int drv_keyboard_init(void)
return -1;
}
config.input.read_keys = tegra_kbc_check;
+ input_add_tables(input);
memset(&dev, '\0', sizeof(dev));
strcpy(dev.name, "tegra-kbc");
diff --git a/include/input.h b/include/input.h
index 7bccc8e..71f3538 100644
--- a/include/input.h
+++ b/include/input.h
@@ -123,6 +123,16 @@ void input_set_delays(struct input_config *config, int
repeat_delay_ms,
int repeat_rate_ms);
/**
+ * Set up the key map tables
+ *
+ * This must be called after input_init() or keycode decoding will not work.
+ *
+ * @param config Input state
+ * @return 0 if ok, -1 on error
+ */
+int input_add_tables(struct input_config *config);
+
+/**
* Set up the input handler with basic key maps.
*
* @param config Input state
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/28] dm: input: Create a keyboard uclass
Add a uclass for keyboard input, mirroring the existing stdio methods.
This is enabled by a new CONFIG_DM_KEYBOARD option.
Signed-off-by: Simon Glass
Reviewed-by: Marek Vasut
---
Changes in v2:
- Add more debug info to input_init() for when it fails
- Support driver's tstc() and getc() methods in the uclass
- Update the comment for the tstc() method to indicate that an error can occur
common/usb_kbd.c| 6 ---
drivers/input/Kconfig | 9
drivers/input/Makefile | 2 +
drivers/input/keyboard-uclass.c | 91 +
include/keyboard.h | 79 +++
5 files changed, 181 insertions(+), 6 deletions(-)
create mode 100644 drivers/input/keyboard-uclass.c
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index 9b8e11e..e37d223 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -649,12 +649,6 @@ U_BOOT_DRIVER(usb_kbd) = {
.probe = usb_kbd_probe,
};
-/* TODO(s...@chromium.org): Move this into a common location */
-UCLASS_DRIVER(keyboard) = {
- .id = UCLASS_KEYBOARD,
- .name = "keyboard",
-};
-
static const struct usb_device_id kbd_id_table[] = {
{
.match_flags = USB_DEVICE_ID_MATCH_INT_CLASS |
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index bb00de7..447c4c3 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -1,3 +1,12 @@
+config DM_KEYBOARD
+ bool "Enable driver model keyboard support"
+ depends on DM
+ help
+ This adds a uclass for keyboards and implements keyboard support
+ using driver model. The API is implemented by keyboard.h and
+ includes methods to start/stop the device, check for available
+ input and update LEDs if the keyboard has them.
+
config CROS_EC_KEYB
bool "Enable Chrome OS EC keyboard support"
help
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index b1161c5..9388dfe 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -5,6 +5,8 @@
# SPDX-License-Identifier: GPL-2.0+
#
+obj-$(CONFIG_DM_KEYBOARD) += keyboard-uclass.o
+
obj-$(CONFIG_I8042_KBD) += i8042.o
obj-$(CONFIG_TEGRA_KEYBOARD) += tegra-kbc.o
obj-$(CONFIG_TWL4030_INPUT) += twl4030.o
diff --git a/drivers/input/keyboard-uclass.c b/drivers/input/keyboard-uclass.c
new file mode 100644
index 000..4698773
--- /dev/null
+++ b/drivers/input/keyboard-uclass.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+
+static int keyboard_start(struct stdio_dev *sdev)
+{
+ struct udevice *dev = sdev->priv;
+ struct keyboard_ops *ops = keyboard_get_ops(dev);
+
+ if (ops->start)
+ return ops->start(dev);
+
+ return 0;
+}
+
+static int keyboard_stop(struct stdio_dev *sdev)
+{
+ struct udevice *dev = sdev->priv;
+ struct keyboard_ops *ops = keyboard_get_ops(dev);
+
+ if (ops->stop)
+ return ops->stop(dev);
+
+ return 0;
+}
+
+static int keyboard_tstc(struct stdio_dev *sdev)
+{
+ struct udevice *dev = sdev->priv;
+ struct keyboard_priv *priv = dev_get_uclass_priv(dev);
+ struct keyboard_ops *ops = keyboard_get_ops(dev);
+
+ /* Just get input to do this for us if we can */
+ if (priv->input.dev)
+ return input_tstc(&priv->input);
+ else if (ops->tstc)
+ return ops->tstc(dev);
+
+ return -ENOSYS;
+}
+
+static int keyboard_getc(struct stdio_dev *sdev)
+{
+ struct udevice *dev = sdev->priv;
+ struct keyboard_priv *priv = dev_get_uclass_priv(dev);
+ struct keyboard_ops *ops = keyboard_get_ops(dev);
+
+ /* Just get input to do this for us if we can */
+ if (priv->input.dev)
+ return input_getc(&priv->input);
+ else if (ops->getc)
+ return ops->getc(dev);
+
+ return -ENOSYS;
+}
+
+static int keyboard_pre_probe(struct udevice *dev)
+{
+ struct keyboard_priv *priv = dev_get_uclass_priv(dev);
+ struct stdio_dev *sdev = &priv->sdev;
+ int ret;
+
+ strlcpy(sdev->name, dev->name, sizeof(sdev->name));
+ sdev->flags = DEV_FLAGS_INPUT | DEV_FLAGS_SYSTEM;
+ sdev->getc = keyboard_getc;
+ sdev->tstc = keyboard_tstc;
+ sdev->start = keyboard_start;
+ sdev->stop = keyboard_stop;
+ sdev->priv = dev;
+ ret = input_init(&priv->input, 0);
+ if (ret) {
+ debug("%s: Cannot set up input, ret=%d - please add DEBUG to
drivers/input/input.c to figure out the cause\n",
+ __func__, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+UCLASS_DRIVER(keyboard) = {
+ .id = UCLASS_KEYBOARD,
+ .name = "keyboard",
+ .pre_probe = keyboard_pre_probe,
+ .per_device_auto_alloc_size = sizeof(struct keyboa
[U-Boot] [PATCH v2 02/28] input: Add a device pointer to the input config
The read_keys() method in input is passed a struct input_config. Add a
device pointer there so that we can find out the device that is referred
to with driver model.
Once all drivers are converted we can update the input structure to use
driver model instead.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
include/input.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/input.h b/include/input.h
index 26e2ad7..7bccc8e 100644
--- a/include/input.h
+++ b/include/input.h
@@ -36,6 +36,7 @@ struct input_key_xlate {
};
struct input_config {
+ struct udevice *dev;
uchar fifo[INPUT_BUFFER_LEN];
int fifo_in, fifo_out;
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] debug_uart: Adjust the declaration of debug_uart_init()
Hi Simon,
On Mon, Oct 19, 2015 at 9:51 AM, Simon Glass wrote:
> We want to be able to add other common code to this function. So change the
> driver's version to have an underscore before it, just like
> _debug_uart_putc(). Define debug_uart_init() to call this version.
>
> Update all drivers to this new method.
>
> Signed-off-by: Simon Glass
> ---
Reviewed-by: Bin Meng
>
> Changes in v2:
> - Adjust all _debug_uart_init() declarations to be static inline
>
> drivers/serial/ns16550.c| 2 +-
> drivers/serial/serial_efi.c | 2 +-
> drivers/serial/serial_s5p.c | 2 +-
> include/debug_uart.h| 9 +++--
> lib/efi/efi_stub.c | 2 +-
> 5 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 6275a11..6433844 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -257,7 +257,7 @@ int NS16550_tstc(NS16550_t com_port)
> (1 << CONFIG_DEBUG_UART_SHIFT), \
> CONFIG_DEBUG_UART_SHIFT)
>
> -void debug_uart_init(void)
> +static inline void _debug_uart_init(void)
> {
> struct NS16550 *com_port = (struct NS16550 *)CONFIG_DEBUG_UART_BASE;
> int baud_divisor;
> diff --git a/drivers/serial/serial_efi.c b/drivers/serial/serial_efi.c
> index cf57d89..ea25c25 100644
> --- a/drivers/serial/serial_efi.c
> +++ b/drivers/serial/serial_efi.c
> @@ -107,7 +107,7 @@ static int serial_efi_pending(struct udevice *dev, bool
> input)
> * There is nothing to init here since the EFI console is already running by
> * the time we enter U-Boot.
> */
> -void debug_uart_init(void)
> +static inline void _debug_uart_init(void)
> {
> }
>
> diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
> index 3f0b588..feba467 100644
> --- a/drivers/serial/serial_s5p.c
> +++ b/drivers/serial/serial_s5p.c
> @@ -207,7 +207,7 @@ U_BOOT_DRIVER(serial_s5p) = {
>
> #include
>
> -void debug_uart_init(void)
> +static inline void _debug_uart_init(void)
> {
> struct s5p_uart *uart = (struct s5p_uart *)CONFIG_DEBUG_UART_BASE;
>
> diff --git a/include/debug_uart.h b/include/debug_uart.h
> index a75e377..257ba00 100644
> --- a/include/debug_uart.h
> +++ b/include/debug_uart.h
> @@ -38,7 +38,7 @@
> * To enable the debug UART in your serial driver:
> *
> * - #include
> - * - Define debug_uart_init(), trying to avoid using the stack
> + * - Define _debug_uart_init(), trying to avoid using the stack
> * - Define _debug_uart_putc() as static inline (avoiding stack usage)
> * - Immediately afterwards, add DEBUG_UART_FUNCS to define the rest of the
> * functionality (printch(), etc.)
> @@ -132,6 +132,11 @@ void printhex8(uint value);
> void printhex8(uint value) \
> { \
> printhex(value, 8); \
> - }
> + } \
> +\
> + void debug_uart_init(void) \
> + { \
> + _debug_uart_init(); \
> + } \
I think the ending \ in the last line will cause problems.
>
> #endif
> diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
> index d4d3e49..e138709 100644
> --- a/lib/efi/efi_stub.c
> +++ b/lib/efi/efi_stub.c
> @@ -59,7 +59,7 @@ struct __packed desctab_info {
> * considering if we start needing more U-Boot functionality. Note that we
> * could then move get_codeseg32() to arch/x86/cpu/cpu.c.
> */
> -void debug_uart_init(void)
> +void _debug_uart_init(void)
> {
> }
>
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb start crashing on arndale
Hi, On 5 April 2014 at 06:50, armdev wrote: > Dear batao / Inderpal, > > ping works only a few times after a number of usb reset / start attempts. > We are using linux 3.13 (exynos_defconfig) and rootfs linaro saucy server. > > Upon linux boot there is only lo in ifconfig. > lsusb results in -99 error, similar to the on reported by batao in > > https://bugs.launchpad.net/linaro-stable-kernel/+bug/1301727 > > Can you suggest anything which we can try / test at our end to solve the > ethernet issue with uboot/linux Somehow I found this thread. It is OK for the GPIO to be missing - the code should check it if is valid before using it. Since this was 18 months ago I hope you were able to fix it :-) > > Best Regards, > > On 12-Mar-2014, at 11:59 am, armdev wrote: > > Dear Inderpal, > > Thanks for helping us, we were able to test ethernet over usb. > It breaks often but it works with the return -1 patch. > The following error is observed most of the time > EHCI timed out on TD - token=0x8008d80 > > -Regards > armdev team > > On 12-Mar-2014, at 9:48 am, Inderpal Singh > wrote: > > Hi, > > > On 11 March 2014 20:25, armdev wrote: >> >> Adding Inderpal singh and Trini. Please help >> >> On 11-Mar-2014, at 12:27 pm, armdev wrote: >> >> > Hi, >> > >> > We have recently started working on arndale and running u-boot head on >> > it. Seems like it is crashing on our setup with a data abort on usb start. >> > Can anyone please confirm and suggest a fix / solution >> > >> > U-Boot 2014.04-rc1-00486-geeb72e6 (Mar 11 2014 - 11:44:32) for ARNDALE >> > >> > CPU:Exynos5250@1000MHz >> > >> > Board: Arndale >> > I2C: i2c_init: failed to init bus 0 for speed = 10 >> > ready >> > DRAM: 2 GiB >> > trace: copying 00084f98 bytes of early data from 5000 to beff >> > trace: enabled >> > WARNING: Caches not enabled >> > MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 >> > i2c_init: failed to init bus 0 for speed = 10 >> > In:serial >> > Out: serial >> > Err: serial >> > Net: Net Initialization Skipped >> > No ethernet found. >> > Hit any key to stop autoboot: 0 >> > ARNDALE # usb start >> > (Re)start USB... >> > USB0: data abort >> > pc : [] lr : [] >> > sp : beb5f9c0 ip : 0003 fp : >> > r10: r9 : beb62ecc r8 : befbcc80 >> > r7 : befbcc84 r6 : r5 : 00ff r4 : 0001 >> > r3 : r2 : 0001 r1 : 00ff r0 : >> > Flags: nzCv IRQs off FIQs off Mode SVC_32 >> > Resetting CPU ... >> > >> > > > > I was able to reproduce the issue and git bisect tells me that it started > happening after the commit "8475c86 s5p: gpio: change gpio coding method for > s5p gpio". > > Upon debugging further I figured out that it happens because the function > fdtdec_setup_gpio returns success even if there is no gpio defined. Since no > error is returned the exynos ehci driver goes ahead to setup the gpio and > data abort happens. If I return failure from this function it works well. > > diff --git a/lib/fdtdec.c b/lib/fdtdec.c > index 1fecab3..b1c4e92 100644 > --- a/lib/fdtdec.c > +++ b/lib/fdtdec.c > @@ -526,7 +526,7 @@ int fdtdec_setup_gpio(struct fdt_gpio_state *gpio) > * optional GPIOs) > */ > if (!fdt_gpio_isvalid(gpio)) > - return 0; > + return -1; > > > I am not sure of the objective to return success if there is no gpio > defined. > Simon, could you please suggest where do we need to fix it ? the above > function or gpio driver ? > > Thanks, > Inder > > > >> >> > Thanks and Regards >> > Armdev@FTM Team >> > >> > > > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 26/28] input: Convert i8042 to driver model
Hi Bin,
On 18 October 2015 at 21:01, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Oct 19, 2015 at 7:17 AM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 15 September 2015 at 00:12, Bin Meng wrote:
>>> Hi Simon,
>>>
>>> On Wed, Sep 9, 2015 at 12:32 PM, Simon Glass wrote:
Adjust this driver to support driver model. The only users are x86 boards
so this should be safe.
Signed-off-by: Simon Glass
---
>>>
>>> After updating QEMU to use the DM i8042 driver below:
>>>
>>> diff --git a/arch/x86/dts/qemu-x86_i440fx.dts
>>> b/arch/x86/dts/qemu-x86_i440fx.dts
>>> index fc74cd0..14782b3 100644
>>> --- a/arch/x86/dts/qemu-x86_i440fx.dts
>>> +++ b/arch/x86/dts/qemu-x86_i440fx.dts
>>> @@ -11,6 +11,7 @@
>>> /include/ "skeleton.dtsi"
>>> /include/ "serial.dtsi"
>>> /include/ "rtc.dtsi"
>>> +/include/ "keyboard.dtsi"
>>>
>>> / {
>>> model = "QEMU x86 (I440FX)";
>>> diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h
>>> index 1b544c1..9daf943 100644
>>> --- a/include/configs/qemu-x86.h
>>> +++ b/include/configs/qemu-x86.h
>>> @@ -30,7 +30,7 @@
>>>
>>> #define CONFIG_PCI_PNP
>>>
>>> -#define CONFIG_STD_DEVICES_SETTINGS"stdin=serial,vga\0" \
>>> +#define CONFIG_STD_DEVICES_SETTINGS"stdin=serial,i8042-kbd\0" \
>>> "stdout=serial,vga\0" \
>>> "stderr=serial,vga\0"
>>>
>>>
>>> The i8042 still does not work. I've applied the same changes to Crown
>>> Bay. i8042 does not work either. Could you please have a look?
>>>
>>
>> It's hard for me to debug this on hardware. I should be able to use
>> qemu though. Is there anything special needed to make it use that
>> keyboard?
>>
>
> I will have another try (and debug if it is needed) on Crown Bay when
> you send the v2 series.
Thanks - also note that I have not fixed the hang on caps lock that
you reported.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] rockchip: firefly: Save the environment on SD card
On 3 October 2015 at 08:27, Simon Glass wrote: > On 18 September 2015 at 22:49, Sjoerd Simons > wrote: >> Save the environment on the SD card for Firefly in the empty space >> between the SPL and the u-boot image. >> >> Signed-off-by: Sjoerd Simons >> >> --- >> >> include/configs/chromebook_jerry.h | 1 + >> include/configs/firefly-rk3288.h | 8 >> include/configs/rk3288_common.h| 1 - >> 3 files changed, 9 insertions(+), 1 deletion(-) > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] rockchip: Also load the initrd below 512M
On 3 October 2015 at 08:27, Simon Glass wrote: > On 18 September 2015 at 22:49, Sjoerd Simons > wrote: >> Similar to load an fdt, when loading an initrd about the 512Mb mark >> things seem to break. For now force loading below 512Mb until the reason >> why this fails has been determined/solved. >> >> Signed-off-by: Sjoerd Simons >> --- >> >> include/configs/rk3288_common.h | 1 + >> 1 file changed, 1 insertion(+) > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 26/28] input: Convert i8042 to driver model
Hi Simon,
On Mon, Oct 19, 2015 at 7:17 AM, Simon Glass wrote:
> Hi Bin,
>
> On 15 September 2015 at 00:12, Bin Meng wrote:
>> Hi Simon,
>>
>> On Wed, Sep 9, 2015 at 12:32 PM, Simon Glass wrote:
>>> Adjust this driver to support driver model. The only users are x86 boards
>>> so this should be safe.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>
>> After updating QEMU to use the DM i8042 driver below:
>>
>> diff --git a/arch/x86/dts/qemu-x86_i440fx.dts
>> b/arch/x86/dts/qemu-x86_i440fx.dts
>> index fc74cd0..14782b3 100644
>> --- a/arch/x86/dts/qemu-x86_i440fx.dts
>> +++ b/arch/x86/dts/qemu-x86_i440fx.dts
>> @@ -11,6 +11,7 @@
>> /include/ "skeleton.dtsi"
>> /include/ "serial.dtsi"
>> /include/ "rtc.dtsi"
>> +/include/ "keyboard.dtsi"
>>
>> / {
>> model = "QEMU x86 (I440FX)";
>> diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h
>> index 1b544c1..9daf943 100644
>> --- a/include/configs/qemu-x86.h
>> +++ b/include/configs/qemu-x86.h
>> @@ -30,7 +30,7 @@
>>
>> #define CONFIG_PCI_PNP
>>
>> -#define CONFIG_STD_DEVICES_SETTINGS"stdin=serial,vga\0" \
>> +#define CONFIG_STD_DEVICES_SETTINGS"stdin=serial,i8042-kbd\0" \
>> "stdout=serial,vga\0" \
>> "stderr=serial,vga\0"
>>
>>
>> The i8042 still does not work. I've applied the same changes to Crown
>> Bay. i8042 does not work either. Could you please have a look?
>>
>
> It's hard for me to debug this on hardware. I should be able to use
> qemu though. Is there anything special needed to make it use that
> keyboard?
>
I will have another try (and debug if it is needed) on Crown Bay when
you send the v2 series.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] x86: ivybridge: Fix saving mrc cache and enable it
Hi Simon,
On Mon, Oct 19, 2015 at 10:51 AM, Simon Glass wrote:
> Hi Bin,
>
> On 18 October 2015 at 20:44, Bin Meng wrote:
>> Hi Simon,
>>
>> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass wrote:
>>> Hi Bin,
>>>
>>> On 12 October 2015 at 02:30, Bin Meng wrote:
Currently sdram_initialise() saves pei_data->mrc_output directly to
gd->arch.mrc_output. This is incorrect as pei_data->mrc_output points
to an address on the stack whose content is no longer valid when we
call mrccache_reserve(). To fix this, save it on the heap instead.
Signed-off-by: Bin Meng
---
arch/x86/cpu/ivybridge/sdram.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/x86/cpu/ivybridge/sdram.c
b/arch/x86/cpu/ivybridge/sdram.c
index fc66a3c..f3d97ca 100644
--- a/arch/x86/cpu/ivybridge/sdram.c
+++ b/arch/x86/cpu/ivybridge/sdram.c
@@ -151,14 +151,8 @@ static int prepare_mrc_cache(struct pei_data
*pei_data)
if (!mrc_cache)
return -ENOENT;
- /*
-* TODO(s...@chromium.org): Skip this for now as it causes boot
-* problems
-*/
- if (0) {
- pei_data->mrc_input = mrc_cache->data;
- pei_data->mrc_input_len = mrc_cache->data_size;
- }
+ pei_data->mrc_input = mrc_cache->data;
+ pei_data->mrc_input_len = mrc_cache->data_size;
debug("%s: at %p, size %x checksum %04x\n", __func__,
pei_data->mrc_input, pei_data->mrc_input_len,
mrc_cache->checksum);
@@ -289,6 +283,7 @@ int sdram_initialise(struct pei_data *pei_data)
unsigned version;
const char *data;
uint16_t done;
+ char *cache;
int ret;
report_platform_info();
@@ -386,8 +381,13 @@ int sdram_initialise(struct pei_data *pei_data)
* This will be copied to SDRAM in reserve_arch(), then
written
* to SPI flash in mrccache_save()
*/
- gd->arch.mrc_output = (char *)pei_data->mrc_output;
- gd->arch.mrc_output_len = pei_data->mrc_output_len;
+ cache = malloc(pei_data->mrc_output_len);
+ if (cache) {
+ memcpy(cache, pei_data->mrc_output,
+ pei_data->mrc_output_len);
+ gd->arch.mrc_output = cache;
+ gd->arch.mrc_output_len = pei_data->mrc_output_len;
+ }
>>>
>>> This isn't really any better than what is there. The malloc() region
>>> is in CAR memory, just a different part of it. The function
>>> reserve_arch() copies it to SDRAM.
>>
>> So where does this pei_data->mrc_input point to? Is it some place that
>> is malloced by the MRC itself and in a place that does not get
>> overwritten?
>
> I think it points into the part of CAR that is reserved for use by the MRC.
>
Thanks, this explains why malloc() is not needed, since it is reserved
and not the same stack that U-Boot uses in the CAR.
>>
>>>
>>> I think with FSP this does not work but for ivybridge it seems OK.
>>>
>>> I'll resend your patch with this part removed. Your comments spurred
>>> me to take another look at why MRC was broken on ivybridge, and I
>>> found that car_uninit() was wrong. I'll send a series to fix it.
>>>
ret = write_seeds_to_cmos(pei_data);
if (ret)
debug("Failed to write seeds to CMOS: %d\n", ret);
--
1.8.2.1
>
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] x86: Support booting SeaBIOS
Hi Bin, On 10 October 2015 at 02:57, Bin Meng wrote: > Hi Simon, > > On Sat, Oct 3, 2015 at 10:29 PM, Simon Glass wrote: >> Hi Bin, >> >> On 29 September 2015 at 11:17, Bin Meng wrote: >>> SeaBIOS is an open source implementation of a 16-bit X86 BIOS. >>> It can run in an emulator or natively on X86 hardware with the >>> use of coreboot. With SeaBIOS's help, we can boot some OSes >>> that require 16-bit BIOS services like Windows/DOS. >>> >>> As U-Boot, we have to manually create a table where SeaBIOS gets >>> system information (eg: E820) from. The table unfortunately has >>> to follow the coreboot table format as SeaBIOS currently supports >>> booting as a coreboot payload. No U-Boot native support there. >>> >>> Booting SeaBIOS is done via U-Boot's bootelf command. >>> >>> This is the initial attempt to support booting SeaBIOS from U-Boot. >>> If the basic concept is good, I can spend time working on follow-on >>> patches to enable BIOS tables as well as graphics support. One issue >>> is that U-Boot x86 does not has a ROM file system like coreboot. >>> This brings difficulities to pass PCI option ROM to SeaBIOS, if we >>> don't modify SeaBIOS's source codes. Maybe we should promote CBFS >>> in U-Boot x86? >>> >>> This is tested on an Intel Crown Bay board with VGA card, booting >>> SeaBIOS then chain loading a GRUB on a USB drive, then Linux kernel >>> finally. >> >> Looks good to me. I think it is OK to use CBFS if needed - are you >> thinking of an option to build u-boot.rom as a CBFS filesystem? > > If using CBFS, that means we may have to abandon ifdtool? Or maybe > mixed usage of both tools? So far I'm not sure of the best approach. At present we have the ROM offsets stored mostly in Kconfig, with the MRC area in the SPI flash device tree node. The environment is also in Kconfig. What sort of option ROMs do you want to support? What other options does seabios provide? What does SEA stand for? [snip] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] x86: ivybridge: Fix saving mrc cache and enable it
Hi Bin,
On 18 October 2015 at 20:44, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 12 October 2015 at 02:30, Bin Meng wrote:
>>> Currently sdram_initialise() saves pei_data->mrc_output directly to
>>> gd->arch.mrc_output. This is incorrect as pei_data->mrc_output points
>>> to an address on the stack whose content is no longer valid when we
>>> call mrccache_reserve(). To fix this, save it on the heap instead.
>>>
>>> Signed-off-by: Bin Meng
>>> ---
>>>
>>> arch/x86/cpu/ivybridge/sdram.c | 20 ++--
>>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
>>> index fc66a3c..f3d97ca 100644
>>> --- a/arch/x86/cpu/ivybridge/sdram.c
>>> +++ b/arch/x86/cpu/ivybridge/sdram.c
>>> @@ -151,14 +151,8 @@ static int prepare_mrc_cache(struct pei_data *pei_data)
>>> if (!mrc_cache)
>>> return -ENOENT;
>>>
>>> - /*
>>> -* TODO(s...@chromium.org): Skip this for now as it causes boot
>>> -* problems
>>> -*/
>>> - if (0) {
>>> - pei_data->mrc_input = mrc_cache->data;
>>> - pei_data->mrc_input_len = mrc_cache->data_size;
>>> - }
>>> + pei_data->mrc_input = mrc_cache->data;
>>> + pei_data->mrc_input_len = mrc_cache->data_size;
>>> debug("%s: at %p, size %x checksum %04x\n", __func__,
>>> pei_data->mrc_input, pei_data->mrc_input_len,
>>> mrc_cache->checksum);
>>> @@ -289,6 +283,7 @@ int sdram_initialise(struct pei_data *pei_data)
>>> unsigned version;
>>> const char *data;
>>> uint16_t done;
>>> + char *cache;
>>> int ret;
>>>
>>> report_platform_info();
>>> @@ -386,8 +381,13 @@ int sdram_initialise(struct pei_data *pei_data)
>>> * This will be copied to SDRAM in reserve_arch(), then
>>> written
>>> * to SPI flash in mrccache_save()
>>> */
>>> - gd->arch.mrc_output = (char *)pei_data->mrc_output;
>>> - gd->arch.mrc_output_len = pei_data->mrc_output_len;
>>> + cache = malloc(pei_data->mrc_output_len);
>>> + if (cache) {
>>> + memcpy(cache, pei_data->mrc_output,
>>> + pei_data->mrc_output_len);
>>> + gd->arch.mrc_output = cache;
>>> + gd->arch.mrc_output_len = pei_data->mrc_output_len;
>>> + }
>>
>> This isn't really any better than what is there. The malloc() region
>> is in CAR memory, just a different part of it. The function
>> reserve_arch() copies it to SDRAM.
>
> So where does this pei_data->mrc_input point to? Is it some place that
> is malloced by the MRC itself and in a place that does not get
> overwritten?
I think it points into the part of CAR that is reserved for use by the MRC.
>
>>
>> I think with FSP this does not work but for ivybridge it seems OK.
>>
>> I'll resend your patch with this part removed. Your comments spurred
>> me to take another look at why MRC was broken on ivybridge, and I
>> found that car_uninit() was wrong. I'll send a series to fix it.
>>
>>> ret = write_seeds_to_cmos(pei_data);
>>> if (ret)
>>> debug("Failed to write seeds to CMOS: %d\n", ret);
>>> --
>>> 1.8.2.1
>>>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] x86: ivybridge: Fix saving mrc cache and enable it
Hi Simon,
On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass wrote:
> Hi Bin,
>
> On 12 October 2015 at 02:30, Bin Meng wrote:
>> Currently sdram_initialise() saves pei_data->mrc_output directly to
>> gd->arch.mrc_output. This is incorrect as pei_data->mrc_output points
>> to an address on the stack whose content is no longer valid when we
>> call mrccache_reserve(). To fix this, save it on the heap instead.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> arch/x86/cpu/ivybridge/sdram.c | 20 ++--
>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
>> index fc66a3c..f3d97ca 100644
>> --- a/arch/x86/cpu/ivybridge/sdram.c
>> +++ b/arch/x86/cpu/ivybridge/sdram.c
>> @@ -151,14 +151,8 @@ static int prepare_mrc_cache(struct pei_data *pei_data)
>> if (!mrc_cache)
>> return -ENOENT;
>>
>> - /*
>> -* TODO(s...@chromium.org): Skip this for now as it causes boot
>> -* problems
>> -*/
>> - if (0) {
>> - pei_data->mrc_input = mrc_cache->data;
>> - pei_data->mrc_input_len = mrc_cache->data_size;
>> - }
>> + pei_data->mrc_input = mrc_cache->data;
>> + pei_data->mrc_input_len = mrc_cache->data_size;
>> debug("%s: at %p, size %x checksum %04x\n", __func__,
>> pei_data->mrc_input, pei_data->mrc_input_len,
>> mrc_cache->checksum);
>> @@ -289,6 +283,7 @@ int sdram_initialise(struct pei_data *pei_data)
>> unsigned version;
>> const char *data;
>> uint16_t done;
>> + char *cache;
>> int ret;
>>
>> report_platform_info();
>> @@ -386,8 +381,13 @@ int sdram_initialise(struct pei_data *pei_data)
>> * This will be copied to SDRAM in reserve_arch(), then
>> written
>> * to SPI flash in mrccache_save()
>> */
>> - gd->arch.mrc_output = (char *)pei_data->mrc_output;
>> - gd->arch.mrc_output_len = pei_data->mrc_output_len;
>> + cache = malloc(pei_data->mrc_output_len);
>> + if (cache) {
>> + memcpy(cache, pei_data->mrc_output,
>> + pei_data->mrc_output_len);
>> + gd->arch.mrc_output = cache;
>> + gd->arch.mrc_output_len = pei_data->mrc_output_len;
>> + }
>
> This isn't really any better than what is there. The malloc() region
> is in CAR memory, just a different part of it. The function
> reserve_arch() copies it to SDRAM.
So where does this pei_data->mrc_input point to? Is it some place that
is malloced by the MRC itself and in a place that does not get
overwritten?
>
> I think with FSP this does not work but for ivybridge it seems OK.
>
> I'll resend your patch with this part removed. Your comments spurred
> me to take another look at why MRC was broken on ivybridge, and I
> found that car_uninit() was wrong. I'll send a series to fix it.
>
>> ret = write_seeds_to_cmos(pei_data);
>> if (ret)
>> debug("Failed to write seeds to CMOS: %d\n", ret);
>> --
>> 1.8.2.1
>>
>
> Regards,
> Simon
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 5/9] arm: serial: Add ability to use pre-initialized UARTs
Hi Tom, On 16 October 2015 at 18:23, Tom Rini wrote: > On Fri, Oct 16, 2015 at 04:27:31PM -0600, Simon Glass wrote: >> Hi Linus, >> >> On 16 October 2015 at 15:23, Linus Walleij wrote: >> > On Wed, Oct 14, 2015 at 6:55 PM, Sergey Temerkhanov >> > wrote: >> > >> >> On some systems, UART initialization is performed before running U-Boot. >> >> This commit allows to skip UART re-initializaion on those systems >> >> >> >> Signed-off-by: Sergey Temerkhanov >> >> Signed-off-by: Radha Mohan Chintakuntla >> >> >> >> Reviewed-by: Simon Glass >> > (...) >> > >> >> diff --git a/doc/device-tree-bindings/serial/pl01x.txt >> >> b/doc/device-tree-bindings/serial/pl01x.txt >> >> index 61c27d1..0591497 100644 >> >> --- a/doc/device-tree-bindings/serial/pl01x.txt >> >> +++ b/doc/device-tree-bindings/serial/pl01x.txt >> >> @@ -5,3 +5,6 @@ Required properties: >> >> - reg: exactly one register range with length 0x1000 >> >> - clock: input clock frequency for the UART (used to calculate the baud >> >>rate divisor) >> >> + >> >> +Optional properties: >> >> +- u-boot,skip-init: skip UART initialization at start. >> > >> > Again: get this merged in the Linux kernel FIRST. Is it? >> >> We had a little bit of a chat about this at ELCE. It would be great to >> get these changes merged with the kernel but the amount of >> push-back/energy it requires is still excessive IMO. Any thoughts? > > But it also requires that we try. Did we try here? My first thought is > that there's a number of things it would be nice to say "don't re-init > stuff" to the kernel as well. See the thread that ends here: http://lists.denx.de/pipermail/u-boot/2015-July/219283.html Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] rtc: mc146818: Use probe() to set up the device
Hi Simon, On Mon, Oct 19, 2015 at 10:38 AM, Simon Glass wrote: > Hi Bin, > > On 18 October 2015 at 20:32, Bin Meng wrote: >> Hi Simon, >> >> On Mon, Oct 19, 2015 at 10:26 AM, Simon Glass wrote: >>> Hi Bin, >>> >>> On 18 October 2015 at 20:22, Bin Meng wrote: Hi Simon, On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote: > At present this driver uses bind() to set up the device. The bind() method > should not touch the hardware, so move the init code to probe(). > I think RTC should be initialized anyway. If moving it to probe, it may not be initialized by U-Boot before jumping to kernel. >>> >>> That's fine, but the correct way to do this is to probe the device, >>> not put the init code into the bind() method. >> >> Yes, I agree. So maybe we explicitly trigger the probe somewhere in >> the initialization path? >> > > Or maybe just before jumping to the OS - e.g. in boot_prep_linux()? > Yes, that sounds good. And we may need consider other OSes as well. Maybe we need some consolidation. > [snip] > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] rtc: mc146818: Use probe() to set up the device
Hi Bin, On 18 October 2015 at 20:32, Bin Meng wrote: > Hi Simon, > > On Mon, Oct 19, 2015 at 10:26 AM, Simon Glass wrote: >> Hi Bin, >> >> On 18 October 2015 at 20:22, Bin Meng wrote: >>> Hi Simon, >>> >>> On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote: At present this driver uses bind() to set up the device. The bind() method should not touch the hardware, so move the init code to probe(). >>> >>> I think RTC should be initialized anyway. If moving it to probe, it >>> may not be initialized by U-Boot before jumping to kernel. >> >> That's fine, but the correct way to do this is to probe the device, >> not put the init code into the bind() method. > > Yes, I agree. So maybe we explicitly trigger the probe somewhere in > the initialization path? > Or maybe just before jumping to the OS - e.g. in boot_prep_linux()? [snip] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: convert altera_tse to driver model and phylib
Convert altera_tse to driver model and phylib.
Signed-off-by: Thomas Chou
---
configs/nios2-generic_defconfig | 2 +
doc/device-tree-bindings/net/altera_tse.txt | 112
drivers/net/Kconfig | 9 +
drivers/net/altera_tse.c| 938 ++--
drivers/net/altera_tse.h| 283 +++--
include/configs/nios2-generic.h | 8 +
6 files changed, 536 insertions(+), 816 deletions(-)
create mode 100644 doc/device-tree-bindings/net/altera_tse.txt
diff --git a/configs/nios2-generic_defconfig b/configs/nios2-generic_defconfig
index ea07b56..fbc27ea 100644
--- a/configs/nios2-generic_defconfig
+++ b/configs/nios2-generic_defconfig
@@ -18,6 +18,8 @@ CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_ALTERA_PIO=y
CONFIG_MISC=y
CONFIG_ALTERA_SYSID=y
+CONFIG_DM_ETH=y
+CONFIG_ALTERA_TSE=y
CONFIG_ALTERA_JTAG_UART=y
CONFIG_ALTERA_JTAG_UART_BYPASS=y
CONFIG_TIMER=y
diff --git a/doc/device-tree-bindings/net/altera_tse.txt
b/doc/device-tree-bindings/net/altera_tse.txt
new file mode 100644
index 000..cb190df
--- /dev/null
+++ b/doc/device-tree-bindings/net/altera_tse.txt
@@ -0,0 +1,112 @@
+* Altera Triple-Speed Ethernet MAC driver (TSE)
+
+Required properties:
+- compatible: Should be "altr,tse-1.0" for legacy SGDMA based TSE, and should
+ be "altr,tse-msgdma-1.0" for the preferred MSGDMA based TSE.
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ "control_port": MAC configuration space region
+ "tx_csr": xDMA Tx dispatcher control and status space region
+ "tx_desc": MSGDMA Tx dispatcher descriptor space region
+ "rx_csr" : xDMA Rx dispatcher control and status space region
+ "rx_desc": MSGDMA Rx dispatcher descriptor space region
+ "rx_resp": MSGDMA Rx dispatcher response space region
+ "s1": SGDMA descriptor memory
+- interrupts: Should contain the TSE interrupts and it's mode.
+- interrupt-names: Should contain the interrupt names
+ "rx_irq": xDMA Rx dispatcher interrupt
+ "tx_irq": xDMA Tx dispatcher interrupt
+- rx-fifo-depth: MAC receive FIFO buffer depth in bytes
+- tx-fifo-depth: MAC transmit FIFO buffer depth in bytes
+- phy-mode: See ethernet.txt in the same directory.
+- phy-handle: See ethernet.txt in the same directory.
+- phy-addr: See ethernet.txt in the same directory. A configuration should
+ include phy-handle or phy-addr.
+- altr,has-supplementary-unicast:
+ If present, TSE supports additional unicast addresses.
+ Otherwise additional unicast addresses are not supported.
+- altr,has-hash-multicast-filter:
+ If present, TSE supports a hash based multicast filter.
+ Otherwise, hash-based multicast filtering is not supported.
+
+- mdio device tree subnode: When the TSE has a phy connected to its local
+ mdio, there must be device tree subnode with the following
+ required properties:
+
+ - compatible: Must be "altr,tse-mdio".
+ - #address-cells: Must be <1>.
+ - #size-cells: Must be <0>.
+
+ For each phy on the mdio bus, there must be a node with the following
+ fields:
+
+ - reg: phy id used to communicate to phy.
+ - device_type: Must be "ethernet-phy".
+
+Optional properties:
+- local-mac-address: See ethernet.txt in the same directory.
+- max-frame-size: See ethernet.txt in the same directory.
+
+Example:
+
+ tse_sub_0_eth_tse_0: ethernet@0x1, {
+ compatible = "altr,tse-msgdma-1.0";
+ reg = <0x0001 0x 0x0400>,
+ <0x0001 0x0460 0x0020>,
+ <0x0001 0x0480 0x0020>,
+ <0x0001 0x04A0 0x0008>,
+ <0x0001 0x0400 0x0020>,
+ <0x0001 0x0420 0x0020>;
+ reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp",
"tx_csr", "tx_desc";
+ interrupt-parent = <&hps_0_arm_gic_0>;
+ interrupts = <0 41 4>, <0 40 4>;
+ interrupt-names = "rx_irq", "tx_irq";
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ address-bits = <48>;
+ max-frame-size = <1500>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ phy-mode = "gmii";
+ altr,has-supplementary-unicast;
+ altr,has-hash-multicast-filter;
+ phy-handle = <&phy0>;
+ mdio {
+ compatible = "altr,tse-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
Re: [U-Boot] [PATCH 2/9] rtc: mc146818: Use probe() to set up the device
Hi Simon,
On Mon, Oct 19, 2015 at 10:26 AM, Simon Glass wrote:
> Hi Bin,
>
> On 18 October 2015 at 20:22, Bin Meng wrote:
>> Hi Simon,
>>
>> On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote:
>>> At present this driver uses bind() to set up the device. The bind() method
>>> should not touch the hardware, so move the init code to probe().
>>>
>>
>> I think RTC should be initialized anyway. If moving it to probe, it
>> may not be initialized by U-Boot before jumping to kernel.
>
> That's fine, but the correct way to do this is to probe the device,
> not put the init code into the bind() method.
Yes, I agree. So maybe we explicitly trigger the probe somewhere in
the initialization path?
>
>>
>>> Signed-off-by: Simon Glass
>>> ---
>>>
>>> drivers/rtc/mc146818.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/rtc/mc146818.c b/drivers/rtc/mc146818.c
>>> index 9e94a80..da804d5 100644
>>> --- a/drivers/rtc/mc146818.c
>>> +++ b/drivers/rtc/mc146818.c
>>> @@ -225,7 +225,7 @@ static int rtc_mc146818_write8(struct udevice *dev,
>>> unsigned int reg, int val)
>>> return 0;
>>> }
>>>
>>> -static int rtc_mc146818_bind(struct udevice *dev)
>>> +static int rtc_mc146818_probe(struct udevice *dev)
>>> {
>>> mc146818_init();
>>>
>>> @@ -249,7 +249,7 @@ U_BOOT_DRIVER(rtc_mc146818) = {
>>> .name = "rtc_mc146818",
>>> .id = UCLASS_RTC,
>>> .of_match = rtc_mc146818_ids,
>>> - .bind = rtc_mc146818_bind,
>>> + .probe = rtc_mc146818_probe,
>>> .ops = &rtc_mc146818_ops,
>>> };
>>>
>>> --
>>
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] x86: baytrail: Issue full system reset in reset_cpu()
Hi Simon,
On Mon, Oct 19, 2015 at 10:24 AM, Simon Glass wrote:
> Hi Bin,
>
> On 18 October 2015 at 20:01, Bin Meng wrote:
>> Hi Simon,
>>
>> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass wrote:
>>> Hi Bin,
>>>
>>> On 11 October 2015 at 22:37, Bin Meng wrote:
With MRC cache enabled, when typing 'reset' in the U-Boot shell,
BayTrail FSP initialization hangs at "Configuring Memory Start":
Setting BootMode to 0
Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56
Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
About to call MrcInit();
BayleyBay Platform Type
CurrentMrcData.BootMode = 4
Taking Fastboot path!
Configuring Memory Start...
Changing reset_cpu() to do a full system reset fixes this issue.
Signed-off-by: Bin Meng
---
arch/x86/cpu/baytrail/valleyview.c | 6 ++
1 file changed, 6 insertions(+)
>>>
>>> Acked-by: Simon Glass
>>>
diff --git a/arch/x86/cpu/baytrail/valleyview.c
b/arch/x86/cpu/baytrail/valleyview.c
index 215e0d0..a009c14 100644
--- a/arch/x86/cpu/baytrail/valleyview.c
+++ b/arch/x86/cpu/baytrail/valleyview.c
@@ -65,3 +65,9 @@ int reserve_arch(void)
#endif
}
#endif
+
+void reset_cpu(ulong addr)
+{
+ /* cold reset */
+ x86_full_reset();
+}
--
1.8.2.1
>>>
>>> Actually on Minnowmax this doesn't fix the hang.
>>
>> That's strange. As full reset indicates a complete power cycle. Does
>> MinnowMax boot with MRC cache enabled?
>
> It's hard to tell because the UART does not work that early. I wish we
> could fix that. I thought I did have it running at one point, but I
> may have imagined it.
We need figure out where the hang happens. Is it in FSP, or in U-Boot?
You can use a debug version of FSP (the gold4 release includes a debug
version FSP) to see where the FSP hangs if it is the FSP hang case.
>
> Re the hang, I'm not sure - it seems to have stopped happening, so
> let's not worry about it for now.
>
>
>>>
>>> Also I don't see any speed-up from using the cache on Minnowmax.
>>
>> On Galileo, I did not see any speed-up either. I think it is because
>> on MinnowMax and Galileo they both uses memory-down configuration. The
>> speed-up seems only helpful for DIMMs (on Intel Bayley Bay)
>
> So what is the point of enabling the MRC cache?
>
On Bayley Bay it indeed improves the boot time. So, maybe we can just
leave this option unselected by the defconfig files for Chromebook and
Galileo?
One thing I noticed that on Chromebook the memory SPD is passed by
device tree. Is there any DIMM on the Chromebook and the SPD in device
tree is just a short-cut for the MRC? If we let MRC reads the SPD,
does MRC cache help?
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/13] x86: fsp: Report correct number of E820 table entries
Hi Tom, On 18 October 2015 at 18:09, Tom Rini wrote: > On Sun, Oct 18, 2015 at 06:58:51AM -0600, Simon Glass wrote: >> Hi Tom, >> >> On 28 September 2015 at 22:52, Simon Glass wrote: >> > On 28 September 2015 at 03:11, Bin Meng wrote: >> >> The logic to calculate the number of E820 table entries is wrong >> >> when walking through the FSP HOB tables. Fix it. >> >> >> >> Signed-off-by: Bin Meng >> >> Tested-by: Jian Luo >> >> >> >> --- >> >> Simon, I think we need get this fix in v2015.10 release. >> >> >> >> Changes in v2: None >> >> >> >> arch/x86/lib/fsp/fsp_dram.c | 3 ++- >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > Acked-by: Simon Glass >> >> Are you able to pick this one up if it is not too late? > > ... > $ git am -3 > U-Boot-v2-02-13-x86-fsp-Report-correct-number-of-E820-table-entries.patch > Applying: x86: fsp: Report correct number of E820 table entries > Using index info to reconstruct a base tree... > Falling back to patching base and 3-way merge... > No changes -- Patch already applied. > $ Sorry, I must have applied it in a moment of delirium. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] x86: ivybridge: Fix car_uninit() to correctly set run state
Hi Bin, On 18 October 2015 at 20:23, Bin Meng wrote: > Hi Simon, > > On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote: >> At present a missing $ causes this code to hang when using the MRC cache/ >> Fix it. >> >> Signed-off-by: Simon Glass > > Reviewed-by: Bin Meng > >> --- >> >> arch/x86/cpu/ivybridge/car.S | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/x86/cpu/ivybridge/car.S b/arch/x86/cpu/ivybridge/car.S >> index 770ef17..b75c2a5 100644 >> --- a/arch/x86/cpu/ivybridge/car.S >> +++ b/arch/x86/cpu/ivybridge/car.S >> @@ -188,7 +188,7 @@ car_uninit: >> wrmsr >> >> /* Disable the no-eviction run state */ >> - movlNOEVICTMOD_MSR, %ecx >> + movl$NOEVICTMOD_MSR, %ecx > > I am wondering why compiler does not complain this. > I suppose it just uses the value at that address. >> rdmsr >> andl$~2, %eax >> wrmsr >> -- Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] rtc: mc146818: Use probe() to set up the device
Hi Bin,
On 18 October 2015 at 20:22, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote:
>> At present this driver uses bind() to set up the device. The bind() method
>> should not touch the hardware, so move the init code to probe().
>>
>
> I think RTC should be initialized anyway. If moving it to probe, it
> may not be initialized by U-Boot before jumping to kernel.
That's fine, but the correct way to do this is to probe the device,
not put the init code into the bind() method.
>
>> Signed-off-by: Simon Glass
>> ---
>>
>> drivers/rtc/mc146818.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/rtc/mc146818.c b/drivers/rtc/mc146818.c
>> index 9e94a80..da804d5 100644
>> --- a/drivers/rtc/mc146818.c
>> +++ b/drivers/rtc/mc146818.c
>> @@ -225,7 +225,7 @@ static int rtc_mc146818_write8(struct udevice *dev,
>> unsigned int reg, int val)
>> return 0;
>> }
>>
>> -static int rtc_mc146818_bind(struct udevice *dev)
>> +static int rtc_mc146818_probe(struct udevice *dev)
>> {
>> mc146818_init();
>>
>> @@ -249,7 +249,7 @@ U_BOOT_DRIVER(rtc_mc146818) = {
>> .name = "rtc_mc146818",
>> .id = UCLASS_RTC,
>> .of_match = rtc_mc146818_ids,
>> - .bind = rtc_mc146818_bind,
>> + .probe = rtc_mc146818_probe,
>> .ops = &rtc_mc146818_ops,
>> };
>>
>> --
>
> Regards,
> Bin
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/13] x86: Use struct mrc_region to describe a mrc region
Hi Bin, On 18 October 2015 at 19:58, Bin Meng wrote: > Hi Simon, > > On Mon, Oct 19, 2015 at 4:26 AM, Simon Glass wrote: >> Hi Bin, >> >> On 11 October 2015 at 22:37, Bin Meng wrote: >>> Currently struct fmap_entry is used to describe a mrc region. >>> However this structure contains some other fields that are not >>> related to mrc cache and causes confusion. Besides, it does not >>> include a base address field to store SPI flash's base address. >>> Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to >>> calculate the SPI flash base address, which unfortunately is >>> not 100% correct as CONFIG_ROM_SIZE may not match the whole >>> SPI flash size. >> >> I'm still not comfortable with CONFIG_ROM_SIZE not being the size of >> the SPI flash. It just seems wrong. Maybe we should have a >> u-boot.rom.min with a minimal images? >> > > As we discussed before, we can just document this in README.x86? > Yes although it irks me when I see a commit message suggesting that it is causing problems! >>> >>> Define a new struct mrc_region and use it instead. >>> >>> Signed-off-by: Bin Meng >>> --- >>> >>> arch/x86/cpu/ivybridge/sdram.c | 2 +- >>> arch/x86/include/asm/mrccache.h | 13 + >>> arch/x86/lib/mrccache.c | 27 +-- >>> 3 files changed, 27 insertions(+), 15 deletions(-) >> >> Acked-by: Simon Glass > > Regards, > Bin Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] x86: baytrail: Issue full system reset in reset_cpu()
Hi Bin,
On 18 October 2015 at 20:01, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 11 October 2015 at 22:37, Bin Meng wrote:
>>> With MRC cache enabled, when typing 'reset' in the U-Boot shell,
>>> BayTrail FSP initialization hangs at "Configuring Memory Start":
>>>
>>> Setting BootMode to 0
>>> Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56
>>> Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
>>> About to call MrcInit();
>>> BayleyBay Platform Type
>>> CurrentMrcData.BootMode = 4
>>> Taking Fastboot path!
>>> Configuring Memory Start...
>>>
>>> Changing reset_cpu() to do a full system reset fixes this issue.
>>>
>>> Signed-off-by: Bin Meng
>>> ---
>>>
>>> arch/x86/cpu/baytrail/valleyview.c | 6 ++
>>> 1 file changed, 6 insertions(+)
>>
>> Acked-by: Simon Glass
>>
>>>
>>> diff --git a/arch/x86/cpu/baytrail/valleyview.c
>>> b/arch/x86/cpu/baytrail/valleyview.c
>>> index 215e0d0..a009c14 100644
>>> --- a/arch/x86/cpu/baytrail/valleyview.c
>>> +++ b/arch/x86/cpu/baytrail/valleyview.c
>>> @@ -65,3 +65,9 @@ int reserve_arch(void)
>>> #endif
>>> }
>>> #endif
>>> +
>>> +void reset_cpu(ulong addr)
>>> +{
>>> + /* cold reset */
>>> + x86_full_reset();
>>> +}
>>> --
>>> 1.8.2.1
>>>
>>
>> Actually on Minnowmax this doesn't fix the hang.
>
> That's strange. As full reset indicates a complete power cycle. Does
> MinnowMax boot with MRC cache enabled?
It's hard to tell because the UART does not work that early. I wish we
could fix that. I thought I did have it running at one point, but I
may have imagined it.
Re the hang, I'm not sure - it seems to have stopped happening, so
let's not worry about it for now.
>>
>> Also I don't see any speed-up from using the cache on Minnowmax.
>
> On Galileo, I did not see any speed-up either. I think it is because
> on MinnowMax and Galileo they both uses memory-down configuration. The
> speed-up seems only helpful for DIMMs (on Intel Bayley Bay)
So what is the point of enabling the MRC cache?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] x86: ivybridge: Enable the MRC cache
On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote:
> From: Bin Meng
>
> This works correctly now, so enable it.
>
> Signed-off-by: Bin Meng
> Dropped malloc() and adjusted commit message:
> Signed-off-by: Simon Glass
>
> ---
>
> arch/x86/cpu/ivybridge/sdram.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
> index d9b3dfc..4372a5c 100644
> --- a/arch/x86/cpu/ivybridge/sdram.c
> +++ b/arch/x86/cpu/ivybridge/sdram.c
> @@ -158,14 +158,8 @@ static int prepare_mrc_cache(struct pei_data *pei_data)
> if (!mrc_cache)
> return -ENOENT;
>
> - /*
> -* TODO(s...@chromium.org): Skip this for now as it causes boot
> -* problems
> -*/
> - if (0) {
> - pei_data->mrc_input = mrc_cache->data;
> - pei_data->mrc_input_len = mrc_cache->data_size;
> - }
> + pei_data->mrc_input = mrc_cache->data;
> + pei_data->mrc_input_len = mrc_cache->data_size;
> debug("%s: at %p, size %x checksum %04x\n", __func__,
> pei_data->mrc_input, pei_data->mrc_input_len,
> mrc_cache->checksum);
> --
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] x86: ivybridge: Measure the MRC code execution time
On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote:
> This code takes about 450ms without the MRC cache and about 27ms with the
> cache. Add a debug timer so that this time can be displayed.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/sdram.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
> index e637909..d9b3dfc 100644
> --- a/arch/x86/cpu/ivybridge/sdram.c
> +++ b/arch/x86/cpu/ivybridge/sdram.c
> @@ -336,9 +336,11 @@ int sdram_initialise(struct pei_data *pei_data)
> if (data) {
> int rv;
> int (*func)(struct pei_data *);
> + ulong start;
>
> debug("Calling MRC at %p\n", data);
> post_code(POST_PRE_MRC);
> + start = get_timer(0);
> func = (int (*)(struct pei_data *))data;
> rv = func(pei_data);
> post_code(POST_MRC);
> @@ -356,6 +358,7 @@ int sdram_initialise(struct pei_data *pei_data)
> printf("Nonzero MRC return value.\n");
> return -EFAULT;
> }
> + debug("MRC execution time %lu ms\n", get_timer(start));
> } else {
> printf("UEFI PEI System Agent not found.\n");
> return -ENOSYS;
> --
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] x86: ivybridge: Fix car_uninit() to correctly set run state
Hi Simon, On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote: > At present a missing $ causes this code to hang when using the MRC cache/ > Fix it. > > Signed-off-by: Simon Glass Reviewed-by: Bin Meng > --- > > arch/x86/cpu/ivybridge/car.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/cpu/ivybridge/car.S b/arch/x86/cpu/ivybridge/car.S > index 770ef17..b75c2a5 100644 > --- a/arch/x86/cpu/ivybridge/car.S > +++ b/arch/x86/cpu/ivybridge/car.S > @@ -188,7 +188,7 @@ car_uninit: > wrmsr > > /* Disable the no-eviction run state */ > - movlNOEVICTMOD_MSR, %ecx > + movl$NOEVICTMOD_MSR, %ecx I am wondering why compiler does not complain this. > rdmsr > andl$~2, %eax > wrmsr > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] x86: ivybridge: Check the RTC return value
On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote:
> The RTC can fail, so check the return value for reads.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/sdram.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
> index 26e2e5b..e637909 100644
> --- a/arch/x86/cpu/ivybridge/sdram.c
> +++ b/arch/x86/cpu/ivybridge/sdram.c
> @@ -107,11 +107,18 @@ static int read_seed_from_cmos(struct pei_data
> *pei_data)
> * the flash too much. So we store these in CMOS and the large MRC
> * data in SPI flash.
> */
> - rtc_read32(dev, CMOS_OFFSET_MRC_SEED, &pei_data->scrambler_seed);
> + ret = rtc_read32(dev, CMOS_OFFSET_MRC_SEED,
> &pei_data->scrambler_seed);
> + if (!ret) {
> + ret = rtc_read32(dev, CMOS_OFFSET_MRC_SEED_S3,
> +&pei_data->scrambler_seed_s3);
> + }
> + if (ret) {
> + debug("Failed to read from RTC %s\n", dev->name);
> + return ret;
> + }
> +
> debug("Read scrambler seed0x%08x from CMOS 0x%02x\n",
> pei_data->scrambler_seed, CMOS_OFFSET_MRC_SEED);
> -
> - rtc_read32(dev, CMOS_OFFSET_MRC_SEED_S3,
> &pei_data->scrambler_seed_s3);
> debug("Read S3 scrambler seed 0x%08x from CMOS 0x%02x\n",
> pei_data->scrambler_seed_s3, CMOS_OFFSET_MRC_SEED_S3);
>
> --
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] dm: rtc: Correct rtc_read32() return value
On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote:
> The current check is incorrect and will fail when any non-zero byte is read.
> Fix it.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/rtc/rtc-uclass.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
> index fe74c69..300e9b3 100644
> --- a/drivers/rtc/rtc-uclass.c
> +++ b/drivers/rtc/rtc-uclass.c
> @@ -68,7 +68,7 @@ int rtc_read32(struct udevice *dev, unsigned int reg, u32
> *valuep)
>
> for (i = 0; i < sizeof(value); i++) {
> ret = rtc_read8(dev, reg + i);
> - if (ret)
> + if (ret < 0)
> return ret;
> value |= ret << (i << 3);
> }
> --
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] x86: ivybridge: Use CONFIG_ENABLE_MRC_CACHE option
Hi Simon, On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote: > Use this option instead of a private CONFIG_CACHE_MRC_BIN option. > The CONFIG_CACHE_MRC_BIN option seems to be used to program the MTRR for the mrc.bin text range to make it run faster. It is nothing related to the MRC cache data that the CONFIG_ENABLE_MRC_CACHE option is about. > Signed-off-by: Simon Glass > --- > > arch/x86/cpu/ivybridge/Kconfig | 6 -- > arch/x86/cpu/ivybridge/car.S | 4 ++-- > 2 files changed, 2 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/cpu/ivybridge/Kconfig b/arch/x86/cpu/ivybridge/Kconfig > index 0e249a4..c3f324e 100644 > --- a/arch/x86/cpu/ivybridge/Kconfig > +++ b/arch/x86/cpu/ivybridge/Kconfig > @@ -8,12 +8,10 @@ > > config NORTHBRIDGE_INTEL_SANDYBRIDGE > bool > - select CACHE_MRC_BIN > select CPU_INTEL_MODEL_206AX > > config NORTHBRIDGE_INTEL_IVYBRIDGE > bool > - select CACHE_MRC_BIN > select CPU_INTEL_MODEL_306AX > > if NORTHBRIDGE_INTEL_SANDYBRIDGE > @@ -136,8 +134,4 @@ config SOCKET_SPECIFIC_OPTIONS # dummy > select SSE > select CACHE_AS_RAM > > -config CACHE_MRC_BIN > - bool > - default n > - > endif > diff --git a/arch/x86/cpu/ivybridge/car.S b/arch/x86/cpu/ivybridge/car.S > index 407e451..770ef17 100644 > --- a/arch/x86/cpu/ivybridge/car.S > +++ b/arch/x86/cpu/ivybridge/car.S > @@ -145,7 +145,7 @@ clear_mtrrs: > wrmsr > > post_code(POST_CAR_ROM_CACHE) > -#ifdef CONFIG_CACHE_MRC_BIN > +#ifdef CONFIG_ENABLE_MRC_CACHE > /* Enable caching for ram init code to run faster */ > movl$MTRR_PHYS_BASE_MSR(2), %ecx > movl$(CACHE_MRC_BASE | MTRR_TYPE_WRPROT), %eax > @@ -200,7 +200,7 @@ car_uninit: > andl$~1, %eax > wrmsr > > -#ifdef CONFIG_CACHE_MRC_BIN > +#ifdef CONFIG_ENABLE_MRC_CACHE > /* Clear the MTRR that was used to cache MRC */ > xorl%eax, %eax > xorl%edx, %edx > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] rtc: mc146818: Use probe() to set up the device
Hi Simon,
On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote:
> At present this driver uses bind() to set up the device. The bind() method
> should not touch the hardware, so move the init code to probe().
>
I think RTC should be initialized anyway. If moving it to probe, it
may not be initialized by U-Boot before jumping to kernel.
> Signed-off-by: Simon Glass
> ---
>
> drivers/rtc/mc146818.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/mc146818.c b/drivers/rtc/mc146818.c
> index 9e94a80..da804d5 100644
> --- a/drivers/rtc/mc146818.c
> +++ b/drivers/rtc/mc146818.c
> @@ -225,7 +225,7 @@ static int rtc_mc146818_write8(struct udevice *dev,
> unsigned int reg, int val)
> return 0;
> }
>
> -static int rtc_mc146818_bind(struct udevice *dev)
> +static int rtc_mc146818_probe(struct udevice *dev)
> {
> mc146818_init();
>
> @@ -249,7 +249,7 @@ U_BOOT_DRIVER(rtc_mc146818) = {
> .name = "rtc_mc146818",
> .id = UCLASS_RTC,
> .of_match = rtc_mc146818_ids,
> - .bind = rtc_mc146818_bind,
> + .probe = rtc_mc146818_probe,
> .ops = &rtc_mc146818_ops,
> };
>
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] x86: ivybridge: Use 'ret' instead of 'rcode'
On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote:
> For consistency, use 'ret' to handle a return value.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/sdram.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
> index fc66a3c..26e2e5b 100644
> --- a/arch/x86/cpu/ivybridge/sdram.c
> +++ b/arch/x86/cpu/ivybridge/sdram.c
> @@ -93,11 +93,11 @@ static int read_seed_from_cmos(struct pei_data *pei_data)
> {
> u16 c1, c2, checksum, seed_checksum;
> struct udevice *dev;
> - int rcode = 0;
> + int ret = 0;
>
> - rcode = uclass_get_device(UCLASS_RTC, 0, &dev);
> - if (rcode) {
> - debug("Cannot find RTC: err=%d\n", rcode);
> + ret = uclass_get_device(UCLASS_RTC, 0, &dev);
> + if (ret) {
> + debug("Cannot find RTC: err=%d\n", ret);
> return -ENODEV;
> }
>
> @@ -170,11 +170,11 @@ static int write_seeds_to_cmos(struct pei_data
> *pei_data)
> {
> u16 c1, c2, checksum;
> struct udevice *dev;
> - int rcode = 0;
> + int ret = 0;
>
> - rcode = uclass_get_device(UCLASS_RTC, 0, &dev);
> - if (rcode) {
> - debug("Cannot find RTC: err=%d\n", rcode);
> + ret = uclass_get_device(UCLASS_RTC, 0, &dev);
> + if (ret) {
> + debug("Cannot find RTC: err=%d\n", ret);
> return -ENODEV;
> }
>
> --
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] rtc: mc146818: Add a comment to the #endif
On Mon, Oct 19, 2015 at 5:55 AM, Simon Glass wrote: > Add a comment to make it clear to which block the #endif relates. > > Signed-off-by: Simon Glass > --- > > drivers/rtc/mc146818.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/rtc/mc146818.c b/drivers/rtc/mc146818.c > index 363ade3..9e94a80 100644 > --- a/drivers/rtc/mc146818.c > +++ b/drivers/rtc/mc146818.c > @@ -192,7 +192,7 @@ static void mc146818_init(void) > /* Clear any pending interrupts */ > mc146818_read8(RTC_CONFIG_C); > } > -#endif > +#endif /* CONFIG_CMD_DATE */ > > #ifdef CONFIG_DM_RTC > > -- Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 11/11] exynos5-dt-types: add board detection for Odroid XU3/XU3L/XU4.
Hi Premyslaw,
On 13 October 2015 at 05:59, Przemyslaw Marczak wrote:
> Hello Simon,
>
>
> On 10/03/2015 04:28 PM, Simon Glass wrote:
>>
>> Hi Przemyslaw,
>>
>> On 21 September 2015 at 13:26, Przemyslaw Marczak
>> wrote:
>>>
>>> This commit adds additional file with implementation of board
>>> detection code for Odroid-XU3/XU4.
>>>
>>> The detection depends on compatible found in fdt:
>>> - "samsung,exynos5" - uses Exynos5 generic code
>>> - "samsung,odroidxu3" - try detect XU3 revision
>>>
>>> There are few revisions of Odroid XU3/XU4, each can be detected
>>> by checking the value of channel 9 of built-in ADC:
>>> Rev ADC Board
>>> 0.1 0 XU3 0.1
>>> 0.2 372 XU3 0.2 | XU3L - no DISPLAYPORT
>>> 0.3 1280 XU4 0.1
>>>
>>> The detection code depends on the ADC+10% value.
>>>
>>> Implementation of functions:
>>> - set_board_type() - read ADC and set type
>>> - get_board_rev() - returns board revision: 1..3
>>> - get_board_type() - returns board type string
>>>
>>> Additional functions with return values of bool:
>>> - board_is_generic() - true if found compatible "samsung,exynos5"
>>> but not "samsung,odroidxu3"
>>> - board_is_odroidxu3() - true if found compatible "samsung,odroidxu3"
>>> and one of XU3 revision.
>>> - board_is_odroidxu4() - true if found compatible "samsung,odroidxu3"
>>> and XU4 revision.
>>>
>>> After I2C controller init, the get_board_type() can check
>>> if the XU3 board is a "Lite" variant, by probing chip
>>> 0x40 on I2C0 (INA231 - exists only on non-lite).
>>> This is useful for setting fdt file name at misc_init_r().
>>>
>>> Enabled configs:
>>> - CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>>> - CONFIG_ODROID_REV_AIN
>>> - CONFIG_REVISION_TAG
>>> - CONFIG_BOARD_TYPES
>>>
>>> Signed-off-by: Przemyslaw Marczak
>>> ---
>>> Changes V2:
>>> - move detection code from exynos5-dt.c to exynos5-dt-types.c
>>> - add header with board type function declarations
>>> - check for compatible before do the detection
>>> - update the ADC max values with 20% tolerance
>>> - fix XU4 adc value, related to mistake from table in XU4 schematic
>>> - return "Not supported" for XU4 when calls one of:
>>>--dfu_get_alt_boot()
>>>--dfu_get_alt_system()
>>> - extend ${dfu_alt_system} by strings:
>>>-- 'exynos5422-odroidxu3-lite.dtb'
>>>-- 'exynos5422-odroidxu4.dtb' - allows prepare card on XU3
>>> ---
>>> board/samsung/common/Makefile | 5 +-
>>> board/samsung/common/exynos5-dt-types.c | 196
>>>
>>> board/samsung/common/exynos5-dt.c | 12 ++
>>> configs/odroid-xu3_defconfig| 2 +
>>> include/configs/odroid_xu3.h| 12 ++
>>> include/samsung/exynos5-dt-types.h | 27 +
>>> 6 files changed, 253 insertions(+), 1 deletion(-)
>>> create mode 100644 board/samsung/common/exynos5-dt-types.c
>>> create mode 100644 include/samsung/exynos5-dt-types.h
>>
>>
>> Reviewed-by: Simon Glass
>>
>> See nits below.
>>
>
> Ok.
>
>
>>>
>>> diff --git a/board/samsung/common/Makefile
>>> b/board/samsung/common/Makefile
>>> index 6cbd906..ef1a8f3 100644
>>> --- a/board/samsung/common/Makefile
>>> +++ b/board/samsung/common/Makefile
>>> @@ -11,5 +11,8 @@ obj-$(CONFIG_MISC_COMMON) += misc.o
>>>
>>> ifndef CONFIG_SPL_BUILD
>>> obj-$(CONFIG_BOARD_COMMON) += board.o
>>> -obj-$(CONFIG_EXYNOS5_DT) += exynos5-dt.o
>>> +ifdef CONFIG_EXYNOS5_DT
>>> +obj-y += exynos5-dt.o
>>> +obj-$(CONFIG_BOARD_TYPES) += exynos5-dt-types.o
>>> +endif
>>> endif
>>> diff --git a/board/samsung/common/exynos5-dt-types.c
>>> b/board/samsung/common/exynos5-dt-types.c
>>> new file mode 100644
>>> index 000..1364e98
>>> --- /dev/null
>>> +++ b/board/samsung/common/exynos5-dt-types.c
>>> @@ -0,0 +1,196 @@
>>> +/*
>>> + * Copyright (C) 2015 Samsung Electronics
>>> + * Przemyslaw Marczak
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +static const struct udevice_id board_ids[] = {
>>> + { .compatible = "samsung,odroidxu3", .data =
>>> EXYNOS5_BOARD_ODROID_XU3 },
>>> + { .compatible = "samsung,exynos5", .data = EXYNOS5_BOARD_GENERIC
>>> },
>>> + { },
>>> +};
>>> +
>>> +/**
>>> + * Odroix XU3/4 board revisions:
>>> + * Rev ADCmax Board
>>> + * 0.1 0 XU3 0.1
>>> + * 0.2 410 XU3 0.2 | XU3L - no DISPLAYPORT (probe I2C0:0x40 /
>>> INA231)
>>> + * 0.3 1408 XU4 0.1
>>> + * Use +10 % for ADC value tolerance.
>>> + */
>>> +struct odroid_rev_info odroid_info[] = {
>>> + { EXYNOS5_BOARD_ODROID_XU3_REV01, 1, 10, "xu3" },
>>> + { EXYNOS5_BOARD_ODROID_XU3_REV02, 2, 410, "xu3" },
>>> + { EXYNOS5_BOARD_ODROID_XU4_REV01, 1, 1408, "xu4" },
>>> + { EXYNOS5_BOARD_ODROID_UNKNOWN
Re: [U-Boot] [PATCH V2 07/11] dm: adc: add Exynos54xx compatible ADC driver
Hi Przemyslaw,
On 13 October 2015 at 05:58, Przemyslaw Marczak wrote:
> Hello Simon,
>
>
> On 10/03/2015 04:28 PM, Simon Glass wrote:
>>
>> Hi Przemyslaw,
>>
>> On 21 September 2015 at 13:26, Przemyslaw Marczak
>> wrote:
>>>
>>> This commit adds driver for Exynos54xx ADC subsystem.
>>>
>>> The driver is implemented using driver model,
>>> amd provides ADC uclass's operations:
>>> - adc_init()
>>> - adc_data()
>>>
>>> This driver uses sdelay() function on pooling, so it can
>>> be used before the delay timer is inited.
>>> The basic parameters of ADC conversion, are:
>>> - sample rate: 600KSPS
>>> - output the data as average of 8 time conversion
>>>
>>> ADC features:
>>> - sample rate: 600KSPS
>>> - resolution: 12-bit
>>> - channels: 10 (analog multiplexer)
>>>
>>> Signed-off-by: Przemyslaw Marczak
>>> ---
>>> Changes V2:
>>> - new commit - move previous adc driver from SoC directory to drivers/adc
>>> ---
>>> arch/arm/mach-exynos/include/mach/adc.h | 45 ++
>>> drivers/adc/Kconfig | 9 +++
>>> drivers/adc/Makefile| 1 +
>>> drivers/adc/exynos-adc.c| 102
>>>
>>> 4 files changed, 157 insertions(+)
>>> create mode 100644 drivers/adc/exynos-adc.c
>>>
>>> diff --git a/arch/arm/mach-exynos/include/mach/adc.h
>>> b/arch/arm/mach-exynos/include/mach/adc.h
>>> index a0e26d7..228acf4 100644
>>> --- a/arch/arm/mach-exynos/include/mach/adc.h
>>> +++ b/arch/arm/mach-exynos/include/mach/adc.h
>>> @@ -9,6 +9,38 @@
>>> #ifndef __ASM_ARM_ARCH_ADC_H_
>>> #define __ASM_ARM_ARCH_ADC_H_
>>>
>>> +#define ADC_V2_CON1_SOFT_RESET (0x2 << 1)
>>> +#define ADC_V2_CON1_STC_EN (0x1)
>>
>>
>> No need for brackets on these simple ones
>>
>
> Okay, I will remove them.
>
>
>>> +
>>> +#define ADC_V2_CON2_OSEL(x)(((x) & 0x1) << 10)
>>> +#define OSEL_2S(0x0)
>>> +#define OSEL_BINARY(0x1)
>>> +#define ADC_V2_CON2_ESEL(x)(((x) & 0x1) << 9)
>>> +#define ESEL_ADC_EVAL_TIME_40CLK (0x0)
>>> +#define ESEL_ADC_EVAL_TIME_20CLK (0x1)
>>> +#define ADC_V2_CON2_HIGHF(x) (((x) & 0x1) << 8)
>>> +#define HIGHF_CONV_RATE_30KSPS (0x0)
>>> +#define HIGHF_CONV_RATE_600KSPS(0x1)
>>> +#define ADC_V2_CON2_C_TIME(x) (((x) & 0x7) << 4)
>>> +#define ADC_V2_CON2_CHAN_SEL(x)((x) & 0xf)
>>> +
>>> +#define ADC_V2_GET_STATUS_FLAG(x) (((x) >> 2) & 0x1)
>>> +#define FLAG_CONV_END (0x1)
>>> +
>>> +#define ADC_V2_INT_DISABLE (0x0)
>>> +#define ADC_V2_INT_ENABLE (0x1)
>>> +#define INT_NOT_GENERATED (0x0)
>>> +#define INT_GENERATED (0x1)
>>> +
>>> +#define ADC_V2_VERSION (0x8008)
>>> +
>>> +#define ADC_V2_MAX_CHANNEL (9)
>>> +
>>> +/* For default 8 time convertion with sample rate 600 kSPS - 15us
>>> timeout */
>>> +#define ADC_V2_CONV_TIMEOUT_US (15)
>>> +
>>> +#define ADC_V2_DAT_MASK(0xfff)
>>> +
>>> #ifndef __ASSEMBLY__
>>> struct s5p_adc {
>>> unsigned int adccon;
>>> @@ -21,6 +53,19 @@ struct s5p_adc {
>>> unsigned int adcmux;
>>> unsigned int adcclrintpndnup;
>>> };
>>> +
>>> +struct exynos_adc_v2 {
>>> + unsigned int con1;
>>> + unsigned int con2;
>>> + unsigned int status;
>>> + unsigned int dat;
>>> + unsigned int int_en;
>>> + unsigned int int_status;
>>> + unsigned int reserved[2];
>>> + unsigned int version;
>>> +};
>>> +
>>> +int exynos_adc_read_channel(int channel);
>>> #endif
>>>
>>> #endif /* __ASM_ARM_ARCH_ADC_H_ */
>>> diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
>>> index 1cb1a8d..8ee6531 100644
>>> --- a/drivers/adc/Kconfig
>>> +++ b/drivers/adc/Kconfig
>>> @@ -6,3 +6,12 @@ config ADC
>>>- device enable
>>>- conversion init
>>>- conversion start and return data with data mask
>>> +
>>> +config ADC_EXYNOS
>>> + bool "Enable Exynos 54xx ADC driver"
>>> + help
>>> + This enables basic driver for Exynos ADC compatible with
>>> Exynos54xx.
>>> + It provides:
>>> + - 10 analog input channels
>>> + - 12-bit resolution
>>> + - 600 KSPS of sample rate
>>
>>
>> Great help!
>>
>
> Thanks:)
>
>
>>> diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
>>> index c4d9618..eb85b8b 100644
>>> --- a/drivers/adc/Makefile
>>> +++ b/drivers/adc/Makefile
>>> @@ -6,3 +6,4 @@
>>> #
>>>
>>> obj-$(CONFIG_ADC) += adc-uclass.o
>>> +obj-$(CONFIG_ADC_EXYNOS) += exynos-adc.o
>>> diff --git a/drivers/adc/exynos-adc.c b/drivers/adc/exynos-adc.c
>>> new file mode 100644
>>> index 000..fdffea0
>>> --- /dev/null
>>> +++ b/drivers/adc/exynos-adc.c
>>> @@ -0,0 +1,102 @@
>>> +/*
>>> + * Copyright (C) 2015 Samsung Electronics
>>> + * Przemyslaw Marczak
>>> + *
>>> + * SPDX-License-I
Re: [U-Boot] [PATCH v2 2/3] x86: spi: Add support for Wildcat Point
On 12 October 2015 at 15:18, George McCollister wrote: > Add the Wildcat Point ID so Broadwell U based boards can use SPI. > > Signed-off-by: George McCollister > Reviewed-by: Bin Meng > --- > Changes for V2: > Add Reviewed-by: Bin Meng > > drivers/spi/ich.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] x86: pci: Add PCI IDs for Wildcat Point
On 12 October 2015 at 15:18, George McCollister wrote: > Add Wildcat Point AHCI and LPC PCI IDs which are present on Broadwell U > based (and possibly other) boards. > > Signed-off-by: George McCollister > Reviewed-by: Bin Meng > --- > Changes for V2: > Add simple sentence as the commit message > Add Reviewed-by: Bin Meng > > include/pci_ids.h | 2 ++ > 1 file changed, 2 insertions(+) Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: Fix expansion ROM programming for multi-function devices
On 8 October 2015 at 18:30, Bin Meng wrote: > Hi Simon, > > On Fri, Oct 9, 2015 at 2:10 AM, Simon Glass wrote: >> Hi Bin, >> >> On 8 October 2015 at 19:07, Simon Glass wrote: >>> On 7 October 2015 at 10:13, Bin Meng wrote: PCI_HEADER_TYPE register (offset 0x0e) bit 7 is an indicator for multi-function devices. We should mask it off before using it as the header type. Signed-off-by: Bin Meng --- drivers/pci/pci_auto.c | 1 + 1 file changed, 1 insertion(+) >>> >>> Acked-by: Simon Glass >> >> I'm not sure if this fix actually fixes anything for existing boards, >> but I'll pick it up. >> > > Yes, it fixes the Crown Bay board where Topcliff PCI device D0:F0 is a > multi-function device and has a ROM. > >> Is there anything else I have missed? >> > > So far I believe everything for this release is in. Thanks! > > Regards, > Bin Applied to u-boot-x86, and now in mainline. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] x86: baytrail: Issue full system reset in reset_cpu()
Hi Simon,
On Mon, Oct 19, 2015 at 4:27 AM, Simon Glass wrote:
> Hi Bin,
>
> On 11 October 2015 at 22:37, Bin Meng wrote:
>> With MRC cache enabled, when typing 'reset' in the U-Boot shell,
>> BayTrail FSP initialization hangs at "Configuring Memory Start":
>>
>> Setting BootMode to 0
>> Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56
>> Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
>> About to call MrcInit();
>> BayleyBay Platform Type
>> CurrentMrcData.BootMode = 4
>> Taking Fastboot path!
>> Configuring Memory Start...
>>
>> Changing reset_cpu() to do a full system reset fixes this issue.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> arch/x86/cpu/baytrail/valleyview.c | 6 ++
>> 1 file changed, 6 insertions(+)
>
> Acked-by: Simon Glass
>
>>
>> diff --git a/arch/x86/cpu/baytrail/valleyview.c
>> b/arch/x86/cpu/baytrail/valleyview.c
>> index 215e0d0..a009c14 100644
>> --- a/arch/x86/cpu/baytrail/valleyview.c
>> +++ b/arch/x86/cpu/baytrail/valleyview.c
>> @@ -65,3 +65,9 @@ int reserve_arch(void)
>> #endif
>> }
>> #endif
>> +
>> +void reset_cpu(ulong addr)
>> +{
>> + /* cold reset */
>> + x86_full_reset();
>> +}
>> --
>> 1.8.2.1
>>
>
> Actually on Minnowmax this doesn't fix the hang.
That's strange. As full reset indicates a complete power cycle. Does
MinnowMax boot with MRC cache enabled?
>
> Also I don't see any speed-up from using the cache on Minnowmax.
On Galileo, I did not see any speed-up either. I think it is because
on MinnowMax and Galileo they both uses memory-down configuration. The
speed-up seems only helpful for DIMMs (on Intel Bayley Bay)
>
> Regards,
> Simon
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/13] x86: Use struct mrc_region to describe a mrc region
Hi Simon, On Mon, Oct 19, 2015 at 4:26 AM, Simon Glass wrote: > Hi Bin, > > On 11 October 2015 at 22:37, Bin Meng wrote: >> Currently struct fmap_entry is used to describe a mrc region. >> However this structure contains some other fields that are not >> related to mrc cache and causes confusion. Besides, it does not >> include a base address field to store SPI flash's base address. >> Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to >> calculate the SPI flash base address, which unfortunately is >> not 100% correct as CONFIG_ROM_SIZE may not match the whole >> SPI flash size. > > I'm still not comfortable with CONFIG_ROM_SIZE not being the size of > the SPI flash. It just seems wrong. Maybe we should have a > u-boot.rom.min with a minimal images? > As we discussed before, we can just document this in README.x86? >> >> Define a new struct mrc_region and use it instead. >> >> Signed-off-by: Bin Meng >> --- >> >> arch/x86/cpu/ivybridge/sdram.c | 2 +- >> arch/x86/include/asm/mrccache.h | 13 + >> arch/x86/lib/mrccache.c | 27 +-- >> 3 files changed, 27 insertions(+), 15 deletions(-) > > Acked-by: Simon Glass Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] debug_uart: Adjust the declaration of debug_uart_init()
We want to be able to add other common code to this function. So change the
driver's version to have an underscore before it, just like
_debug_uart_putc(). Define debug_uart_init() to call this version.
Update all drivers to this new method.
Signed-off-by: Simon Glass
---
Changes in v2:
- Adjust all _debug_uart_init() declarations to be static inline
drivers/serial/ns16550.c| 2 +-
drivers/serial/serial_efi.c | 2 +-
drivers/serial/serial_s5p.c | 2 +-
include/debug_uart.h| 9 +++--
lib/efi/efi_stub.c | 2 +-
5 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 6275a11..6433844 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -257,7 +257,7 @@ int NS16550_tstc(NS16550_t com_port)
(1 << CONFIG_DEBUG_UART_SHIFT), \
CONFIG_DEBUG_UART_SHIFT)
-void debug_uart_init(void)
+static inline void _debug_uart_init(void)
{
struct NS16550 *com_port = (struct NS16550 *)CONFIG_DEBUG_UART_BASE;
int baud_divisor;
diff --git a/drivers/serial/serial_efi.c b/drivers/serial/serial_efi.c
index cf57d89..ea25c25 100644
--- a/drivers/serial/serial_efi.c
+++ b/drivers/serial/serial_efi.c
@@ -107,7 +107,7 @@ static int serial_efi_pending(struct udevice *dev, bool
input)
* There is nothing to init here since the EFI console is already running by
* the time we enter U-Boot.
*/
-void debug_uart_init(void)
+static inline void _debug_uart_init(void)
{
}
diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
index 3f0b588..feba467 100644
--- a/drivers/serial/serial_s5p.c
+++ b/drivers/serial/serial_s5p.c
@@ -207,7 +207,7 @@ U_BOOT_DRIVER(serial_s5p) = {
#include
-void debug_uart_init(void)
+static inline void _debug_uart_init(void)
{
struct s5p_uart *uart = (struct s5p_uart *)CONFIG_DEBUG_UART_BASE;
diff --git a/include/debug_uart.h b/include/debug_uart.h
index a75e377..257ba00 100644
--- a/include/debug_uart.h
+++ b/include/debug_uart.h
@@ -38,7 +38,7 @@
* To enable the debug UART in your serial driver:
*
* - #include
- * - Define debug_uart_init(), trying to avoid using the stack
+ * - Define _debug_uart_init(), trying to avoid using the stack
* - Define _debug_uart_putc() as static inline (avoiding stack usage)
* - Immediately afterwards, add DEBUG_UART_FUNCS to define the rest of the
* functionality (printch(), etc.)
@@ -132,6 +132,11 @@ void printhex8(uint value);
void printhex8(uint value) \
{ \
printhex(value, 8); \
- }
+ } \
+\
+ void debug_uart_init(void) \
+ { \
+ _debug_uart_init(); \
+ } \
#endif
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index d4d3e49..e138709 100644
--- a/lib/efi/efi_stub.c
+++ b/lib/efi/efi_stub.c
@@ -59,7 +59,7 @@ struct __packed desctab_info {
* considering if we start needing more U-Boot functionality. Note that we
* could then move get_codeseg32() to arch/x86/cpu/cpu.c.
*/
-void debug_uart_init(void)
+void _debug_uart_init(void)
{
}
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] debug_uart: Support board-specific UART initialisation
Some boards need to set things up before the debug UART can be used. On
these boards a call to debug_uart_init() is insufficient. When this option
is enabled, the function board_debug_uart_init() will be called when
debug_uart_init() is called. You can put any code here that is needed to
set up the UART ready for use, such as set pin multiplexing or enable
clocks.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/serial/Kconfig | 11 +++
include/debug_uart.h | 14 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index ddb725d..39f6500 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -109,6 +109,17 @@ config DEBUG_UART_SHIFT
value. Use this value to specify the shift to use, where 0=byte
registers, 2=32-bit word registers, etc.
+config DEBUG_UART_BOARD_INIT
+ bool "Enable board-specific debug UART init"
+ depends on DEBUG_UART
+ help
+ Some boards need to set things up before the debug UART can be used.
+ On these boards a call to debug_uart_init() is insufficient. When
+ this option is enabled, the function board_debug_uart_init() will
+ be called when debug_uart_init() is called. You can put any code
+ here that is needed to set up the UART ready for use, such as set
+ pin multiplexing or enable clocks.
+
config ROCKCHIP_SERIAL
bool "Rockchip on-chip UART support"
depends on ARCH_ROCKCHIP && DM_SERIAL
diff --git a/include/debug_uart.h b/include/debug_uart.h
index 257ba00..a6b7ce8 100644
--- a/include/debug_uart.h
+++ b/include/debug_uart.h
@@ -42,6 +42,11 @@
* - Define _debug_uart_putc() as static inline (avoiding stack usage)
* - Immediately afterwards, add DEBUG_UART_FUNCS to define the rest of the
* functionality (printch(), etc.)
+ *
+ * If your board needs additional init for the UART to work, enable
+ * CONFIG_DEBUG_UART_BOARD_INIT and write a function called
+ * board_debug_uart_init() to perform that init. When debug_uart_init() is
+ * called, the init will happen automatically.
*/
/**
@@ -57,6 +62,14 @@
*/
void debug_uart_init(void);
+#ifdef CONFIG_DEBUG_UART_BOARD_INIT
+void board_debug_uart_init(void);
+#else
+static inline void board_debug_uart_init(void)
+{
+}
+#endif
+
/**
* printch() - Output a character to the debug UART
*
@@ -136,6 +149,7 @@ void printhex8(uint value);
\
void debug_uart_init(void) \
{ \
+ board_debug_uart_init(); \
_debug_uart_init(); \
} \
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 26/28] input: Convert i8042 to driver model
Hi Bin,
On 18 October 2015 at 17:17, Simon Glass wrote:
> Hi Bin,
>
> On 15 September 2015 at 00:12, Bin Meng wrote:
>> Hi Simon,
>>
>> On Wed, Sep 9, 2015 at 12:32 PM, Simon Glass wrote:
>>> Adjust this driver to support driver model. The only users are x86 boards
>>> so this should be safe.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>
>> After updating QEMU to use the DM i8042 driver below:
>>
>> diff --git a/arch/x86/dts/qemu-x86_i440fx.dts
>> b/arch/x86/dts/qemu-x86_i440fx.dts
>> index fc74cd0..14782b3 100644
>> --- a/arch/x86/dts/qemu-x86_i440fx.dts
>> +++ b/arch/x86/dts/qemu-x86_i440fx.dts
>> @@ -11,6 +11,7 @@
>> /include/ "skeleton.dtsi"
>> /include/ "serial.dtsi"
>> /include/ "rtc.dtsi"
>> +/include/ "keyboard.dtsi"
>>
>> / {
>> model = "QEMU x86 (I440FX)";
>> diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h
>> index 1b544c1..9daf943 100644
>> --- a/include/configs/qemu-x86.h
>> +++ b/include/configs/qemu-x86.h
>> @@ -30,7 +30,7 @@
>>
>> #define CONFIG_PCI_PNP
>>
>> -#define CONFIG_STD_DEVICES_SETTINGS"stdin=serial,vga\0" \
>> +#define CONFIG_STD_DEVICES_SETTINGS"stdin=serial,i8042-kbd\0" \
>> "stdout=serial,vga\0" \
>> "stderr=serial,vga\0"
>>
>>
>> The i8042 still does not work. I've applied the same changes to Crown
>> Bay. i8042 does not work either. Could you please have a look?
>>
>
> It's hard for me to debug this on hardware. I should be able to use
> qemu though. Is there anything special needed to make it use that
> keyboard?
Actually it works for me with qemu.
However it is intermittent, as it was before my series. So there is
something else going on.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] debug_uart: Add an option to announce the debug UART
It is useful to see a message from the debug UART early during boot so that
you know things are working. Add an option to enable this. The message will
be displayed as soon as debug_uart_init() is called.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/serial/Kconfig | 10 ++
include/debug_uart.h | 7 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 39f6500..ac5920a 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -120,6 +120,16 @@ config DEBUG_UART_BOARD_INIT
here that is needed to set up the UART ready for use, such as set
pin multiplexing or enable clocks.
+config DEBUG_UART_ANNOUNCE
+ bool "Show a message when the debug UART starts up"
+ depends on DEBUG_UART
+ help
+ Enable this option to show a message when the debug UART is ready
+ for use. You will see a message like " " as soon as
+ U-Boot has the UART ready for use (i.e. your code calls
+ debug_uart_init()). This can be useful just as a check that
+ everything is working.
+
config ROCKCHIP_SERIAL
bool "Rockchip on-chip UART support"
depends on ARCH_ROCKCHIP && DM_SERIAL
diff --git a/include/debug_uart.h b/include/debug_uart.h
index a6b7ce8..5d5349b 100644
--- a/include/debug_uart.h
+++ b/include/debug_uart.h
@@ -105,6 +105,12 @@ void printhex4(uint value);
*/
void printhex8(uint value);
+#ifdef CONFIG_DEBUG_UART_ANNOUNCE
+#define _DEBUG_UART_ANNOUNCE printascii(" ");
+#else
+#define _DEBUG_UART_ANNOUNCE
+#endif
+
/*
* Now define some functions - this should be inserted into the serial driver
*/
@@ -151,6 +157,7 @@ void printhex8(uint value);
{ \
board_debug_uart_init(); \
_debug_uart_init(); \
+ _DEBUG_UART_ANNOUNCE \
} \
#endif
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 1/3] dm: implement a Timer uclass
Hi Thomas, On 13 October 2015 at 07:17, Thomas Chou wrote: > > > On 10/10/2015 03:16 PM, Thomas Chou wrote: >> >> Implement a Timer uclass to work with lib/time.c. >> >> Signed-off-by: Thomas Chou >> Acked-by: Simon Glass >> --- >> v2 >>fix coding style. >> v3 >>add description to Kconfig as Simon suggested. >>move timer.c code to lib/time.c. >>add dm_timer dev to global data. >>remove timer_init(). >>change API name get_clock. >> v4 >>add comment about timer hardware. >> v5 >>revert to get_rate and use uclass priv to store the clock_rate. >>split gd->dm_timer renewal to anohter patch. >> v6 >>rename to CONFIG_TIMER as Simon suggested. >> v7 >>fix string replacement error in v6 >> v8 >>replace all dm_timer with timer. >> >> drivers/Kconfig | 2 ++ >> drivers/Makefile | 1 + >> drivers/timer/Kconfig | 12 + >> drivers/timer/Makefile| 7 ++ >> drivers/timer/timer-uclass.c | 42 +++ >> include/asm-generic/global_data.h | 3 +++ >> include/dm/uclass-id.h| 1 + >> include/timer.h | 52 >> +++ >> lib/time.c| 49 >> >> 9 files changed, 169 insertions(+) >> create mode 100644 drivers/timer/Kconfig >> create mode 100644 drivers/timer/Makefile >> create mode 100644 drivers/timer/timer-uclass.c >> create mode 100644 include/timer.h >> > > Applied to u-boot-nios. > Please do create a test for this uclass using a fake sandbox timer. Note also time_ut.c which might have some ideas. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] x86: Init the debug UART if enabled
If the debug UART is enabled, get it ready for use at the earliest possible opportunity. This is not actually very early, but until we have a stack it is difficult to make it work. Signed-off-by: Simon Glass --- Changes in v2: - Remove comment block since we now always enable the debug UART - Use a tab after the 'call' instruction arch/x86/cpu/start.S | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index d072825..5b4ee79 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -126,14 +126,9 @@ car_init_ret: callboard_init_f_mem mov %eax, %esp - /* -* Debug UART is available here although it may not be plumbed out -* to pins depending on the board. To use it: -* -* call debug_uart_init -* mov $'a', %eax -* call printch -*/ +#ifdef CONFIG_DEBUG_UART + calldebug_uart_init +#endif /* Get address of global_data */ mov %fs:0, %edx -- 2.6.0.rc2.230.g3dd15c0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] x86: chromebook_link: Enable the debug UART
Add support for the debug UART on link. This is useful for early debugging.
Signed-off-by: Simon Glass
---
Changes in v2: None
arch/x86/cpu/ivybridge/cpu.c | 7 +++
configs/chromebook_link_defconfig | 4
2 files changed, 11 insertions(+)
diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
index cce5923..0e6512c 100644
--- a/arch/x86/cpu/ivybridge/cpu.c
+++ b/arch/x86/cpu/ivybridge/cpu.c
@@ -340,3 +340,10 @@ int print_cpuinfo(void)
return 0;
}
+
+void board_debug_uart_init(void)
+{
+ /* This enables the debug UART */
+ pci_x86_write_config(NULL, PCH_LPC_DEV, LPC_EN, COMA_LPC_EN,
+PCI_SIZE_16);
+}
diff --git a/configs/chromebook_link_defconfig
b/configs/chromebook_link_defconfig
index fbecf8b..78a9470 100644
--- a/configs/chromebook_link_defconfig
+++ b/configs/chromebook_link_defconfig
@@ -22,6 +22,10 @@ CONFIG_CROS_EC_LPC=y
CONFIG_SPI_FLASH=y
CONFIG_DM_PCI=y
CONFIG_DM_RTC=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_BASE=0x3f8
+CONFIG_DEBUG_UART_CLOCK=1843200
+CONFIG_DEBUG_UART_BOARD_INIT=y
CONFIG_DM_TPM=y
CONFIG_TPM_TIS_LPC=y
CONFIG_VIDEO_VESA=y
--
2.6.0.rc2.230.g3dd15c0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] x86: Early debug enhancements
This series adds a few more features to the debug UART, making it possible to use it even when the board needs to perform additional init for the UART to work. The debug UART is anabled on link. Some minor PCI tidy-ups are also included. Link currently does not boot due to lack of early malloc() memory. For now just increase the size. Changes in v2: - Adjust all _debug_uart_init() declarations to be static inline - Remove comment block since we now always enable the debug UART - Use a tab after the 'call' instruction Simon Glass (5): debug_uart: Adjust the declaration of debug_uart_init() debug_uart: Support board-specific UART initialisation debug_uart: Add an option to announce the debug UART x86: Init the debug UART if enabled x86: chromebook_link: Enable the debug UART arch/x86/cpu/ivybridge/cpu.c | 7 +++ arch/x86/cpu/start.S | 11 +++ configs/chromebook_link_defconfig | 4 drivers/serial/Kconfig| 21 + drivers/serial/ns16550.c | 2 +- drivers/serial/serial_efi.c | 2 +- drivers/serial/serial_s5p.c | 2 +- include/debug_uart.h | 30 -- lib/efi/efi_stub.c| 2 +- 9 files changed, 67 insertions(+), 14 deletions(-) -- 2.6.0.rc2.230.g3dd15c0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: dfu_sf: Use the erase sector size for erase operations
Hi Lukasz, On Tue, Sep 22, 2015 at 4:46 AM, Lukasz Majewski wrote: > Hi Fabio, > >> From: Fabio Estevam >> >> SPI NOR flashes need to erase the entire sector size and we cannot >> pass any arbitrary length for the erase operation. >> >> To illustrate the problem: >> >> Copying data from PC to DFU device >> Download[=] 100% 478208 bytes >> Download done. >> state(7) = dfuMANIFEST, status(0) = No error condition is present >> state(10) = dfuERROR, status(14) = Something went wrong, but the >> device does not know what it was >> Done! >> >> In this case, the binary has 478208 bytes and the M25P32 SPI NOR >> has an erase sector of 64kB. >> >> 478208 = 7 entire sectors of 64kiB + 19456 bytes. >> >> Erasing the first seven 64 kB sectors works fine, but when trying >> to erase the remainding 19456 causes problem and the board hangs. >> >> Fix the issue by always erasing with the erase sector size. >> >> Signed-off-by: Fabio Estevam > Acked-by: Lukasz Majewski > > Applied to u-boot-dfu tree. > > Thanks for your work. > > I'm looking forward for more patches :-) Any chance of getting this one applied for 2015.10? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
