Re: [U-Boot] [PATCH 1/4 v4] spi: Add Cadence QSPI DM driver used by SoCFPGA
On 06.12.2014 13:56, Marek Vasut wrote: On Saturday, November 08, 2014 at 01:18:31 PM, Stefan Roese wrote: On 07.11.2014 20:56, Dinh Nguyen wrote: +CC: Graham Moore On 11/07/2014 09:26 AM, Stefan Roese wrote: Hi Dinh, Hi Vince! snip Could we not just use a plain GPL (v2) license here as well. Especially since the other files in this driver are just normal GPL files. Comments welcome. Graham recent posted to lkml a patch series for QSPI that has a plain GPLv2. http://marc.info/?l=linux-kernelm=141417788514196w=2 Interesting. Thanks for this info. But what is the implication of this new plain GPLv2'ed driver code to the current code in this patch (based on your Rocketboard.org version)? Frankly, I really don't have time and motivation to re-port this new Linux version to U-Boot to get the GPLv2 version. How could we solve this? Can you re-release this code under this new license (header)? Hi, I have this one still marked as Open Issue, any news here ? Not from my side I'm afraid. Perhaps somebody from Altera (Dinh, Graham?) could chime in and let us know, if it would be possible to license the current QSPI file under GPL? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Add DT support for SoCFPGA
Hi Marek, On 06.12.2014 13:58, Marek Vasut wrote: On Thursday, October 30, 2014 at 09:19:56 AM, Stefan Roese wrote: This patch includes the latest DT sources for socfpga from the current Linux kernel. And enables CONFIG_OF_CONTROL for socfpga_cyclone5 to make use of this new DT support. Note that now the image to use is u-boot-dtb.img! Signed-off-by: Stefan Roese s...@denx.de Cc: Marek Vasut ma...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Vince Bridgers vbrid...@altera.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Pavel Machek pa...@denx.de Hi Stefan, any chance you can update this against current u-boot-socfpga/master please ? I think this should be 5 minute job at best. Will do. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Add DT support for SoCFPGA
Marek, On 08.12.2014 09:15, Stefan Roese wrote: On 06.12.2014 13:58, Marek Vasut wrote: On Thursday, October 30, 2014 at 09:19:56 AM, Stefan Roese wrote: This patch includes the latest DT sources for socfpga from the current Linux kernel. And enables CONFIG_OF_CONTROL for socfpga_cyclone5 to make use of this new DT support. Note that now the image to use is u-boot-dtb.img! Signed-off-by: Stefan Roese s...@denx.de Cc: Marek Vasut ma...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Vince Bridgers vbrid...@altera.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Pavel Machek pa...@denx.de Hi Stefan, any chance you can update this against current u-boot-socfpga/master please ? I think this should be 5 minute job at best. Will do. Its already in mainline. This patch has superseeded the one you refer by this mail: 51c580c6c92c01884f520f4ffaeb6885ee8e666e arm: socfpga: Add DT support for SoCFPGA and add socfpga_socrates target Let me know if something is still missing or unclear. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sun6i: Update Colombus defconfig settings
On Sun, 2014-12-07 at 21:23 +0100, Hans de Goede wrote: The Colombus defconfig settings are missing a number of settings for recently added features, because we did not know exactly how things were hooked up. Maxime Ripard has run various tests to get us the necessary details, this commit updates the defconfig with this info. This commit also updates the dram clk and zq values with values verified by Maxime to be the ones used by the original firmware for this board. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: mmc: Properly setup mod-clk and clock sampling phases
On Sun, 2014-12-07 at 21:23 +0100, Hans de Goede wrote: The sunxi mmc controller has both an internal clock divider, as well as the divider in the mod0-clk for the mmc controller. The internal divider cannot be used, as it conflicts with the setting of clock sampling phases which is done in the mod0-clk, so it must be set to 0 (divide by 1). For some reason while the kernel has had this correct from day one, the u-boot sunxi mmc code has been using a fixed mod0-clk and setting its internal divider depending on the desired speed. This is something which we've inherited from the original Allwinner u-boot sources, but while this has been fixed in Allwinner's own u-boot code at least for the A23 and later upstream u-boot was still doing this wrong. This commit fixes this, thereby also fixing mmc support not working reliable on the A23 (which seems more sensitive to this) and possible also fixes some other sunxi mmc issues. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sun6i: Update Colombus defconfig settings
On Mon, 2014-12-08 at 09:26 +, Ian Campbell wrote: On Sun, 2014-12-07 at 21:23 +0100, Hans de Goede wrote: The Colombus defconfig settings are missing a number of settings for recently added features, because we did not know exactly how things were hooked up. Maxime Ripard has run various tests to get us the necessary details, this commit updates the defconfig with this info. This commit also updates the dram clk and zq values with values verified by Maxime to be the ones used by the original firmware for this board. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell ian.campb...@citrix.com Ooops, rather make that i...@hellion.org.uk, as usual... Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sun6i: Update Colombus defconfig settings
Hi, On 08-12-14 10:31, Ian Campbell wrote: On Mon, 2014-12-08 at 09:26 +, Ian Campbell wrote: On Sun, 2014-12-07 at 21:23 +0100, Hans de Goede wrote: The Colombus defconfig settings are missing a number of settings for recently added features, because we did not know exactly how things were hooked up. Maxime Ripard has run various tests to get us the necessary details, this commit updates the defconfig with this info. This commit also updates the dram clk and zq values with values verified by Maxime to be the ones used by the original firmware for this board. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell ian.campb...@citrix.com Ooops, rather make that i...@hellion.org.uk, as usual... Thanks for the reviews, I've queued both of these up in u-boot-sunxi/next (also rebased on latest origin/master, so I've done a forced push). I would also like to queue these 2 up, if you've some time can you please review them ? : http://patchwork.ozlabs.org/patch/415109/ http://patchwork.ozlabs.org/patch/415110/ Thanks Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sun6i: Update Colombus defconfig settings
On Mon, 2014-12-08 at 11:59 +0100, Hans de Goede wrote: Hi, On 08-12-14 10:31, Ian Campbell wrote: On Mon, 2014-12-08 at 09:26 +, Ian Campbell wrote: On Sun, 2014-12-07 at 21:23 +0100, Hans de Goede wrote: The Colombus defconfig settings are missing a number of settings for recently added features, because we did not know exactly how things were hooked up. Maxime Ripard has run various tests to get us the necessary details, this commit updates the defconfig with this info. This commit also updates the dram clk and zq values with values verified by Maxime to be the ones used by the original firmware for this board. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell ian.campb...@citrix.com Ooops, rather make that i...@hellion.org.uk, as usual... Thanks for the reviews, I've queued both of these up in u-boot-sunxi/next (also rebased on latest origin/master, so I've done a forced push). I would also like to queue these 2 up, if you've some time can you please review them ? : http://patchwork.ozlabs.org/patch/415109/ http://patchwork.ozlabs.org/patch/415110/ Ack to both of those too. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] fastboot: handle flash write to GPT partition
Hi Steve,
Implement a feature to allow fastboot to write the downloaded image
to the space reserved for the Protective MBR and the Primary GUID
Partition Table.
Signed-off-by: Steve Rae s...@broadcom.com
---
README | 7 +++
common/fb_mmc.c | 19 ---
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 66770b6..3b6ef7f 100644
--- a/README
+++ b/README
@@ -1769,6 +1769,13 @@ The following options need to be configured:
regarding the non-volatile storage device. Define
this to the eMMC device that fastboot should use to store the image.
+ CONFIG_FASTBOOT_GPT_NAME
+ The fastboot flash command supports writing the
downloaded
+ image to the Protective MBR and the Primary GUID
Partition
+ Table. This occurs when the specified partition
name on the
+ fastboot flash command line matches this value.
+ Default is GPT_ENTRY_NAME (currently gpt) if
undefined. +
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index fb06d8a..89fbf23 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -4,12 +4,17 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include config.h
#include common.h
#include fb_mmc.h
#include part.h
#include aboot.h
#include sparse_format.h
+#ifndef CONFIG_FASTBOOT_GPT_NAME
+#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
+#endif
+
/* The 64 defined bytes plus the '\0' */
#define RESPONSE_LEN (64 + 1)
@@ -62,9 +67,9 @@ static void write_raw_image(block_dev_desc_t
*dev_desc, disk_partition_t *info, void fb_mmc_flash_write(const char
*cmd, void *download_buffer, unsigned int download_bytes, char
*response) {
- int ret;
block_dev_desc_t *dev_desc;
disk_partition_t info;
+ lbaint_t blksz;
/* initialize the response buffer */
response_str = response;
@@ -76,8 +81,16 @@ void fb_mmc_flash_write(const char *cmd, void
*download_buffer, return;
}
- ret = get_partition_info_efi_by_name(dev_desc, cmd, info);
- if (ret) {
+ if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
+ printf(%s: updating GUID Partition Table (including
MBR)\n,
+__func__);
+ /* start at Protective MBR */
+ info.start = (GPT_PRIMARY_PARTITION_TABLE_LBA - 1);
+ blksz = dev_desc-blksz;
+ info.blksz = blksz;
+ /* assume that the Partition Entry Array starts in
LBA 2 */
+ info.size = (2 + (GPT_ENTRY_NUMBERS *
GPT_ENTRY_SIZE) / blksz);
+ } else if (get_partition_info_efi_by_name(dev_desc, cmd,
info)) { error(cannot find partition: '%s'\n, cmd);
fastboot_fail(cannot find partition);
return;
Sorry for a late reply. I've just come back from a short holidays.
I'm curious if you have encountered any problems with GPT replaced in
that way?
It seems strange to me that you only change primary GPT partition
without taking care of the secondary (backup) one.
From my experience when you export your eMMC to Host PC via UMS, host's
PC tools will complain about mismatch in the GPT tables.
Moreover, I would suggest transactional update of GPT by checking GPT
image CRC before writing. In this way you can always perform recovery if
needed.
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] fastboot: handle flash write to GPT partition
Hi Marek, On Thursday, December 04, 2014 at 11:36:33 PM, Steve Rae wrote: Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Signed-off-by: Steve Rae s...@broadcom.com Lukasz, what do you think please ? I've just commented to this e-mail. In my option, there's nothing really explicitly problematic: Reviewed-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut BTW: Marek, do you plan to send USB PR to Tom in a near future? -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning
Hi Albert, Hello Lukasz, Thank you and Guillaume for the indications. So gcc 4.7.2 and 4.8.1 should exhibit the problem. Apparently, 4.7.4 and 4.8.3 don't. :( /me goes and fetches a 4.8.1 somewhere. Amicalement, Is there any progress with preparing fix for this warning? -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] kirkwood: ib62x0: add CONFIG_SYS_GENERIC_BOARD define
Hi Prafulla, any luck with getting this patches in your or master tree? Luka On Mon, Dec 01, 2014 at 12:34:50AM -0800, Prafulla Wadaskar wrote: -Original Message- From: Luka Perkov [mailto:l...@openwrt.org] Sent: 30 November 2014 09:31 To: u-boot@lists.denx.de Cc: Luka Perkov; Prafulla Wadaskar; Stefan Roese Subject: [PATCH 1/6] kirkwood: ib62x0: add CONFIG_SYS_GENERIC_BOARD define Signed-off-by: Luka Perkov l...@openwrt.org CC: Prafulla Wadaskar prafu...@marvell.com CC: Stefan Roese s...@denx.de --- I will pull this patch series in this week. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A23 u-boot with SPL / dram init available in my personal git repo
On Sunday, December 7, 2014 9:27:37 PM UTC+1, Hans de Goede wrote: Hi, This is still a bit rough around the edges, I'll clean it up as time permits and then post it upstream. Hip, Hip Hooray. Thank you. How did you pull it off? Did you find documentation somewhere? Or by piecing things together? In the mean time people interested can find $subject here: https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-wip ChenYu, this also has a mmc fix which you may find interesting, it may explain some of the problems with mmc you've been having on both the A80 board, as well as the A31 dev board you've. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Implementing the uBoot SYSCALL interface for MIPS
Hi all, I've been recently working on and promoting a common bare-metal semi-hosting interface for the MIPS architecture. The main goal of this is to allow a bare-metal MIPS application to run on the maximum number of simulation and hardware platforms without (much/any) modification. The interface uses the MIPS SYSCALL interface and a custom ABI to request operations from an OS or monitor. As far as I can see uBoot's new(ish) API as not yet been mapped onto the MIPS architecture. I would like to find out if it will be acceptable to access some map some of the operations from the semi-hosting interface onto the uBoot API. In particular I'd like to get: open, read, write, close, fstat implemented such that FD 0/1 behave as if attached to a serial port. Open/close and fstat wouldn't do anything special as they would just say that FD 0/1 exist. Read and write would map to getc and putc for FD 0 and FD 1 respectively. The interface is being implemented directly in qemu, and as part of libgloss on the consumer side (not upstream yet). I will be promoting its use in any other open source simulators and hosting libraries too as I find them. I'm also boldly trying to abstract away from any ABI issues (O32/N32/N64) to potentially allow the consumer and producer side of the interface to have different ABIs to some extent. I am also trying to create a well-defined entry-point interface to reduce the variance in how arguments are passed from bootloader to application, at least one person has shown interest in this from the kernel list. If it sounds like it will be acceptable then I'll send more details of the interface as a follow up but I would really like to include uBoot in the list of supported environments. There is of course scope to add any number of extra operations to the interface to cover more of the uBoot API but I generally agree with the principle that exploiting too much of uBoot is bad form if an application is non-GPL. Thanks, Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
While switching a custom i.MX6DL board port to the common mx6 infrastructure without any board specific DCD file (*.cfg), booting from SD-card (mmc0) via the bmode command (bmode mmc0) did not work any more. Adding this one line for the CCGR0 solves this issue. I have to admit that I'm not really sure why this is needed in this case. So if somebody has an explanation for the need for this CCGR0 register setup in the DCD, then please let me know. Signed-off-by: Stefan Roese s...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de --- arch/arm/imx-common/spl_sd.cfg | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/imx-common/spl_sd.cfg b/arch/arm/imx-common/spl_sd.cfg index 5fc3e8a..8239def 100644 --- a/arch/arm/imx-common/spl_sd.cfg +++ b/arch/arm/imx-common/spl_sd.cfg @@ -6,3 +6,12 @@ IMAGE_VERSION 2 BOOT_FROM sd + +#define __ASSEMBLY__ +#include config.h +#include asm/arch/mx6-ddr.h +#include asm/arch/iomux.h +#include asm/arch/crm_regs.h + +/* Set the default clock gate to save power */ +DATA 4, CCM_CCGR0, 0x00C03F3F -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB Host not enumerating properly on AM335x-based board
Hi Anatolij, On Sat, Nov 22, 2014 at 12:40:58AM +0100, Anatolij Gustschin wrote: The same USB port with the same device works fine under Linux. The VBUS pin is still up after running the command, so it's not really a matter of power being shut down on the bus. I'm kind of running out of idea on what to test next. The differences between u-boot's musb-new and Linux' own musb driver seems thin and to make sense, so I don't think the driver itself is to blame. Anyone experienced such a thing? We experienced similar thing this week, but on an imx6dl based board. Quite a lot of debugging and comparison with USB host operation under Linux didn't really help much. Finally we found the issue with the timer implementation, udelay(1) took too much time, about 35 usec. Whereas one would expect it to take about 1 usec, ideally. EHCI-HCD, USB-Hub and Storage drivers in U-Boot use udelay()/mdelay() quite extensively. Reworking the timer implementation for our platform resulted in udelay(1) times taking about 2.5 usec. This was enough for USB driver code to work again. I just gave it a try. mdelay(1000) and udelay (1000 * 1000) are both taking around 1s (1.0002... for udelay, 1.13... for mdelay). udelay(1) on the other hand takes around 151us, which seems to be the same overhead we saw for udelay(1000 * 1000). While that looks really high with regard to what you were saying, but I just tested it with a beaglebone black that have similar delay values, and yet the usb storage works as expected. So I don't think it's really the issue there :/ Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
Hi Stefan, On Mon, Dec 8, 2014 at 11:31 AM, Stefan Roese s...@denx.de wrote: While switching a custom i.MX6DL board port to the common mx6 infrastructure without any board specific DCD file (*.cfg), booting from SD-card (mmc0) via the bmode command (bmode mmc0) did not work any more. Adding this one line for the CCGR0 solves this issue. I have to admit that I'm not really sure why this is needed in this case. So if somebody has an explanation for the need for this CCGR0 register setup in the DCD, then please let me know. Could you please try to narrow down what exact field of the CGR0 register makes your board boot? I suspect it could be the AIPS related clocks (CG0 / CG1). Please confirm. If this is the case, then we should turn on the AIPS clocks inside init_aips(). Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A23 u-boot with SPL / dram init available in my personal git repo
On Mon, Dec 8, 2014 at 4:27 AM, Hans de Goede hdego...@redhat.com wrote: Hi, This is still a bit rough around the edges, I'll clean it up as time permits and then post it upstream. In the mean time people interested can find $subject here: https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-wip Hopefully I'll get around to testing this. BTW, what tablet do you have? ChenYu, this also has a mmc fix which you may find interesting, it may explain some of the problems with mmc you've been having on both the A80 board, as well as the A31 dev board you've. Yes. With that fix my Hummingbird A31 boots properly without raising DCDC1 to 3.3V. Thanks! I'll send the defconfig out later. ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
Hi Fabio, On 08.12.2014 15:15, Fabio Estevam wrote: On Mon, Dec 8, 2014 at 11:31 AM, Stefan Roese s...@denx.de wrote: While switching a custom i.MX6DL board port to the common mx6 infrastructure without any board specific DCD file (*.cfg), booting from SD-card (mmc0) via the bmode command (bmode mmc0) did not work any more. Adding this one line for the CCGR0 solves this issue. I have to admit that I'm not really sure why this is needed in this case. So if somebody has an explanation for the need for this CCGR0 register setup in the DCD, then please let me know. Could you please try to narrow down what exact field of the CGR0 register makes your board boot? I suspect it could be the AIPS related clocks (CG0 / CG1). I tested with these values: 0x00C03F30 0x00C03F33 0x00C03F3C All do not boot. Only the original one does: 0x00C03F3F So yes, AIPS related clocks are definitely needed! I'm wondering about this, since the default value after reset should be 0x for this register, right? All clocks enabled. But this does not seem to be the case. As SPL is not started correctly (no output at all on the console) when I don't add this line to spl_sd.cfg. Its not easy for me to debug this issue since the board usually boots from NAND. I can't strap this board to boot via MMC0 right now. So I have to use the bmode mmc0 command. And JTAG debugging via BDI3000 doesn't seem to survive the bmode command. Please confirm. If this is the case, then we should turn on the AIPS clocks inside init_aips(). See above. Could you test this on one of your board? If your board also fails to boot via the bmode mmc0 command if the CCGR0 register value is missing? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
Hi Stefan, On Mon, Dec 8, 2014 at 12:32 PM, Stefan Roese s...@denx.de wrote: Could you test this on one of your board? If your board also fails to boot via the bmode mmc0 command if the CCGR0 register value is missing? I am currently out of the office without access to my mx6 board, but looking in board/freescale/mx6sabresd/mx6sabresd.c we have: writel(0x00C03F3F, ccm-CCGR0); ,which turns on the AIPS clocks. Can't you just turn on the AIPS clocks inside in your board file like we do on sabresd? I am not sure where the AIPS clocks are being turned off in your case though. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] exynos5250/arndale: Enable SATA/AHCI support.
This is based on some old patches from the chromeos-v2011.12 branch of
http://git.chromium.org/chromiumos/third_party/u-boot.git by Taylor Hutt.
Specifically:
http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit;h=26f6c570b5deb37c52306920ae049203c68f014a
exynos: sata: on-board controller initialization
Signed-off-by: Taylor Hutt th...@chromium.org
http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit;h=d8cac5cf0b63df00d2d6ac7df814613e4b60b9d1
exynos: sata: Add sata_initialize() interface
Signed-off-by: Taylor Hutt th...@chromium.org
http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit;h=dd32462453d6328bc5770859d1b56501f7920d7d
exynos: sata: SATA self-configuration for when SATA device is enabled
Signed-off-by: Taylor Hutt th...@chromium.org
As well as rebasing there have been some significant changes.
- Drop support for smdk5250, which I don't own.
- Implement support for arndale, which I do.
- Since arndale has no need to frob a GPIO on SATA init drop the associated
code.
- Initialise via the existing scsi_init hook rather than introducing
sata_initialize, associated build system and include/configs/*.h changes.
- Use set/clrbits in a bunch of places
- Add some #defines for some magic numbers.
- Use samsung_get_base_* for peripheral base addresses and structs to
access individual registers
- Lots of coding style improvements (checkpatch.pl clean) and general cleanup
Before launching the OS reset the PHY, otherwise Linux cannot reliably
detect the disk.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Taylor Hutt th...@chromium.org
Cc: Simon Glass s...@chromium.org
---
Lots of changes in v2:
- Rebase to latest master branch.
- use samsung_get_base_* for sata phy
- use samsung_get_base_* for sata i2c
- use samsung_get_base_* for sata axi
- Lots of Coding Style improvements
- Drop unused mmio argument to phy init
- Move code controlling phy power to power.c
- Remove unused SCLK_SATA_FREQ
- Use #defines for SATA_GENERATIONN, less fickle than enum
- avoid non-existent BIT macro
- Use bool more consistently in a few places
- No uppercase variable names
- Use SPDX License + copyright
- Use arch_preboot_os to reset SATA controller, and do so more
thoroughly than in the previous HACK. It now appears to be reliable
in my testing.
---
arch/arm/cpu/armv7/exynos/Makefile | 4 +
arch/arm/cpu/armv7/exynos/power.c| 23 ++
arch/arm/cpu/armv7/exynos/sata.c | 412 +++
arch/arm/cpu/armv7/exynos/soc.c | 8 +
arch/arm/include/asm/arch-exynos/cpu.h | 15 ++
arch/arm/include/asm/arch-exynos/power.h | 4 +
arch/arm/include/asm/arch-exynos/sata.h | 13 +
arch/arm/lib/board.c | 1 +
board/samsung/arndale/arndale.c | 9 +
include/configs/arndale.h| 3 +
include/configs/exynos5-common.h | 18 ++
11 files changed, 510 insertions(+)
create mode 100644 arch/arm/cpu/armv7/exynos/sata.c
create mode 100644 arch/arm/include/asm/arch-exynos/sata.h
diff --git a/arch/arm/cpu/armv7/exynos/Makefile
b/arch/arm/cpu/armv7/exynos/Makefile
index e207bd6..c74a2d4 100644
--- a/arch/arm/cpu/armv7/exynos/Makefile
+++ b/arch/arm/cpu/armv7/exynos/Makefile
@@ -7,6 +7,10 @@
obj-y += clock.o power.o soc.o system.o pinmux.o tzpc.o
+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_EXYNOS5250_AHCI) += sata.o
+endif
+
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_EXYNOS5) += clock_init_exynos5.o
obj-$(CONFIG_EXYNOS5) += dmc_common.o dmc_init_ddr3.o
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 1520d64..8f36d10 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -37,6 +37,29 @@ void set_mipi_phy_ctrl(unsigned int dev_index, unsigned int
enable)
exynos4_mipi_phy_control(dev_index, enable);
}
+void exynos5_set_sata_phy_ctrl(unsigned int enable)
+{
+ struct exynos5_power *power =
+ (struct exynos5_power *)samsung_get_base_power();
+
+ if (enable) {
+ /* Enabling SATA_PHY */
+ setbits_le32(power-sata_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ } else {
+ /* Disabling SATA_PHY */
+ clrbits_le32(power-sata_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ }
+}
+
+void set_sata_phy_ctrl(unsigned int enable)
+{
+ if (cpu_is_exynos5())
+ exynos5_set_sata_phy_ctrl(enable);
+}
+
+
void exynos5_set_usbhost_phy_ctrl(unsigned int enable)
{
struct exynos5_power *power =
diff --git a/arch/arm/cpu/armv7/exynos/sata.c b/arch/arm/cpu/armv7/exynos/sata.c
new file mode 100644
index 000..4e994d6
--- /dev/null
+++ b/arch/arm/cpu/armv7/exynos/sata.c
@@ -0,0 +1,412 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors.
+ * Copyright (c) 2014 Ian Campbell
+ *
+
[U-Boot] [PATCH V3 00/12] cleanup and refactor lcd.c
This series is a first step towards an end goal of merging all CONFIG_LCD related functionality into CONFIG_VIDEO code. My plan is to start by refactoring lcd.c into something cleaner (less ifdefs) and more modular (split code into multiple files), then possibly refactor CONFIG_VIDEO code if needed, and then finally: move CONFIG_LCD related functionality over to CONFIG_VIDEO code, replacing as much CONFIG_LCD related code with CONFIG_VIDEO related code as possible. This specific step eliminates some unused code and refactors lcd console stuff into its own file. The patches (lcd: rename console_(row|col) to lcd: make lcd_drawchars() independant of lcd_base) are preparatory patches meant to illustrate exactly what changed and where in the transition from lcd.c to lcd_console.c, and are not necesserily code improvements when viewed out of context. Changes in V3: - Function documentation - Cache values of lcd_get(bg|fg)color() instead of calling the functions multiple times. The whole series was rebased over current mainline, and compile tested for arm and powerpc. Cc: Anatolij Gustschin ag...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Simon Glass s...@chromium.org Cc: Stephen Warren swar...@wwwdotorg.org Entire series: Tested-by: Stephen Warren swar...@wwwdotorg.org Tested-by: Simon Glass s...@chromium.org Nikita Kiryanov (12): lcd: remove CONFIG_SYS_INVERT_COLORS lcd: cleanup lcd_drawchars mpc8xx_lcd: get rid of CONFIG_EDT32F10 lcd: remove LCD_MONOCHROME lcd: rename console_(row|col) lcd: replace CONSOLE_(ROWS|COLS) with variables lcd: expand console api lcd: get rid of COLOR_MASK lcd: introduce getters for bg/fg color lcd: make lcd_drawchars() independant of lcd_base lcd: refactor lcd console stuff into its own file lcd_console: remove unused defines common/Makefile| 2 +- common/lcd.c | 313 + common/lcd_console.c | 211 ++ drivers/video/mpc8xx_lcd.c | 49 +-- drivers/video/pxa_lcd.c| 15 --- include/configs/R360MPI.h | 1 - include/lcd.h | 25 ++-- include/lcd_console.h | 86 + 8 files changed, 347 insertions(+), 355 deletions(-) create mode 100644 common/lcd_console.c create mode 100644 include/lcd_console.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 01/12] lcd: remove CONFIG_SYS_INVERT_COLORS
No one is using CONFIG_SYS_INVERT_COLORS; remove related code. Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Cc: Simon Glass s...@chromium.org Cc: Anatolij Gustschin ag...@denx.de Acked-by: Simon Glass s...@chromium.org --- Changes in V3: - No changes. Changes in V2: - No changes. common/lcd.c | 8 drivers/video/mpc8xx_lcd.c | 4 +--- 2 files changed, 1 insertion(+), 11 deletions(-) diff --git a/common/lcd.c b/common/lcd.c index 28b3fe7..c7d597e 100644 --- a/common/lcd.c +++ b/common/lcd.c @@ -685,11 +685,7 @@ void bitmap_plot(int x, int y) *(cmap + BMP_LOGO_OFFSET) = lut_entry; cmap++; #else /* !CONFIG_ATMEL_LCD */ -#ifdef CONFIG_SYS_INVERT_COLORS - *cmap++ = 0x - colreg; -#else *cmap++ = colreg; -#endif #endif /* CONFIG_ATMEL_LCD */ } @@ -967,11 +963,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y) ( ((cte.red)8) 0xf800) | ( ((cte.green) 3) 0x07e0) | ( ((cte.blue) 3) 0x001f) ; -#ifdef CONFIG_SYS_INVERT_COLORS - *cmap = 0x - colreg; -#else *cmap = colreg; -#endif #if defined(CONFIG_MPC823) cmap--; #else diff --git a/drivers/video/mpc8xx_lcd.c b/drivers/video/mpc8xx_lcd.c index 2bc3ceb..98b9f5e 100644 --- a/drivers/video/mpc8xx_lcd.c +++ b/drivers/video/mpc8xx_lcd.c @@ -373,9 +373,7 @@ lcd_setcolreg (ushort regno, ushort red, ushort green, ushort blue) colreg = ((red0x0F) 8) | ((green 0x0F) 4) | (blue 0x0F) ; -#ifdef CONFIG_SYS_INVERT_COLORS - colreg ^= 0x0FFF; -#endif + *cmap_ptr = colreg; debug (setcolreg: reg %2d @ %p: R=%02X G=%02X B=%02X = %02X%02X\n, -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 04/12] lcd: remove LCD_MONOCHROME
No one is using LCD_MONOCHROME; remove related code.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Wolfgang Denk w...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Acked-by: Simon Glass s...@chromium.org
---
Changes in V3:
- No changes.
Changes in V2:
- No changes.
common/lcd.c | 30 ++
drivers/video/mpc8xx_lcd.c | 17 -
drivers/video/pxa_lcd.c| 15 ---
include/lcd.h | 10 +-
4 files changed, 3 insertions(+), 69 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 22bb488..ed451a9 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -97,10 +97,7 @@
#define CONSOLE_SIZE (CONSOLE_ROW_SIZE * CONSOLE_ROWS)
#define CONSOLE_SCROLL_SIZE(CONSOLE_SIZE - CONSOLE_ROW_SIZE)
-#if LCD_BPP == LCD_MONOCHROME
-# define COLOR_MASK(c) ((c) | (c) 1 | (c) 2 | (c) 3 | \
-(c) 4 | (c) 5 | (c) 6 | (c) 7)
-#elif (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16) || \
+#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16) || \
(LCD_BPP == LCD_COLOR32)
# define COLOR_MASK(c) (c)
#else
@@ -313,10 +310,6 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str,
int count)
y += BMP_LOGO_HEIGHT;
#endif
-#if LCD_BPP == LCD_MONOCHROME
- ushort off = x * (1 LCD_BPP) % 8;
-#endif
-
dest = (uchar *)(lcd_base + y * lcd_line_length + x * NBITS(LCD_BPP)/8);
for (row = 0; row VIDEO_FONT_HEIGHT; ++row, dest += lcd_line_length) {
@@ -330,33 +323,18 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str,
int count)
uchar *d = dest;
#endif
-#if LCD_BPP == LCD_MONOCHROME
- uchar rest = *d -(1 (8 - off));
- uchar sym;
-#endif
for (i = 0; i count; ++i) {
uchar c, bits;
c = *s++;
bits = video_fontdata[c * VIDEO_FONT_HEIGHT + row];
-#if LCD_BPP == LCD_MONOCHROME
- sym = (COLOR_MASK(lcd_color_fg) bits) |
- (COLOR_MASK(lcd_color_bg) ~bits);
-
- *d++ = rest | (sym off);
- rest = sym (8-off);
-#else /* LCD_BPP == LCD_COLOR8 or LCD_COLOR16 or LCD_COLOR32 */
for (c = 0; c 8; ++c) {
*d++ = (bits 0x80) ?
lcd_color_fg : lcd_color_bg;
bits = 1;
}
-#endif
}
-#if LCD_BPP == LCD_MONOCHROME
- *d = rest | (*d ((1 (8 - off)) - 1));
-#endif
}
}
@@ -443,11 +421,7 @@ int drv_lcd_init(void)
/*--*/
void lcd_clear(void)
{
-#if LCD_BPP == LCD_MONOCHROME
- /* Setting the palette */
- lcd_initcolregs();
-
-#elif LCD_BPP == LCD_COLOR8
+#if LCD_BPP == LCD_COLOR8
/* Setting the palette */
lcd_setcolreg(CONSOLE_COLOR_BLACK, 0, 0, 0);
lcd_setcolreg(CONSOLE_COLOR_RED, 0xFF, 0, 0);
diff --git a/drivers/video/mpc8xx_lcd.c b/drivers/video/mpc8xx_lcd.c
index 3ea240d..3c16bf6 100644
--- a/drivers/video/mpc8xx_lcd.c
+++ b/drivers/video/mpc8xx_lcd.c
@@ -357,23 +357,6 @@ lcd_setcolreg (ushort regno, ushort red, ushort green,
ushort blue)
/*--*/
-#if LCD_BPP == LCD_MONOCHROME
-static
-void lcd_initcolregs (void)
-{
- volatile immap_t *immr = (immap_t *) CONFIG_SYS_IMMR;
- volatile cpm8xx_t *cp = (immr-im_cpm);
- ushort regno;
-
- for (regno = 0; regno 16; regno++) {
- cp-lcd_cmap[regno * 2] = 0;
- cp-lcd_cmap[(regno * 2) + 1] = regno 0x0f;
- }
-}
-#endif
-
-/*--*/
-
void lcd_enable (void)
{
volatile immap_t *immr = (immap_t *) CONFIG_SYS_IMMR;
diff --git a/drivers/video/pxa_lcd.c b/drivers/video/pxa_lcd.c
index e19f6ac..f66f615 100644
--- a/drivers/video/pxa_lcd.c
+++ b/drivers/video/pxa_lcd.c
@@ -379,21 +379,6 @@ lcd_setcolreg (ushort regno, ushort red, ushort green,
ushort blue)
#endif /* LCD_COLOR8 */
/*--*/
-#if LCD_BPP == LCD_MONOCHROME
-void lcd_initcolregs (void)
-{
- struct pxafb_info *fbi = panel_info.pxa;
- cmap = (ushort *)fbi-palette;
- ushort regno;
-
- for (regno = 0; regno 16; regno++) {
- cmap[regno * 2] = 0;
- cmap[(regno * 2) + 1] = regno 0x0f;
- }
-}
-#endif /* LCD_MONOCHROME */
-
-/*--*/
__weak void lcd_enable(void)
{
}
diff --git a/include/lcd.h b/include/lcd.h
index 020d880..01609ac 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -359,15 +359,7 @@ void
[U-Boot] [PATCH V3 03/12] mpc8xx_lcd: get rid of CONFIG_EDT32F10
No one is using CONFIG_EDT32F10; remove related code.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Wolfgang Denk w...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Acked-by: Simon Glass s...@chromium.org
---
Changes in V3:
- No changes.
Changes in V2:
- No changes.
drivers/video/mpc8xx_lcd.c | 28
include/configs/R360MPI.h | 1 -
2 files changed, 29 deletions(-)
diff --git a/drivers/video/mpc8xx_lcd.c b/drivers/video/mpc8xx_lcd.c
index 98b9f5e..3ea240d 100644
--- a/drivers/video/mpc8xx_lcd.c
+++ b/drivers/video/mpc8xx_lcd.c
@@ -34,11 +34,6 @@
#define CONFIG_LCD_INFO/* Display Logo, (C) and system info
*/
#endif
-#if defined(CONFIG_EDT32F10)
-#undef CONFIG_LCD_LOGO
-#undef CONFIG_LCD_INFO
-#endif
-
/*--*/
#ifdef CONFIG_KYOCERA_KCS057QV1AJ
/*
@@ -224,20 +219,6 @@ vidinfo_t panel_info = {
};
#endif /* CONFIG_OPTREX_BW */
-/*-*/
-#ifdef CONFIG_EDT32F10
-/*
- * Emerging Display Technologies 320x240. Passive, monochrome, single scan.
- */
-#define LCD_BPPLCD_MONOCHROME
-#define LCD_DF 10
-
-vidinfo_t panel_info = {
-320, 240, 0, 0, CONFIG_SYS_HIGH, CONFIG_SYS_HIGH, CONFIG_SYS_HIGH,
CONFIG_SYS_HIGH, CONFIG_SYS_LOW,
-LCD_BPP, 0, 0, 0, 0, 33, 0, 0, 0
-};
-#endif
-
//
/* - chipset specific functions --- */
//
@@ -305,7 +286,6 @@ void lcd_ctrl_init (void *lcdbase)
immr-im_clkrst.car_sccr = ~0x1F;
immr-im_clkrst.car_sccr |= LCD_DF; /* was 8 */
-#if !defined(CONFIG_EDT32F10)
/* Enable LCD on port D.
*/
immr-im_ioport.iop_pdpar |= 0x1FFF;
@@ -315,14 +295,6 @@ void lcd_ctrl_init (void *lcdbase)
*/
immr-im_cpm.cp_pbpar |= 0x5001;
immr-im_cpm.cp_pbdir |= 0x5001;
-#else
- /* Enable LCD on port D.
-*/
- immr-im_ioport.iop_pdpar |= 0x1DFF;
- immr-im_ioport.iop_pdpar = ~0x0200;
- immr-im_ioport.iop_pddir |= 0x1FFF;
- immr-im_ioport.iop_pddat |= 0x0200;
-#endif
/* Load the physical address of the linear frame buffer
* into the LCD controller.
diff --git a/include/configs/R360MPI.h b/include/configs/R360MPI.h
index 009d1cf..fbaf6a5 100644
--- a/include/configs/R360MPI.h
+++ b/include/configs/R360MPI.h
@@ -24,7 +24,6 @@
#define CONFIG_LCD
#define CONFIG_MPC8XX_LCD
-#undef CONFIG_EDT32F10
#define CONFIG_SHARP_LQ057Q3DC02
#defineCONFIG_SPLASH_SCREEN
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 06/12] lcd: replace CONSOLE_(ROWS|COLS) with variables
Replace CONSOLE_(ROWS|COLS) macros with variables, and assign the
original macro values.
This is a preparatory step for extracting lcd console code into its own
file.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Anatolij Gustschin ag...@denx.de
Cc: Simon Glass s...@chromium.org
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes in V3:
- No changes.
Changes in V2:
- New patch.
common/lcd.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 371f4a2..f8fff90 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -81,20 +81,12 @@
//
/* ** CONSOLE DEFINITIONS FUNCTIONS */
//
-#if defined(CONFIG_LCD_LOGO) !defined(CONFIG_LCD_INFO_BELOW_LOGO)
-# define CONSOLE_ROWS ((panel_info.vl_row-BMP_LOGO_HEIGHT) \
- / VIDEO_FONT_HEIGHT)
-#else
-# define CONSOLE_ROWS (panel_info.vl_row / VIDEO_FONT_HEIGHT)
-#endif
-
-#define CONSOLE_COLS (panel_info.vl_col / VIDEO_FONT_WIDTH)
#define CONSOLE_ROW_SIZE (VIDEO_FONT_HEIGHT * lcd_line_length)
#define CONSOLE_ROW_FIRST lcd_console_address
#define CONSOLE_ROW_SECOND (lcd_console_address + CONSOLE_ROW_SIZE)
#define CONSOLE_ROW_LAST (lcd_console_address + CONSOLE_SIZE \
- CONSOLE_ROW_SIZE)
-#define CONSOLE_SIZE (CONSOLE_ROW_SIZE * CONSOLE_ROWS)
+#define CONSOLE_SIZE (CONSOLE_ROW_SIZE * console_rows)
#define CONSOLE_SCROLL_SIZE(CONSOLE_SIZE - CONSOLE_ROW_SIZE)
#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16) || \
@@ -124,6 +116,8 @@ char lcd_is_enabled = 0;
static short console_curr_col;
static short console_curr_row;
+static short console_cols;
+static short console_rows;
static void *lcd_console_address;
static void *lcd_base; /* Start of framebuffer memory */
@@ -196,7 +190,7 @@ static void console_scrollup(void)
static inline void console_back(void)
{
if (--console_curr_col 0) {
- console_curr_col = CONSOLE_COLS-1;
+ console_curr_col = console_cols - 1;
if (--console_curr_row 0)
console_curr_row = 0;
}
@@ -212,7 +206,7 @@ static inline void console_newline(void)
console_curr_col = 0;
/* Check if we need to scroll the terminal */
- if (++console_curr_row = CONSOLE_ROWS)
+ if (++console_curr_row = console_rows)
console_scrollup();
else
lcd_sync();
@@ -246,7 +240,7 @@ void lcd_putc(const char c)
console_curr_col += 8;
console_curr_col = ~7;
- if (console_curr_col = CONSOLE_COLS)
+ if (console_curr_col = console_cols)
console_newline();
return;
@@ -257,7 +251,7 @@ void lcd_putc(const char c)
default:
lcd_putc_xy(console_curr_col * VIDEO_FONT_WIDTH,
console_curr_row * VIDEO_FONT_HEIGHT, c);
- if (++console_curr_col = CONSOLE_COLS)
+ if (++console_curr_col = console_cols)
console_newline();
}
}
@@ -464,6 +458,13 @@ void lcd_clear(void)
debug([LCD] Drawing the logo...\n);
lcd_console_address = lcd_logo();
+#if defined(CONFIG_LCD_LOGO) !defined(CONFIG_LCD_INFO_BELOW_LOGO)
+ console_rows = (panel_info.vl_row - BMP_LOGO_HEIGHT);
+ console_rows /= VIDEO_FONT_HEIGHT;
+#else
+ console_rows = panel_info.vl_row / VIDEO_FONT_HEIGHT;
+#endif
+ console_cols = panel_info.vl_col / VIDEO_FONT_WIDTH;
console_curr_col = 0;
console_curr_row = 0;
lcd_sync();
@@ -1100,8 +1101,8 @@ U_BOOT_ENV_CALLBACK(splashimage, on_splashimage);
void lcd_position_cursor(unsigned col, unsigned row)
{
- console_curr_col = min_t(short, col, CONSOLE_COLS - 1);
- console_curr_row = min_t(short, row, CONSOLE_ROWS - 1);
+ console_curr_col = min_t(short, col, console_cols - 1);
+ console_curr_row = min_t(short, row, console_rows - 1);
}
int lcd_get_pixel_width(void)
@@ -1116,12 +1117,12 @@ int lcd_get_pixel_height(void)
int lcd_get_screen_rows(void)
{
- return CONSOLE_ROWS;
+ return console_rows;
}
int lcd_get_screen_columns(void)
{
- return CONSOLE_COLS;
+ return console_cols;
}
#if defined(CONFIG_LCD_DT_SIMPLEFB)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 05/12] lcd: rename console_(row|col)
Rename console_(row|col) to console_curr_(row|col) to better distinguish
it from console_(rows|cols).
This is a preparatory step for extracting lcd console code into its own file.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Simon Glass s...@chromium.org
Cc: Anatolij Gustschin ag...@denx.de
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes in V3:
- No changes.
Changes in V2:
- New patch.
common/lcd.c | 54 +++---
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index ed451a9..371f4a2 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -122,8 +122,8 @@ int lcd_line_length;
char lcd_is_enabled = 0;
-static short console_col;
-static short console_row;
+static short console_curr_col;
+static short console_curr_row;
static void *lcd_console_address;
static void *lcd_base; /* Start of framebuffer memory */
@@ -188,31 +188,31 @@ static void console_scrollup(void)
}
#endif
lcd_sync();
- console_row -= rows;
+ console_curr_row -= rows;
}
/*--*/
static inline void console_back(void)
{
- if (--console_col 0) {
- console_col = CONSOLE_COLS-1 ;
- if (--console_row 0)
- console_row = 0;
+ if (--console_curr_col 0) {
+ console_curr_col = CONSOLE_COLS-1;
+ if (--console_curr_row 0)
+ console_curr_row = 0;
}
- lcd_putc_xy(console_col * VIDEO_FONT_WIDTH,
- console_row * VIDEO_FONT_HEIGHT, ' ');
+ lcd_putc_xy(console_curr_col * VIDEO_FONT_WIDTH,
+ console_curr_row * VIDEO_FONT_HEIGHT, ' ');
}
/*--*/
static inline void console_newline(void)
{
- console_col = 0;
+ console_curr_col = 0;
/* Check if we need to scroll the terminal */
- if (++console_row = CONSOLE_ROWS)
+ if (++console_curr_row = CONSOLE_ROWS)
console_scrollup();
else
lcd_sync();
@@ -235,7 +235,7 @@ void lcd_putc(const char c)
switch (c) {
case '\r':
- console_col = 0;
+ console_curr_col = 0;
return;
case '\n':
@@ -243,10 +243,10 @@ void lcd_putc(const char c)
return;
case '\t': /* Tab (8 chars alignment) */
- console_col += 8;
- console_col = ~7;
+ console_curr_col += 8;
+ console_curr_col = ~7;
- if (console_col = CONSOLE_COLS)
+ if (console_curr_col = CONSOLE_COLS)
console_newline();
return;
@@ -255,9 +255,9 @@ void lcd_putc(const char c)
return;
default:
- lcd_putc_xy(console_col * VIDEO_FONT_WIDTH,
- console_row * VIDEO_FONT_HEIGHT, c);
- if (++console_col = CONSOLE_COLS)
+ lcd_putc_xy(console_curr_col * VIDEO_FONT_WIDTH,
+ console_curr_row * VIDEO_FONT_HEIGHT, c);
+ if (++console_curr_col = CONSOLE_COLS)
console_newline();
}
}
@@ -464,8 +464,8 @@ void lcd_clear(void)
debug([LCD] Drawing the logo...\n);
lcd_console_address = lcd_logo();
- console_col = 0;
- console_row = 0;
+ console_curr_col = 0;
+ console_curr_row = 0;
lcd_sync();
}
@@ -508,11 +508,11 @@ static int lcd_init(void *lcdbase)
lcd_enable();
/* Initialize the console */
- console_col = 0;
+ console_curr_col = 0;
#ifdef CONFIG_LCD_INFO_BELOW_LOGO
- console_row = 7 + BMP_LOGO_HEIGHT / VIDEO_FONT_HEIGHT;
+ console_curr_row = 7 + BMP_LOGO_HEIGHT / VIDEO_FONT_HEIGHT;
#else
- console_row = 1;/* leave 1 blank line below logo */
+ console_curr_row = 1; /* leave 1 blank line below logo */
#endif
return 0;
@@ -1062,8 +1062,8 @@ static void *lcd_logo(void)
bitmap_plot(0, 0);
#ifdef CONFIG_LCD_INFO
- console_col = LCD_INFO_X / VIDEO_FONT_WIDTH;
- console_row = LCD_INFO_Y / VIDEO_FONT_HEIGHT;
+ console_curr_col = LCD_INFO_X / VIDEO_FONT_WIDTH;
+ console_curr_row = LCD_INFO_Y / VIDEO_FONT_HEIGHT;
lcd_show_board_info();
#endif /* CONFIG_LCD_INFO */
@@ -1100,8 +1100,8 @@ U_BOOT_ENV_CALLBACK(splashimage, on_splashimage);
void lcd_position_cursor(unsigned col, unsigned row)
{
- console_col = min_t(short, col, CONSOLE_COLS - 1);
- console_row = min_t(short, row, CONSOLE_ROWS - 1);
+ console_curr_col = min_t(short, col, CONSOLE_COLS - 1);
+ console_curr_row = min_t(short, row, CONSOLE_ROWS - 1);
}
int
[U-Boot] [PATCH V3 02/12] lcd: cleanup lcd_drawchars
Remove code duplication from lcd_drawchars().
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Anatolij Gustschin ag...@denx.de
Cc: Simon Glass s...@chromium.org
Acked-by: Simon Glass s...@chromium.org
---
Changes in V3:
- No changes.
Changes in V2:
- No changes.
common/lcd.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index c7d597e..22bb488 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -346,19 +346,7 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str,
int count)
*d++ = rest | (sym off);
rest = sym (8-off);
-#elif LCD_BPP == LCD_COLOR8
- for (c = 0; c 8; ++c) {
- *d++ = (bits 0x80) ?
- lcd_color_fg : lcd_color_bg;
- bits = 1;
- }
-#elif LCD_BPP == LCD_COLOR16
- for (c = 0; c 8; ++c) {
- *d++ = (bits 0x80) ?
- lcd_color_fg : lcd_color_bg;
- bits = 1;
- }
-#elif LCD_BPP == LCD_COLOR32
+#else /* LCD_BPP == LCD_COLOR8 or LCD_COLOR16 or LCD_COLOR32 */
for (c = 0; c 8; ++c) {
*d++ = (bits 0x80) ?
lcd_color_fg : lcd_color_bg;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 12/12] lcd_console: remove unused defines
CONSOLE_ROW_SECOND, CONSOLE_ROW_LAST, and CONSOLE_SCROLL_SIZE are unused. Remove them. Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Cc: Anatolij Gustschin ag...@denx.de Cc: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- Changes in V3: - No changes. Changes in V2: - New patch. common/lcd_console.c | 4 1 file changed, 4 deletions(-) diff --git a/common/lcd_console.c b/common/lcd_console.c index f948e5a..74c388a 100644 --- a/common/lcd_console.c +++ b/common/lcd_console.c @@ -12,11 +12,7 @@ #define CONSOLE_ROW_SIZE (VIDEO_FONT_HEIGHT * lcd_line_length) #define CONSOLE_ROW_FIRST lcd_console_address -#define CONSOLE_ROW_SECOND (lcd_console_address + CONSOLE_ROW_SIZE) -#define CONSOLE_ROW_LAST (lcd_console_address + CONSOLE_SIZE \ - - CONSOLE_ROW_SIZE) #define CONSOLE_SIZE (CONSOLE_ROW_SIZE * console_rows) -#define CONSOLE_SCROLL_SIZE(CONSOLE_SIZE - CONSOLE_ROW_SIZE) static short console_curr_col; static short console_curr_row; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 08/12] lcd: get rid of COLOR_MASK
COLOR_MASK macro doesn't do anything; Remove it to reduce visual
complexity.
This is a preparatory step for extracting lcd console code into its own
file.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Anatolij Gustschin ag...@denx.de
Cc: Simon Glass s...@chromium.org
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes in V3:
- No changes.
Changes in V2:
- New patch.
common/lcd.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index bc15c78..f98aaaf 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -89,10 +89,8 @@
#define CONSOLE_SIZE (CONSOLE_ROW_SIZE * console_rows)
#define CONSOLE_SCROLL_SIZE(CONSOLE_SIZE - CONSOLE_ROW_SIZE)
-#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16) || \
- (LCD_BPP == LCD_COLOR32)
-# define COLOR_MASK(c) (c)
-#else
+#if (LCD_BPP != LCD_COLOR8) (LCD_BPP != LCD_COLOR16) \
+ (LCD_BPP != LCD_COLOR32)
# error Unsupported LCD BPP.
#endif
@@ -188,7 +186,7 @@ static void console_scrollup(void)
/* Clear the last rows */
#if (LCD_BPP != LCD_COLOR32)
memset(lcd_console_address + CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows,
- COLOR_MASK(lcd_color_bg),
+ lcd_color_bg,
CONSOLE_ROW_SIZE * rows);
#else
u32 *ppix = lcd_console_address +
@@ -197,7 +195,7 @@ static void console_scrollup(void)
for (i = 0;
i (CONSOLE_ROW_SIZE * rows) / NBYTES(panel_info.vl_bpix);
i++) {
- *ppix++ = COLOR_MASK(lcd_color_bg);
+ *ppix++ = lcd_color_bg;
}
#endif
lcd_sync();
@@ -462,7 +460,7 @@ void lcd_clear(void)
/* set framebuffer to background color */
#if (LCD_BPP != LCD_COLOR32)
memset((char *)lcd_base,
- COLOR_MASK(lcd_color_bg),
+ lcd_color_bg,
lcd_line_length * panel_info.vl_row);
#else
u32 *ppix = lcd_base;
@@ -470,7 +468,7 @@ void lcd_clear(void)
for (i = 0;
i (lcd_line_length * panel_info.vl_row)/NBYTES(panel_info.vl_bpix);
i++) {
- *ppix++ = COLOR_MASK(lcd_color_bg);
+ *ppix++ = lcd_color_bg;
}
#endif
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 07/12] lcd: expand console api
Introduce set_console_row(), set_console_col(), and lcd_init_console().
Use these functions in lcd functions: lcd_init(), lcd_clear(), lcd_logo().
This is a preparatory step for extracting lcd console code into its own
file.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Anatolij Gustschin ag...@denx.de
Cc: Simon Glass s...@chromium.org
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes in V3:
- No changes.
Changes in V2:
- New patch.
common/lcd.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index f8fff90..bc15c78 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -155,6 +155,25 @@ void lcd_set_flush_dcache(int flush)
lcd_flush_dcache = (flush != 0);
}
+void lcd_init_console(void *address, int rows, int cols)
+{
+ console_curr_col = 0;
+ console_curr_row = 0;
+ console_cols = cols;
+ console_rows = rows;
+ lcd_console_address = address;
+}
+
+void lcd_set_col(short col)
+{
+ console_curr_col = col;
+}
+
+void lcd_set_row(short row)
+{
+ console_curr_row = row;
+}
+
/*--*/
static void console_scrollup(void)
@@ -415,6 +434,7 @@ int drv_lcd_init(void)
/*--*/
void lcd_clear(void)
{
+ short console_rows, console_cols;
#if LCD_BPP == LCD_COLOR8
/* Setting the palette */
lcd_setcolreg(CONSOLE_COLOR_BLACK, 0, 0, 0);
@@ -456,8 +476,6 @@ void lcd_clear(void)
#endif
/* Paint the logo and retrieve LCD base address */
debug([LCD] Drawing the logo...\n);
- lcd_console_address = lcd_logo();
-
#if defined(CONFIG_LCD_LOGO) !defined(CONFIG_LCD_INFO_BELOW_LOGO)
console_rows = (panel_info.vl_row - BMP_LOGO_HEIGHT);
console_rows /= VIDEO_FONT_HEIGHT;
@@ -465,8 +483,7 @@ void lcd_clear(void)
console_rows = panel_info.vl_row / VIDEO_FONT_HEIGHT;
#endif
console_cols = panel_info.vl_col / VIDEO_FONT_WIDTH;
- console_curr_col = 0;
- console_curr_row = 0;
+ lcd_init_console(lcd_logo(), console_rows, console_cols);
lcd_sync();
}
@@ -509,11 +526,11 @@ static int lcd_init(void *lcdbase)
lcd_enable();
/* Initialize the console */
- console_curr_col = 0;
+ lcd_set_col(0);
#ifdef CONFIG_LCD_INFO_BELOW_LOGO
- console_curr_row = 7 + BMP_LOGO_HEIGHT / VIDEO_FONT_HEIGHT;
+ lcd_set_row(7 + BMP_LOGO_HEIGHT / VIDEO_FONT_HEIGHT);
#else
- console_curr_row = 1; /* leave 1 blank line below logo */
+ lcd_set_row(1); /* leave 1 blank line below logo */
#endif
return 0;
@@ -1063,8 +1080,8 @@ static void *lcd_logo(void)
bitmap_plot(0, 0);
#ifdef CONFIG_LCD_INFO
- console_curr_col = LCD_INFO_X / VIDEO_FONT_WIDTH;
- console_curr_row = LCD_INFO_Y / VIDEO_FONT_HEIGHT;
+ lcd_set_col(LCD_INFO_X / VIDEO_FONT_WIDTH);
+ lcd_set_row(LCD_INFO_Y / VIDEO_FONT_HEIGHT);
lcd_show_board_info();
#endif /* CONFIG_LCD_INFO */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 11/12] lcd: refactor lcd console stuff into its own file
common/lcd.c is a mix of code portions that do different but related
things. To improve modularity, the various code portions should be split
into their own modules. Separate lcd console code into its own file.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Anatolij Gustschin ag...@denx.de
Cc: Simon Glass s...@chromium.org
Cc: Stephen Warren swar...@wwwdotorg.org
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes in V3:
- Updated comment for lcd_printf().
Changes in V2:
- New patch.
common/Makefile | 2 +-
common/lcd.c | 229 --
common/lcd_console.c | 215 +++
include/lcd.h | 1 +
include/lcd_console.h | 86 +++
5 files changed, 303 insertions(+), 230 deletions(-)
create mode 100644 common/lcd_console.c
create mode 100644 include/lcd_console.h
diff --git a/common/Makefile b/common/Makefile
index 9c47e20..66584fc 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -206,7 +206,7 @@ obj-$(CONFIG_CMD_KGDB) += kgdb.o kgdb_stubs.o
obj-$(CONFIG_I2C_EDID) += edid.o
obj-$(CONFIG_KALLSYMS) += kallsyms.o
obj-y += splash.o
-obj-$(CONFIG_LCD) += lcd.o
+obj-$(CONFIG_LCD) += lcd.o lcd_console.o
obj-$(CONFIG_LYNXKDI) += lynxkdi.o
obj-$(CONFIG_MENU) += menu.o
obj-$(CONFIG_MODEM_SUPPORT) += modem.o
diff --git a/common/lcd.c b/common/lcd.c
index 0c90502..bef8079 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -73,22 +73,6 @@
#define CONFIG_LCD_ALIGNMENT PAGE_SIZE
#endif
-/* By default we scroll by a single line */
-#ifndef CONFIG_CONSOLE_SCROLL_LINES
-#define CONFIG_CONSOLE_SCROLL_LINES 1
-#endif
-
-//
-/* ** CONSOLE DEFINITIONS FUNCTIONS */
-//
-#define CONSOLE_ROW_SIZE (VIDEO_FONT_HEIGHT * lcd_line_length)
-#define CONSOLE_ROW_FIRST lcd_console_address
-#define CONSOLE_ROW_SECOND (lcd_console_address + CONSOLE_ROW_SIZE)
-#define CONSOLE_ROW_LAST (lcd_console_address + CONSOLE_SIZE \
- - CONSOLE_ROW_SIZE)
-#define CONSOLE_SIZE (CONSOLE_ROW_SIZE * console_rows)
-#define CONSOLE_SCROLL_SIZE(CONSOLE_SIZE - CONSOLE_ROW_SIZE)
-
#if (LCD_BPP != LCD_COLOR8) (LCD_BPP != LCD_COLOR16) \
(LCD_BPP != LCD_COLOR32)
# error Unsupported LCD BPP.
@@ -96,9 +80,6 @@
DECLARE_GLOBAL_DATA_PTR;
-static void lcd_drawchars(ushort x, ushort y, uchar *str, int count);
-static inline void lcd_putc_xy(ushort x, ushort y, uchar c);
-
static int lcd_init(void *lcdbase);
static void *lcd_logo(void);
@@ -112,12 +93,6 @@ int lcd_line_length;
char lcd_is_enabled = 0;
-static short console_curr_col;
-static short console_curr_row;
-static short console_cols;
-static short console_rows;
-
-static void *lcd_console_address;
static void *lcd_base; /* Start of framebuffer memory */
static char lcd_flush_dcache; /* 1 to flush dcache after each lcd update */
@@ -153,82 +128,6 @@ void lcd_set_flush_dcache(int flush)
lcd_flush_dcache = (flush != 0);
}
-void lcd_init_console(void *address, int rows, int cols)
-{
- console_curr_col = 0;
- console_curr_row = 0;
- console_cols = cols;
- console_rows = rows;
- lcd_console_address = address;
-}
-
-void lcd_set_col(short col)
-{
- console_curr_col = col;
-}
-
-void lcd_set_row(short row)
-{
- console_curr_row = row;
-}
-
-/*--*/
-
-static void console_scrollup(void)
-{
- const int rows = CONFIG_CONSOLE_SCROLL_LINES;
- int bg_color = lcd_getbgcolor();
-
- /* Copy up rows ignoring those that will be overwritten */
- memcpy(CONSOLE_ROW_FIRST,
- lcd_console_address + CONSOLE_ROW_SIZE * rows,
- CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows);
-
- /* Clear the last rows */
-#if (LCD_BPP != LCD_COLOR32)
- memset(lcd_console_address + CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows,
- bg_color, CONSOLE_ROW_SIZE * rows);
-#else
- u32 *ppix = lcd_console_address +
- CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows;
- u32 i;
- for (i = 0;
- i (CONSOLE_ROW_SIZE * rows) / NBYTES(panel_info.vl_bpix);
- i++) {
- *ppix++ = bg_color;
- }
-#endif
- lcd_sync();
- console_curr_row -= rows;
-}
-
-/*--*/
-
-static inline void console_back(void)
-{
- if (--console_curr_col 0) {
- console_curr_col = console_cols - 1;
- if (--console_curr_row 0)
- console_curr_row = 0;
- }
-
- lcd_putc_xy(console_curr_col * VIDEO_FONT_WIDTH,
-
[U-Boot] [PATCH V3 09/12] lcd: introduce getters for bg/fg color
Introduce lcd_getbgcolor() and lcd_getfgcolor(), and use them where
applicable.
This is a preparatory step for extracting lcd console code into its own
file.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Anatolij Gustschin ag...@denx.de
Cc: Simon Glass s...@chromium.org
---
Changes in V3:
- Instead of invoking lcd_get(bg|fg)color() each time, do it only once
and cache the value. This is done in console_scrollup(),
lcd_drawchars(), and drv_lcd_init().
Changes in V2:
- New patch.
common/lcd.c | 31 ++-
include/lcd.h | 14 ++
2 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index f98aaaf..a29e7a2 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -177,6 +177,7 @@ void lcd_set_row(short row)
static void console_scrollup(void)
{
const int rows = CONFIG_CONSOLE_SCROLL_LINES;
+ int bg_color = lcd_getbgcolor();
/* Copy up rows ignoring those that will be overwritten */
memcpy(CONSOLE_ROW_FIRST,
@@ -186,8 +187,7 @@ static void console_scrollup(void)
/* Clear the last rows */
#if (LCD_BPP != LCD_COLOR32)
memset(lcd_console_address + CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows,
- lcd_color_bg,
- CONSOLE_ROW_SIZE * rows);
+ bg_color, CONSOLE_ROW_SIZE * rows);
#else
u32 *ppix = lcd_console_address +
CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows;
@@ -195,7 +195,7 @@ static void console_scrollup(void)
for (i = 0;
i (CONSOLE_ROW_SIZE * rows) / NBYTES(panel_info.vl_bpix);
i++) {
- *ppix++ = lcd_color_bg;
+ *ppix++ = bg_color;
}
#endif
lcd_sync();
@@ -316,6 +316,7 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str,
int count)
{
uchar *dest;
ushort row;
+ int fg_color, bg_color;
#if defined(CONFIG_LCD_LOGO) !defined(CONFIG_LCD_INFO_BELOW_LOGO)
y += BMP_LOGO_HEIGHT;
@@ -334,6 +335,8 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str,
int count)
uchar *d = dest;
#endif
+ fg_color = lcd_getfgcolor();
+ bg_color = lcd_getbgcolor();
for (i = 0; i count; ++i) {
uchar c, bits;
@@ -341,8 +344,7 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str,
int count)
bits = video_fontdata[c * VIDEO_FONT_HEIGHT + row];
for (c = 0; c 8; ++c) {
- *d++ = (bits 0x80) ?
- lcd_color_fg : lcd_color_bg;
+ *d++ = (bits 0x80) ? fg_color : bg_color;
bits = 1;
}
}
@@ -433,6 +435,7 @@ int drv_lcd_init(void)
void lcd_clear(void)
{
short console_rows, console_cols;
+ int bg_color;
#if LCD_BPP == LCD_COLOR8
/* Setting the palette */
lcd_setcolreg(CONSOLE_COLOR_BLACK, 0, 0, 0);
@@ -449,9 +452,11 @@ void lcd_clear(void)
#ifndef CONFIG_SYS_WHITE_ON_BLACK
lcd_setfgcolor(CONSOLE_COLOR_BLACK);
lcd_setbgcolor(CONSOLE_COLOR_WHITE);
+ bg_color = CONSOLE_COLOR_WHITE;
#else
lcd_setfgcolor(CONSOLE_COLOR_WHITE);
lcd_setbgcolor(CONSOLE_COLOR_BLACK);
+ bg_color = CONSOLE_COLOR_BLACK;
#endif /* CONFIG_SYS_WHITE_ON_BLACK */
#ifdef LCD_TEST_PATTERN
@@ -459,16 +464,14 @@ void lcd_clear(void)
#else
/* set framebuffer to background color */
#if (LCD_BPP != LCD_COLOR32)
- memset((char *)lcd_base,
- lcd_color_bg,
- lcd_line_length * panel_info.vl_row);
+ memset((char *)lcd_base, bg_color, lcd_line_length * panel_info.vl_row);
#else
u32 *ppix = lcd_base;
u32 i;
for (i = 0;
i (lcd_line_length * panel_info.vl_row)/NBYTES(panel_info.vl_bpix);
i++) {
- *ppix++ = lcd_color_bg;
+ *ppix++ = bg_color;
}
#endif
#endif
@@ -575,6 +578,11 @@ static void lcd_setfgcolor(int color)
lcd_color_fg = color;
}
+int lcd_getfgcolor(void)
+{
+ return lcd_color_fg;
+}
+
/*--*/
static void lcd_setbgcolor(int color)
@@ -582,6 +590,11 @@ static void lcd_setbgcolor(int color)
lcd_color_bg = color;
}
+int lcd_getbgcolor(void)
+{
+ return lcd_color_bg;
+}
+
//
/* ** Chipset depending Bitmap / Logo stuff... */
//
diff --git a/include/lcd.h b/include/lcd.h
index 01609ac..2235b9b 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -291,6 +291,20 @@ int lcd_get_screen_rows(void);
int lcd_get_screen_columns(void);
/**
+ * Get the
[U-Boot] [PATCH v2 6/9] ARM: UniPhier: add more device nodes to device tree
Add I2C controller and NAND controller devices. Fix indentation too.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes v2:
- I2C Ch4 does not exist on PH1-Pro4
- Add clock-frequency property
arch/arm/dts/uniphier-ph1-ld4-ref.dts | 27 +++---
arch/arm/dts/uniphier-ph1-ld4.dtsi | 44 ++-
arch/arm/dts/uniphier-ph1-pro4-ref.dts | 29 ---
arch/arm/dts/uniphier-ph1-pro4.dtsi| 64 +-
arch/arm/dts/uniphier-ph1-sld8-ref.dts | 27 +++---
arch/arm/dts/uniphier-ph1-sld8.dtsi| 44 ++-
6 files changed, 220 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
index f01189c..08bbd03 100644
--- a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
@@ -23,20 +23,39 @@
bootargs = console=ttyPS0,115200 earlyprintk;
stdout-path = uart0;
};
+
+ aliases {
+ uart0 = uart0;
+ uart1 = uart1;
+ uart2 = uart2;
+ uart3 = uart3;
+ i2c0 = i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ };
};
uart0 {
- status = okay;
+ status = okay;
};
uart1 {
- status = okay;
+ status = okay;
+};
+
+i2c0 {
+ status = okay;
+ eeprom {
+ compatible = i2c-eeprom;
+ reg = 0x50;
+ };
};
usb0 {
- status = okay;
+ status = okay;
};
usb1 {
- status = okay;
+ status = okay;
};
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index 80074c5..2a3dd73 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -13,8 +13,8 @@
compatible = panasonic,ph1-ld4;
cpus {
- #size-cells = 0;
#address-cells = 1;
+ #size-cells = 0;
cpu@0 {
device_type = cpu;
@@ -57,6 +57,42 @@
clock-frequency = 36864000;
};
+ i2c0: i2c@5840 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5840 0x40;
+ clock-frequency = 10;
+ status = disabled;
+ };
+
+ i2c1: i2c@5848 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5848 0x40;
+ clock-frequency = 10;
+ status = disabled;
+ };
+
+ i2c2: i2c@5850 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5850 0x40;
+ clock-frequency = 10;
+ status = disabled;
+ };
+
+ i2c3: i2c@5858 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5858 0x40;
+ clock-frequency = 10;
+ status = disabled;
+ };
+
usb0: usb@5a800100 {
compatible = panasonic,uniphier-ehci, usb-ehci;
status = disabled;
@@ -74,5 +110,11 @@
status = disabled;
reg = 0x5a820100 0x100;
};
+
+ nand: nand@6800 {
+ compatible = denali,denali-nand-dt;
+ reg = 0x6800 0x20, 0x6810 0x1000;
+ reg-names = nand_data, denali_reg;
+ };
};
};
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index 52fa81f..23add7c 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -23,20 +23,41 @@
bootargs = console=ttyPS0,115200 earlyprintk;
stdout-path = uart0;
};
+
+ aliases {
+ uart0 = uart0;
+ uart1 = uart1;
+ uart2 = uart2;
+ uart3 = uart3;
+ i2c0 = i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ i2c5 = i2c5;
+ i2c6 = i2c6;
+ };
};
uart0 {
- status = okay;
+ status = okay;
};
uart1 {
- status = okay;
+ status = okay;
+};
+
+i2c0 {
+ status = okay;
+ eeprom {
+ compatible =
[U-Boot] [PATCH v2 7/9] ARM: UniPhier: add device tree sources for PH1-sLD3
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v2:
- Add clock-frequency property
arch/arm/dts/Makefile | 1 +
arch/arm/dts/uniphier-ph1-sld3-ref.dts | 60
arch/arm/dts/uniphier-ph1-sld3.dtsi| 125 +
3 files changed, 186 insertions(+)
create mode 100644 arch/arm/dts/uniphier-ph1-sld3-ref.dts
create mode 100644 arch/arm/dts/uniphier-ph1-sld3.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 01df9a9..187d58c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -33,6 +33,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra124-jetson-tk1.dtb \
tegra124-venice2.dtb
dtb-$(CONFIG_ARCH_UNIPHIER) += \
+ uniphier-ph1-sld3-ref.dtb \
uniphier-ph1-pro4-ref.dtb \
uniphier-ph1-ld4-ref.dtb \
uniphier-ph1-sld8-ref.dtb
diff --git a/arch/arm/dts/uniphier-ph1-sld3-ref.dts
b/arch/arm/dts/uniphier-ph1-sld3-ref.dts
new file mode 100644
index 000..91b4dbe
--- /dev/null
+++ b/arch/arm/dts/uniphier-ph1-sld3-ref.dts
@@ -0,0 +1,60 @@
+/*
+ * Device Tree Source for UniPhier PH1-sLD3 Reference Board
+ *
+ * Copyright (C) 2014 Panasonic Corporation
+ * Author: Masahiro Yamada yamad...@jp.panasonic.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ uniphier-ph1-sld3.dtsi
+
+/ {
+ model = Panasonic UniPhier PH1-sLD3 Reference Board;
+ compatible = panasonic,ph1-sld3-ref, panasonic,ph1-sld3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000;
+ };
+
+ chosen {
+ bootargs = console=ttyPS0,115200 earlyprintk;
+ stdout-path = uart0;
+ };
+
+ aliases {
+ uart0 = uart0;
+ uart1 = uart1;
+ uart2 = uart2;
+ i2c0 = i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ };
+};
+
+uart0 {
+ status = okay;
+};
+
+uart1 {
+ status = okay;
+};
+
+i2c0 {
+ status = okay;
+ eeprom {
+ compatible = i2c-eeprom;
+ reg = 0x50;
+ };
+};
+
+usb0 {
+ status = okay;
+};
+
+usb1 {
+ status = okay;
+};
diff --git a/arch/arm/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/dts/uniphier-ph1-sld3.dtsi
new file mode 100644
index 000..f5529d2
--- /dev/null
+++ b/arch/arm/dts/uniphier-ph1-sld3.dtsi
@@ -0,0 +1,125 @@
+/*
+ * Device Tree Source for UniPhier PH1-sLD3 SoC
+ *
+ * Copyright (C) 2014 Panasonic Corporation
+ * Author: Masahiro Yamada yamad...@jp.panasonic.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ compatible = panasonic,ph1-sld3;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0;
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 1;
+ };
+ };
+
+ soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ uart0: serial@54006800 {
+ compatible = panasonic,uniphier-uart;
+ status = disabled;
+ reg = 0x54006800 0x20;
+ clock-frequency = 36864000;
+ };
+
+ uart1: serial@54006900 {
+ compatible = panasonic,uniphier-uart;
+ status = disabled;
+ reg = 0x54006900 0x20;
+ clock-frequency = 36864000;
+ };
+
+ uart2: serial@54006a00 {
+ compatible = panasonic,uniphier-uart;
+ status = disabled;
+ reg = 0x54006a00 0x20;
+ clock-frequency = 36864000;
+ };
+
+ i2c0: i2c@5840 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5840 0x40;
+ clock-frequency = 10;
+ status = disabled;
+ };
+
+ i2c1: i2c@5848 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5848 0x40;
+ clock-frequency = 10;
+ status = disabled;
+ };
+
+ i2c2: i2c@5850 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+
[U-Boot] [PATCH V3 10/12] lcd: make lcd_drawchars() independant of lcd_base
lcd_logo() has the following return value:
#if defined(CONFIG_LCD_LOGO) !defined(CONFIG_LCD_INFO_BELOW_LOGO)
return (void *)((ulong)lcd_base + BMP_LOGO_HEIGHT * lcd_line_length);
#else
return (void *)lcd_base;
#endif
This return value gets assigned to lcd_console_address.
lcd_console_address is not assigned or modified anywhere else.
Thus:
#if defined(CONFIG_LCD_LOGO) !defined(CONFIG_LCD_INFO_BELOW_LOGO):
y' = BMP_LOGO_HEIGHT + y;
lcd_base + y' * lcd_line_length ==
lcd_base + (BMP_LOGO_HEIGHT + y) * lcd_line_length ==
lcd_base + BMP_LOGO_HEIGHT * lcd_line_length + y * lcd_line_length ==
lcd_console_address + y * lcd_line_length
#else
lcd_base + y * lcd_line_length == lcd_console_address + y *
lcd_line_length
#endif
This is a preparatory step for extracting lcd console code into its own
file.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Cc: Anatolij Gustschin ag...@denx.de
Cc: Simon Glass s...@chromium.org
---
Changes in V3:
- No changes.
Changes in V2:
- New patch.
common/lcd.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index a29e7a2..0c90502 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -318,11 +318,8 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str,
int count)
ushort row;
int fg_color, bg_color;
-#if defined(CONFIG_LCD_LOGO) !defined(CONFIG_LCD_INFO_BELOW_LOGO)
- y += BMP_LOGO_HEIGHT;
-#endif
-
- dest = (uchar *)(lcd_base + y * lcd_line_length + x * NBITS(LCD_BPP)/8);
+ dest = (uchar *)(lcd_console_address +
+ y * lcd_line_length + x * NBITS(LCD_BPP) / 8);
for (row = 0; row VIDEO_FONT_HEIGHT; ++row, dest += lcd_line_length) {
uchar *s = str;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] ARM: UniPhier: add more device nodes to device tree
2014-12-09 0:16 GMT+09:00 Masahiro Yamada yamad...@jp.panasonic.com: Add I2C controller and NAND controller devices. Fix indentation too. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes v2: - I2C Ch4 does not exist on PH1-Pro4 - Add clock-frequency property Applied to u-boot-uniphier. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] ARM: UniPhier: add device tree sources for PH1-sLD3
2014-12-09 0:16 GMT+09:00 Masahiro Yamada yamad...@jp.panasonic.com: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v2: - Add clock-frequency property Applied to u-boot-uniphier. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
Hi Fabio, On 08.12.2014 15:51, Fabio Estevam wrote: Could you test this on one of your board? If your board also fails to boot via the bmode mmc0 command if the CCGR0 register value is missing? I am currently out of the office without access to my mx6 board, I see. Perhaps you could do that once you are back in the office... but looking in board/freescale/mx6sabresd/mx6sabresd.c we have: writel(0x00C03F3F, ccm-CCGR0); ,which turns on the AIPS clocks. Can't you just turn on the AIPS clocks inside in your board file like we do on sabresd? I'm doing just that. Its copied directly from your code. Problem is, this seems to be too late. The BootROM doesn't seem to load SPL completely from the SD card when this CCGR0 line is missing. At least this is how I'm interpreting this hangup. I am not sure where the AIPS clocks are being turned off in your case though. I'm pretty sure that no code is turning them off. As mentioned before, its not that easy for me to debug this though. Again, my current best guess is, that the BootROM fails to load the SPL from SD card completely. So we have no chance to configure this register via code, but need to do it via the DCD. It might be that this is related to the bmode mmc0 command. As I'm unable to test direct SD card booting via strapping. Not sure though. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-uniphier (updated!)
Hi Tom,
If it is not too late, please let me replace the PR I sent yesterday
with this one.
This includes one fixes.
The following changes since commit 97cdf64026c7d749dd7a5c0dbaba7a60a7292ac9:
Merge branch 'sandbox' of git://git.denx.de/u-boot-x86 (2014-12-04
09:24:05 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-uniphier.git master
for you to fetch changes up to 7a3620b24649663857d99e8ab73ec0b3bd60e50e:
ARM: UniPhier: detect the number of flash banks at run-time
(2014-12-09 00:08:33 +0900)
Masahiro Yamada (11):
ARM: UniPhier: remove Denali NAND controller fixup code
flash: do not fail even if flash_size is zero
ARM: UniPhier: disable autostart by default
ARM: UniPhier: use boot_is_swapped() macro for readability
ARM: UniPhier: move CONFIG_UNIPHIER_SMP to Kconfig
ARM: UniPhier: move support card select to Kconfig
ARM: UniPhier: merge UniPhier config headers into a single file
ARM: UniPhier: add more device nodes to device tree
ARM: UniPhier: add device tree sources for PH1-sLD3
ARM: UniPhier: extend register area of init page table for PH1-sLD3
ARM: UniPhier: detect the number of flash banks at run-time
arch/arm/cpu/armv7/uniphier/Kconfig | 31 -
arch/arm/cpu/armv7/uniphier/Makefile | 1 +
arch/arm/cpu/armv7/uniphier/board_early_init_r.c | 15 +
arch/arm/cpu/armv7/uniphier/board_late_init.c | 38 ---
arch/arm/cpu/armv7/uniphier/init_page_table.c | 7 ++-
arch/arm/cpu/armv7/uniphier/ph1-pro4/sbc_init.c | 20 +++---
arch/arm/cpu/armv7/uniphier/support_card.c| 125
+
arch/arm/dts/Makefile | 1 +
arch/arm/dts/uniphier-ph1-ld4-ref.dts | 27 ++--
arch/arm/dts/uniphier-ph1-ld4.dtsi| 44 -
arch/arm/dts/uniphier-ph1-pro4-ref.dts| 29 +++--
arch/arm/dts/uniphier-ph1-pro4.dtsi | 64 ++-
arch/arm/dts/uniphier-ph1-sld3-ref.dts| 60 ++
arch/arm/dts/uniphier-ph1-sld3.dtsi | 125
+
arch/arm/dts/uniphier-ph1-sld8-ref.dts| 27 ++--
arch/arm/dts/uniphier-ph1-sld8.dtsi | 44 -
arch/arm/include/asm/arch-uniphier/board.h| 7 +++
common/board_r.c | 18 +-
configs/ph1_ld4_defconfig | 1 +
configs/ph1_pro4_defconfig| 1 +
configs/ph1_sld8_defconfig| 1 +
include/configs/ph1_ld4.h | 53
include/configs/ph1_pro4.h| 55
include/configs/ph1_sld8.h| 55
include/configs/{uniphier-common.h = uniphier.h} | 63 ++-
25 files changed, 611 insertions(+), 301 deletions(-)
create mode 100644 arch/arm/cpu/armv7/uniphier/board_early_init_r.c
create mode 100644 arch/arm/dts/uniphier-ph1-sld3-ref.dts
create mode 100644 arch/arm/dts/uniphier-ph1-sld3.dtsi
delete mode 100644 include/configs/ph1_ld4.h
delete mode 100644 include/configs/ph1_pro4.h
delete mode 100644 include/configs/ph1_sld8.h
rename include/configs/{uniphier-common.h = uniphier.h} (84%)
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
On Mon, Dec 8, 2014 at 1:19 PM, Stefan Roese s...@denx.de wrote: Hi Fabio, On 08.12.2014 15:51, Fabio Estevam wrote: Could you test this on one of your board? If your board also fails to boot via the bmode mmc0 command if the CCGR0 register value is missing? I am currently out of the office without access to my mx6 board, I see. Perhaps you could do that once you are back in the office... Sure, I will test it and will let you know how it goes. In the meantime, I am wondering if the change below would allow your board to boot: --- a/arch/arm/cpu/armv7/mx6/soc.c +++ b/arch/arm/cpu/armv7/mx6/soc.c @@ -105,6 +105,10 @@ void init_aips(void) #ifdef CONFIG_MX6SX struct aipstz_regs *aips3; #endif + struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR; + + /* Turn on AIPS1 and AIPS2 clocks */ + setbits_le32(ccm-CCGR0, 0xf); aips1 = (struct aipstz_regs *)AIPS1_BASE_ADDR; aips2 = (struct aipstz_regs *)AIPS2_BASE_ADDR; Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
On 08.12.2014 16:36, Fabio Estevam wrote: Could you test this on one of your board? If your board also fails to boot via the bmode mmc0 command if the CCGR0 register value is missing? I am currently out of the office without access to my mx6 board, I see. Perhaps you could do that once you are back in the office... Sure, I will test it and will let you know how it goes. Thanks! In the meantime, I am wondering if the change below would allow your board to boot: --- a/arch/arm/cpu/armv7/mx6/soc.c +++ b/arch/arm/cpu/armv7/mx6/soc.c @@ -105,6 +105,10 @@ void init_aips(void) #ifdef CONFIG_MX6SX struct aipstz_regs *aips3; #endif + struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR; + + /* Turn on AIPS1 and AIPS2 clocks */ + setbits_le32(ccm-CCGR0, 0xf); aips1 = (struct aipstz_regs *)AIPS1_BASE_ADDR; aips2 = (struct aipstz_regs *)AIPS2_BASE_ADDR; I just tested it. And it doesn't help. I really think this code is not reached in this failure case. As the SPL is not loaded completely. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
Hi Stefan, On Mon, Dec 8, 2014 at 1:42 PM, Stefan Roese s...@denx.de wrote: I just tested it. And it doesn't help. I really think this code is not reached in this failure case. As the SPL is not loaded completely. Do you have this patch applied? commit f2863ff3f47c99c4b5ba00be572e3a2c4213c5a2 Author: Nikita Kiryanov nik...@compulab.co.il Date: Wed Oct 29 19:28:33 2014 +0200 arm: imx: make bmode command work with SPL/U-Boot combo The bmode command forces the SoC to use a specific boot device by writing its boot mode into SRC_GPR9, and notifying the SoC of the change using SRC_GPR10[28] bit: if the bit is on, bootROM uses the value in SRC_GPR9 instead of SRC_SMBR1 to determine the boot device. SPL on the other hand is oblivious to this distinction, so once the bootROM loads SPL from the device configured in SRC_GPR10, SPL will attempt to load U-Boot from the device configured in SRC_SMBR1, which is not updated by the bootROM to the value in SRC_GPR9. The result is that the selected boot device is not used across all the boot stages. Update spl_boot_device() to look at gpr9 when necessary. Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Cc: Stefano Babic sba...@denx.de Cc: Troy Kisky troy.ki...@boundarydevices.com Cc: Tim Harvey thar...@gateworks.com Cc: Eric Nelson eric.nel...@boundarydevices.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Heiko Schocher h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
On 08.12.2014 17:13, Fabio Estevam wrote: I just tested it. And it doesn't help. I really think this code is not reached in this failure case. As the SPL is not loaded completely. Do you have this patch applied? commit f2863ff3f47c99c4b5ba00be572e3a2c4213c5a2 Author: Nikita Kiryanov nik...@compulab.co.il Date: Wed Oct 29 19:28:33 2014 +0200 arm: imx: make bmode command work with SPL/U-Boot combo The bmode command forces the SoC to use a specific boot device by writing its boot mode into SRC_GPR9, and notifying the SoC of the change using SRC_GPR10[28] bit: if the bit is on, bootROM uses the value in SRC_GPR9 instead of SRC_SMBR1 to determine the boot device. SPL on the other hand is oblivious to this distinction, so once the bootROM loads SPL from the device configured in SRC_GPR10, SPL will attempt to load U-Boot from the device configured in SRC_SMBR1, which is not updated by the bootROM to the value in SRC_GPR9. The result is that the selected boot device is not used across all the boot stages. Update spl_boot_device() to look at gpr9 when necessary. Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Cc: Stefano Babic sba...@denx.de Cc: Troy Kisky troy.ki...@boundarydevices.com Cc: Tim Harvey thar...@gateworks.com Cc: Eric Nelson eric.nel...@boundarydevices.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Heiko Schocher h...@denx.de Yes, its applied. I'm nearly on mainline right now. And it doesn't help. Which makes sense if my current guess is correct, that the BootROM doesn't load the SPL completely without this CCGR0 register setting in the DCD. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/12] spi: sf: Support byte program for sst spi flash
Hi Bin,
On 1 November 2014 at 14:23, Bin Meng bmeng...@gmail.com wrote:
Currently if SST flash advertises SST_WP flag in the params table
the word program command (ADh) with auto address increment will be
used for the flash write op. However some SPI controllers do not
support the word program command (like the Intel ICH 7), the byte
programm command (02h) has to be used.
A new TX operation mode SPI_OPM_TX_BP is introduced for such SPI
controller to use byte program op for SST flash.
We have SST_WP which is word program - for specific flash's (not for
controller specific
at-least from params data)
Which is this SST_BP relies for ? controller or specific flash ?
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
drivers/mtd/spi/sf_internal.h | 2 ++
drivers/mtd/spi/sf_ops.c | 31 +++
drivers/mtd/spi/sf_probe.c| 8 ++--
drivers/spi/ich.c | 9 +++--
include/spi.h | 1 +
5 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 5b7670c..f519060 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -107,6 +107,8 @@ enum {
int sst_write_wp(struct spi_flash *flash, u32 offset, size_t len,
const void *buf);
+int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
+ const void *buf);
#endif
/**
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 85cf22d..3703acb 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -516,4 +516,35 @@ int sst_write_wp(struct spi_flash *flash, u32 offset,
size_t len,
spi_release_bus(flash-spi);
return ret;
}
+
+int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
+ const void *buf)
+{
+ size_t actual;
+ int ret;
+
+ ret = spi_claim_bus(flash-spi);
+ if (ret) {
+ debug(SF: Unable to claim SPI bus\n);
+ return ret;
+ }
+
+ for (actual = 0; actual len; actual++) {
+ ret = sst_byte_write(flash, offset, buf + actual);
+ if (ret) {
+ debug(SF: sst byte program failed\n);
+ break;
+ }
+ offset++;
+ }
+
+ if (!ret)
+ ret = spi_flash_cmd_write_disable(flash);
+
+ debug(SF: sst: program %s %zu bytes @ 0x%zx\n,
+ ret ? failure : success, len, offset - actual);
+
+ spi_release_bus(flash-spi);
+ return ret;
+}
#endif
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 2636426..b7ff63f 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -135,8 +135,12 @@ static int spi_flash_validate_params(struct spi_slave
*spi, u8 *idcode,
#ifndef CONFIG_DM_SPI_FLASH
flash-write = spi_flash_cmd_write_ops;
#if defined(CONFIG_SPI_FLASH_SST)
- if (params-flags SST_WP)
- flash-write = sst_write_wp;
+ if (params-flags SST_WP) {
+ if (flash-spi-op_mode_tx SPI_OPM_TX_BP)
+ flash-write = sst_write_bp;
+ else
+ flash-write = sst_write_wp;
+ }
#endif
flash-erase = spi_flash_cmd_erase_ops;
flash-read = spi_flash_cmd_read_ops;
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index b356411..16730ec 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -141,9 +141,14 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
ich-slave.max_write_size = ctlr.databytes;
ich-speed = max_hz;
- /* ICH 7 SPI controller only supports array read command */
- if (ctlr.ich_version == 7)
+ /*
+* ICH 7 SPI controller only supports array read command
+* and byte program command for SST flash
+*/
+ if (ctlr.ich_version == 7) {
ich-slave.op_mode_rx = SPI_OPM_RX_AS;
+ ich-slave.op_mode_tx = SPI_OPM_TX_BP;
+ }
return ich-slave;
}
diff --git a/include/spi.h b/include/spi.h
index aa0a48e..60202ee 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -34,6 +34,7 @@
/* SPI TX operation modes */
#define SPI_OPM_TX_QPP (1 0)
+#define SPI_OPM_TX_BP (1 1)
/* SPI RX operation modes */
#define SPI_OPM_RX_AS (1 0)
--
1.8.2.1
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Link error for arm targets
Guys, I need some help to understand the link error introduced by commit d455d8789d5b35a39a0a179b3af4b423db13bfdd fs: API changes enabling extra parameter to return size of type loff_t I don't see anything wrong with this commit, but some of my targets don't link after this commit. The error I got for compiling ls1021aqds_nor is: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(bpabi.o) /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_divdi3.o) /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_udivdi3.o) make[2]: *** [u-boot] Error 1 make[1]: *** [__build_one_by_one] Error 2 make: *** [sub-make] Error 2 I don't know much about this error. Can someone help? I should have caught this error earlier but a bad escape flaw in my Jenkins script skipped all the ARM targets I normally test. I hope I didn't let in any patch with compiling errors (finger crossed). York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] fastboot: handle flash write to GPT partition
Hi Lukasz,
On 14-12-08 03:21 AM, Lukasz Majewski wrote:
Hi Steve,
Implement a feature to allow fastboot to write the downloaded image
to the space reserved for the Protective MBR and the Primary GUID
Partition Table.
Signed-off-by: Steve Rae s...@broadcom.com
---
README | 7 +++
common/fb_mmc.c | 19 ---
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 66770b6..3b6ef7f 100644
--- a/README
+++ b/README
@@ -1769,6 +1769,13 @@ The following options need to be configured:
regarding the non-volatile storage device. Define
this to the eMMC device that fastboot should use to store the image.
+ CONFIG_FASTBOOT_GPT_NAME
+ The fastboot flash command supports writing the
downloaded
+ image to the Protective MBR and the Primary GUID
Partition
+ Table. This occurs when the specified partition
name on the
+ fastboot flash command line matches this value.
+ Default is GPT_ENTRY_NAME (currently gpt) if
undefined. +
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index fb06d8a..89fbf23 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -4,12 +4,17 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include config.h
#include common.h
#include fb_mmc.h
#include part.h
#include aboot.h
#include sparse_format.h
+#ifndef CONFIG_FASTBOOT_GPT_NAME
+#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
+#endif
+
/* The 64 defined bytes plus the '\0' */
#define RESPONSE_LEN (64 + 1)
@@ -62,9 +67,9 @@ static void write_raw_image(block_dev_desc_t
*dev_desc, disk_partition_t *info, void fb_mmc_flash_write(const char
*cmd, void *download_buffer, unsigned int download_bytes, char
*response) {
- int ret;
block_dev_desc_t *dev_desc;
disk_partition_t info;
+ lbaint_t blksz;
/* initialize the response buffer */
response_str = response;
@@ -76,8 +81,16 @@ void fb_mmc_flash_write(const char *cmd, void
*download_buffer, return;
}
- ret = get_partition_info_efi_by_name(dev_desc, cmd, info);
- if (ret) {
+ if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
+ printf(%s: updating GUID Partition Table (including
MBR)\n,
+ __func__);
+ /* start at Protective MBR */
+ info.start = (GPT_PRIMARY_PARTITION_TABLE_LBA - 1);
+ blksz = dev_desc-blksz;
+ info.blksz = blksz;
+ /* assume that the Partition Entry Array starts in
LBA 2 */
+ info.size = (2 + (GPT_ENTRY_NUMBERS *
GPT_ENTRY_SIZE) / blksz);
+ } else if (get_partition_info_efi_by_name(dev_desc, cmd,
info)) { error(cannot find partition: '%s'\n, cmd);
fastboot_fail(cannot find partition);
return;
Sorry for a late reply. I've just come back from a short holidays.
I'm curious if you have encountered any problems with GPT replaced in
that way?
No -- this technique seems to be fine (for the Primary GPT)
It seems strange to me that you only change primary GPT partition
without taking care of the secondary (backup) one.
It seems that the device operates correctly with or without the Backup
GPT, and it doesn't seem to matter if they are the same or not.
Thus, we have gone back and forth on this one - should we automatically
update the Backup GPT whenever the Primary GPT is updated, or should
there be a second step (possibly a fastboot oem command) to update the
Backup GPT... (currently, we are proposing the latter)
What would you suggest?
From my experience when you export your eMMC to Host PC via UMS, host's
PC tools will complain about mismatch in the GPT tables.
( I have never done this - what tools are you using? Could you provide
instructions for me to try? Thanks! )
Moreover, I would suggest transactional update of GPT by checking GPT
image CRC before writing. In this way you can always perform recovery if
needed.
This is a good idea - I'll look into it - Thanks!
Thanks, Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A23 u-boot with SPL / dram init available in my personal git repo
Hi, On 08-12-14 15:28, Chen-Yu Tsai wrote: On Mon, Dec 8, 2014 at 4:27 AM, Hans de Goede hdego...@redhat.com wrote: Hi, This is still a bit rough around the edges, I'll clean it up as time permits and then post it upstream. In the mean time people interested can find $subject here: https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-wip Hopefully I'll get around to testing this. BTW, what tablet do you have? I've an Ippo q8h v1.2, there are at least 2 differences from the v5 you've. The dram clk speed and zq value are different, and the wifi is different. The wifi does not matter for u-boot, but does mean we need separate dtb files for the 2. My u-boot sunxi-wip branch has a defconfig for the v1.2, you should be able to copy that over to the v5 defconfig, adjust dram clk and zq values with the ones from the v5 fix, change v1.2 to v5 in the CONFIG_FDTFILE setting and thats it. Let me know if this works, then I'll also include an update for the v5 defconfig to enable the SPL when I send this upstream. ChenYu, this also has a mmc fix which you may find interesting, it may explain some of the problems with mmc you've been having on both the A80 board, as well as the A31 dev board you've. Yes. With that fix my Hummingbird A31 boots properly without raising DCDC1 to 3.3V. Thanks! I'll send the defconfig out later. Good, so I guess this means that DCDC1 should be 3V for your board, since that is what the factory firmware uses, right ? I guess it is time to make DCDC1 voltage configurable. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3
Lukasz Majewski l.majew...@majess.pl writes: [...] On 28 November 2014 at 06:46, Lukasz Majewski l.majew...@majess.pl wrote: Hello Javier, Hello Lukasz, On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majew...@majess.pl wrote: I have yet to take him up on that offer though, but it sounds like a good way forward. The current layout really isn't practical. It indeed isn't very practical, but this is what you received from HardKernel when you buy XU3 board. Of course you can grab their sources, modify the layout, prepare u-boot's SPL and send it to them to be signed. However, it is not the way the normal user do things. He or she would like to replace standard (and outdated) HardKernel u-boot on their SD card and go forward with booting kernel. I agree with Sjoed that normal users don't replace the low-level components that are provided by the board vendor. After all you can boot a mainline kernel using the vendor u-boot, just append the DTB and create a uImage. The practical reason why someone would want to replace the vendor u-boot is to have more features but is very hard to do if there is a constraint in the maximum u-boot image size (even harder if the maximum is such small like in the XU3). I agree that 328 KiB size for u-boot is a constraint. I don't know HardKernel's justification for this. For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence we are obliged to have u-boot size smaller than 328 KiB. It is challenging but for sure doable. It is doable but I don't see why the default BL2 _must_ be used. For practical/pragmatic reasons: 1. It is difficult to have signed BL2 - each time we need to ask HardKernel for signing it. It is impractical and hampers usage of mainline SPL (BL2) with XU3. 2. All the documentation on the HardKernel wiki site refers to the default BL2. 3. We will have new BL2, which source code is based on 2012.07 mainline u-boot. 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner or latter. A user that wants to replace the kernel or u-boot is already tech-savy and can for sure replace the BL2 as well if it's publicly available. Sorry, but I'm a bit sceptical about updating such low level code. Bad things do happen. Maybe hardkernel folks can even make the modified BL2 available on their website and the link added in the comment explaining the layout? We would then require HardKernel to: 1. Provide updated BL2.img 2. Update their wiki to reflect the new BL2. Also, it is an artificial constraint after all and can be easily modified. In fact I think we should push hardkernel to change that layout by default and use a BL2/SPL that has more sensible size for the u-boot binary even if they don't need it for their vendor u-boot which seems to be quite small. I totally agree. I'd like to propose a following plan: 1. Accept Hyungwon's patches to have XU3 u-boot 328 KiB (with link to default BL2) to have XU3 support in place (and treat it as a starting point) 2. If u-boot's size less than 328 KiB is _really_ a problem to somebody then ask hardkernel to change BL2 or: - modify their sources to change the layout (I regard this as a quick hack solution) - with a lot of pain develop BL2/SPL (by whom?) which base on newest mainline (then for each test hardkernel must sign the binary). My 2p worth... The current Hardkernel BL1 looks broken to me - it is just too old. +1 FWIW, the XU3 firmware is broken in other ways as well which have a major impact on power management. First, with mainline kernels using MCPM, only 6 of 8 CPUs come online. However, even with that fixed[1], it turns out that the kernel can't properly manage CCI due to secure firmware[2], which means that MCPM (multi-cluster power management) can't work, and thus the low-power cluster-idle states can't work, the big.LITTLE switcher cannot work, and the ongoing work on energy-aware scheduling will not be useful on this platform. Anyone know what are the chances of getting a non-secure version of the firmware for this platform. The Samsung Chromebook2 with basically the same SoC (5800 compared to the 5422 on the XU3) ships with non-secure firmware so all of the above mentioned features are working just fine. I'm working on getting these same features working on the XU3, but this broken firmware as brought a halt to any real progress. Kevin [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305790.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306480.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support for Seagate BlackArmor NAS220
Add support for Seagate BlackArmor NAS220 Signed-off-by: Evgeni Dobrev evg...@studio-punkt.com --- arch/arm/cpu/arm926ejs/kirkwood/Kconfig |4 + board/Seagate/nas220/Kconfig| 12 +++ board/Seagate/nas220/MAINTAINERS|6 ++ board/Seagate/nas220/Makefile |7 ++ board/Seagate/nas220/kwbimage.cfg | 151 +++ board/Seagate/nas220/nas220.c | 118 ++ configs/nas220_defconfig|3 + include/configs/nas220.h| 168 +++ 8 files changed, 469 insertions(+) create mode 100644 board/Seagate/nas220/Kconfig create mode 100644 board/Seagate/nas220/MAINTAINERS create mode 100644 board/Seagate/nas220/Makefile create mode 100644 board/Seagate/nas220/kwbimage.cfg create mode 100644 board/Seagate/nas220/nas220.c create mode 100644 configs/nas220_defconfig create mode 100644 include/configs/nas220.h diff --git a/arch/arm/cpu/arm926ejs/kirkwood/Kconfig b/arch/arm/cpu/arm926ejs/kirkwood/Kconfig index 6c037a1..45c6687 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/Kconfig +++ b/arch/arm/cpu/arm926ejs/kirkwood/Kconfig @@ -57,6 +57,9 @@ config TARGET_DOCKSTAR config TARGET_GOFLEXHOME bool GoFlex Home Board +config TARGET_NAS220 + bool BlackArmor NAS220 + endchoice config SYS_SOC @@ -80,5 +83,6 @@ source board/LaCie/wireless_space/Kconfig source board/raidsonic/ib62x0/Kconfig source board/Seagate/dockstar/Kconfig source board/Seagate/goflexhome/Kconfig +source board/Seagate/nas220/Kconfig endif diff --git a/board/Seagate/nas220/Kconfig b/board/Seagate/nas220/Kconfig new file mode 100644 index 000..0fa529c --- /dev/null +++ b/board/Seagate/nas220/Kconfig @@ -0,0 +1,12 @@ +if TARGET_NAS220 + +config SYS_BOARD + default nas220 + +config SYS_VENDOR + default Seagate + +config SYS_CONFIG_NAME + default nas220 + +endif diff --git a/board/Seagate/nas220/MAINTAINERS b/board/Seagate/nas220/MAINTAINERS new file mode 100644 index 000..f2df7ea --- /dev/null +++ b/board/Seagate/nas220/MAINTAINERS @@ -0,0 +1,6 @@ +NAS220 BOARD +M: Evgeni Dobrev evg...@studio-punkt.com +S: Maintained +F: board/Seagate/nas220/ +F: include/configs/nas220.h +F: configs/nas220_defconfig diff --git a/board/Seagate/nas220/Makefile b/board/Seagate/nas220/Makefile new file mode 100644 index 000..9de73e6 --- /dev/null +++ b/board/Seagate/nas220/Makefile @@ -0,0 +1,7 @@ +# +# Copyright (C) 2014 Evgeni Dobrev evg...@studio-punkt.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := nas220.o diff --git a/board/Seagate/nas220/kwbimage.cfg b/board/Seagate/nas220/kwbimage.cfg new file mode 100644 index 000..dbbfb9c --- /dev/null +++ b/board/Seagate/nas220/kwbimage.cfg @@ -0,0 +1,151 @@ +# +# Copyright (C) 2014 Evgeni Dobrev evg...@studio-punkt.com +# +# Based on sheevaplug/kwbimage.cfg originally written by +# Prafulla Wadaskar prafu...@marvell.com +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# +# SPDX-License-Identifier: GPL-2.0+ +# +# Refer doc/README.kwbimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM nand +NAND_ECC_MODE default +NAND_PAGE_SIZE 0x0200 + +# SOC registers configuration using bootrom header extension +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed + +# Configure RGMII-0 interface pad voltage to 1.8V +DATA 0xFFD100e0 0x1b1b1b9b + +#Dram initalization for SINGLE x16 CL=5 @ 400MHz +DATA 0xFFD01400 0x43000618 # DDR Configuration register +# bit13-0: 0xa00 (2560 DDR2 clks refresh rate) +# bit23-14: zero +# bit24: 1= enable exit self refresh mode on DDR access +# bit25: 1 required +# bit29-26: zero +# bit31-30: 01 + +DATA 0xFFD01404 0x35143000 # DDR Controller Control Low +# bit 4:0=addr/cmd in smame cycle +# bit 5:0=clk is driven during self refresh, we don't care for APX +# bit 6:0=use recommended falling edge of clk for addr/cmd +# bit14:0=input buffer always powered up +# bit18:1=cpu lock transaction enabled +# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0 +# bit27-24: 8= CL+3, STARTBURST sample stages, for freqs 400MHz, unbuffered DIMM +# bit30-28: 3 required +# bit31:0=no additional STARTBURST delay + +DATA 0xFFD01408 0x11012227 # DDR Timing (Low) (active cycles value +1) +# bit7-4: TRCD +# bit11- 8: TRP +# bit15-12: TWR +# bit19-16: TWTR +# bit20:TRAS msb +# bit23-21: 0x0 +# bit27-24: TRRD +# bit31-28: TRTP + +DATA 0xFFD0140C 0x0819 # DDR Timing (High) +# bit6-0: TRFC +# bit8-7: TR2R +# bit10-9: TR2W +# bit12-11: TW2W +# bit31-13: zero required + + +DATA 0xFFD01410 0x000d # DDR Address Control +# bit1-0: 00, Cs0width=x8 +# bit3-2: 11, Cs0size=1Gb +# bit5-4: 00, Cs1width=nonexistent +# bit7-6: 00, Cs1size =nonexistent +# bit9-8: 00, Cs2width=nonexistent +# bit11-10: 00, Cs2size
Re: [U-Boot] Link error for arm targets
On Mon, 2014-12-08 at 10:13 -0800, York Sun wrote: Guys, I need some help to understand the link error introduced by commit d455d8789d5b35a39a0a179b3af4b423db13bfdd fs: API changes enabling extra parameter to return size of type loff_t I don't see anything wrong with this commit, but some of my targets don't link after this commit. The error I got for compiling ls1021aqds_nor is: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(bpabi.o) /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_divdi3.o) /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_udivdi3.o) make[2]: *** [u-boot] Error 1 make[1]: *** [__build_one_by_one] Error 2 make: *** [sub-make] Error 2 I don't know much about this error. Can someone help? I should have caught this error earlier but a bad escape flaw in my Jenkins script skipped all the ARM targets I normally test. I hope I didn't let in any patch with compiling errors (finger crossed). USE_PRIVATE_LIBGCC=yes -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5] mpc85xx: inhibit qman and bman portals by default
Not all portals might be managed and therefore visible.
Set the isdr register so that the corresponding isr register
won't be set. This is required when supporting power management.
Signed-off-by: Jeffrey Ladouceur jeffrey.ladouc...@freescale.com
---
The following dependent patches should be applied first:
http://patchwork.ozlabs.org/patch/403532
http://patchwork.ozlabs.org/patch/403533
http://patchwork.ozlabs.org/patch/403540
http://patchwork.ozlabs.org/patch/403534
http://patchwork.ozlabs.org/patch/403535
http://patchwork.ozlabs.org/patch/403538
http://patchwork.ozlabs.org/patch/403536
http://patchwork.ozlabs.org/patch/403539
Changes in v5:
- Qman portals also require their isdr register to be set in order to support
power management (sleep, deepsleep). Otherwise QMan will appear to not be idle
if all portals are not managed by the OS.
Changes in v4:
- The assertion that reading from portal reserved memory would return zero
is incorrect. Therefore modify code to depend on specified number of
portals in board config file
Changes in v3:
- Update subject title to be consistent
Changes in v2:
- Removed P1023RDS as it is no longer supported.
arch/powerpc/cpu/mpc85xx/portals.c | 43 +++
include/configs/B4860QDS.h | 16 +
include/configs/P1023RDB.h | 16 +
include/configs/P2041RDB.h | 16 +
include/configs/T102xQDS.h | 16 +
include/configs/T102xRDB.h | 16 +
include/configs/T1040QDS.h | 16 +
include/configs/T104xRDB.h | 16 +
include/configs/T208xQDS.h | 16 +
include/configs/T208xRDB.h | 16 +
include/configs/T4240EMU.h | 16 +
include/configs/T4240QDS.h | 16 +
include/configs/T4240RDB.h | 16 +
include/configs/corenet_ds.h| 16 +
include/configs/km/kmp204x-common.h | 16 +
15 files changed, 267 insertions(+)
diff --git a/arch/powerpc/cpu/mpc85xx/portals.c
b/arch/powerpc/cpu/mpc85xx/portals.c
index 98815f8..ec3b292 100644
--- a/arch/powerpc/cpu/mpc85xx/portals.c
+++ b/arch/powerpc/cpu/mpc85xx/portals.c
@@ -14,9 +14,46 @@
#include asm/fsl_portals.h
#include asm/fsl_liodn.h
+#define MAX_BPORTALS (CONFIG_SYS_BMAN_CINH_SIZE / CONFIG_SYS_BMAN_SP_CINH_SIZE)
+#define MAX_QPORTALS (CONFIG_SYS_QMAN_CINH_SIZE / CONFIG_SYS_QMAN_SP_CINH_SIZE)
+static void inhibit_portals(void __iomem *addr, int max_portals,
+ int arch_max_portals, int portal_cinh_size)
+{
+ uint32_t val;
+ int i;
+
+ /* arch_max_portals is the maximum based on memory size. This includes
+* the reserved memory in the SoC. max_portals the number of physical
+* portals in the SoC */
+ if (max_portals arch_max_portals) {
+ printf(ERROR: portal config error\n);
+ max_portals = arch_max_portals;
+ }
+
+ for (i = 0; i max_portals; i++) {
+ out_be32(addr, -1);
+ val = in_be32(addr);
+ if (!val) {
+ printf(ERROR: Stopped after %d portals\n, i);
+ goto done;
+ }
+ addr += portal_cinh_size;
+ }
+#ifdef DEBUG
+ printf(Cleared %d portals\n, i);
+#endif
+done:
+
+ return;
+}
+
void setup_portals(void)
{
ccsr_qman_t *qman = (void *)CONFIG_SYS_FSL_QMAN_ADDR;
+ void __iomem *bpaddr = (void *)CONFIG_SYS_BMAN_CINH_BASE +
+ CONFIG_SYS_BMAN_SWP_ISDR_REG;
+ void __iomem *qpaddr = (void *)CONFIG_SYS_QMAN_CINH_BASE +
+ CONFIG_SYS_QMAN_SWP_ISDR_REG;
#ifdef CONFIG_FSL_CORENET
int i;
@@ -38,6 +75,12 @@ void setup_portals(void)
out_be32(qman-qcsp_bare, (u32)(CONFIG_SYS_QMAN_MEM_PHYS 32));
#endif
out_be32(qman-qcsp_bar, (u32)CONFIG_SYS_QMAN_MEM_PHYS);
+
+ /* Change default state of BMan ISDR portals to all 1s */
+ inhibit_portals(bpaddr, CONFIG_SYS_BMAN_NUM_PORTALS, MAX_BPORTALS,
+ CONFIG_SYS_BMAN_SP_CINH_SIZE);
+ inhibit_portals(qpaddr, CONFIG_SYS_QMAN_NUM_PORTALS, MAX_QPORTALS,
+ CONFIG_SYS_QMAN_SP_CINH_SIZE);
}
/* Update portal containter to match LAW setup of portal in phy map */
diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h
index dc1a9bc..4256488 100644
--- a/include/configs/B4860QDS.h
+++ b/include/configs/B4860QDS.h
@@ -641,6 +641,14 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_SYS_BMAN_MEM_PHYS CONFIG_SYS_BMAN_MEM_BASE
#endif
#define CONFIG_SYS_BMAN_MEM_SIZE 0x0200
+#define CONFIG_SYS_BMAN_SP_CENA_SIZE 0x4000
+#define CONFIG_SYS_BMAN_SP_CINH_SIZE 0x1000
+#define CONFIG_SYS_BMAN_CENA_BASE CONFIG_SYS_BMAN_MEM_BASE
+#define
[U-Boot] [PATCH v4] mpc85xx: inhibit bman portals by default
Not all portals might be managed and therefore visible.
Set the isdr register so that the corresponding isr register
won't be set. This is needed for deepsleep.
Signed-off-by: Jeffrey Ladouceur jeffrey.ladouc...@freescale.com
---
The following dependent patches should be applied first:
http://patchwork.ozlabs.org/patch/403532
http://patchwork.ozlabs.org/patch/403533
http://patchwork.ozlabs.org/patch/403540
http://patchwork.ozlabs.org/patch/403534
http://patchwork.ozlabs.org/patch/403535
http://patchwork.ozlabs.org/patch/403538
http://patchwork.ozlabs.org/patch/403536
http://patchwork.ozlabs.org/patch/403539
Changes in v4:
- The assertion that reading from portal reserved memory would return zero
is incorrect. Therefore modify code to depend on specified number of
portals in board config file
Changes in v3:
- Update subject title to be consistent
Changes in v2:
- Removed P1023RDS as it is no longer supported.
arch/powerpc/cpu/mpc85xx/portals.c | 36 +++
include/configs/B4860QDS.h |8
include/configs/P1023RDB.h |8
include/configs/P2041RDB.h |8
include/configs/T102xQDS.h |8
include/configs/T102xRDB.h |8
include/configs/T1040QDS.h |8
include/configs/T104xRDB.h |8
include/configs/T208xQDS.h |8
include/configs/T208xRDB.h |8
include/configs/T4240EMU.h |8
include/configs/T4240QDS.h |8
include/configs/T4240RDB.h |8
include/configs/corenet_ds.h|8
include/configs/km/kmp204x-common.h |8
15 files changed, 148 insertions(+)
diff --git a/arch/powerpc/cpu/mpc85xx/portals.c
b/arch/powerpc/cpu/mpc85xx/portals.c
index 98815f8..2972865 100644
--- a/arch/powerpc/cpu/mpc85xx/portals.c
+++ b/arch/powerpc/cpu/mpc85xx/portals.c
@@ -14,6 +14,39 @@
#include asm/fsl_portals.h
#include asm/fsl_liodn.h
+#define MAX_PORTALS (CONFIG_SYS_BMAN_CINH_SIZE / CONFIG_SYS_BMAN_SP_CINH_SIZE)
+void inhibit_bman_portals(void)
+{
+ void __iomem *addr = (void *)CONFIG_SYS_BMAN_CINH_BASE +
+ CONFIG_SYS_BMAN_SWP_ISDR_REG;
+ uint32_t val;
+ int i, max_portals = CONFIG_SYS_BMAN_NUM_PORTALS;
+
+ /* MAX_PORTALS is the maximum based on memory size. This includes the
+* reserved memory in the SoC. CONFIG_SYS_BMAN_NUM_PORTALS is the
+* number of physical portals in the SoC */
+ if (CONFIG_SYS_BMAN_NUM_PORTALS MAX_PORTALS) {
+ printf(ERROR: BMAN portal config error\n);
+ max_portals = MAX_PORTALS;
+ }
+
+ for (i = 0; i max_portals; i++) {
+ out_be32(addr, -1);
+ val = in_be32(addr);
+ if (!val) {
+ printf(ERROR: Stopped after %d BMan portals\n, i);
+ goto done;
+ }
+ addr += CONFIG_SYS_BMAN_SP_CINH_SIZE;
+ }
+#ifdef DEBUG
+ printf(Cleared %d Bman portals\n, i);
+#endif
+done:
+
+ return;
+}
+
void setup_portals(void)
{
ccsr_qman_t *qman = (void *)CONFIG_SYS_FSL_QMAN_ADDR;
@@ -38,6 +71,9 @@ void setup_portals(void)
out_be32(qman-qcsp_bare, (u32)(CONFIG_SYS_QMAN_MEM_PHYS 32));
#endif
out_be32(qman-qcsp_bar, (u32)CONFIG_SYS_QMAN_MEM_PHYS);
+
+ /* Change default state of BMan ISDR portals to all 1s */
+ inhibit_bman_portals();
}
/* Update portal containter to match LAW setup of portal in phy map */
diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h
index dc1a9bc..31f1d3f 100644
--- a/include/configs/B4860QDS.h
+++ b/include/configs/B4860QDS.h
@@ -641,6 +641,14 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_SYS_BMAN_MEM_PHYS CONFIG_SYS_BMAN_MEM_BASE
#endif
#define CONFIG_SYS_BMAN_MEM_SIZE 0x0200
+#define CONFIG_SYS_BMAN_SP_CENA_SIZE 0x4000
+#define CONFIG_SYS_BMAN_SP_CINH_SIZE 0x1000
+#define CONFIG_SYS_BMAN_CENA_BASE CONFIG_SYS_BMAN_MEM_BASE
+#define CONFIG_SYS_BMAN_CENA_SIZE (CONFIG_SYS_BMAN_MEM_SIZE 1)
+#define CONFIG_SYS_BMAN_CINH_BASE (CONFIG_SYS_BMAN_MEM_BASE + \
+ CONFIG_SYS_BMAN_CENA_SIZE)
+#define CONFIG_SYS_BMAN_CINH_SIZE (CONFIG_SYS_BMAN_MEM_SIZE 1)
+#define CONFIG_SYS_BMAN_SWP_ISDR_REG 0xE08
#define CONFIG_SYS_QMAN_NUM_PORTALS25
#define CONFIG_SYS_QMAN_MEM_BASE 0xf600
#ifdef CONFIG_PHYS_64BIT
diff --git a/include/configs/P1023RDB.h b/include/configs/P1023RDB.h
index 6b29add..053113f 100644
--- a/include/configs/P1023RDB.h
+++ b/include/configs/P1023RDB.h
@@ -347,6 +347,14 @@ extern unsigned long get_clock_freq(void);
#define CONFIG_SYS_BMAN_MEM_BASE 0xff20
#define CONFIG_SYS_BMAN_MEM_PHYS CONFIG_SYS_BMAN_MEM_BASE
#define CONFIG_SYS_BMAN_MEM_SIZE 0x0020
+#define
Re: [U-Boot] Link error for arm targets
On 12/08/2014 11:31 AM, Scott Wood wrote: On Mon, 2014-12-08 at 10:13 -0800, York Sun wrote: Guys, I need some help to understand the link error introduced by commit d455d8789d5b35a39a0a179b3af4b423db13bfdd fs: API changes enabling extra parameter to return size of type loff_t I don't see anything wrong with this commit, but some of my targets don't link after this commit. The error I got for compiling ls1021aqds_nor is: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(bpabi.o) /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_divdi3.o) /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/libgcc.a(_udivdi3.o) make[2]: *** [u-boot] Error 1 make[1]: *** [__build_one_by_one] Error 2 make: *** [sub-make] Error 2 I don't know much about this error. Can someone help? I should have caught this error earlier but a bad escape flaw in my Jenkins script skipped all the ARM targets I normally test. I hope I didn't let in any patch with compiling errors (finger crossed). USE_PRIVATE_LIBGCC=yes Thanks. Bill Pringlemeir points me a patch later committed. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 9/9] arm: ls102xa: Add NAND boot support for LS1021AQDS board
On 12/06/2014 06:46 AM, Alison Wang wrote: This patch adds NAND boot support for LS1021AQDS board. SPL framework is used. PBL initialize the internal RAM and copy SPL to it, then SPL initialize DDR using SPD and copy u-boot from NAND flash to DDR, finally SPL transfer control to u-boot. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: Use some defines instead of the magic numbers. v3: New file. arch/arm/include/asm/arch-ls102xa/config.h| 1 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 5 ++ board/freescale/ls1021aqds/MAINTAINERS| 1 + board/freescale/ls1021aqds/ls1021aqds.c | 16 + board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg | 7 +++ configs/ls1021aqds_nand_defconfig | 4 ++ drivers/mtd/nand/fsl_ifc_spl.c| 10 include/configs/ls1021aqds.h | 72 +++ 8 files changed, 116 insertions(+) create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg create mode 100644 configs/ls1021aqds_nand_defconfig diff --git a/arch/arm/include/asm/arch-ls102xa/config.h b/arch/arm/include/asm/arch-ls102xa/config.h index ba86eea..8318c91 100644 --- a/arch/arm/include/asm/arch-ls102xa/config.h +++ b/arch/arm/include/asm/arch-ls102xa/config.h @@ -13,6 +13,7 @@ #define OCRAM_SIZE 0x0002 #define CONFIG_SYS_IMMR 0x0100 +#define CONFIG_SYS_DCSRBAR 0x2020 This line is conflict with this patch http://patchwork.ozlabs.org/patch/402218/. Which one is correct? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc/gitmail-rc: Update m68k alias
On Thu, Dec 04, 2014 at 11:27:29AM -0500, Tom Rini wrote: Signed-off-by: Tom Rini tr...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Fri, Dec 05, 2014 at 09:53:49AM -0500, Tom Rini wrote: Hello myself, The following changes since commit f0c6e1c31b94f193047619b6adf67c2d792b659e: Revert image-fdt: boot_get_fdt() return value when no DTB exists (2014-12-03 13:19:34 -0500) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 956a8bae537974673e126f67a227355f27e48ec6: ns16550.c: Fix for ns16550 driver hanging on OMAP4 (2014-12-04 21:28:32 -0500) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [i2c] Pull request
On Mon, Dec 08, 2014 at 07:29:16AM +0100, Heiko Schocher wrote: Hello Tom, please pull from u-boot-i2c.git The following changes since commit 97cdf64026c7d749dd7a5c0dbaba7a60a7292ac9: Merge branch 'sandbox' of git://git.denx.de/u-boot-x86 (2014-12-04 09:24:05 -0500) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to f4ed36964a7ab4e729d62e96dac15a674dcc2668: i2c: Correct spelling error (2014-12-08 07:27:22 +0100) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] MMC SD fs boot partition config coding style and proper description
On Sat, Nov 08, 2014 at 11:14:55PM +0100, Paul Kocialkowski wrote: CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION ought to be called CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to keep it consistent with other config options such as: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR. In addition, it is not related to raw mode booting but to fs mode instead. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx master
On Fri, Dec 05, 2014 at 08:10:01AM -0800, York Sun wrote: Tom, The following changes since commit 38cd8c4253013ccdd4052ee021f6066fe9a52551: Merge branch 'master' of git://git.denx.de/u-boot-mips (2014-11-27 10:49:38 -0500) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to af7219de2c66b64ddae0348b3d3fa5072d800dd2: powerpc/hydra: fix judging condition of RGMII selection (2014-12-05 08:06:17 -0800) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/master
On Fri, Dec 05, 2014 at 11:15:17AM +0900, Nobuhiro Iwamatsu wrote: Dear Tom Rini. Please pull u-boot-sh master branch. The following changes since commit 97cdf64026c7d749dd7a5c0dbaba7a60a7292ac9: Merge branch 'sandbox' of git://git.denx.de/u-boot-x86 (2014-12-04 09:24:05 -0500) are available in the git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to 9675f6107725a1002858df2246ebfb0cd3082e76: mmc: sh_mmcif: Add support rmobile (2014-12-05 11:16:22 +0900) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] get_maintainer.pl: fix source tree detection
On Sun, Nov 16, 2014 at 08:30:11PM +0100, Daniel Schwierzeck wrote: get_maintainer.pl always fails with following message: ./scripts/get_maintainer.pl: The current directory does not appear to be a linux kernel source tree. This was caused by commit: commit 548b310c68ac99a0330d8b56c797c09ff0742d1e Author: Masahiro Yamada yamad...@jp.panasonic.com Date: Thu Oct 30 15:50:15 2014 +0900 Remove the CREDITS file This file is not maintained these days. We use MAINTAINERS for the maintainership of the supported boards. For dead boards, we have some clues in doc/README.scrapyard and also imperishable history in git-log. Remove CREDITS from source tree detection to fix this. Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fix console functions for U-Boot API
On Thu, Nov 13, 2014 at 08:51:12PM -0700, Simon Glass wrote: Commit 709ea54 made a subtle change to the way the U-Boot API jump table is set up. So at present putc(), getc(), tstc() and puts() do not work correctly from functions that use the U-Boot API. Previously these were set to the stdio functions, but these now take a parameter specifying which stdio device to use. Instead, we should change them to use the global functions which do not have a parameter. This is a slight change in behaviour. The functions will now output to all selected stdio devices - for example putc() will output a character to all devices selected by stdout. However in most cases there is only one, and it isn't necessarily incorrect behaviour anyway. The API version is not changed since it is compatible with what was there before. Reported-by: Martin Dorwig dor...@tektronik.com Signed-off-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Tue, Nov 18, 2014 at 10:44:46AM +0100, Guillaume GARDET wrote: In SPL MMC, boot modes are exclusive. So, if MMCSD_MODE_RAW fails, the board hangs. This patch allows to try MMCSD_MODE_FS then, if available. It has been tested on a pandaboard (rev. A3). Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MAINTAINERS: add me as a maintainer of UBI
On Tue, Nov 18, 2014 at 09:08:45AM +0100, Heiko Schocher wrote: Add me for UBI custodian. Signed-off-by: Heiko Schocher h...@denx.de Acked-by: Stefan Roese s...@denx.de Acked-by: Kyungmin Park kyungmin.p...@samsung.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: bootp: as CONFIG_BOOTP_SERVERIP is defined, keep bootfile not changed
On Tue, Nov 18, 2014 at 01:07:08PM +0800, Wu, Josh wrote: Currenly when CONFIG_BOOTP_SERVERIP is defined, the SERVERIP is not changed when receive the BOOTP packet. But BOOTFILE is changed via BOOTP packet. As we will load the BOOTFILE from SERVERIP, if the BOOTFILE is modified by bootp packet but SERVERIP is not, that is not make sense. This patch make SERVERIP and BOOTFILE be consistent. If we define the CONFIG_BOOTP_SERVERIP, then SERVERIP and BOOTFILE will not changed by BOOTP packet. Only IP address is changed. Signed-off-by: Josh Wu josh...@atmel.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/2] ARM: rpi: support an environment
On Wed, Nov 19, 2014 at 08:41:04PM -0700, Stephen Warren wrote: Enable ENV_IS_IN_FAT so that the environment can be stored persistently. It's stored in the FAT partition that the RPi firmware requires. On most RPis, this is on the SD card (which must be present in order for the system to boot). On the CM this is on the built-in eMMC device. Since we now have a persistent environment, there's no need to load uEnv.txt at boot; we only did that to work around the lack of persistent environment. Signed-off-by: Stephen Warren swar...@wwwdotorg.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git-mailrc: fix mips alias
On Wed, Nov 19, 2014 at 08:20:11PM +0100, Daniel Schwierzeck wrote: Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] cmd_fuse: return CMD_RET_FAILURE on error
On Thu, Nov 20, 2014 at 09:27:42AM +0100, Hector Palacios wrote: Fuse drivers, like the mxs_ocotp.c, may return negative error codes but the commands are only allowed to return CMD_RET_* enum values to the shell, otherwise the following error appears: exit not allowed from main input shell. Signed-off-by: Hector Palacios hector.palac...@digi.com Reviewed-by: Benoît Thébaudeau benoit.thebaudeau@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] powerpc: lwmon5: remove redundant CONFIG_SPL_* defines
On Fri, Nov 21, 2014 at 11:50:08AM +0900, Masahiro Yamada wrote: The CPU directory of this board is arch/powerpc/cpu/ppc4xx. Without the CONFIG_SPL_START_S_PATH and CONFIG_SPL_LDSCRIPT defines, the same start.o and u-boot-spl.lds are selected by default. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Wolfgang Denk w...@denx.de Acked-by: Stefan Roese s...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/2] ARM: rpi: rename rpi_b to rpi
On Wed, Nov 19, 2014 at 08:41:03PM -0700, Stephen Warren wrote: The U-Boot port runs on a variety of RPi models, not just the B. So, rename the port to something slightly more generic. Signed-off-by: Stephen Warren swar...@wwwdotorg.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git-mailrc: fix mips alias
On Wed, Nov 19, 2014 at 08:20:11PM +0100, Daniel Schwierzeck wrote: Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] powerpc: mpc8xx: remove hermes board support
On Fri, Nov 21, 2014 at 11:26:11AM +0900, Masahiro Yamada wrote: This board sprinkles #ifdef(CONFIG_HERMES) over various global files such as include/common.h, common/board_r.c, common/cmd_bdinfo.c. Let's zap such an ill-behaved board. It has not been converted to generic board yet and mpc8xx is old enough. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Wolfgang Denk w...@denx.de Acked-by: Wolfgang Denk w...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,U-Boot] ARM: rpi_b: detect board revision
On Tue, Nov 18, 2014 at 09:40:21PM -0700, Stephen Warren wrote: Detect the board revision early during boot, and print the decoded model name. Eventually, this information can be used for tasks such as: - Allowing/preventing USB device mode; some models have a USB device on- board so only host mode makes sense. Others connect the SoC directly to the USB connector, so device-mode might make sense. - The on-board USB hub/Ethernet requires different GPIOs to enable it, although luckily the default appears to be fine so far. - The compute module contains an on-board eMMC device, so we could store the environment there. Other models use an SD card and so don't support saving the environment (unless we store it in a file on the FAT boot partition...) Set $fdtfile based on this information. At present, the mainline Linux kernel doesn't contain a separate DTB for most models, but I hope that will change soon. Signed-off-by: Stephen Warren swar...@wwwdotorg.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/3] imx6: remove redudant CONFIG_SPL_START_S_PATH define
On Fri, Nov 21, 2014 at 11:50:10AM +0900, Masahiro Yamada wrote: The CPU directory of IMX6 is arch/arm/cpu/armv7, so setting CONFIG_SPL_START_S_PATH to arch/arm/cpu/armv7 is totally redundant. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Stefano Babic sba...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] powerpc: a3m071: remove redundant CONFIG_SPL_* defines
On Fri, Nov 21, 2014 at 11:50:09AM +0900, Masahiro Yamada wrote: The CPU directory of this board is arch/powerpc/cpu/mpc5xxx. Without the CONFIG_SPL_START_S_PATH and CONFIG_SPL_LDSCRIPT defines, the same start.o and u-boot-spl.lds are selected by default. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Stefan Roese s...@denx.de Acked-by: Stefan Roese s...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/5] serial: pl01x: pass pl01x_type to set baudrate
On Fri, Nov 21, 2014 at 10:34:19AM -0800, Vikas Manocha wrote: Although we were checking the pl01x type, seems like PL010 type was being passed by mistake. Signed-off-by: Vikas Manocha vikas.mano...@st.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/5] serial: pl01x: fix pl011 baud rate configuration
On Fri, Nov 21, 2014 at 10:34:20AM -0800, Vikas Manocha wrote: UART_IBRD, UART_FBRD, and UART_LCR_H form a single 30-bit wide register which is updated on a single write strobe generated by a UART_LCR_H write. So, to internally update the content of UART_IBRD or UART_FBRD, a write to UART_LCR_H must always be performed at the end. Signed-off-by: Vikas Manocha vikas.mano...@st.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 5/5] serial: pl01x: avoid pl01x type check two times
On Fri, Nov 21, 2014 at 10:34:23AM -0800, Vikas Manocha wrote: Signed-off-by: Vikas Manocha vikas.mano...@st.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/5] serial: pl01x: disable as per type of pl01x
On Fri, Nov 21, 2014 at 10:34:22AM -0800, Vikas Manocha wrote: pl010 pl011 have different control register offsets, setting it as per the pl01x type. Signed-off-by: Vikas Manocha vikas.mano...@st.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/5] serial: pl01x: move all line control at same place
On Fri, Nov 21, 2014 at 10:34:21AM -0800, Vikas Manocha wrote: Receive line control uses same setting as transmit line control, also one lcrh write is effective for both baud rate receive line control internal update. Signed-off-by: Vikas Manocha vikas.mano...@st.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] Kbuild: introduce Makefile in arch/$ARCH/
On Fri, Nov 21, 2014 at 11:51:33PM +0100, Daniel Schwierzeck wrote: Introduce a Makefile under arch/$ARCH/ and include it in the top Makefile (similar to Linux kernel). This allows further refactoringi like moving architecture-specific code out of global makefiles, deprecating config variables (CPU, CPUDIR, SOC) or deprecating arch/$ARCH/config.mk. In contrary to Linux kernel, U-Boot defines the ARCH variable by Kconfig, thus the arch Makefile can only included conditionally after the top config.mk. Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com Acked-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add Alison Wang m68k custodian email/alias
On Tue, Nov 25, 2014 at 10:05:41AM +0100, ang...@sysam.it wrote: Signed-off-by: Angelo Dureghello ang...@sysam.it Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] Add custodians to the m68k subsystem.
On Mon, Nov 24, 2014 at 03:36:57PM +0100, ang...@sysam.it wrote: Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] blackfin: include linux/compiler.h rather than define __iomem
On Wed, Nov 26, 2014 at 04:02:54PM +0900, Masahiro Yamada wrote: The macro __iomem is defined in include/linux/compiler.h. Let's include it rather than double __iomem defines. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Sonic Zhang sonic@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] arm: bcm: update Cygnus and NSP board families
On Fri, Nov 21, 2014 at 01:29:51PM -0800, Steve Rae wrote: - updates to support Cygnus and NSP board families better - add functions so CONFIG_ARMV7_NONSEC can be enabled on Cygnus boards Signed-off-by: Steve Rae s...@broadcom.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Replace compiler.h with linux/compiler.h
On Wed, Nov 26, 2014 at 04:00:58PM +0900, Masahiro Yamada wrote: Including linux/compiler.h is enough for general use. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] linux/compat.h: remove redundant macro defines
On Wed, Nov 26, 2014 at 04:02:53PM +0900, Masahiro Yamada wrote: __user and __iomem are defined in include/linux/compiler.h. MAX_ERRNO is defined in include/linux/err.h. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined
On Thu, Nov 27, 2014 at 01:24:16PM -0800, Suriyan Ramasami wrote: The boot commands - bootz/bootm mandate a third argument which is the address to the FDT blob. In cases where this argument is not specified, boot fails with a message indicating a missing FDT. This causes non-FDT kernels to fail to boot. This patch allows both FDT and non-FDT kernels to boot by making the third parameter to the bootm/bootz optional. Signed-off-by: Suriyan Ramasami suriya...@gmail.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] lib: bzip2: move bzip2 files to lib/bzip2/ directory
On Fri, Nov 28, 2014 at 11:13:26AM +0900, Masahiro Yamada wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/3] libfdt: descend from lib/ to lib/libfdt/
On Fri, Nov 28, 2014 at 11:13:27AM +0900, Masahiro Yamada wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] kconfig: Fix warning ‘jump’ may be used uninitialized
On Sat, Nov 29, 2014 at 05:26:04PM +0900, Masahiro Yamada wrote: From: Peter Kümmel syntheti...@gmx.net Warning: In file included from scripts/kconfig/zconf.tab.c:2537:0: scripts/kconfig/menu.c: In function ‘get_symbol_str’: scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized] jump-offset = strlen(r-s); Simplifies the test logic because (head local) means (jump != 0) and makes GCC happy when checking if the jump pointer was initialized. Signed-off-by: Peter Kümmel syntheti...@gmx.net Signed-off-by: Michal Marek mma...@suse.cz [ imported from Linux Kernel, commit 2d5603060967 ] Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2015.01-rc3 released
Hey all, I've pushed v2015.01-rc3 out to the repository and tarballs should exist soon. So, we're nearing the end now, relatively speaking, so things should start getting quieter. I'd like everyone to please build their respective areas and make sure everything is building right. As always, if anything else is broken please speak up. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-uniphier (updated!)
On Tue, Dec 09, 2014 at 12:23:36AM +0900, Masahiro YAMADA wrote: Hi Tom, If it is not too late, please let me replace the PR I sent yesterday with this one. This includes one fixes. The following changes since commit 97cdf64026c7d749dd7a5c0dbaba7a60a7292ac9: Merge branch 'sandbox' of git://git.denx.de/u-boot-x86 (2014-12-04 09:24:05 -0500) are available in the git repository at: git://git.denx.de/u-boot-uniphier.git master for you to fetch changes up to 7a3620b24649663857d99e8ab73ec0b3bd60e50e: ARM: UniPhier: detect the number of flash banks at run-time (2014-12-09 00:08:33 +0900) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/3] libfdt: move CONFIG_OF_LIBFDT and CONFIG_FIT to lib/Makefile
On Fri, Nov 28, 2014 at 11:13:28AM +0900, Masahiro Yamada wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A23 u-boot with SPL / dram init available in my personal git repo
On Sun, Dec 07, 2014 at 09:27:27PM +0100, Hans de Goede wrote: Hi, This is still a bit rough around the edges, I'll clean it up as time permits and then post it upstream. In the mean time people interested can find $subject here: https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-wip ChenYu, this also has a mmc fix which you may find interesting, it may explain some of the problems with mmc you've been having on both the A80 board, as well as the A31 dev board you've. Wow, very cool, including PMIC support et al. Thanks a lot :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ti, am3517: errata 430973 workaround
Hi, A while ago [1], a RFC was posted to disable workaround for besides others, errata 430973. It is a bit unclear to me which revision actually need this workaround, but as suggested in [2] also enabling this workaround in Linux seem to make some weird problems go away in linux (signal 4, bad instruction, 11 segfaults etc). As said, I am a bit in doubt why this works. The board in question is a tam3517 derived one: cat /proc/cpuinfo Processor: ARMv7 Processor rev 7 (v7l) BogoMIPS: 397.57 Features: swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer: 0x41 CPU architecture: 7 CPU variant: 0x1 CPU part: 0xc08 CPU revision: 7 Which makes this a r1p7 I assume, and hence the workaround of linux, CONFIG_ARM_ERRATA_430973, This option enables the workaround for the 430973 Cortex-A8 (r1p0..r1p2) erratum, should not be needed it seems. On the other hand Andreas Bießman, wrote at [3] I have rev 20.0 from 13-Apr-10. The three mentioned errata should be fixed in r2p1. note, this mentions r2p1 not r1p2! Since I don't have access to ARM Core Cortex-A8 (AT400/AT401) errata, I cannot look this up. Hence the question, is u-boot wrong by enabling this workaround for a r1p7 revision or is the comment in the kernel flawed? (or am I missing something else..) If someone could shed some light on this it would be appreciated. Regards, Jeroen [1] http://lists.denx.de/pipermail/u-boot/2013-July/158377.html [2] http://lists.denx.de/pipermail/u-boot/2013-July/158404.html [3] http://lists.denx.de/pipermail/u-boot/2013-July/158386.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.01-rc3 released
Dear Tom, In message 20141208214410.GJ20704@bill-the-cat you wrote: I've pushed v2015.01-rc3 out to the repository and tarballs should exist soon. Tarball is on the FTP server. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Artificial Intelligence is the study of how to make real computers act like the ones in movies. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] exynos5250/arndale: Enable SATA/AHCI support.
Hi Ian,
On 8 December 2014 at 07:54, Ian Campbell ian.campb...@citrix.com wrote:
This is based on some old patches from the chromeos-v2011.12 branch of
http://git.chromium.org/chromiumos/third_party/u-boot.git by Taylor Hutt.
Specifically:
http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit;h=26f6c570b5deb37c52306920ae049203c68f014a
exynos: sata: on-board controller initialization
Signed-off-by: Taylor Hutt th...@chromium.org
http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit;h=d8cac5cf0b63df00d2d6ac7df814613e4b60b9d1
exynos: sata: Add sata_initialize() interface
Signed-off-by: Taylor Hutt th...@chromium.org
http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit;h=dd32462453d6328bc5770859d1b56501f7920d7d
exynos: sata: SATA self-configuration for when SATA device is enabled
Signed-off-by: Taylor Hutt th...@chromium.org
Thanks for cleaning this up and submitting it.
As well as rebasing there have been some significant changes.
- Drop support for smdk5250, which I don't own.
- Implement support for arndale, which I do.
- Since arndale has no need to frob a GPIO on SATA init drop the associated
code.
- Initialise via the existing scsi_init hook rather than introducing
sata_initialize, associated build system and include/configs/*.h changes.
- Use set/clrbits in a bunch of places
- Add some #defines for some magic numbers.
- Use samsung_get_base_* for peripheral base addresses and structs to
access individual registers
- Lots of coding style improvements (checkpatch.pl clean) and general cleanup
Before launching the OS reset the PHY, otherwise Linux cannot reliably
detect the disk.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Taylor Hutt th...@chromium.org
Cc: Simon Glass s...@chromium.org
---
Lots of changes in v2:
- Rebase to latest master branch.
- use samsung_get_base_* for sata phy
- use samsung_get_base_* for sata i2c
- use samsung_get_base_* for sata axi
- Lots of Coding Style improvements
- Drop unused mmio argument to phy init
- Move code controlling phy power to power.c
- Remove unused SCLK_SATA_FREQ
- Use #defines for SATA_GENERATIONN, less fickle than enum
- avoid non-existent BIT macro
- Use bool more consistently in a few places
- No uppercase variable names
- Use SPDX License + copyright
- Use arch_preboot_os to reset SATA controller, and do so more
thoroughly than in the previous HACK. It now appears to be reliable
in my testing.
---
arch/arm/cpu/armv7/exynos/Makefile | 4 +
arch/arm/cpu/armv7/exynos/power.c| 23 ++
arch/arm/cpu/armv7/exynos/sata.c | 412
+++
arch/arm/cpu/armv7/exynos/soc.c | 8 +
arch/arm/include/asm/arch-exynos/cpu.h | 15 ++
arch/arm/include/asm/arch-exynos/power.h | 4 +
arch/arm/include/asm/arch-exynos/sata.h | 13 +
arch/arm/lib/board.c | 1 +
board/samsung/arndale/arndale.c | 9 +
include/configs/arndale.h| 3 +
include/configs/exynos5-common.h | 18 ++
11 files changed, 510 insertions(+)
create mode 100644 arch/arm/cpu/armv7/exynos/sata.c
create mode 100644 arch/arm/include/asm/arch-exynos/sata.h
diff --git a/arch/arm/cpu/armv7/exynos/Makefile
b/arch/arm/cpu/armv7/exynos/Makefile
index e207bd6..c74a2d4 100644
--- a/arch/arm/cpu/armv7/exynos/Makefile
+++ b/arch/arm/cpu/armv7/exynos/Makefile
@@ -7,6 +7,10 @@
obj-y += clock.o power.o soc.o system.o pinmux.o tzpc.o
+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_EXYNOS5250_AHCI) += sata.o
+endif
+
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_EXYNOS5) += clock_init_exynos5.o
obj-$(CONFIG_EXYNOS5) += dmc_common.o dmc_init_ddr3.o
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 1520d64..8f36d10 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -37,6 +37,29 @@ void set_mipi_phy_ctrl(unsigned int dev_index, unsigned
int enable)
exynos4_mipi_phy_control(dev_index, enable);
}
+void exynos5_set_sata_phy_ctrl(unsigned int enable)
+{
+ struct exynos5_power *power =
+ (struct exynos5_power *)samsung_get_base_power();
+
+ if (enable) {
+ /* Enabling SATA_PHY */
+ setbits_le32(power-sata_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ } else {
+ /* Disabling SATA_PHY */
+ clrbits_le32(power-sata_phy_control,
+POWER_USB_HOST_PHY_CTRL_EN);
+ }
+}
+
+void set_sata_phy_ctrl(unsigned int enable)
+{
+ if (cpu_is_exynos5())
+ exynos5_set_sata_phy_ctrl(enable);
+}
+
+
void exynos5_set_usbhost_phy_ctrl(unsigned int enable)
{
struct exynos5_power *power =
diff --git a/arch/arm/cpu/armv7/exynos/sata.c
Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3
Hi Kevin, On 8 December 2014 at 10:58, Kevin Hilman khil...@kernel.org wrote: Lukasz Majewski l.majew...@majess.pl writes: [...] On 28 November 2014 at 06:46, Lukasz Majewski l.majew...@majess.pl wrote: Hello Javier, Hello Lukasz, On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majew...@majess.pl wrote: I have yet to take him up on that offer though, but it sounds like a good way forward. The current layout really isn't practical. It indeed isn't very practical, but this is what you received from HardKernel when you buy XU3 board. Of course you can grab their sources, modify the layout, prepare u-boot's SPL and send it to them to be signed. However, it is not the way the normal user do things. He or she would like to replace standard (and outdated) HardKernel u-boot on their SD card and go forward with booting kernel. I agree with Sjoed that normal users don't replace the low-level components that are provided by the board vendor. After all you can boot a mainline kernel using the vendor u-boot, just append the DTB and create a uImage. The practical reason why someone would want to replace the vendor u-boot is to have more features but is very hard to do if there is a constraint in the maximum u-boot image size (even harder if the maximum is such small like in the XU3). I agree that 328 KiB size for u-boot is a constraint. I don't know HardKernel's justification for this. For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence we are obliged to have u-boot size smaller than 328 KiB. It is challenging but for sure doable. It is doable but I don't see why the default BL2 _must_ be used. For practical/pragmatic reasons: 1. It is difficult to have signed BL2 - each time we need to ask HardKernel for signing it. It is impractical and hampers usage of mainline SPL (BL2) with XU3. 2. All the documentation on the HardKernel wiki site refers to the default BL2. 3. We will have new BL2, which source code is based on 2012.07 mainline u-boot. 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner or latter. A user that wants to replace the kernel or u-boot is already tech-savy and can for sure replace the BL2 as well if it's publicly available. Sorry, but I'm a bit sceptical about updating such low level code. Bad things do happen. Maybe hardkernel folks can even make the modified BL2 available on their website and the link added in the comment explaining the layout? We would then require HardKernel to: 1. Provide updated BL2.img 2. Update their wiki to reflect the new BL2. Also, it is an artificial constraint after all and can be easily modified. In fact I think we should push hardkernel to change that layout by default and use a BL2/SPL that has more sensible size for the u-boot binary even if they don't need it for their vendor u-boot which seems to be quite small. I totally agree. I'd like to propose a following plan: 1. Accept Hyungwon's patches to have XU3 u-boot 328 KiB (with link to default BL2) to have XU3 support in place (and treat it as a starting point) 2. If u-boot's size less than 328 KiB is _really_ a problem to somebody then ask hardkernel to change BL2 or: - modify their sources to change the layout (I regard this as a quick hack solution) - with a lot of pain develop BL2/SPL (by whom?) which base on newest mainline (then for each test hardkernel must sign the binary). My 2p worth... The current Hardkernel BL1 looks broken to me - it is just too old. +1 FWIW, the XU3 firmware is broken in other ways as well which have a major impact on power management. First, with mainline kernels using MCPM, only 6 of 8 CPUs come online. However, even with that fixed[1], it turns out that the kernel can't properly manage CCI due to secure firmware[2], which means that MCPM (multi-cluster power management) can't work, and thus the low-power cluster-idle states can't work, the big.LITTLE switcher cannot work, and the ongoing work on energy-aware scheduling will not be useful on this platform. Anyone know what are the chances of getting a non-secure version of the firmware for this platform. The Samsung Chromebook2 with basically the same SoC (5800 compared to the 5422 on the XU3) ships with non-secure firmware so all of the above mentioned features are working just fine. I have pushed on this but apparently it is not possible - they need to sign every BL2. The only implementation I've seen sets up the chip in BL2 (U-Boot SPL) so I don't think we can work around it. It takes us back to the 1960s where we sent off our code at night to run it :-) I think the best bet is the current effort to mainline the rest of the Chromebook code then try to build it for XU3. I'm working on getting these same features
