Re: [U-Boot] [PATCH v2 4/7] x86: Allow cpu-x86 driver to be probed for UP
On Tue, Jul 21, 2015 at 8:15 PM, Bin Meng bmeng...@gmail.com wrote: Currently cpu-x86 driver is probed only for SMP. We add the same support for UP when there is only one cpu node in the deive tree. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to allow cpu-x86 driver to be probed for UP arch/x86/cpu/cpu.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c index b4e0fd9..1c69a18 100644 --- a/arch/x86/cpu/cpu.c +++ b/arch/x86/cpu/cpu.c @@ -35,6 +35,7 @@ #include asm/processor-flags.h #include asm/interrupt.h #include asm/tables.h +#include dm/device-internal.h #include linux/compiler.h DECLARE_GLOBAL_DATA_PTR; @@ -696,6 +697,12 @@ __weak int x86_init_cpus(void) #ifdef CONFIG_SMP debug(Init additional CPUs\n); x86_mp_init(); +#else + struct udevice *dev = NULL; + + uclass_first_device(UCLASS_CPU, dev); + if (dev) + device_probe(dev); Looks that the call to device_probe() is not necessary. #endif return 0; -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: tegra: Add Tegra20 SPI device nodes
On 07/21/2015 03:36 AM, Mirza Krak wrote:
From: Mirza Krak mirza.k...@hostmobility.com
Add the device tree node for the SPI controllers found on Tegra20 SOCs.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
+ spi@7000d400 {
+ compatible = nvidia,tegra20-slink;
+ reg = 0x7000d400 0x200;
+ interrupts = 0 59 0x04;
+ nvidia,dma-request-selector = apbdma 15;
That property doesn't seem to exist in the kernel DT, and resets,
reset-names, dmas, dma-names are missing. I'd suggest simply
cutting/pasting from the kernel DT to make sure they stay in sync.
interrupts and clocks should also use the #defines to provide named
constants for better readability and the same consistency reasons.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
Le lundi 20 juillet 2015 à 17:13 +0200, Heiko Schocher a écrit :
Hello Paul,
Am 20.07.2015 um 15:30 schrieb Paul Kocialkowski:
I am just on the jump into my holidays, so I have not yet the time
to test it ... I want to try it for all builds with the scripts
I posted with my v2 ... but a first fast look into your patch looks
nice, if it works, it is ok with me ... I am back aprox. july 5th.
Okay, maybe I'll have a go at your scripts then! The idea to coordinate
Uh.. I am just a script beginner, they are not perfect ...
I'll let you know when I have some time to do the testing properly then!
Maybe this can be done/added at travis.org ?
See u-boot builds there:
https://travis-ci.org/u-boot/u-boot/
I don't like the idea of using a third-party's architecture for that.
This is service as a software substitute: see
http://www.gnu.org/philosophy/who-does-that-server-really-serve.html
with Debian developers would be to use their infrastructure to
automatically test as many u-boot targets as possible in an automated
and periodical manner (e.g. once a month), so that we can easily spot
which target is broken or which commit introduced a regression.
This sounds good ... feel free to trigger me, if I can help.
bye,
Heiko
maybe a README entry would be fine ;-)
Good point, that makes sense. I'll craft that in v2. I'll just wait for
some more feedback before sending a new version.
Thanks!
It would be nice to have this tested on as many boards as possible to
spot other areas that make the binaries not reproducible. However, I
doubt this patch will evolve much and other fixes should be sent in
subsequent patches.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
Makefile | 7 ---
tools/default_image.c | 21 -
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 37cc4c3..71aeac7 100644
--- a/Makefile
+++ b/Makefile
@@ -1231,9 +1231,10 @@ define filechk_version.h
endef
define filechk_timestamp.h
-(LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'; \
-LC_ALL=C date +'#define U_BOOT_TIME %T'; \
-LC_ALL=C date +'#define U_BOOT_TZ %z')
+(SOURCE_DATE=$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}; \
+LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define
U_BOOT_DATE %b %d %C%y'; \
+LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define
U_BOOT_TIME %T'; \
+LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TZ
%z' )
endef
$(version_h): include/config/uboot.release FORCE
diff --git a/tools/default_image.c b/tools/default_image.c
index cf5c0d4..18940af 100644
--- a/tools/default_image.c
+++ b/tools/default_image.c
@@ -88,6 +88,9 @@ static void image_set_header(void *ptr, struct stat
*sbuf, int ifd,
struct image_tool_params *params)
{
uint32_t checksum;
+char *source_date_epoch;
+struct tm *time_universal;
+time_t time;
image_header_t * hdr = (image_header_t *)ptr;
@@ -96,9 +99,25 @@ static void image_set_header(void *ptr, struct stat
*sbuf, int ifd,
sizeof(image_header_t)),
sbuf-st_size - sizeof(image_header_t));
+source_date_epoch = getenv(SOURCE_DATE_EPOCH);
+if (source_date_epoch != NULL) {
+time = (time_t) strtol(source_date_epoch, NULL, 10);
+
+time_universal = gmtime(time);
+if (time_universal == NULL) {
+fprintf(stderr, %s: SOURCE_DATE_EPOCH is not
valid\n,
+__func__);
+time = 0;
+} else {
+time = mktime(time_universal);
+}
+} else {
+time = sbuf-st_mtime;
+}
+
/* Build new header */
image_set_magic(hdr, IH_MAGIC);
-image_set_time(hdr, sbuf-st_mtime);
+image_set_time(hdr, time);
image_set_size(hdr, sbuf-st_size - sizeof(image_header_t));
image_set_load(hdr, params-addr);
image_set_ep(hdr, params-ep);
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/15][v2] imx: mx7dsabresd: Add support for MX7D SABRESD board
Hi Fabio, -Original Message- From: Fabio Estevam [mailto:feste...@gmail.com] Sent: Monday, July 20, 2015 7:50 PM To: Alonso Lazcano Adrian-B38018 Cc: U-Boot-Denx; Stefano Babic; Estevam Fabio-R49496; Otavio Salvador Subject: Re: [U-Boot] [PATCH 15/15][v2] imx: mx7dsabresd: Add support for MX7D SABRESD board Hi Adrian, On Mon, Jul 20, 2015 at 9:17 PM, Adrian Alonso aalo...@freescale.com wrote: --- /dev/null +++ b/board/freescale/mx7dsabresd/MAINTAINERS @@ -0,0 +1,6 @@ +MX7DSABRESD BOARD +M: Fabio Estevam fabio.este...@freescale.com I think it makes more sense to put your name here :-) [Adrian] Yep I can be the maintainer for this board, let me know if there are additional comments for the other imx7d patch's Regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
Le lundi 20 juillet 2015 à 07:45 -0700, Vagrant Cascadian a écrit :
On 2015-07-20, Paul Kocialkowski wrote:
In order to achieve reproducible builds in U-Boot, timestamps that are
defined
at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH
environment
variable allows setting a fixed value for those timestamps.
...
diff --git a/Makefile b/Makefile
index 37cc4c3..71aeac7 100644
--- a/Makefile
+++ b/Makefile
@@ -1231,9 +1231,10 @@ define filechk_version.h
endef
define filechk_timestamp.h
- (LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'; \
- LC_ALL=C date +'#define U_BOOT_TIME %T'; \
- LC_ALL=C date +'#define U_BOOT_TZ %z')
+ (SOURCE_DATE=$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}; \
+ LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_DATE %b %d
%C%y'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TIME %T';
\
+ LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TZ %z' )
endef
$(version_h): include/config/uboot.release FORCE
This does effectively hard-code U_BOOT_TZ to UTC; may as well not call
date for setting U_BOOT_TZ. Or conditionally set it to UTC only when
SOURCE_DATE_EPOCH is set?
That's true, but I like how consistent those commands look. Either way,
it's not a dramatic overhead, but I agree it's slightly confusing. If
you really think it's worth it, I could simply hardcode UTC in v2. Just
let me know!
I'd rather keep everything in one call (doing UTC only when
SOURCE_DATE_EPOCH is set looks overkill).
Any reason not to use the longhand options for date, e.g. --utc and
--date ? They're more readable; are they less portable?
I don't think they are, but the short options look fine to me. Note that
out of those lines, two still fit in a 80 chars column. Adding long
options would make readability harder in that regard.
As far as I'm concerned, it's fine as it is, but if you really think it
would be a worthwhile addition to use the long options, let me know.
Please do check that it doesn't break portability, too.
Thanks for the review!
--
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.
Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/18] dm: pci: Add support for PCI driver matching
Hi Simon,
On Tue, Jul 7, 2015 at 6:47 AM, Simon Glass s...@chromium.org wrote:
At present all PCI devices must be present in the device tree in order to
be used. Many or most PCI devices don't require any configuration other than
that which is done automatically by U-Boot. It is inefficent to add a node
with nothing but a compatible string in order to get a device working.
Add a mechanism whereby PCI drivers can be declared along with the device
parameters they support (vendor/device/class). When no suitable driver is
found in the device tree the list of such devices is consulted to determine
the correct driver. If this also fails, then a generic driver is used as
before.
The mechanism used is very similar to that provided by Linux and the header
file defintions are copied from Linux 4.1.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/pci/pci-uclass.c | 129
++-
include/pci.h| 79 -
2 files changed, 193 insertions(+), 15 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 5b91fe3..41daa0d 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -353,6 +353,101 @@ int dm_pci_hose_probe_bus(struct pci_controller *hose,
pci_dev_t bdf)
return sub_bus;
}
+/**
+ * pci_match_one_device - Tell if a PCI device structure has a matching
+ *PCI device id structure
+ * @id: single PCI device id structure to match
+ * @dev: the PCI device structure to match against
+ *
+ * Returns the matching pci_device_id structure or %NULL if there is no
match.
+ */
+static bool pci_match_one_id(const struct pci_device_id *id,
+const struct pci_device_id *find)
+{
+ if ((id-vendor == PCI_ANY_ID || id-vendor == find-vendor)
+ (id-device == PCI_ANY_ID || id-device == find-device)
+ (id-subvendor == PCI_ANY_ID || id-subvendor == find-subvendor)
+ (id-subdevice == PCI_ANY_ID || id-subdevice == find-subdevice)
+ !((id-class ^ find-class) id-class_mask))
+ return true;
+
+ return false;
+}
+
+/**
+ * pci_find_and_bind_driver() - Find and bind the right PCI driver
+ *
+ * This only looks at certain fields in the descriptor.
+ */
+static int pci_find_and_bind_driver(struct udevice *parent,
+ struct pci_device_id *find_id, int devfn,
+ struct udevice **devp)
+{
+ struct pci_driver_entry *start, *entry;
+ const char *drv;
+ int n_ents;
+ int ret;
+ char name[30], *str;
+
+ *devp = NULL;
+
+ debug(%s: Searching for driver: vendor=%x, device=%x\n, __func__,
+ find_id-vendor, find_id-device);
+ start = ll_entry_start(struct pci_driver_entry, pci_driver_entry);
+ n_ents = ll_entry_count(struct pci_driver_entry, pci_driver_entry);
+ for (entry = start; entry != start + n_ents; entry++) {
+ const struct pci_device_id *id;
+ struct udevice *dev;
+ const struct driver *drv;
+
+ for (id = entry-match;
+id-vendor || id-subvendor || id-class_mask;
+id++) {
+ if (!pci_match_one_id(id, find_id))
+ continue;
+
+ drv = entry-driver;
+ /*
+* We could pass the descriptor to the driver as
+* platdata (instead of NULL) and allow its bind()
+* method to return -ENOENT if it doesn't support this
+* device. That way we could continue the search to
+* find another driver. For now this doesn't seem
+* necesssary, so just bind the first match.
+*/
+ ret = device_bind(parent, drv, drv-name, NULL, -1,
+ dev);
+ if (ret)
+ goto error;
+ debug(%s: Match found: %s\n, __func__, drv-name);
+ dev-driver_data = find_id-driver_data;
+ *devp = dev;
+ return 0;
+ }
+ }
+
+ /* Bind a generic driver so that the device can be used */
+ sprintf(name, pci_%x:%x.%x, parent-seq, PCI_DEV(devfn),
+ PCI_FUNC(devfn));
+ str = strdup(name);
+ if (!str)
+ return -ENOMEM;
+ drv = (find_id-class 8) == PCI_CLASS_BRIDGE_PCI ?
pci_bridge_drv :
+ pci_generic_drv;
+ ret = device_bind_driver(parent, drv, str, devp);
+ if (ret) {
+ debug(%s: Failed to bind generic driver: %d, __func__, ret);
+
Re: [U-Boot] [PATCHv4 0/3] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA
On Wednesday, July 22, 2015 at 12:46:15 AM, Dinh Nguyen wrote: On 07/20/2015 02:40 PM, Marek Vasut wrote: On Monday, July 20, 2015 at 09:31:39 PM, Dinh Nguyen wrote: [...] Hi, yeah, I have some insane amount of cleanup patches and fixes already. I will post them once I'm done. What I am sorely missing is the UniPHY register interface documentation, it looks like that is not public, so I don't exactly know if what sequencer.c does is really correct. Sometimes I have serious doubts about that too . Can you give me the documentation please ? Have you seen this link[1]? Yes, but that is by far not all of the registers used in the sequencer.c, is it ? Looks like it's in the entire emi.pdf file[1]. Please look at volume 3, or page 531 of 895. The section for the UniPHY. I extracted all the possible addresses used in the sequencer while cleaning it up, they're below. I cannot find these in any documentation. I checked the EMI RM, sure, but there seems to be many more registers all around the place than what are described in the EMI RM. Any ideas please ? Maybe this is not even the UniPHY anymore ? Hi! I'll try to get those questions answered for you shortly. Thanks! BTW, I tested out our your branch, but I think I'm missing a step as where to put the SPL DTB? U-Boot SPL 2015.07-rc3-00100-ga2e2da6 (Jul 21 2015 - 17:15:54) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Missing DTB ### ERROR ### Please RESET the board ### Do: make u-boot-with-spl-dtb.sfp This will produce u-boot-with-spl-dtb.sfp, which you write directly to that 0xa2 socfpga boot partition. It includes U-Boot SPL, DTB and U-Boot. You will also need to define CONFIG_SPL_MMC_SUPPORT in include/configs/socfpga_common.h as I didn't solve how to configure this on per-board basis, do this before building the U-Boot of course. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB and unbinding
Hi Hans, On 21 July 2015 at 13:52, Hans de Goede hdego...@redhat.com wrote: Hi, On 07/20/2015 05:49 PM, Simon Glass wrote: Hi Hans, On 20 July 2015 at 09:31, Hans de Goede hdego...@redhat.com wrote: Hi, On 20-07-15 04:23, Simon Glass wrote: Hi Hans, I've been thinking about the USB unbinding code. I know that I agreed to go with it, but in retrospect I think that was a mistake. I believe we should separate out the unbinding and make it an option, so that it is not required in order to use USB. In effect this makes one of driver model's design goals (the option to drop unused code) useless since USB is a common interface. If I recall the only problem the lack of unbinding caused was that the keyboard driver broke. I suspect it broke in a way that can be fixed. In fact I recently converted usb_ether to driver model and I'm willing to do the keyboard side also. I'd like the USB code to function with or without the unbinding (i.e. it uses it if there). What do you think? I strongly believe that unbinding is the proper thing todo for usb since it is a hotplug bus. IMHO the way the usb_find_emul_child() function was used before to re-use udevice-s after e.g. a usb reset was an ugly hack which just happened to work, but it in no way reflects reality. More importantly we need unbind support to properly stop usb controllers when booting the OS, so that they are not DMA-ing to/from their scratch-ram area in DRAM when the main OS boots, so not having unbind support combined with USB really is a no no. This is why I suggested to simply select the unbind Kconfig when USB is selected in Kconfig. I think you are referring to remove(), not unbind(). Right I mean that the remove callback *must* be called on usb_stop to avoid the usb controller dma-ing over random DRAM when the OS starts. OK. Although we might consider spiting them so we have a DM_DEVICE_REMOVE and a separate DM_DEVICE_UNBIND. The actual unbind core code is not that big, so I believe that the best solution is to always build the core if either DM_DEVICE_REMOVE *or* DM_USB is selected, and non USB drivers can leave out their unbind code if DM_DEVICE_REMOVE is not set, that should still give us most of the size savings without needing to do ugly hacks for USB. My main objection is that we tie USB such that it *will not work* unless we support unbinding. I'm fine with it being recommended, but core driver model features should be independent of subsystems. This also seems quite unnecessary. Re your common about the 'ugly hack that just happened to work', in principle we can just keep on creating new devices and ignore the old ones. That will still cause problems with code addressing the usb-devices by index, as the old devices will still be there. That's the idea behind not supporting unbinding. There should be no problem with this approach. This approach will only work if find_child_devnum is fixed to search backwards through the childs list, so that it will check the newly added nodes first. Or that it just ignores the nodes that aren't active. Anyway that function is a hang-over from the old code. It makes no sense to enumerate the devices when you can just look up the data and find them. I think it can be made to work for now, but perhaps we should port the keyboard drivers to DM? So I'd like to adjust the USB code so that it still works without unbinding, even if it is not optimal. I think that is the right thing to do in this case. As said, the remove callback of usb-host drivers *must* always be called, other then that if you can make things work without unbind that is fine with me. OK thanks, will give it a crack. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/55] dm: exynos: Driver model improvements leading to spring support
On 20/07/15 23:19, Simon Glass wrote: Hi Minkyu, On 2 July 2015 at 18:15, Simon Glass s...@chromium.org wrote: This series adds a number of fixes and improvements to driver model as well as two new uclasses (video bridges and I2c muxes). The series is aimed at adding support for spring (HP 11 Chromebook). Since it is very similar to other ARM Chromebooks, some effory is made to use common code rather than duplicating functionality. In fact spring uses the same code as several other boards, just with a different device tree and a few configuration changes. Audio works correctly on pit, pi, spring and snow with this series. A bug in the I2C driver broken this recently. The exynos implementation still has a few rough areas - e.g. some hard-coded GPIOs and the old-style SPL. Also it does not yet support CPU frequency scaling and power management. Spring has some oddities and they are hard to handle with U-Boot's old way of doing drivers. With driver model these can be implemented cleanly and this sort of problem was the original motivation for my interest in driver model. This series is available at u-boot-dm in branch spring-working. It is based on the previous set of driver model changes in branch clk-working. Are you planning to pick this up or should I? It is still dependent on some driver model changes which I am working to apply. If you want, please take patches to dm tree. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] x86: Allow cpu-x86 driver to be probed for UP
Hi Simon, On Wed, Jul 22, 2015 at 7:37 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 21 July 2015 at 09:37, Bin Meng bmeng...@gmail.com wrote: On Tue, Jul 21, 2015 at 8:15 PM, Bin Meng bmeng...@gmail.com wrote: Currently cpu-x86 driver is probed only for SMP. We add the same support for UP when there is only one cpu node in the deive tree. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to allow cpu-x86 driver to be probed for UP arch/x86/cpu/cpu.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c index b4e0fd9..1c69a18 100644 --- a/arch/x86/cpu/cpu.c +++ b/arch/x86/cpu/cpu.c @@ -35,6 +35,7 @@ #include asm/processor-flags.h #include asm/interrupt.h #include asm/tables.h +#include dm/device-internal.h #include linux/compiler.h DECLARE_GLOBAL_DATA_PTR; @@ -696,6 +697,12 @@ __weak int x86_init_cpus(void) #ifdef CONFIG_SMP debug(Init additional CPUs\n); x86_mp_init(); +#else + struct udevice *dev = NULL; + + uclass_first_device(UCLASS_CPU, dev); + if (dev) + device_probe(dev); Looks that the call to device_probe() is not necessary. Right. Also shouldn't uclass_first_device() return an error on failure? If not, please add a comment. We should allow boards that do not convert to use cpu uclass to boot, so I will add a comment for this. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2] patman: add distutils based installer
Hi Chris,
On 18 July 2015 at 03:49, Chris Packham judge.pack...@gmail.com wrote:
To make it easier to use patman on other projects add a distutils style
installer. Now patman can be installed with
cd u-boot/tools/patman python setup.py install
There are also the usual distutils options for creating source/binary
distributions of patman.
This looks good but can you please add a note to the patman README
about how to install it?
Tested-by: Simon Glass s...@chromium.org
Signed-off-by: Chris Packham judge.pack...@gmail.com
---
This gives us something that can be distributed separately as well as
in-tree. The import trick allows the python module patman to be
distributed and enables in-tree use without moving things around. An
alternative would be to move the files into a sub directory
(unfortunately a directory called patman would clash with the existing
symlink). I've left this as RFC so that the community can decide if we
want to live with this ugliness or come up with something else.
Thanks,
Chris
Changes in v2:
- Install as patman package
- Allow running in-tree or out-of-tree
tools/patman/__init__.py | 3 +++
tools/patman/patman.py | 20
tools/patman/setup.py| 13 +
3 files changed, 28 insertions(+), 8 deletions(-)
create mode 100644 tools/patman/__init__.py
create mode 100644 tools/patman/setup.py
diff --git a/tools/patman/__init__.py b/tools/patman/__init__.py
new file mode 100644
index 000..7cbe5fa
--- /dev/null
+++ b/tools/patman/__init__.py
@@ -0,0 +1,3 @@
+__all__ = ['checkpatch', 'command', 'commit', 'cros_subprocess',
+ 'get_maintainer', 'gitutil', 'patchstream', 'project',
+ 'series', 'settings', 'terminal', 'test']
diff --git a/tools/patman/patman.py b/tools/patman/patman.py
index 6c6473e..e76fc42 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/patman.py
@@ -14,14 +14,18 @@ import sys
import unittest
# Our modules
-import checkpatch
-import command
-import gitutil
-import patchstream
-import project
-import settings
-import terminal
-import test
+try:
+from patman import checkpatch, command, gitutil, patchstream, \
+project, settings, terminal, test
+except ImportError:
+import checkpatch
+import command
+import gitutil
+import patchstream
+import project
+import settings
+import terminal
+import test
parser = OptionParser()
diff --git a/tools/patman/setup.py b/tools/patman/setup.py
new file mode 100644
index 000..e61804f
--- /dev/null
+++ b/tools/patman/setup.py
@@ -0,0 +1,13 @@
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+from distutils.core import setup
+setup(name='patman',
+ version='1.0',
+ license='GPL-2.0+',
+ scripts=['patman'],
+ packages=['patman'],
+ package_dir={'patman': ''},
+ package_data={'patman': ['README']},
+ classifiers=['Environment :: Console',
+ 'Topic :: Software Development'])
--
2.5.0.rc0
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG
Hi,
On 07/19/2015 06:01 AM, Hans de Goede wrote:
Hi,
On 13-07-15 16:16, Bin Liu wrote:
Hi,
On 07/11/2015 08:04 AM, Hans de Goede wrote:
Hi,
On 10-07-15 17:31, Bin Liu wrote:
Hi,
On 07/10/2015 10:12 AM, Heiko Schocher wrote:
Hello Samuel,
Am 10.07.2015 um 16:50 schrieb Egli, Samuel:
Hi Hans,
-Original Message- From: Hans de Goede
[mailto:hdego...@redhat.com] Sent: Freitag, 10. Juli 2015 16:37
To: Egli, Samuel; ma...@denx.de Cc: u-boot@lists.denx.de;
tr...@konsulko.com; Bin Liu; Meier, Roger; Daniel Mack Subject:
Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG
Hi,
On 10-07-15 16:30, Hans de Goede wrote:
Hi,
On 10-07-15 15:16, Samuel Egli wrote:
From: Bin Liu b-...@ti.com
Do not config MUSB to highspeed mode if
CONFIG_USB_GADGET_DUALSPEED is not set, in which case Ether
gadget only operates in fullspeed.
Note: This patch is necessary for devices like some siemens
boards that allow only FULL SPEED USB 1.1, e.g. DFU
download.
Signed-off-by: Bin Liu b-...@ti.com Reviewed-by: Tom Rini
tr...@konsulko.com Tested-by: Samuel Egli
samuel.e...@siemens.com CC: Marek Vasut ma...@denx.de CC:
Heiko Schocher h...@denx.de CC: Daniel Mack
zon...@gmail.com CC: Roger Meier r.me...@siemens.com
Nack this breaks highspeed mode on boards which use the musb in
host mode, and thus do not set CONFIG_USB_GADGET_DUALSPEED.
My bad, I had a short thought about this when I was initially
working on
this patch, but did not really think about it throughly. Thanks for
bring it up.
p.s.
Given that you want to use this as a hack to work around the
broken pcb design of your board I suggest adding a new option for
this
Well, lets not discuss the broken pcb design. It seems that
wiring protection is not that common. Unfortunately, such a
protection is too expensive for USB High speed :-(.
Agreed, we have seen many cases that have nothing to do with hardware
design, but MUSB has to work in full-speed mode.
titled: CONFIG_USB_MUSB_NO_HIGHSPEED and then do:
+#ifndef CONFIG_USB_MUSB_NO_HIGHSPEED | MUSB_POWER_HSENAB
+#endif
This would be good enough. The point is indeed to limit it to full
speed.
Using CONFIG_USB_GADGET_DUALSPEED for this seems wrong, since
this has nothing to do with enabling dualspeed mode for the
gadget code really.
I agree that the name is confusing.
Yes, I vote for Hans suggestion.
*Adding* a new macro CONFIG_USB_MUSB_NO_HIGHSPEED for musb driver
causes
CONFIG_USB_GADGET_DUALSPEED redundant, because both control for
full-speed.
I suggest to *rename* CONFIG_USB_GADGET_DUALSPEED to
CONFIG_USB_FULLSPEED_ONLY. So that we can use one macro for both gadget
and musb drivers. Considering supper-speed exists and future, I think
CONFIG_USB_NO_HIGHSPEED is confusing...
Sorry I was too fast. CONFIG_USB_FULLSPEED_ONLY is IMHO not acceptable
as it is not granular enough. sunxi boards have both EHCI/OHCI usb
controller
pairs for host ports and an musb controller. One may be limited to
fullspeed
while the other is not.
Likewise I can see a case where some ports but not all ports are
fullspeed
only, so we still want to build the gadged code with dual-speed
descriptors.
Good point.
I really believe that something like:
CONFIG_MUSB_FULLSPEED_ONLY
I am not sure like the idea of using two macros in config.h to control
one thing. Please review the following patch which uses
CONFIG_USB_GADGET_DUALSPEED and musb-board_mode instead. Beware that
this patch is not tested.
The 2 macros do not control one thing, it is for example perfectly possible
to have multiple otg controllers, one which can only do fullspeed and one
which can do both high/full speed in this case one will want to build
the gadget code in dualspeed mode even though one of the usb controllers
is fullspeed only.
This case is a different problem, which requires a separate patch to
solve, maybe CONFIG_MUSB_NO_HIGHSPEED can play here.
My original and 2nd patch were trying to solve the issue that MUSB
controller was not set consistently with the gadget driver. Unless the
patch breaks something else (as did the original patch), nothing else
needs to be added in.
Regards,
-Bin.
Regards,
Hans
diff --git a/drivers/usb/musb-new/musb_core.c
b/drivers/usb/musb-new/musb_core.c
index eeaacdf..55d1c20 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -931,6 +931,7 @@ void musb_start(struct musb *musb)
{
void __iomem*regs = musb-mregs;
u8 devctl = musb_readb(regs, MUSB_DEVCTL);
+ u8 power;
dev_dbg(musb-controller, == devctl %02x\n, devctl);
@@ -942,11 +943,12 @@ void musb_start(struct musb *musb)
musb_writeb(regs, MUSB_TESTMODE, 0);
/* put into basic highspeed mode and start session */
- musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
- | MUSB_POWER_HSENAB
- /* ENSUSPEND wedges
tusb
[U-Boot] [PATCH] nokia_rx51: Typo in CONFIG_MUSB_HCD fixup
CONFIG_MUSB_HDC should be CONFIG_MUSB_HCD to have any effect. Signed-off-by: Paul Kocialkowski cont...@paulk.fr --- include/configs/nokia_rx51.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h index efc583f..6e3ce4d 100644 --- a/include/configs/nokia_rx51.h +++ b/include/configs/nokia_rx51.h @@ -109,7 +109,7 @@ /* USB */ #define CONFIG_MUSB_UDC -#define CONFIG_MUSB_HDC +#define CONFIG_MUSB_HCD #define CONFIG_USB_OMAP3 #define CONFIG_TWL4030_USB -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] gpio: UniPhier: add driver for UniPhier GPIO controller
Hi Simon, 2015-07-18 23:36 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 13 July 2015 at 02:29, Masahiro Yamada yamada.masah...@socionext.com wrote: This GPIO controller device is used on UniPhier SoCs. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- drivers/gpio/Kconfig | 6 ++ drivers/gpio/Makefile| 1 + drivers/gpio/gpio-uniphier.c | 186 +++ 3 files changed, 193 insertions(+) create mode 100644 drivers/gpio/gpio-uniphier.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 0c43777..1176e3f 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -36,6 +36,12 @@ config SANDBOX_GPIO_COUNT of 'anonymous' GPIOs that do not belong to any device or bank. Select a suitable value depending on your needs. +config GPIO_UNIPHIER + bool UniPhier GPIO + depends on ARCH_UNIPHIER + help + Say yes here to support UniPhier GPIOs. + config VYBRID_GPIO bool Vybrid GPIO driver depends on DM diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index 5864850..5ec4ad7 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -44,5 +44,6 @@ oby-$(CONFIG_SX151X) += sx151x.o obj-$(CONFIG_SUNXI_GPIO) += sunxi_gpio.o obj-$(CONFIG_LPC32XX_GPIO) += lpc32xx_gpio.o obj-$(CONFIG_STM32_GPIO) += stm32_gpio.o +obj-$(CONFIG_GPIO_UNIPHIER)+= gpio-uniphier.o obj-$(CONFIG_ZYNQ_GPIO)+= zynq_gpio.o obj-$(CONFIG_VYBRID_GPIO) += vybrid_gpio.o diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c new file mode 100644 index 000..8f8ea38 --- /dev/null +++ b/drivers/gpio/gpio-uniphier.c @@ -0,0 +1,186 @@ +/* + * Copyright (C) 2015 Masahiro Yamada yamada.masah...@socionext.com + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include common.h +#include mapmem.h +#include linux/io.h +#include asm/errno.h +#include asm/gpio.h +#include dm/device.h + +/* + * Unfortunately, the hardware specification adopts weird GPIO pin labeling. + * The ports are named as + * PORT00, PORT01, PORT02, ..., PORT07, + * PORT10, PORT11, PORT12, ..., PORT17, + * PORT20, PORT21, PORT22, ..., PORT27, + *... + * PORT90, PORT91, PORT92, ..., PORT97, + * PORT100, PORT101, PORT102, ..., PORT107, + *... + * + * The PORTs with 8 or 9 in the one's place are missing, i.e. the one's place + * is octal, while the other places are decimal. If we handle the port numbers + * as seen in the hardware documents, the GPIO offsets must be non-contiguous. + * It is possible to have sparse GPIO pins, but not handy for GPIO range + * mappings, register accessing, etc. This is because they are separate banks: PORT0, PORT1, PORT2, each with 8 GPIOs. Exynos and Tegra have the same thing. Both of these use a separate device for each bank - this works out nicely with device tree since you can say: port1 2 0 and it will do the right thing. With exynos they are described in the device tree. With tegra the top-level GPIO device is in the device tree and we manually bind its children, one for each bank. Maybe you should do a similar thing for uniphier? As far as I understood, drivers/gpio/tegra_gpio.c in U-boot binds its children, while drivers/gpio/gpio-tegra.c in Linux adds only one GPIO chip for the whole banks. Because the Tegra device tree has only one GPIO node, so you cannot do like port0 3 0, port1 2 0, ... For Exynos, yes, there are multiple GPIO nodes under the pinctrl OF node. So, it is possible to do like port0 3 0, port1 2 0, ... Unfortunately, UniPhier SoCs have much more GPIO banks. I had already consulted linux-gpio ML: https://lkml.org/lkml/2015/6/18/933 First, I tried to add 30 separate GPIO nodes in my device tree, but finally, I thought it was ridiculous. So, I turned around into the single OF node. My design priority is to use an identical device tree for both Linux and U-Boot. This is quite natural because device tree is a hardware description language. I implemented a GPIO driver for Linux first in order to decide the device tree interface and basic design policy. Then, I backported it to U-boot. This is because the GPIO subsystem in Linux has more factors that should be taken into account: - Interaction between GPIO and Pinctrl: gpio-ranges, gpio-ranges-group-names - gpioirq_chip - better support for OF (drivers/gpio/gpiolib-of.c). I want to match the device and the OF node to take advantage of it. This is why I do not want to do like Tegra. I posted the GPIO driver for Linux, and v3 is now under review. https://lkml.org/lkml/2015/7/13/856 I still not 100% sure what is the best solution. Perhaps, I may be missing something. If you think I am doing wrong, you can delay this series. I am not in a hurry about this series. BTW, Tegra has
Re: [U-Boot] [PATCH 1/8] doc: dfu: tftp: README entry for TFTP extension of DFU
On Mon, 20 Jul 2015 14:17:45 -0500 Joe Hershberger joe.hershber...@gmail.com wrote: Hi Lukasz, On Mon, Jul 20, 2015 at 1:59 PM, Lukasz Majewski l.majew...@majess.pl wrote: Hi Joe, Hi Lukasz, On Thu, Jul 16, 2015 at 2:59 PM, Lukasz Majewski l.majew...@majess.pl wrote: Hi Joe, Thank you for your review. Hi Lukasz, On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski l.majew...@majess.pl wrote: Documentation file for DFU extension. With this functionality it is now possible to transfer FIT images with firmware updates via TFTP and use DFU backend for storing them. Signed-off-by: Lukasz Majewski l.majew...@majess.pl --- doc/README.dfutftp | 153 + 1 file changed, 153 insertions(+) create mode 100644 doc/README.dfutftp diff --git a/doc/README.dfutftp b/doc/README.dfutftp new file mode 100644 index 000..4636321 --- /dev/null +++ b/doc/README.dfutftp @@ -0,0 +1,153 @@ +Device Firmware Upgrade (DFU) - extension to use TFTP += + +Why? + + +* Update TFTP (CONFIG_UPDATE_TFTP) only supports writing +code to NAND memory via TFTP. +* DFU supports writing data to variety of mediums (NAND, +eMMC, SD, partitions, RAM, etc) via USB. + +Combination of both solves their shortcomings! + + +Overview + + +This document briefly describes how to use BF for BF? It should be DFU. +upgrading firmware (e.g. kernel, u-boot, rootfs, etc.) +via TFTP protocol. + +By using Ethernet (TFTP protocol to be precise) it was +possible to overcome the major problem of USB based DFU - +the relatively low transfer speed for large files. +This was caused by DFU standard, which imposed utilization +of only EP0 for transfer. By using Ethernet we can circumvent +this shortcoming. + +Beagle Bone Black (BBB) powered by TI's am335x CPU has been used +as a demo board. + +To utilize this feature, one needs to first enable support +for USB based DFU (CONFIG_DFU_*) and TFTP update +(CONFIG_UPDATE_TFTP) described in ./doc/README.update. Does it really make sense to reuse this UPDATE_TFTP config? Why not DFU_TFTP? Enabling CONFIG_UPDATE_TFTP allows reusing parts of the legacy update_tftp() code. I can understand reusing the code, but that doesn't mean we should force both complete features to be included. The legacy ./common/update.c was using two flags - namely CONFIG_UPDATE_TFTP (to allow compilation of this file) and CONFIG_SYS_NO_FLASH. Lack of the latter was using #error to terminate a compilation. It seems the CONFIG_SYS_NO_FLASH is simply making sure that some other required feature is included. It wasn't actually selecting this feature. The CONFIG_UPDATE_TFTP was actually enabling the feature. It seems that should remain the case. That was the old behavior - one needed to define both flags to compile in the legacy code. You actually were required to have *not* defined CONFIG_SYS_NO_FLASH. Moreover the CONFIG_UPDATE_TFTP is used to enable running update_tftp() in the early boot stage. Yes... That could probably be left as is for now. My changes in the ./common/update.c file have split the code to common one (enabled by CONFIG_UPDATE_TFTP) and legacy one (NAND support specific) enabled by CONFIG_SYS_NO_FLASH. I think you need to make the common code be enabled by seeing either CONFIG_UPDATE_TFTP or CONFIG_DFU_TFTP. You also need to have a check that fails if CONFIG_UPDATE_TFTP CONFIG_SYS_NO_FLASH. That preserves old behavior. Ok. Sounds good. What I mean is that one should enable legacy CONFIG_UPDATE_TFTP as a prerequisite for using dfu tftp transfer. What if a new config like DFU_TFTP enabled the shared code, but not the old behaviors. DFU_TFTP enables dfu specific code - not the shared code (at ./common/update.c). It should also enable the shared code. Shared code is enabled by CONFIG_UPDATE_TFTP. It should enable the shared code as well as the legacy-specific behavior. +New dfutftp command has been introduced to comply with present +USB related commands' syntax. + +This code works without fitupd command enabled. + +As of this writing (SHA1:241746e618fa725491e9ff689710c5f73ffd9139) the +update.c code is not enabled (CONFIG_UPDATE_TFTP) by any board in the +contemporary u-boot tree. So maybe we should remove it. This is IMHO a tricky issue. On the one hand there hasn't left any board supporting this feature in mainline (recently some old PPC boards have been removed from u-boot). One the other hand _probably_ there are deployed systems (as a derivative of the boards supported in u-boot and using this
[U-Boot] [PATCH v2 2/2] warp: Add MAX77696 support
From: Fabio Estevam fabio.este...@freescale.com
Warp has a MAX77696 PMIC connected via I2C1 bus.
Add support for it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- None
board/warp/warp.c | 50 ++
include/configs/warp.h | 11 +++
2 files changed, 61 insertions(+)
diff --git a/board/warp/warp.c b/board/warp/warp.c
index 21ac5e7..49dfdb6 100644
--- a/board/warp/warp.c
+++ b/board/warp/warp.c
@@ -15,13 +15,17 @@
#include asm/arch/sys_proto.h
#include asm/gpio.h
#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
#include asm/io.h
#include linux/sizes.h
#include common.h
#include watchdog.h
#include fsl_esdhc.h
+#include i2c.h
#include mmc.h
#include usb.h
+#include power/pmic.h
+#include power/max77696_pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -35,6 +39,11 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_SRE_FAST | PAD_CTL_HYS | \
PAD_CTL_LVE)
+#define I2C_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
int dram_init(void)
{
gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -88,6 +97,45 @@ int board_usb_phy_mode(int port)
return USB_INIT_DEVICE;
}
+/* I2C1 for PMIC */
+#define I2C_PMIC 0
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+struct i2c_pads_info i2c_pad_info1 = {
+ .sda = {
+ .i2c_mode = MX6_PAD_I2C1_SDA__I2C1_SDA | PC,
+ .gpio_mode = MX6_PAD_I2C1_SDA__GPIO_3_13 | PC,
+ .gp = IMX_GPIO_NR(3, 13),
+ },
+ .scl = {
+ .i2c_mode = MX6_PAD_I2C1_SCL__I2C1_SCL | PC,
+ .gpio_mode = MX6_PAD_I2C1_SCL__GPIO_3_12 | PC,
+ .gp = IMX_GPIO_NR(3, 12),
+ },
+};
+
+int power_init_board(void)
+{
+ struct pmic *p;
+ int ret;
+ unsigned int reg;
+
+ ret = power_max77696_init(I2C_PMIC);
+ if (ret)
+ return ret;
+
+ p = pmic_get(MAX77696);
+ if (!p)
+ return -EINVAL;
+
+ ret = pmic_reg_read(p, CID, reg);
+ if (ret)
+ return ret;
+
+ printf(PMIC: MAX77696 detected, rev=0x%x\n, reg);
+
+ return pmic_probe(p);
+}
+
int board_early_init_f(void)
{
setup_iomux_uart();
@@ -99,6 +147,8 @@ int board_init(void)
/* address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info1);
+
return 0;
}
diff --git a/include/configs/warp.h b/include/configs/warp.h
index 48e2058..f38f781 100644
--- a/include/configs/warp.h
+++ b/include/configs/warp.h
@@ -98,6 +98,17 @@
#define CONFIG_CMD_FUSE
#define CONFIG_MXC_OCOTP
+/* I2C Configs */
+#define CONFIG_CMD_I2C
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_I2C_SPEED 10
+
+/* PMIC */
+#define CONFIG_POWER
+#define CONFIG_POWER_I2C
+#define CONFIG_POWER_MAX77696
+
#define CONFIG_EXTRA_ENV_SETTINGS \
script=boot.scr\0 \
image=zImage\0 \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] power: pmic: Add support for MAX77696 PMIC
From: Fabio Estevam fabio.este...@freescale.com
Add support for MAX77696 PMIC.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Fix the range of PMIC registers
drivers/power/pmic/Makefile| 1 +
drivers/power/pmic/pmic_max77696.c | 32
include/power/max77696_pmic.h | 61 ++
3 files changed, 94 insertions(+)
create mode 100644 drivers/power/pmic/pmic_max77696.c
create mode 100644 include/power/max77696_pmic.h
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index ae86f04..4ad6df3 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
+obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
diff --git a/drivers/power/pmic/pmic_max77696.c
b/drivers/power/pmic/pmic_max77696.c
new file mode 100644
index 000..93d92f5
--- /dev/null
+++ b/drivers/power/pmic/pmic_max77696.c
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Fabio Estevam fabio.este...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include errno.h
+#include i2c.h
+#include power/pmic.h
+#include power/max77696_pmic.h
+
+int power_max77696_init(unsigned char bus)
+{
+ static const char name[] = MAX77696;
+ struct pmic *p = pmic_alloc();
+
+ if (!p) {
+ printf(%s: POWER allocation error!\n, __func__);
+ return -ENOMEM;
+ }
+
+ p-name = name;
+ p-interface = PMIC_I2C;
+ p-number_of_regs = PMIC_NUM_OF_REGS;
+ p-hw.i2c.addr = CONFIG_POWER_MAX77696_I2C_ADDR;
+ p-hw.i2c.tx_num = 1;
+ p-bus = bus;
+
+ return 0;
+}
diff --git a/include/power/max77696_pmic.h b/include/power/max77696_pmic.h
new file mode 100644
index 000..58f295c
--- /dev/null
+++ b/include/power/max77696_pmic.h
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Fabio Estevam fabio.este...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __MAX77696_PMIC_H__
+#define __MAX77696_PMIC_H__
+
+#define CONFIG_POWER_MAX77696_I2C_ADDR 0x3C
+
+enum {
+ L01_CNFG1 = 0x43,
+ L01_CNFG2,
+ L02_CNFG1,
+ L02_CNFG2,
+ L03_CNFG1,
+ L03_CNFG2,
+ L04_CNFG1,
+ L04_CNFG2,
+ L05_CNFG1,
+ L05_CNFG2,
+ L06_CNFG1,
+ L06_CNFG2,
+ L07_CNFG1,
+ L07_CNFG2,
+ L08_CNFG1,
+ L08_CNFG2,
+ L09_CNFG1,
+ L09_CNFG2,
+ L10_CNFG1,
+ L10_CNFG2,
+ LDO_INT1,
+ LDO_INT2,
+ LDO_INT1M,
+ LDO_INT2M,
+ LDO_CNFG3,
+ SW1_CNTRL,
+ SW2_CNTRL,
+ SW3_CNTRL,
+ SW4_CNTRL,
+ EPDCNFG,
+ EPDINTS,
+ EPDINT,
+ EPDINTM,
+ EPDVCOM,
+ EPDVEE,
+ EPDVNEG,
+ EPDVPOS,
+ EPDVDDH,
+ EPDSEQ,
+ EPDOKINTS,
+ CID = 0x9c,
+ EPDDIS =0xb5,
+ PMIC_NUM_OF_REGS,
+};
+
+int power_max77696_init(unsigned char bus);
+
+#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix RTC build error on ivybridge
Hi Bin, On 21 July 2015 at 15:06, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Bin, On Tue, 21 Jul 2015 20:21:28 +0800, Bin Meng bmeng...@gmail.com wrote: Hi Albert, On Tue, Jul 21, 2015 at 8:19 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Bin, On Tue, 21 Jul 2015 00:55:13 -0700, Bin Meng bmeng...@gmail.com wrote: For some unknown reason, buildman does not report build error when building commit 06c4b7e. This commit is to correct the build error and needs to be squashed into commit 06c4b7e. You can use -C to force a reconfigure after every build. Otherwise it defaults to an incremental build which will not reconfigure. It automatically reconfigures if it gets an error, but does not look for errors. This case is rare enough that I don't worry about it too much. Which repository and branch contains this commit 06c4b7e? I cannot find it at all under u-boot/master. It is on the u-boot-x86/master. Ok, thanks. Besides, fixes are not done by squashing commit. Yep, I know that once something goes into mainline, it is not allowed to change any history. As this is on the u-boot-x86/master and Simon has not asked Tom to pull, I believe it is OK. Fine then. Regards, Bin Amicalement, -- Albert. Acked-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] gpio: UniPhier: add driver for UniPhier GPIO controller
Hi Masahiro, On 21 July 2015 at 12:19, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, 2015-07-18 23:36 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 13 July 2015 at 02:29, Masahiro Yamada yamada.masah...@socionext.com wrote: This GPIO controller device is used on UniPhier SoCs. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- drivers/gpio/Kconfig | 6 ++ drivers/gpio/Makefile| 1 + drivers/gpio/gpio-uniphier.c | 186 +++ 3 files changed, 193 insertions(+) create mode 100644 drivers/gpio/gpio-uniphier.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 0c43777..1176e3f 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -36,6 +36,12 @@ config SANDBOX_GPIO_COUNT of 'anonymous' GPIOs that do not belong to any device or bank. Select a suitable value depending on your needs. +config GPIO_UNIPHIER + bool UniPhier GPIO + depends on ARCH_UNIPHIER + help + Say yes here to support UniPhier GPIOs. + config VYBRID_GPIO bool Vybrid GPIO driver depends on DM diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index 5864850..5ec4ad7 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -44,5 +44,6 @@ oby-$(CONFIG_SX151X) += sx151x.o obj-$(CONFIG_SUNXI_GPIO) += sunxi_gpio.o obj-$(CONFIG_LPC32XX_GPIO) += lpc32xx_gpio.o obj-$(CONFIG_STM32_GPIO) += stm32_gpio.o +obj-$(CONFIG_GPIO_UNIPHIER)+= gpio-uniphier.o obj-$(CONFIG_ZYNQ_GPIO)+= zynq_gpio.o obj-$(CONFIG_VYBRID_GPIO) += vybrid_gpio.o diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c new file mode 100644 index 000..8f8ea38 --- /dev/null +++ b/drivers/gpio/gpio-uniphier.c @@ -0,0 +1,186 @@ +/* + * Copyright (C) 2015 Masahiro Yamada yamada.masah...@socionext.com + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include common.h +#include mapmem.h +#include linux/io.h +#include asm/errno.h +#include asm/gpio.h +#include dm/device.h + +/* + * Unfortunately, the hardware specification adopts weird GPIO pin labeling. + * The ports are named as + * PORT00, PORT01, PORT02, ..., PORT07, + * PORT10, PORT11, PORT12, ..., PORT17, + * PORT20, PORT21, PORT22, ..., PORT27, + *... + * PORT90, PORT91, PORT92, ..., PORT97, + * PORT100, PORT101, PORT102, ..., PORT107, + *... + * + * The PORTs with 8 or 9 in the one's place are missing, i.e. the one's place + * is octal, while the other places are decimal. If we handle the port numbers + * as seen in the hardware documents, the GPIO offsets must be non-contiguous. + * It is possible to have sparse GPIO pins, but not handy for GPIO range + * mappings, register accessing, etc. This is because they are separate banks: PORT0, PORT1, PORT2, each with 8 GPIOs. Exynos and Tegra have the same thing. Both of these use a separate device for each bank - this works out nicely with device tree since you can say: port1 2 0 and it will do the right thing. With exynos they are described in the device tree. With tegra the top-level GPIO device is in the device tree and we manually bind its children, one for each bank. Maybe you should do a similar thing for uniphier? As far as I understood, drivers/gpio/tegra_gpio.c in U-boot binds its children, while drivers/gpio/gpio-tegra.c in Linux adds only one GPIO chip for the whole banks. Because the Tegra device tree has only one GPIO node, so you cannot do like port0 3 0, port1 2 0, ... Well instead we do things like gpio TEGRA_GPIO(H, 3) GPIO_ACTIVE_HIGH It's not quite as nice but it works. For Exynos, yes, there are multiple GPIO nodes under the pinctrl OF node. So, it is possible to do like port0 3 0, port1 2 0, ... Unfortunately, UniPhier SoCs have much more GPIO banks. I had already consulted linux-gpio ML: https://lkml.org/lkml/2015/6/18/933 First, I tried to add 30 separate GPIO nodes in my device tree, but finally, I thought it was ridiculous. So, I turned around into the single OF node. OK. My design priority is to use an identical device tree for both Linux and U-Boot. This is quite natural because device tree is a hardware description language. Yes. I implemented a GPIO driver for Linux first in order to decide the device tree interface and basic design policy. Then, I backported it to U-boot. This is because the GPIO subsystem in Linux has more factors that should be taken into account: - Interaction between GPIO and Pinctrl: gpio-ranges, gpio-ranges-group-names - gpioirq_chip - better support for OF (drivers/gpio/gpiolib-of.c). I want to match the device and the OF node to take advantage of it. This is why I do not want to do like Tegra. I posted the GPIO driver for Linux, and v3 is now under
Re: [U-Boot] USB and unbinding
Hi, On 07/20/2015 05:49 PM, Simon Glass wrote: Hi Hans, On 20 July 2015 at 09:31, Hans de Goede hdego...@redhat.com wrote: Hi, On 20-07-15 04:23, Simon Glass wrote: Hi Hans, I've been thinking about the USB unbinding code. I know that I agreed to go with it, but in retrospect I think that was a mistake. I believe we should separate out the unbinding and make it an option, so that it is not required in order to use USB. In effect this makes one of driver model's design goals (the option to drop unused code) useless since USB is a common interface. If I recall the only problem the lack of unbinding caused was that the keyboard driver broke. I suspect it broke in a way that can be fixed. In fact I recently converted usb_ether to driver model and I'm willing to do the keyboard side also. I'd like the USB code to function with or without the unbinding (i.e. it uses it if there). What do you think? I strongly believe that unbinding is the proper thing todo for usb since it is a hotplug bus. IMHO the way the usb_find_emul_child() function was used before to re-use udevice-s after e.g. a usb reset was an ugly hack which just happened to work, but it in no way reflects reality. More importantly we need unbind support to properly stop usb controllers when booting the OS, so that they are not DMA-ing to/from their scratch-ram area in DRAM when the main OS boots, so not having unbind support combined with USB really is a no no. This is why I suggested to simply select the unbind Kconfig when USB is selected in Kconfig. I think you are referring to remove(), not unbind(). Right I mean that the remove callback *must* be called on usb_stop to avoid the usb controller dma-ing over random DRAM when the OS starts. Although we might consider spiting them so we have a DM_DEVICE_REMOVE and a separate DM_DEVICE_UNBIND. The actual unbind core code is not that big, so I believe that the best solution is to always build the core if either DM_DEVICE_REMOVE *or* DM_USB is selected, and non USB drivers can leave out their unbind code if DM_DEVICE_REMOVE is not set, that should still give us most of the size savings without needing to do ugly hacks for USB. My main objection is that we tie USB such that it *will not work* unless we support unbinding. I'm fine with it being recommended, but core driver model features should be independent of subsystems. This also seems quite unnecessary. Re your common about the 'ugly hack that just happened to work', in principle we can just keep on creating new devices and ignore the old ones. That will still cause problems with code addressing the usb-devices by index, as the old devices will still be there. That's the idea behind not supporting unbinding. There should be no problem with this approach. This approach will only work if find_child_devnum is fixed to search backwards through the childs list, so that it will check the newly added nodes first. So I'd like to adjust the USB code so that it still works without unbinding, even if it is not optimal. I think that is the right thing to do in this case. As said, the remove callback of usb-host drivers *must* always be called, other then that if you can make things work without unbind that is fine with me. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/20] dm: net: Support usbethaddr environment variable
Hi Joe, On 20 July 2015 at 12:10, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Mon, Jul 20, 2015 at 8:56 AM, Simon Glass s...@chromium.org wrote: Hi Joe, On 8 July 2015 at 15:07, Simon Glass s...@chromium.org wrote: Hi Joe, On 8 July 2015 at 14:43, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Wed, Jul 8, 2015 at 3:31 PM, Simon Glass s...@chromium.org wrote: +Hans Hi Joe, On 7 July 2015 at 22:04, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Tue, Jul 7, 2015 at 9:53 PM, Simon Glass s...@chromium.org wrote: For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically. I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev-seq? It should already be unique in the DM, right? I was really looking forward to that all going away. Ah, OK, sorry. Do you think we need a way of specifying the eth interface # as we do with aliases at present? We did have one but Han has just removed it :-) Can you reference where this happened. A quick search didn't turn it up for me. Otherwise we'll just end up counting up from the last 'fixed' ethernet interface. Maybe that is good enough. That's probably good enough, but some may prefer more explicit control. The thread is here: http://patchwork.ozlabs.org/patch/485637/ Before, we could I think add USB devices to the device tree and give them a specific number (although I never actually tested it), but that won't work now. What are you thoughts on this? I'd like to bring this series in soon (the parts without rpi anyway). I don't mind just having one past wired Eth as the starting point. If someone cares about specifying it in the device tree that can be added later without redoing what you are adding here, right? OK I'll go with that, Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/18] dm: pci: Add support for PCI driver matching
Hi Bin,
On 21 July 2015 at 10:12, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Tue, Jul 7, 2015 at 6:47 AM, Simon Glass s...@chromium.org wrote:
At present all PCI devices must be present in the device tree in order to
be used. Many or most PCI devices don't require any configuration other than
that which is done automatically by U-Boot. It is inefficent to add a node
with nothing but a compatible string in order to get a device working.
Add a mechanism whereby PCI drivers can be declared along with the device
parameters they support (vendor/device/class). When no suitable driver is
found in the device tree the list of such devices is consulted to determine
the correct driver. If this also fails, then a generic driver is used as
before.
The mechanism used is very similar to that provided by Linux and the header
file defintions are copied from Linux 4.1.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/pci/pci-uclass.c | 129
++-
include/pci.h| 79 -
2 files changed, 193 insertions(+), 15 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 5b91fe3..41daa0d 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -353,6 +353,101 @@ int dm_pci_hose_probe_bus(struct pci_controller *hose,
pci_dev_t bdf)
return sub_bus;
}
+/**
+ * pci_match_one_device - Tell if a PCI device structure has a matching
+ *PCI device id structure
+ * @id: single PCI device id structure to match
+ * @dev: the PCI device structure to match against
+ *
+ * Returns the matching pci_device_id structure or %NULL if there is no
match.
+ */
+static bool pci_match_one_id(const struct pci_device_id *id,
+const struct pci_device_id *find)
+{
+ if ((id-vendor == PCI_ANY_ID || id-vendor == find-vendor)
+ (id-device == PCI_ANY_ID || id-device == find-device)
+ (id-subvendor == PCI_ANY_ID || id-subvendor ==
find-subvendor)
+ (id-subdevice == PCI_ANY_ID || id-subdevice ==
find-subdevice)
+ !((id-class ^ find-class) id-class_mask))
+ return true;
+
+ return false;
+}
+
+/**
+ * pci_find_and_bind_driver() - Find and bind the right PCI driver
+ *
+ * This only looks at certain fields in the descriptor.
+ */
+static int pci_find_and_bind_driver(struct udevice *parent,
+ struct pci_device_id *find_id, int devfn,
+ struct udevice **devp)
+{
+ struct pci_driver_entry *start, *entry;
+ const char *drv;
+ int n_ents;
+ int ret;
+ char name[30], *str;
+
+ *devp = NULL;
+
+ debug(%s: Searching for driver: vendor=%x, device=%x\n, __func__,
+ find_id-vendor, find_id-device);
+ start = ll_entry_start(struct pci_driver_entry, pci_driver_entry);
+ n_ents = ll_entry_count(struct pci_driver_entry, pci_driver_entry);
+ for (entry = start; entry != start + n_ents; entry++) {
+ const struct pci_device_id *id;
+ struct udevice *dev;
+ const struct driver *drv;
+
+ for (id = entry-match;
+id-vendor || id-subvendor || id-class_mask;
+id++) {
+ if (!pci_match_one_id(id, find_id))
+ continue;
+
+ drv = entry-driver;
+ /*
+* We could pass the descriptor to the driver as
+* platdata (instead of NULL) and allow its bind()
+* method to return -ENOENT if it doesn't support
this
+* device. That way we could continue the search to
+* find another driver. For now this doesn't seem
+* necesssary, so just bind the first match.
+*/
+ ret = device_bind(parent, drv, drv-name, NULL, -1,
+ dev);
+ if (ret)
+ goto error;
+ debug(%s: Match found: %s\n, __func__, drv-name);
+ dev-driver_data = find_id-driver_data;
+ *devp = dev;
+ return 0;
+ }
+ }
+
+ /* Bind a generic driver so that the device can be used */
+ sprintf(name, pci_%x:%x.%x, parent-seq, PCI_DEV(devfn),
+ PCI_FUNC(devfn));
+ str = strdup(name);
+ if (!str)
+ return -ENOMEM;
+ drv = (find_id-class 8) == PCI_CLASS_BRIDGE_PCI ?
pci_bridge_drv :
+ pci_generic_drv;
+ ret = device_bind_driver(parent, drv, str, devp);
+ if (ret) {
+
Re: [U-Boot] [PATCH v2] ARM: tegra: Add Tegra20 SPI device nodes
2015-07-21 22:28 GMT+02:00 Simon Glass s...@chromium.org: Hi Also it's pretty easy to just copy over the kernel files. They should just work! Regards, Simon Ok, will give it a go then. -- Med Vänliga Hälsningar / Best Regards *** Mirza Krak Host Mobility AB mirza.k...@hostmobility.com Anders Personsgatan 12, 416 64 Göteborg Sweden http://www.hostmobility.com Direct: +46 31 31 32 704 Phone: +46 31 31 32 700 Fax: +46 31 80 67 51 Mobile: +46 730 28 06 22 *** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am33xx: Drop timer_init call from s_init - udelay is wrong at ddr configuration
On Fri, Jul 17, 2015 at 07:47:44AM +, Egli, Samuel wrote: Hi Tom, I stumbled over your commit b352dde1ea715e8481946ec7d8086b3c3eb126ae where you removed timer_init() from .../am33xx/board.c. In the commit message it's written that timer_init will be called earlier. However, since this commit udelay will not generate correct delays in spl code in our am335xx based boards. I'm wondering where the timer_init shold be placed. grep-ing the code I see that we have a call in spl.c but I this is too late. Hmm, if you switch it over to using arch/arm/cpu/armv7/arch_timer.c does the problem go away? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] x86: mpspec: Allow platform to determine how PIRQ is connected to I/O APIC
On 21 July 2015 at 06:15, Bin Meng bmeng...@gmail.com wrote: Currently during writing MP table I/O interrupt assignment entry, we assume the PIRQ is directly mapped to I/O APIC INTPIN#16-23, which however is not always the case on some platforms. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - Drop patches that are already applied - Add a TODO comment above mp_determine_pci_dstirq() arch/x86/include/asm/mpspec.h | 17 + arch/x86/lib/mpspec.c | 24 +--- 2 files changed, 34 insertions(+), 7 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] x86: Reserve PCIe ECAM address range in the E820 table
On 21 July 2015 at 06:15, Bin Meng bmeng...@gmail.com wrote: We should mark PCIe ECAM address range in the E820 table as reserved otherwise kernel will not attempt to use ECAM. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to reserve PCIe ECAM address range in the E820 table arch/x86/Kconfig| 10 ++ arch/x86/lib/fsp/fsp_dram.c | 6 ++ arch/x86/lib/zimage.c | 5 - 3 files changed, 20 insertions(+), 1 deletion(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] x86: qemu: Enable writing MP table
On 21 July 2015 at 06:15, Bin Meng bmeng...@gmail.com wrote: Enable writing MP table for QEMU boads (i440fx and q35). Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - Drop QEMU mp_init patch - Change /cpus node to include just one cpu arch/x86/cpu/qemu/pci.c | 34 +++--- arch/x86/dts/qemu-x86_i440fx.dts | 12 arch/x86/dts/qemu-x86_q35.dts| 12 configs/qemu-x86_defconfig | 3 +++ 4 files changed, 58 insertions(+), 3 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] keystone2: add high memory test
On Wed, Jul 08, 2015 at 11:51:39AM -0400, Vitaly Andrianov wrote: Keystone2 SOC physical DDR3 address range is outside the first 4GB and cannot be entirely accessible without MMU enabled. Only first 2GB of the physical memory have 32-bits aliased addresses. This patch adds u-boot shell command that allows to enable/disable MMU and map the 1GB of 36bits physical memory to the first 4GB address range. Signed-off-by: Vitaly Andrianov vita...@ti.com --- arch/arm/mach-keystone/Makefile | 3 +- arch/arm/mach-keystone/highmem.c | 162 +++ 2 files changed, 164 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-keystone/highmem.c The code looks reasonable. But why do we need this? Thanks. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix RTC build error on ivybridge
Hello Bin, On Tue, 21 Jul 2015 20:21:28 +0800, Bin Meng bmeng...@gmail.com wrote: Hi Albert, On Tue, Jul 21, 2015 at 8:19 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Bin, On Tue, 21 Jul 2015 00:55:13 -0700, Bin Meng bmeng...@gmail.com wrote: For some unknown reason, buildman does not report build error when building commit 06c4b7e. This commit is to correct the build error and needs to be squashed into commit 06c4b7e. Which repository and branch contains this commit 06c4b7e? I cannot find it at all under u-boot/master. It is on the u-boot-x86/master. Ok, thanks. Besides, fixes are not done by squashing commit. Yep, I know that once something goes into mainline, it is not allowed to change any history. As this is on the u-boot-x86/master and Simon has not asked Tom to pull, I believe it is OK. Fine then. Regards, Bin Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] arm/rpi: Enable dcache
On Monday 20 July 2015, 23:00:04 wrote Alexander Stein: Now that mailbox driver supports cache flush and invalidation, we can enable dcache. Signed-off-by: Alexander Stein alexander...@web.de Well, I just noticed that the dwc2 driver does not support dache yet. I'm on the way to add that there too and will send v3. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: baytrail: Configure FSP UPD from device tree
Hi Andrew,
On 10 July 2015 at 12:24, Andrew Bradford and...@bradfordembedded.com wrote:
Hi Simon,
On 07/10 06:53, Simon Glass wrote:
Hi,
On 8 July 2015 at 05:30, Andrew Bradford and...@bradfordembedded.com wrote:
Hi Bin,
On 07/08 11:18, Bin Meng wrote:
Hi Andrew,
On Wed, Jul 8, 2015 at 3:16 AM, and...@bradfordembedded.com wrote:
From: Andrew Bradford andrew.bradf...@kodakalaris.com
Allow for configuration of FSP UPD from the device tree which will
override any settings which the FSP was built with itself if the device
tree settings exist, otherwise simply trust the FSP's defaults.
Modifies the MinnowMax board to transfer the FSP UPD hard-coded settings
to the MinnowMax dts.
Signed-off-by: Andrew Bradford andrew.bradf...@kodakalaris.com
---
Changes from v1:
- Use - rather than _ in dt property names.
- Use Bay Trail for the formal name of the Intel product family.
- Use an fsp, prefix for dt property names for clarity.
- Fix minor code indentation issues.
- Create a dt subnode for the memory-down-params.
- Clarify documentation that dt overrides the FSP's config, so we don't
use booleans.
arch/x86/cpu/baytrail/fsp_configs.c| 188
+
arch/x86/dts/minnowmax.dts | 30
.../misc/intel,baytrail-fsp.txt| 119 +
include/fdtdec.h | 2 +
lib/fdtdec.c | 2 +
5 files changed, 311 insertions(+), 30 deletions(-)
create mode 100644 doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
diff --git a/arch/x86/cpu/baytrail/fsp_configs.c
b/arch/x86/cpu/baytrail/fsp_configs.c
index 86b6926..fce76e6 100644
--- a/arch/x86/cpu/baytrail/fsp_configs.c
+++ b/arch/x86/cpu/baytrail/fsp_configs.c
@@ -1,14 +1,18 @@
/*
* Copyright (C) 2013, Intel Corporation
* Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ * Copyright (C) 2015, Kodak Alaris, Inc
*
* SPDX-License-Identifier:Intel
*/
#include common.h
+#include fdtdec.h
#include asm/arch/fsp/azalia.h
#include asm/fsp/fsp_support.h
+DECLARE_GLOBAL_DATA_PTR;
+
/* ALC262 Verb Table - 10EC0262 */
static const uint32_t verb_table_data13[] = {
/* Pin Complex (NID 0x11) */
@@ -116,41 +120,165 @@ const struct pch_azalia_config azalia_config = {
.reset_wait_timer_us = 300
};
+/**
+ * Update the FSP's UPD. The FSP itself can be configured for
defaults to
+ * store in UPD through Intel's GUI configurator but likely a specific
board
+ * will want to update these from u-boot, so allow for that via device
tree.
+ * If the device tree does not specify a setting, trust the FSP's
default.
+ */
void update_fsp_upd(struct upd_region *fsp_upd)
{
struct memory_down_data *mem;
+ const void *blob = gd-fdt_blob;
+ int node;
- /*
-* Configure everything here to avoid the poor hard-pressed user
-* needing to run Intel's binary configuration tool. It may
also allow
-* us to support the 1GB single core variant easily.
-*
-* TODO(s...@chromium.org): Move to device tree
-*/
- fsp_upd-mrc_init_tseg_size = 8;
- fsp_upd-mrc_init_mmio_size = 0x800;
- fsp_upd-emmc_boot_mode = 0xff;
- fsp_upd-enable_sdio = 1;
- fsp_upd-enable_sdcard = 1;
- fsp_upd-enable_hsuart0 = 1;
fsp_upd-azalia_config_ptr = (uint32_t)azalia_config;
- fsp_upd-enable_i2_c0 = 0;
- fsp_upd-enable_i2_c2 = 0;
- fsp_upd-enable_i2_c3 = 0;
- fsp_upd-enable_i2_c4 = 0;
- fsp_upd-enable_xhci = 0;
- fsp_upd-igd_render_standby = 1;
+
+ node = fdtdec_next_compatible(blob, 0,
COMPAT_INTEL_BAYTRAIL_FSP);
+ if (node 0) {
+ debug(%s: Cannot find FSP node\n, __func__);
+ return;
+ }
+
+ fsp_upd-mrc_init_tseg_size = fdtdec_get_int(blob, node,
+
fsp,mrc-int-tseg-size,
mrc-int? Guess it is mrc-init.
Yes, thank you for catching this. Will fix in v3.
+
fsp_upd-mrc_init_tseg_size);
+ fsp_upd-mrc_init_mmio_size = fdtdec_get_int(blob, node,
+
fsp,mrc-init-mmio-size,
+
fsp_upd-mrc_init_mmio_size);
+ fsp_upd-mrc_init_spd_addr1 = fdtdec_get_int(blob, node,
+
fsp,mrc-init-spd-addr1,
+
fsp_upd-mrc_init_spd_addr1);
+ fsp_upd-mrc_init_spd_addr2 =
Re: [U-Boot] [PATCH v2] ARM: tegra: Add Tegra20 SPI device nodes
Hi,
On 21 July 2015 at 09:56, Stephen Warren swar...@wwwdotorg.org wrote:
On 07/21/2015 03:36 AM, Mirza Krak wrote:
From: Mirza Krak mirza.k...@hostmobility.com
Add the device tree node for the SPI controllers found on Tegra20 SOCs.
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
+ spi@7000d400 {
+ compatible = nvidia,tegra20-slink;
+ reg = 0x7000d400 0x200;
+ interrupts = 0 59 0x04;
+ nvidia,dma-request-selector = apbdma 15;
That property doesn't seem to exist in the kernel DT, and resets,
reset-names, dmas, dma-names are missing. I'd suggest simply
cutting/pasting from the kernel DT to make sure they stay in sync.
interrupts and clocks should also use the #defines to provide named
constants for better readability and the same consistency reasons.
Also it's pretty easy to just copy over the kernel files. They should just work!
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] dm: pci: Correct primary/secondary/subordinate bus number assignment
Hi Bin, On 19 July 2015 at 20:38, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Mon, Jul 20, 2015 at 9:59 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote: In driver model, each pci bridge device has its own hose structure. hose-first_busno points to the bridge device's device number, so we should not substract hose-first_busno before programming the bridge device's primary/secondary/subordinate bus number registers. Signed-off-by: Bin Meng bmeng...@gmail.com --- drivers/pci/pci_auto.c | 9 + 1 file changed, 9 insertions(+) Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org I'm not happy with how each PCI bridge has its own hose structure. I think that was a mistake. It just creates problems. I'm thinking we should instead have a UCLASS_PCI which is strictly for the PCI controller, and a new UCLASS_PCI_BRIDGE for bridges. What do you think? I guess that may help. During the debug, I feel the dm pci codes are really not that intuitive than the previous non-dm version. It took me sometime to figure out where is the problem. Agreed. Part of the problem I think is that it is still compatible with the old code. We should be able to do things like pci_read_config16(struct udevice *dev, ...) I guess we could move to separate things more. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sabresd: Use 'int' for return values
From: Fabio Estevam fabio.este...@freescale.com
The variable 'ret' is used to store the value returned by pfuze_mode_init(),
so it should of type 'int' instead of 'unsigned int' in order to correctly
handle negative numbers.
Fix the variable type.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 23f8f6b..fa800f4 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -631,7 +631,8 @@ int board_init(void)
int power_init_board(void)
{
struct pmic *p;
- unsigned int reg, ret;
+ unsigned int reg;
+ int ret;
p = pfuze_common_init(I2C_PMIC);
if (!p)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] warp: Add MAX77696 support
From: Fabio Estevam fabio.este...@freescale.com
Warp has a MAX77696 PMIC connected via I2C1 bus.
Add support for it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/warp/warp.c | 50 ++
include/configs/warp.h | 11 +++
2 files changed, 61 insertions(+)
diff --git a/board/warp/warp.c b/board/warp/warp.c
index 21ac5e7..49dfdb6 100644
--- a/board/warp/warp.c
+++ b/board/warp/warp.c
@@ -15,13 +15,17 @@
#include asm/arch/sys_proto.h
#include asm/gpio.h
#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
#include asm/io.h
#include linux/sizes.h
#include common.h
#include watchdog.h
#include fsl_esdhc.h
+#include i2c.h
#include mmc.h
#include usb.h
+#include power/pmic.h
+#include power/max77696_pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -35,6 +39,11 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_SRE_FAST | PAD_CTL_HYS | \
PAD_CTL_LVE)
+#define I2C_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
int dram_init(void)
{
gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -88,6 +97,45 @@ int board_usb_phy_mode(int port)
return USB_INIT_DEVICE;
}
+/* I2C1 for PMIC */
+#define I2C_PMIC 0
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+struct i2c_pads_info i2c_pad_info1 = {
+ .sda = {
+ .i2c_mode = MX6_PAD_I2C1_SDA__I2C1_SDA | PC,
+ .gpio_mode = MX6_PAD_I2C1_SDA__GPIO_3_13 | PC,
+ .gp = IMX_GPIO_NR(3, 13),
+ },
+ .scl = {
+ .i2c_mode = MX6_PAD_I2C1_SCL__I2C1_SCL | PC,
+ .gpio_mode = MX6_PAD_I2C1_SCL__GPIO_3_12 | PC,
+ .gp = IMX_GPIO_NR(3, 12),
+ },
+};
+
+int power_init_board(void)
+{
+ struct pmic *p;
+ int ret;
+ unsigned int reg;
+
+ ret = power_max77696_init(I2C_PMIC);
+ if (ret)
+ return ret;
+
+ p = pmic_get(MAX77696);
+ if (!p)
+ return -EINVAL;
+
+ ret = pmic_reg_read(p, CID, reg);
+ if (ret)
+ return ret;
+
+ printf(PMIC: MAX77696 detected, rev=0x%x\n, reg);
+
+ return pmic_probe(p);
+}
+
int board_early_init_f(void)
{
setup_iomux_uart();
@@ -99,6 +147,8 @@ int board_init(void)
/* address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info1);
+
return 0;
}
diff --git a/include/configs/warp.h b/include/configs/warp.h
index 48e2058..f38f781 100644
--- a/include/configs/warp.h
+++ b/include/configs/warp.h
@@ -98,6 +98,17 @@
#define CONFIG_CMD_FUSE
#define CONFIG_MXC_OCOTP
+/* I2C Configs */
+#define CONFIG_CMD_I2C
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_I2C_SPEED 10
+
+/* PMIC */
+#define CONFIG_POWER
+#define CONFIG_POWER_I2C
+#define CONFIG_POWER_MAX77696
+
#define CONFIG_EXTRA_ENV_SETTINGS \
script=boot.scr\0 \
image=zImage\0 \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] power: pmic: Add support for MAX77696 PMIC
From: Fabio Estevam fabio.este...@freescale.com
Add support for MAX77696 PMIC.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/power/pmic/Makefile| 1 +
drivers/power/pmic/pmic_max77696.c | 32
include/power/max77696_pmic.h | 60 ++
3 files changed, 93 insertions(+)
create mode 100644 drivers/power/pmic/pmic_max77696.c
create mode 100644 include/power/max77696_pmic.h
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index ae86f04..4ad6df3 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
+obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
diff --git a/drivers/power/pmic/pmic_max77696.c
b/drivers/power/pmic/pmic_max77696.c
new file mode 100644
index 000..93d92f5
--- /dev/null
+++ b/drivers/power/pmic/pmic_max77696.c
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Fabio Estevam fabio.este...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include errno.h
+#include i2c.h
+#include power/pmic.h
+#include power/max77696_pmic.h
+
+int power_max77696_init(unsigned char bus)
+{
+ static const char name[] = MAX77696;
+ struct pmic *p = pmic_alloc();
+
+ if (!p) {
+ printf(%s: POWER allocation error!\n, __func__);
+ return -ENOMEM;
+ }
+
+ p-name = name;
+ p-interface = PMIC_I2C;
+ p-number_of_regs = PMIC_NUM_OF_REGS;
+ p-hw.i2c.addr = CONFIG_POWER_MAX77696_I2C_ADDR;
+ p-hw.i2c.tx_num = 1;
+ p-bus = bus;
+
+ return 0;
+}
diff --git a/include/power/max77696_pmic.h b/include/power/max77696_pmic.h
new file mode 100644
index 000..71cdf88
--- /dev/null
+++ b/include/power/max77696_pmic.h
@@ -0,0 +1,60 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Fabio Estevam fabio.este...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __MAX77696_PMIC_H__
+#define __MAX77696_PMIC_H__
+
+#define CONFIG_POWER_MAX77696_I2C_ADDR 0x3C
+
+enum {
+ L01_CNFG1 = 0x43,
+ L01_CNFG2,
+ L02_CNFG1,
+ L02_CNFG2,
+ L03_CNFG1,
+ L03_CNFG2,
+ L04_CNFG1,
+ L04_CNFG2,
+ L05_CNFG1,
+ L05_CNFG2,
+ L06_CNFG1,
+ L06_CNFG2,
+ L07_CNFG1,
+ L07_CNFG2,
+ L08_CNFG1,
+ L08_CNFG2,
+ L09_CNFG1,
+ L09_CNFG2,
+ L10_CNFG1,
+ L10_CNFG2,
+ LDO_INT1,
+ LDO_INT2,
+ LDO_INT1M,
+ LDO_INT2M,
+ LDO_CNFG3,
+ SW1_CNTRL,
+ SW2_CNTRL,
+ SW3_CNTRL,
+ SW4_CNTRL,
+ EPDCNFG,
+ EPDINTS,
+ EPDINT,
+ EPDINTM,
+ EPDVCOM,
+ EPDVEE,
+ EPDVNEG,
+ EPDVPOS,
+ EPDVDDH,
+ EPDSEQ,
+ EPDOKINTS,
+ CID = 0x9c,
+ PMIC_NUM_OF_REGS,
+};
+
+int power_max77696_init(unsigned char bus);
+
+#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 0/3] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA
On 07/20/2015 02:40 PM, Marek Vasut wrote: On Monday, July 20, 2015 at 09:31:39 PM, Dinh Nguyen wrote: [...] Hi, yeah, I have some insane amount of cleanup patches and fixes already. I will post them once I'm done. What I am sorely missing is the UniPHY register interface documentation, it looks like that is not public, so I don't exactly know if what sequencer.c does is really correct. Sometimes I have serious doubts about that too . Can you give me the documentation please ? Have you seen this link[1]? Yes, but that is by far not all of the registers used in the sequencer.c, is it ? Looks like it's in the entire emi.pdf file[1]. Please look at volume 3, or page 531 of 895. The section for the UniPHY. I extracted all the possible addresses used in the sequencer while cleaning it up, they're below. I cannot find these in any documentation. I checked the EMI RM, sure, but there seems to be many more registers all around the place than what are described in the EMI RM. Any ideas please ? Maybe this is not even the UniPHY anymore ? I'll try to get those questions answered for you shortly. BTW, I tested out our your branch, but I think I'm missing a step as where to put the SPL DTB? U-Boot SPL 2015.07-rc3-00100-ga2e2da6 (Jul 21 2015 - 17:15:54) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Missing DTB ### ERROR ### Please RESET the board ### Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sxsabresd: Use 'int' for return values
From: Fabio Estevam fabio.este...@freescale.com
The variable 'ret' is used to store the value returned by pfuze_mode_init(),
so it should be of type 'int' instead of 'unsigned int' in order to
correctly handle negative numbers.
Fix the variable type.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 2ff960e..d58a79a 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -199,7 +199,8 @@ static struct i2c_pads_info i2c_pad_info1 = {
int power_init_board(void)
{
struct pmic *p;
- unsigned int reg, ret;
+ unsigned int reg;
+ int ret;
p = pfuze_common_init(I2C_PMIC);
if (!p)
--
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 4/7] x86: Allow cpu-x86 driver to be probed for UP
Hi Bin, On 21 July 2015 at 09:37, Bin Meng bmeng...@gmail.com wrote: On Tue, Jul 21, 2015 at 8:15 PM, Bin Meng bmeng...@gmail.com wrote: Currently cpu-x86 driver is probed only for SMP. We add the same support for UP when there is only one cpu node in the deive tree. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to allow cpu-x86 driver to be probed for UP arch/x86/cpu/cpu.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c index b4e0fd9..1c69a18 100644 --- a/arch/x86/cpu/cpu.c +++ b/arch/x86/cpu/cpu.c @@ -35,6 +35,7 @@ #include asm/processor-flags.h #include asm/interrupt.h #include asm/tables.h +#include dm/device-internal.h #include linux/compiler.h DECLARE_GLOBAL_DATA_PTR; @@ -696,6 +697,12 @@ __weak int x86_init_cpus(void) #ifdef CONFIG_SMP debug(Init additional CPUs\n); x86_mp_init(); +#else + struct udevice *dev = NULL; + + uclass_first_device(UCLASS_CPU, dev); + if (dev) + device_probe(dev); Looks that the call to device_probe() is not necessary. Right. Also shouldn't uclass_first_device() return an error on failure? If not, please add a comment. #endif return 0; -- Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pxe: add AArch64 image support
From: Stephen Warren swar...@nvidia.com The sysboot and pxe commands currently support either U-Boot formats or raw zImages. Add support for the AArch64 Linux port's native image format too. As with zImage support, there is no auto-detection of the native image format. Rather, if the image is auto-detected as a U-Boot format, U-Boot will try to interpret it as such. Otherwise, U-Boot will fall back to a raw/native image format, if one is enabled. My belief is that CONFIG_CMD_BOOTZ won't ever be enabled for any AArch64 port, hence there's never a need to differentiate between CONFIG_CMD_ _BOOTI and _BOOTZ at run-time; compile-time will do. Even if this isn't true, we want to prefer _BOOTI over _BOOTZ when defined, since _BOOTI is definitely the native format for AArch64. Change-Id: I83c5cc7566032afd72516de46f4e5eb7a780284a Signed-off-by: Stephen Warren swar...@nvidia.com --- common/cmd_pxe.c | 8 ++-- include/command.h | 2 ++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c index abf0941b579c..080b3760de00 100644 --- a/common/cmd_pxe.c +++ b/common/cmd_pxe.c @@ -793,8 +793,12 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label *label) /* Try bootm for legacy and FIT format image */ if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID) do_bootm(cmdtp, 0, bootm_argc, bootm_argv); -#ifdef CONFIG_CMD_BOOTZ - /* Try booting a zImage */ +#ifdef CONFIG_CMD_BOOTI + /* Try booting an AArch64 Linux kernel image */ + else + do_booti(cmdtp, 0, bootm_argc, bootm_argv); +#elif defined(CONFIG_CMD_BOOTZ) + /* Try booting a Image */ else do_bootz(cmdtp, 0, bootm_argc, bootm_argv); #endif diff --git a/include/command.h b/include/command.h index bd3fc049ecaa..6c04cd9007a5 100644 --- a/include/command.h +++ b/include/command.h @@ -104,6 +104,8 @@ static inline int bootm_maybe_autostart(cmd_tbl_t *cmdtp, const char *cmd) extern int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]); +extern int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]); + extern int common_diskboot(cmd_tbl_t *cmdtp, const char *intf, int argc, char *const argv[]); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/15][v2] imx: iomux-v3: add imx7d support for iomuxc
* Add imx7d support for iomux controller
* imx7d has two iomux controllers iomuxc (0x3033000) and iomuxc-lpsr
(0x302C) each conroller provides control and mux mode pad
registers but shares iomuxc input select register with iomuxc-lpsr
IOMUX_CONFIG_LPSR flag is used to properly set daisy chain settings
for iomuxc-lpsr pads.
* Since mx7d introduces LPSR IOMUX pins, add new base to IOMUX v3
driver for these LPSR pins.
Signed-off-by: Adrian Alonso aalo...@freescale.com
Signed-off-by: Fugang Duan b38...@freescale.com
Signed-off-by: Ye.Li b37...@freescale.com
---
Changes for V2:
- Update commit log information
arch/arm/imx-common/iomux-v3.c | 20 +-
arch/arm/include/asm/arch-mx7/mx7-pins.h | 19 +
arch/arm/include/asm/arch-mx7/mx7d_pins.h | 1308
arch/arm/include/asm/imx-common/iomux-v3.h | 32 +
4 files changed, 1378 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/arch-mx7/mx7-pins.h
create mode 100644 arch/arm/include/asm/arch-mx7/mx7d_pins.h
diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c
index 7fb23dd..07e75a6 100644
--- a/arch/arm/imx-common/iomux-v3.c
+++ b/arch/arm/imx-common/iomux-v3.c
@@ -4,7 +4,7 @@
* Copyright (C) 2009 by Jan Weitzel Phytec Messtechnik GmbH,
* armli...@phytec.de
*
- * Copyright (C) 2004-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2004-2015 Freescale Semiconductor, Inc.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -41,6 +41,18 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
}
#endif
+#ifdef CONFIG_IOMUX_LPSR
+ u32 lpsr = (pad MUX_MODE_LPSR) MUX_MODE_SHIFT;
+
+ if (lpsr == IOMUX_CONFIG_LPSR) {
+ base = (void *)IOMUXC_LPSR_BASE_ADDR;
+ mux_mode = ~IOMUX_CONFIG_LPSR;
+ /* set daisy chain sel_input */
+ if (sel_input_ofs)
+ sel_input_ofs += IOMUX_LPSR_SEL_INPUT_OFS;
+ }
+#endif
+
if (mux_ctrl_ofs)
__raw_writel(mux_mode, base + mux_ctrl_ofs);
@@ -55,6 +67,12 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
if (!(pad_ctrl NO_PAD_CTRL) pad_ctrl_ofs)
__raw_writel(pad_ctrl, base + pad_ctrl_ofs);
#endif
+
+#ifdef CONFIG_IOMUX_LPSR
+ if (lpsr == IOMUX_CONFIG_LPSR)
+ base = (void *)IOMUXC_BASE_ADDR;
+#endif
+
}
/* configures a list of pads within declared with IOMUX_PADS macro */
diff --git a/arch/arm/include/asm/arch-mx7/mx7-pins.h
b/arch/arm/include/asm/arch-mx7/mx7-pins.h
new file mode 100644
index 000..164c2be
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx7/mx7-pins.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef __ASM_ARCH_MX7_PINS_H__
+#define __ASM_ARCH_MX7_PINS_H__
+
+#include asm/imx-common/iomux-v3.h
+
+#if defined(CONFIG_MX7D)
+#include mx7d_pins.h
+#elif defined(CONFIG_MX7S)
+#include mx7s_pins.h
+#else
+#error Please select cpu
+#endif /* CONFIG_MX7D */
+
+#endif /*__ASM_ARCH_MX7_PINS_H__ */
diff --git a/arch/arm/include/asm/arch-mx7/mx7d_pins.h
b/arch/arm/include/asm/arch-mx7/mx7d_pins.h
new file mode 100644
index 000..d8b4097
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx7/mx7d_pins.h
@@ -0,0 +1,1308 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_IMX7D_PINS_H__
+#define __ASM_ARCH_IMX7D_PINS_H__
+
+#include asm/imx-common/iomux-v3.h
+
+enum {
+ MX7D_PAD_GPIO1_IO00__GPIO1_IO0 =
IOMUX_PAD(0x0030, 0x, IOMUX_CONFIG_LPSR | 0, 0x, 0, 0),
+ MX7D_PAD_GPIO1_IO00__PWM4_OUT=
IOMUX_PAD(0x0030, 0x, IOMUX_CONFIG_LPSR | 1, 0x, 0, 0),
+ MX7D_PAD_GPIO1_IO00__WDOG1_WDOG_B=
IOMUX_PAD(0x0030, 0x, IOMUX_CONFIG_LPSR | 3, 0x, 0, 0),
+
+ MX7D_PAD_GPIO1_IO01__GPIO1_IO1 =
IOMUX_PAD(0x0034, 0x0004, IOMUX_CONFIG_LPSR | 0, 0x, 0, 0),
+ MX7D_PAD_GPIO1_IO01__PWM1_OUT=
IOMUX_PAD(0x0034, 0x0004, IOMUX_CONFIG_LPSR | 1, 0x, 0, 0),
+ MX7D_PAD_GPIO1_IO01__CCM_ENET_REF_CLK3 =
IOMUX_PAD(0x0034, 0x0004, IOMUX_CONFIG_LPSR | 2, 0x, 0, 0),
+ MX7D_PAD_GPIO1_IO01__SAI1_MCLK =
IOMUX_PAD(0x0034, 0x0004, IOMUX_CONFIG_LPSR | 3, 0x, 0, 0),
+
+ MX7D_PAD_GPIO1_IO02__GPIO1_IO2 =
IOMUX_PAD(0x0038, 0x0008, IOMUX_CONFIG_LPSR | 0, 0x, 0, 0),
+ MX7D_PAD_GPIO1_IO02__PWM2_OUT=
IOMUX_PAD(0x0038, 0x0008, IOMUX_CONFIG_LPSR | 1, 0x, 0, 0),
+ MX7D_PAD_GPIO1_IO02__CCM_ENET_REF_CLK1 =
IOMUX_PAD(0x0038, 0x0008, IOMUX_CONFIG_LPSR | 2, 0x0564, 3, 0),
+ MX7D_PAD_GPIO1_IO02__SAI2_MCLK =
IOMUX_PAD(0x0038, 0x0008,
Re: [U-Boot] [PATCH 3/3] at91, taurus, smartweb: add dfu support
Hi Heiko,
[root@pollux dfu-util]# ./src/dfu-util -l
dfu-util 0.8
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-u...@lists.gnumonks.org
Found DFU: [0908:02d2] ver=0212, devnum=119, cfg=1, intf=0, alt=0,
name=Linux, serial=UNKNOWN [root@pollux dfu-util]#
Signed-off-by: Heiko Schocher h...@denx.de
---
board/siemens/smartweb/smartweb.c | 29 +
board/siemens/taurus/taurus.c | 27 +++
include/configs/smartweb.h| 34
++ include/configs/taurus.h
| 28 +++- 4 files changed, 113 insertions(+),
5 deletions(-)
diff --git a/board/siemens/smartweb/smartweb.c
b/board/siemens/smartweb/smartweb.c index cf8a7f5..2d42488 100644
--- a/board/siemens/smartweb/smartweb.c
+++ b/board/siemens/smartweb/smartweb.c
@@ -25,6 +25,7 @@
#include asm/arch/at91_pmc.h
#include asm/arch/at91_spi.h
#include spi.h
+#include asm/arch/clk.h
#include asm/arch/gpio.h
#include watchdog.h
#ifdef CONFIG_MACB
@@ -108,6 +109,29 @@ static void smartweb_macb_hw_init(void)
}
#endif /* CONFIG_MACB */
+#ifdef CONFIG_USB_GADGET_AT91
+#include linux/usb/at91_udc.h
+
+void at91_udp_hw_init(void)
+{
+ at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
+
+ /* Enable PLLB */
+ writel(get_pllb_init(), pmc-pllbr);
+ while ((readl(pmc-sr) AT91_PMC_LOCKB) != AT91_PMC_LOCKB)
+ ;
+
+ /* Enable UDPCK clock, MCK is enabled in at91_clock_init() */
+ at91_periph_clk_enable(ATMEL_ID_UDP);
+
+ writel(AT91SAM926x_PMC_UDP, pmc-scer);
+}
+
+struct at91_udc_data board_udc_data = {
+ .baseaddr = ATMEL_BASE_UDP0,
+};
+#endif
+
int board_early_init_f(void)
{
/* enable this here, as we have SPL without serial support */
@@ -134,6 +158,11 @@ int board_init(void)
at91_set_gpio_output(AT91_PIN_PC10, 0);
at91_set_gpio_output(AT91_PIN_PC11, 1);
+#ifdef CONFIG_USB_GADGET_AT91
+ at91_udp_hw_init();
+ at91_udc_probe(board_udc_data);
+#endif
+
return 0;
}
diff --git a/board/siemens/taurus/taurus.c
b/board/siemens/taurus/taurus.c index d10411c..54f67da 100644
--- a/board/siemens/taurus/taurus.c
+++ b/board/siemens/taurus/taurus.c
@@ -272,6 +272,29 @@ void spi_cs_deactivate(struct spi_slave *slave)
at91_set_gpio_value(TAURUS_SPI_CS_PIN, 1);
}
+#ifdef CONFIG_USB_GADGET_AT91
+#include linux/usb/at91_udc.h
+
+void at91_udp_hw_init(void)
+{
+ at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
+
+ /* Enable PLLB */
+ writel(get_pllb_init(), pmc-pllbr);
+ while ((readl(pmc-sr) AT91_PMC_LOCKB) != AT91_PMC_LOCKB)
+ ;
+
+ /* Enable UDPCK clock, MCK is enabled in at91_clock_init() */
+ at91_periph_clk_enable(ATMEL_ID_UDP);
+
+ writel(AT91SAM926x_PMC_UDP, pmc-scer);
+}
+
+struct at91_udc_data board_udc_data = {
+ .baseaddr = ATMEL_BASE_UDP0,
+};
+#endif
+
int board_init(void)
{
/* adress of boot parameters */
@@ -284,6 +307,10 @@ int board_init(void)
taurus_macb_hw_init();
#endif
at91_spi0_hw_init(TAURUS_SPI_MASK);
+#ifdef CONFIG_USB_GADGET_AT91
+ at91_udp_hw_init();
+ at91_udc_probe(board_udc_data);
+#endif
return 0;
}
diff --git a/include/configs/smartweb.h b/include/configs/smartweb.h
index 9f22139..baec73b 100644
--- a/include/configs/smartweb.h
+++ b/include/configs/smartweb.h
@@ -75,7 +75,7 @@
/* Size of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN \
- ROUND(3 * CONFIG_ENV_SIZE + (128 10), 0x1000)
+ ROUND(3 * CONFIG_ENV_SIZE + 4*1024*1024, 0x1000)
/* NAND flash settings */
#define CONFIG_NAND_ATMEL
@@ -140,15 +140,42 @@
#if !defined(CONFIG_SPL_BUILD)
/* USB configuration */
+#define CONFIG_CMD_USB
#define CONFIG_USB_ATMEL
#define CONFIG_USB_ATMEL_CLK_SEL_PLLB
#define CONFIG_USB_OHCI_NEW
-#define CONFIG_USB_STORAGE
-#define CONFIG_DOS_PARTITION
#define CONFIG_SYS_USB_OHCI_CPU_INIT
#define CONFIG_SYS_USB_OHCI_REGS_BASEATMEL_UHP_BASE
#define CONFIG_SYS_USB_OHCI_SLOT_NAMEat91sam9260
#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2
+
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_USB_ETHER_MCS7830
+
+/* USB DFU support */
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_MTD_DEVICE
+#define CONFIG_MTD_PARTITIONS
+
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_AT91
+
+/* DFU class support */
+#define CONFIG_CMD_DFU
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_NAND
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_USB_GADGET_VBUS_DRAW 2
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE (1 20)
+#define DFU_MANIFEST_POLL_TIMEOUT25000
+
+/* USB DFU IDs */
+#define CONFIG_G_DNL_VENDOR_NUM 0x0908
+#define
Re: [U-Boot] [PATCH 1/5] arm: mvebu: Add SPL SDIO/MMC boot support
Hi Albert, On 21.07.2015 09:24, Albert ARIBAUD wrote: On Mon, 20 Jul 2015 11:20:36 +0200, Stefan Roese s...@denx.de wrote: This patch adds basic SDIO/MMC booting support to MVEBU SoC's. Since I don't know of a way to test the boot-device upon runtime, this patch hardcodes the spl_boot_device instead. Not sure about 6820, but for 6710 this info can be traced back from the functional spec [1] to the device data sheet [2] as the sample-at-reset (SAR) data, which (for the 6710 at least) is an embedded XLS sheet [3]. Maybe you can find the same info for 6820? For 6710: [1] 88F6710, 88F6707, and 88F6W11 ARMADA ® 370 SoC Functional Specifications – Unrestricted Doc. No. MV-S107979-U0, Rev. B [2] 88F6710, 88F6707, and 88F6W11 ARMADA ® 370 SoC Hardware Specifications Doc. No. MV-S107978-00, Rev. G [3] Sample at Reset Table and Boot Source List tabs in 88F6707_Pin_information.xls Thanks Albert. Yes, this seems possible for AXP and A38x. I currently don't have access to the SD-card booting A38x platform though. So I would like to get this patch accepted now. And will send a patch for runtime boot-device detection later. Or perhaps somebody else will jump in... :) Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: Fix RTC build error on ivybridge
For some unknown reason, buildman does not report build error
when building commit 06c4b7e. This commit is to correct the
build error and needs to be squashed into commit 06c4b7e.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/ivybridge/lpc.c | 1 -
arch/x86/cpu/ivybridge/sdram.c | 32
arch/x86/dts/rtc.dtsi | 1 +
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/arch/x86/cpu/ivybridge/lpc.c b/arch/x86/cpu/ivybridge/lpc.c
index bc1a0f0..3efd3e8 100644
--- a/arch/x86/cpu/ivybridge/lpc.c
+++ b/arch/x86/cpu/ivybridge/lpc.c
@@ -252,7 +252,6 @@ static void pch_rtc_init(pci_dev_t dev)
/* TODO: Handle power failure */
if (rtc_failed)
printf(RTC power failed\n);
- rtc_init();
}
/* CougarPoint PCH Power Management init */
diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
index af907c5..7f3b13d 100644
--- a/arch/x86/cpu/ivybridge/sdram.c
+++ b/arch/x86/cpu/ivybridge/sdram.c
@@ -128,6 +128,14 @@ static int get_mrc_entry(struct udevice **devp, struct
fmap_entry *entry)
static int read_seed_from_cmos(struct pei_data *pei_data)
{
u16 c1, c2, checksum, seed_checksum;
+ struct udevice *dev;
+ int rcode = 0;
+
+ rcode = uclass_get_device(UCLASS_RTC, 0, dev);
+ if (rcode) {
+ debug(Cannot find RTC: err=%d\n, rcode);
+ return -ENODEV;
+ }
/*
* Read scrambler seeds from CMOS RAM. We don't want to store them in
@@ -135,11 +143,11 @@ static int read_seed_from_cmos(struct pei_data *pei_data)
* the flash too much. So we store these in CMOS and the large MRC
* data in SPI flash.
*/
- pei_data-scrambler_seed = rtc_read32(CMOS_OFFSET_MRC_SEED);
+ rtc_read32(dev, CMOS_OFFSET_MRC_SEED, pei_data-scrambler_seed);
debug(Read scrambler seed0x%08x from CMOS 0x%02x\n,
pei_data-scrambler_seed, CMOS_OFFSET_MRC_SEED);
- pei_data-scrambler_seed_s3 = rtc_read32(CMOS_OFFSET_MRC_SEED_S3);
+ rtc_read32(dev, CMOS_OFFSET_MRC_SEED_S3, pei_data-scrambler_seed_s3);
debug(Read S3 scrambler seed 0x%08x from CMOS 0x%02x\n,
pei_data-scrambler_seed_s3, CMOS_OFFSET_MRC_SEED_S3);
@@ -150,8 +158,8 @@ static int read_seed_from_cmos(struct pei_data *pei_data)
sizeof(u32));
checksum = add_ip_checksums(sizeof(u32), c1, c2);
- seed_checksum = rtc_read8(CMOS_OFFSET_MRC_SEED_CHK);
- seed_checksum |= rtc_read8(CMOS_OFFSET_MRC_SEED_CHK + 1) 8;
+ seed_checksum = rtc_read8(dev, CMOS_OFFSET_MRC_SEED_CHK);
+ seed_checksum |= rtc_read8(dev, CMOS_OFFSET_MRC_SEED_CHK + 1) 8;
if (checksum != seed_checksum) {
debug(%s: invalid seed checksum\n, __func__);
@@ -223,13 +231,21 @@ static int build_mrc_data(struct mrc_data_container
**datap)
static int write_seeds_to_cmos(struct pei_data *pei_data)
{
u16 c1, c2, checksum;
+ struct udevice *dev;
+ int rcode = 0;
+
+ rcode = uclass_get_device(UCLASS_RTC, 0, dev);
+ if (rcode) {
+ debug(Cannot find RTC: err=%d\n, rcode);
+ return -ENODEV;
+ }
/* Save the MRC seed values to CMOS */
- rtc_write32(CMOS_OFFSET_MRC_SEED, pei_data-scrambler_seed);
+ rtc_write32(dev, CMOS_OFFSET_MRC_SEED, pei_data-scrambler_seed);
debug(Save scrambler seed0x%08x to CMOS 0x%02x\n,
pei_data-scrambler_seed, CMOS_OFFSET_MRC_SEED);
- rtc_write32(CMOS_OFFSET_MRC_SEED_S3, pei_data-scrambler_seed_s3);
+ rtc_write32(dev, CMOS_OFFSET_MRC_SEED_S3, pei_data-scrambler_seed_s3);
debug(Save s3 scrambler seed 0x%08x to CMOS 0x%02x\n,
pei_data-scrambler_seed_s3, CMOS_OFFSET_MRC_SEED_S3);
@@ -240,8 +256,8 @@ static int write_seeds_to_cmos(struct pei_data *pei_data)
sizeof(u32));
checksum = add_ip_checksums(sizeof(u32), c1, c2);
- rtc_write8(CMOS_OFFSET_MRC_SEED_CHK, checksum 0xff);
- rtc_write8(CMOS_OFFSET_MRC_SEED_CHK + 1, (checksum 8) 0xff);
+ rtc_write8(dev, CMOS_OFFSET_MRC_SEED_CHK, checksum 0xff);
+ rtc_write8(dev, CMOS_OFFSET_MRC_SEED_CHK + 1, (checksum 8) 0xff);
return 0;
}
diff --git a/arch/x86/dts/rtc.dtsi b/arch/x86/dts/rtc.dtsi
index 93dacd7..1797e04 100644
--- a/arch/x86/dts/rtc.dtsi
+++ b/arch/x86/dts/rtc.dtsi
@@ -1,6 +1,7 @@
/ {
rtc {
compatible = motorola,mc146818;
+ u-boot,dm-pre-reloc;
reg = 0x70 2;
};
};
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/3] mtd: nand: mxs check maximum ecc that platfrom supports
Check maximum ecc strength for each platfrom to avoid the calculated ecc
exceed the limitation.
Signed-off-by: Peng Fan peng@freescale.com
Signed-off-by: Han Xu b45...@freescale.com
Reviewed-by: Marek Vasut ma...@denx.de
---
Changes v2:
Add Marek's reviewed by.
drivers/mtd/nand/mxs_nand.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 33ce817..97011b2 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -149,6 +149,13 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t
page_data_size,
uint32_t page_oob_size)
{
int ecc_strength;
+ int max_ecc_strength_supported;
+
+ /* Refer to Chapter 17 for i.MX6DQ, Chapter 18 for i.MX6SX */
+ if (is_cpu_type(MXC_CPU_MX6SX))
+ max_ecc_strength_supported = 62;
+ else
+ max_ecc_strength_supported = 40;
/*
* Determine the ECC layout with the formula:
@@ -162,7 +169,7 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t
page_data_size,
/ (galois_field *
mxs_nand_ecc_chunk_cnt(page_data_size));
- return round_down(ecc_strength, 2);
+ return min(round_down(ecc_strength, 2), max_ecc_strength_supported);
}
static inline uint32_t mxs_nand_get_mark_offset(uint32_t page_data_size,
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH resend V2 1/3] mtd: nand: mxs support oobsize bigger than 512
If ecc chunk data size is 512 and oobsize is bigger than 512, there is
a chance that block_mark_bit_offset conflicts with bch ecc area.
The following graph is modified from kernel gpmi-nand.c driver with
each data block 512 bytes. We can see that Block Mark conflicts with
ecc area from bch view. We can enlarge the ecc chunk size to avoid
this problem to those oobsize which is larger than 512.
| P|
|-|
| |
|(Block Mark) |
| P' | | | |
|---| D | | O'|
| |-| |-|
V V V V V
+---+--+-+--+-+--+-+--+-+---+
| M | data |E| data |E| data |E| data |E| |
+---+--+-+--+-+--+-+--+-+---+
^ ^
| O|
||
P : the page size for BCH module.
E : The ECC strength.
G : the length of Galois Field.
N : The chunk count of per page.
M : the metasize of per page.
C : the ecc chunk size, aka the data above.
P': the nand chip's page size.
O : the nand chip's oob size.
O': the free oob.
Signed-off-by: Peng Fan peng@freescale.com
Reviewed-by: Marek Vasut ma...@denx.de
---
Changes v2:
none
Changes v1:
The previous patch is https://patchwork.ozlabs.org/patch/422757/
This version contains a minor change to the name from gf_len to galois_field.
Also add Marek's Reviewed-by.
arch/arm/include/asm/imx-common/regs-bch.h | 2 ++
drivers/mtd/nand/mxs_nand.c| 32 +-
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/imx-common/regs-bch.h
b/arch/arm/include/asm/imx-common/regs-bch.h
index a33d341..5c47783 100644
--- a/arch/arm/include/asm/imx-common/regs-bch.h
+++ b/arch/arm/include/asm/imx-common/regs-bch.h
@@ -148,6 +148,7 @@ struct mxs_bch_regs {
#defineBCH_FLASHLAYOUT0_ECC0_ECC30 (0xf 12)
#defineBCH_FLASHLAYOUT0_ECC0_ECC32 (0x10 12)
#defineBCH_FLASHLAYOUT0_GF13_0_GF14_1 (1 10)
+#defineBCH_FLASHLAYOUT0_GF13_0_GF14_1_OFFSET 10
#defineBCH_FLASHLAYOUT0_DATA0_SIZE_MASK0xfff
#defineBCH_FLASHLAYOUT0_DATA0_SIZE_OFFSET 0
@@ -178,6 +179,7 @@ struct mxs_bch_regs {
#defineBCH_FLASHLAYOUT1_ECCN_ECC30 (0xf 12)
#defineBCH_FLASHLAYOUT1_ECCN_ECC32 (0x10 12)
#defineBCH_FLASHLAYOUT1_GF13_0_GF14_1 (1 10)
+#defineBCH_FLASHLAYOUT1_GF13_0_GF14_1_OFFSET 10
#defineBCH_FLASHLAYOUT1_DATAN_SIZE_MASK0xfff
#defineBCH_FLASHLAYOUT1_DATAN_SIZE_OFFSET 0
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 9c144a2..33ce817 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -68,6 +68,8 @@ struct mxs_nand_info {
};
struct nand_ecclayout fake_ecc_layout;
+static int chunk_data_size = MXS_NAND_CHUNK_DATA_CHUNK_SIZE;
+static int galois_field = 13;
/*
* Cache management functions
@@ -130,12 +132,12 @@ static void mxs_nand_return_dma_descs(struct
mxs_nand_info *info)
static uint32_t mxs_nand_ecc_chunk_cnt(uint32_t page_data_size)
{
- return page_data_size / MXS_NAND_CHUNK_DATA_CHUNK_SIZE;
+ return page_data_size / chunk_data_size;
}
static uint32_t mxs_nand_ecc_size_in_bits(uint32_t ecc_strength)
{
- return ecc_strength * MXS_NAND_BITS_PER_ECC_LEVEL;
+ return ecc_strength * galois_field;
}
static uint32_t mxs_nand_aux_status_offset(void)
@@ -157,8 +159,8 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t
page_data_size,
* (page oob size - meta data size) * (bits per byte)
*/
ecc_strength = ((page_oob_size - MXS_NAND_METADATA_SIZE) * 8)
- / (MXS_NAND_BITS_PER_ECC_LEVEL *
- mxs_nand_ecc_chunk_cnt(page_data_size));
+ / (galois_field *
+ mxs_nand_ecc_chunk_cnt(page_data_size));
return round_down(ecc_strength, 2);
}
@@ -173,7 +175,7 @@ static inline uint32_t mxs_nand_get_mark_offset(uint32_t
page_data_size,
uint32_t
Re: [U-Boot] [PATCH 2/3] usb: gadget: at91_udc: add support for at91_udc
Hi Heiko, ported from linux: b2ba27a5c56ff: usb: gadget: at91_udc: move prepare clk into process context IMHO, presented above description is not enough. I'd prefer to see one patch which adds the code from linux - including the exact commit message. Then, u-boot specific adjustments should be applied in a separate patch. In that way you would: 1. Avoid #ifdef __UBOOT__ 2. Make the process of updating code easier Signed-off-by: Heiko Schocher h...@denx.de --- checkpatch detects a lot of errors, but as this code is copied from linux, I tend to not fix them, so later updates with linux code is easier. drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/at91_udc.c | 2203 + drivers/usb/gadget/at91_udc.h | 171 include/linux/usb/at91_udc.h | 20 + 4 files changed, 2395 insertions(+) create mode 100644 drivers/usb/gadget/at91_udc.c create mode 100644 drivers/usb/gadget/at91_udc.h create mode 100644 include/linux/usb/at91_udc.h diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 70bb550..22323fa 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_USB_ETHER) += epautoconf.o config.o usbstring.o # new USB gadget layer dependencies ifdef CONFIG_USB_GADGET +obj-$(CONFIG_USB_GADGET_AT91) += at91_udc.o obj-$(CONFIG_USB_GADGET_ATMEL_USBA) += atmel_usba_udc.o obj-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o obj-$(CONFIG_USB_GADGET_S3C_UDC_OTG_PHY) += s3c_udc_otg_phy.o diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c new file mode 100644 index 000..f4ae13b --- /dev/null +++ b/drivers/usb/gadget/at91_udc.c @@ -- 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] checkarmreloc error for AArch64 (using vexpress_aemv8a_defconfig)
Hello David J, On Mon, 20 Jul 2015 22:17:49 +, Chou, David J david.j.c...@intel.com wrote: Hello Albert, You are right. it seems the file' program in my Ubuntu- 12.04.5 LTS system doesn't have the aarch64 database of signatures as you said. But If I moved the 64 bit u-boot I built in my Ubuntu- 12.04.5 LTS system to an Ubuntu14.04.02 LTS system, the file u-boot shows u-boot: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), statically linked, not stripped. So, can I conclude the way I build aarch64 u-boot by following is correct? $ make distclean $ make vexpress_aemv8a_juno_defconfig $ make all ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- This is one way of building U-Boot, indeed, which should amount to the same as the Building the Software instructions given in the README file. Thanks. Best Regards, David Chou Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] arm: mvebu: Add SPL SDIO/MMC boot support
Hello Stefan, On Mon, 20 Jul 2015 11:20:36 +0200, Stefan Roese s...@denx.de wrote: This patch adds basic SDIO/MMC booting support to MVEBU SoC's. Since I don't know of a way to test the boot-device upon runtime, this patch hardcodes the spl_boot_device instead. Not sure about 6820, but for 6710 this info can be traced back from the functional spec [1] to the device data sheet [2] as the sample-at-reset (SAR) data, which (for the 6710 at least) is an embedded XLS sheet [3]. Maybe you can find the same info for 6820? For 6710: [1] 88F6710, 88F6707, and 88F6W11 ARMADA ® 370 SoC Functional Specifications – Unrestricted Doc. No. MV-S107979-U0, Rev. B [2] 88F6710, 88F6707, and 88F6W11 ARMADA ® 370 SoC Hardware Specifications Doc. No. MV-S107978-00, Rev. G [3] Sample at Reset Table and Boot Source List tabs in 88F6707_Pin_information.xls Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] kwbimage: Rename CONFIG_SYS_SPI_U_BOOT_OFFS to CONFIG_SYS_U_BOOT_OFFS
Hi Albert, On 21.07.2015 09:37, Albert ARIBAUD wrote: On Mon, 20 Jul 2015 11:20:38 +0200, Stefan Roese s...@denx.de wrote: To use this offset for other boot device (like SDIO/MMC), lets rename it to a more generic name. This will be used be the SDIO/MMC SPL boot support for the A38x. Hmm, what if SPL gets support for booting from several sources with different U-Boot offsets for different sources? If this happens then lets deal with it. For now I prefer to not add a new define / macro, if the current one can handle both supported cases. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/3] mtd: nand: mxs invalidate dcache before DMA read
Follow linux dma flow:
Before DMA read, be sure to invalidate the cache over the address
range of DMA buffer to prevent cache coherency problems.
After DMA read, invalidate dcache again.
Signed-off-by: Peng Fan peng@freescale.com
Acked-by: Marek Vasut ma...@denx.de
---
Changes v2:
Add Marek's Acked by
drivers/mtd/nand/mxs_nand.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 97011b2..f15cf36 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -469,6 +469,9 @@ static void mxs_nand_read_buf(struct mtd_info *mtd, uint8_t
*buf, int length)
mxs_dma_desc_append(channel, d);
+ /* Invalidate caches */
+ mxs_nand_inval_data_buf(nand_info);
+
/* Execute the DMA chain. */
ret = mxs_dma_go(channel);
if (ret) {
@@ -635,6 +638,9 @@ static int mxs_nand_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *nand,
mxs_dma_desc_append(channel, d);
+ /* Invalidate caches */
+ mxs_nand_inval_data_buf(nand_info);
+
/* Execute the DMA chain. */
ret = mxs_dma_go(channel);
if (ret) {
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] x86: qemu: Enable writing MP table
Enable writing MP table for QEMU boads (i440fx and q35).
Signed-off-by: Bin Meng bmeng...@gmail.com
---
Changes in v2:
- Drop QEMU mp_init patch
- Change /cpus node to include just one cpu
arch/x86/cpu/qemu/pci.c | 34 +++---
arch/x86/dts/qemu-x86_i440fx.dts | 12
arch/x86/dts/qemu-x86_q35.dts| 12
configs/qemu-x86_defconfig | 3 +++
4 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu/qemu/pci.c b/arch/x86/cpu/qemu/pci.c
index ab93e76..acbd922 100644
--- a/arch/x86/cpu/qemu/pci.c
+++ b/arch/x86/cpu/qemu/pci.c
@@ -13,6 +13,8 @@
DECLARE_GLOBAL_DATA_PTR;
+static bool i440fx;
+
void board_pci_setup_hose(struct pci_controller *hose)
{
hose-first_busno = 0;
@@ -61,7 +63,8 @@ int board_pci_post_scan(struct pci_controller *hose)
* PCI device ID.
*/
device = x86_pci_read_config16(PCI_BDF(0, 0, 0), PCI_DEVICE_ID);
- pam = (device == PCI_DEVICE_ID_INTEL_82441) ? I440FX_PAM : Q35_PAM;
+ i440fx = (device == PCI_DEVICE_ID_INTEL_82441);
+ pam = i440fx ? I440FX_PAM : Q35_PAM;
/*
* Initialize Programmable Attribute Map (PAM) Registers
@@ -71,7 +74,7 @@ int board_pci_post_scan(struct pci_controller *hose)
for (i = 0; i PAM_NUM; i++)
x86_pci_write_config8(PCI_BDF(0, 0, 0), pam + i, PAM_RW);
- if (device == PCI_DEVICE_ID_INTEL_82441) {
+ if (i440fx) {
/*
* Enable legacy IDE I/O ports decode
*
@@ -97,10 +100,35 @@ int board_pci_post_scan(struct pci_controller *hose)
* board, it shows as device 2, while for Q35 and ICH9 chipset board,
* it shows as device 1.
*/
- vga = (device == PCI_DEVICE_ID_INTEL_82441) ? I440FX_VGA : Q35_VGA;
+ vga = i440fx ? I440FX_VGA : Q35_VGA;
start = get_timer(0);
ret = pci_run_vga_bios(vga, NULL, PCI_ROM_USE_NATIVE);
debug(BIOS ran in %lums\n, get_timer(start));
return ret;
}
+
+#ifdef CONFIG_GENERATE_MP_TABLE
+int mp_determine_pci_dstirq(int bus, int dev, int func, int pirq)
+{
+ u8 irq;
+
+ if (i440fx) {
+ /*
+* Not like most x86 platforms, the PIRQ[A-D] on PIIX3 are not
+* connected to I/O APIC INTPIN#16-19. Instead they are routed
+* to an irq number controled by the PIRQ routing register.
+*/
+ irq = x86_pci_read_config8(PCI_BDF(bus, dev, func),
+ PCI_INTERRUPT_LINE);
+ } else {
+ /*
+* ICH9's PIRQ[A-H] are not consecutive numbers from 0 to 7.
+* PIRQ[A-D] still maps to [0-3] but PIRQ[E-H] maps to [8-11].
+*/
+ irq = pirq 8 ? pirq + 16 : pirq + 12;
+ }
+
+ return irq;
+}
+#endif
diff --git a/arch/x86/dts/qemu-x86_i440fx.dts b/arch/x86/dts/qemu-x86_i440fx.dts
index 0c522c8..c26c71b 100644
--- a/arch/x86/dts/qemu-x86_i440fx.dts
+++ b/arch/x86/dts/qemu-x86_i440fx.dts
@@ -24,6 +24,18 @@
stdout-path = /serial;
};
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = cpu-x86;
+ reg = 0;
+ intel,apic-id = 0;
+ };
+ };
+
pci {
compatible = pci-x86;
#address-cells = 3;
diff --git a/arch/x86/dts/qemu-x86_q35.dts b/arch/x86/dts/qemu-x86_q35.dts
index 5fbabc2..2e785fa 100644
--- a/arch/x86/dts/qemu-x86_q35.dts
+++ b/arch/x86/dts/qemu-x86_q35.dts
@@ -35,6 +35,18 @@
stdout-path = /serial;
};
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = cpu-x86;
+ reg = 0;
+ intel,apic-id = 0;
+ };
+ };
+
pci {
compatible = pci-x86;
#address-cells = 3;
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index a4c20bd..4b18d51 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -1,6 +1,8 @@
CONFIG_X86=y
CONFIG_DEFAULT_DEVICE_TREE=qemu-x86_i440fx
CONFIG_GENERATE_PIRQ_TABLE=y
+CONFIG_GENERATE_MP_TABLE=y
+CONFIG_CMD_CPU=y
# CONFIG_CMD_IMLS is not set
# CONFIG_CMD_FLASH is not set
# CONFIG_CMD_SETEXPR is not set
@@ -9,6 +11,7 @@ CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
CONFIG_CMD_BOOTSTAGE=y
CONFIG_OF_CONTROL=y
+CONFIG_CPU=y
CONFIG_SPI_FLASH=y
CONFIG_VIDEO_VESA=y
CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] x86: qemu: Turn on PCIe ECAM address range decoding on Q35
Turn on PCIe ECAM address range decoding on Q35.
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v2: None
arch/x86/cpu/qemu/pci.c | 4
arch/x86/include/asm/arch-qemu/qemu.h | 4
2 files changed, 8 insertions(+)
diff --git a/arch/x86/cpu/qemu/pci.c b/arch/x86/cpu/qemu/pci.c
index acbd922..2e94456 100644
--- a/arch/x86/cpu/qemu/pci.c
+++ b/arch/x86/cpu/qemu/pci.c
@@ -90,6 +90,10 @@ int board_pci_post_scan(struct pci_controller *hose)
xbcs = x86_pci_read_config16(PIIX_ISA, XBCS);
xbcs |= APIC_EN;
x86_pci_write_config16(PIIX_ISA, XBCS, xbcs);
+ } else {
+ /* Configure PCIe ECAM base address */
+ x86_pci_write_config32(PCI_BDF(0, 0, 0), PCIEX_BAR,
+ CONFIG_PCIE_ECAM_BASE | BAR_EN);
}
/*
diff --git a/arch/x86/include/asm/arch-qemu/qemu.h
b/arch/x86/include/asm/arch-qemu/qemu.h
index 8c8e4ac..b67d342 100644
--- a/arch/x86/include/asm/arch-qemu/qemu.h
+++ b/arch/x86/include/asm/arch-qemu/qemu.h
@@ -22,6 +22,10 @@
#define IDE1_TIM 0x42
#define IDE_DECODE_EN (1 15)
+/* PCIe ECAM Base Address Register */
+#define PCIEX_BAR 0x60
+#define BAR_EN (1 0)
+
/* I/O Ports */
#define CMOS_ADDR_PORT 0x70
#define CMOS_DATA_PORT 0x71
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] x86: Allow cpu-x86 driver to be probed for UP
Currently cpu-x86 driver is probed only for SMP. We add the same support for UP when there is only one cpu node in the deive tree. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to allow cpu-x86 driver to be probed for UP arch/x86/cpu/cpu.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c index b4e0fd9..1c69a18 100644 --- a/arch/x86/cpu/cpu.c +++ b/arch/x86/cpu/cpu.c @@ -35,6 +35,7 @@ #include asm/processor-flags.h #include asm/interrupt.h #include asm/tables.h +#include dm/device-internal.h #include linux/compiler.h DECLARE_GLOBAL_DATA_PTR; @@ -696,6 +697,12 @@ __weak int x86_init_cpus(void) #ifdef CONFIG_SMP debug(Init additional CPUs\n); x86_mp_init(); +#else + struct udevice *dev = NULL; + + uclass_first_device(UCLASS_CPU, dev); + if (dev) + device_probe(dev); #endif return 0; -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] x86: Reserve PCIe ECAM address range in the E820 table
We should mark PCIe ECAM address range in the E820 table as reserved otherwise kernel will not attempt to use ECAM. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to reserve PCIe ECAM address range in the E820 table arch/x86/Kconfig| 10 ++ arch/x86/lib/fsp/fsp_dram.c | 6 ++ arch/x86/lib/zimage.c | 5 - 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index cbbaa4f..e8968a7 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -369,4 +369,14 @@ config PCIE_ECAM_BASE assigned to PCI devices - i.e. the memory and prefetch regions, as passed to pci_set_region(). +config PCIE_ECAM_SIZE + hex + default 0x1000 + help + This is the size of memory-mapped address of PCI configuration space, + which is only available through the Enhanced Configuration Access + Mechanism (ECAM) with PCI Express. Each bus consumes 1 MiB memory, + so a default 0x1000 size covers all of the 256 buses which is the + maximum number of PCI buses as defined by the PCI specification. + endmenu diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c index 4c0a7c8..28552fa 100644 --- a/arch/x86/lib/fsp/fsp_dram.c +++ b/arch/x86/lib/fsp/fsp_dram.c @@ -77,5 +77,11 @@ unsigned install_e820_map(unsigned max_entries, struct e820entry *entries) num_entries++; } + /* Mark PCIe ECAM address range as reserved */ + entries[num_entries].addr = CONFIG_PCIE_ECAM_BASE; + entries[num_entries].size = CONFIG_PCIE_ECAM_SIZE; + entries[num_entries].type = E820_RESERVED; + num_entries++; + return num_entries; } diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c index 144471c..a1ec57e 100644 --- a/arch/x86/lib/zimage.c +++ b/arch/x86/lib/zimage.c @@ -61,8 +61,11 @@ __weak unsigned install_e820_map(unsigned max_entries, entries[2].addr = ISA_END_ADDRESS; entries[2].size = gd-ram_size - ISA_END_ADDRESS; entries[2].type = E820_RAM; + entries[3].addr = CONFIG_PCIE_ECAM_BASE; + entries[3].size = CONFIG_PCIE_ECAM_SIZE; + entries[3].type = E820_RESERVED; - return 3; + return 4; } static void build_command_line(char *command_line, int auto_boot) -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/7] x86: qemu: Enable I/O APIC chip select on PIIX3
The PIIX3 chipset does not integrate an I/O APIC, instead it supports
connecting to an external I/O APIC which needs to be enabled manually.
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v2: None
arch/x86/cpu/qemu/pci.c | 7 ++-
arch/x86/include/asm/arch-qemu/qemu.h | 6 +-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/cpu/qemu/pci.c b/arch/x86/cpu/qemu/pci.c
index 1a9140b..ab93e76 100644
--- a/arch/x86/cpu/qemu/pci.c
+++ b/arch/x86/cpu/qemu/pci.c
@@ -50,7 +50,7 @@ void board_pci_setup_hose(struct pci_controller *hose)
int board_pci_post_scan(struct pci_controller *hose)
{
int ret = 0;
- u16 device;
+ u16 device, xbcs;
int pam, i;
pci_dev_t vga;
ulong start;
@@ -82,6 +82,11 @@ int board_pci_post_scan(struct pci_controller *hose)
*/
x86_pci_write_config16(PIIX_IDE, IDE0_TIM, IDE_DECODE_EN);
x86_pci_write_config16(PIIX_IDE, IDE1_TIM, IDE_DECODE_EN);
+
+ /* Enable I/O APIC */
+ xbcs = x86_pci_read_config16(PIIX_ISA, XBCS);
+ xbcs |= APIC_EN;
+ x86_pci_write_config16(PIIX_ISA, XBCS, xbcs);
}
/*
diff --git a/arch/x86/include/asm/arch-qemu/qemu.h
b/arch/x86/include/asm/arch-qemu/qemu.h
index 5cb..8c8e4ac 100644
--- a/arch/x86/include/asm/arch-qemu/qemu.h
+++ b/arch/x86/include/asm/arch-qemu/qemu.h
@@ -13,10 +13,14 @@
#define PAM_NUM7
#define PAM_RW 0x33
+/* X-Bus Chip Select Register */
+#define XBCS 0x4e
+#define APIC_EN(1 8)
+
/* IDE Timing Register */
#define IDE0_TIM 0x40
#define IDE1_TIM 0x42
-#define IDE_DECODE_EN 0x8000
+#define IDE_DECODE_EN (1 15)
/* I/O Ports */
#define CMOS_ADDR_PORT 0x70
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] x86: mpspec: Allow platform to determine how PIRQ is connected to I/O APIC
Currently during writing MP table I/O interrupt assignment entry, we
assume the PIRQ is directly mapped to I/O APIC INTPIN#16-23, which
however is not always the case on some platforms.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
Changes in v2:
- Drop patches that are already applied
- Add a TODO comment above mp_determine_pci_dstirq()
arch/x86/include/asm/mpspec.h | 17 +
arch/x86/lib/mpspec.c | 24 +---
2 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index efa9231..ad8eba9 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -432,6 +432,23 @@ void mp_write_compat_address_space(struct mp_config_table
*mc, int busid,
u32 mptable_finalize(struct mp_config_table *mc);
/**
+ * mp_determine_pci_dstirq() - Determine PCI device's int pin on the I/O APIC
+ *
+ * This determines a PCI device's interrupt pin number on the I/O APIC.
+ *
+ * This can be implemented by platform codes to handle specifal cases, which
+ * do not conform to the normal chipset/board design where PIRQ[A-H] are mapped
+ * directly to I/O APIC INTPIN#16-23.
+ *
+ * @bus: bus number of the pci device
+ * @dev: device number of the pci device
+ * @func: function number of the pci device
+ * @pirq: PIRQ number the PCI device's interrupt pin is routed to
+ * @return:interrupt pin number on the I/O APIC
+ */
+int mp_determine_pci_dstirq(int bus, int dev, int func, int pirq);
+
+/**
* write_mp_table() - Write MP table
*
* This writes MP table at a given address.
diff --git a/arch/x86/lib/mpspec.c b/arch/x86/lib/mpspec.c
index f16fbcb..9b2a59b 100644
--- a/arch/x86/lib/mpspec.c
+++ b/arch/x86/lib/mpspec.c
@@ -269,6 +269,13 @@ static bool check_dup_entry(struct mpc_config_intsrc
*intsrc_base,
return (i == entry_num) ? false : true;
}
+/* TODO: move this to driver model */
+__weak int mp_determine_pci_dstirq(int bus, int dev, int func, int pirq)
+{
+ /* PIRQ[A-H] are connected to I/O APIC INTPIN#16-23 */
+ return pirq + 16;
+}
+
static int mptable_add_intsrc(struct mp_config_table *mc,
int bus_isa, int apicid)
{
@@ -304,24 +311,27 @@ static int mptable_add_intsrc(struct mp_config_table *mc,
for (i = 0; i count; i++) {
struct pirq_routing pr;
+ int bus, dev, func;
+ int dstirq;
pr.bdf = fdt_addr_to_cpu(cell[0]);
pr.pin = fdt_addr_to_cpu(cell[1]);
pr.pirq = fdt_addr_to_cpu(cell[2]);
+ bus = PCI_BUS(pr.bdf);
+ dev = PCI_DEV(pr.bdf);
+ func = PCI_FUNC(pr.bdf);
if (check_dup_entry(intsrc_base, intsrc_entries,
- PCI_BUS(pr.bdf), PCI_DEV(pr.bdf), pr.pin)) {
+ bus, dev, pr.pin)) {
debug(found entry for bus %d device %d INT%c,
skipping\n,
- PCI_BUS(pr.bdf), PCI_DEV(pr.bdf),
- 'A' + pr.pin - 1);
+ bus, dev, 'A' + pr.pin - 1);
cell += sizeof(struct pirq_routing) / sizeof(u32);
continue;
}
- /* PIRQ[A-H] are always connected to I/O APIC INTPIN#16-23 */
- mp_write_pci_intsrc(mc, MP_INT, PCI_BUS(pr.bdf),
- PCI_DEV(pr.bdf), pr.pin, apicid,
- pr.pirq + 16);
+ dstirq = mp_determine_pci_dstirq(bus, dev, func, pr.pirq);
+ mp_write_pci_intsrc(mc, MP_INT, bus, dev, pr.pin,
+ apicid, dstirq);
intsrc_entries++;
cell += sizeof(struct pirq_routing) / sizeof(u32);
}
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] x86: mpspec: Move writing ISA interrupt entry after PCI
On some platforms the I/O APIC interrupt pin#0-15 may be connected
to platform pci devices' interrupt pin. In such cases the legacy ISA
IRQ is not available so we should not write ISA interrupt entry if
it is already occupied.
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v2: None
arch/x86/lib/mpspec.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/x86/lib/mpspec.c b/arch/x86/lib/mpspec.c
index 9b2a59b..f3ad116 100644
--- a/arch/x86/lib/mpspec.c
+++ b/arch/x86/lib/mpspec.c
@@ -21,6 +21,8 @@
DECLARE_GLOBAL_DATA_PTR;
+static bool isa_irq_occupied[16];
+
struct mp_config_table *mp_write_floating_table(struct mp_floating_table *mf)
{
u32 mc;
@@ -243,10 +245,18 @@ static void mptable_add_isa_interrupts(struct
mp_config_table *mc, int bus_isa,
MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH,
bus_isa, 0, apicid, 2);
- for (i = 3; i 16; i++)
+ for (i = 3; i 16; i++) {
+ /*
+* Do not write ISA interrupt entry if it is already occupied
+* by the platform devices.
+*/
+ if (isa_irq_occupied[i])
+ continue;
+
mp_write_intsrc(mc, MP_INT,
MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH,
bus_isa, i, apicid, i);
+ }
}
/*
@@ -287,10 +297,6 @@ static int mptable_add_intsrc(struct mp_config_table *mc,
const u32 *cell;
int i;
- /* Legacy Interrupts */
- debug(Writing ISA IRQs\n);
- mptable_add_isa_interrupts(mc, bus_isa, apicid, 0);
-
/* Get I/O interrupt information from device tree */
node = fdtdec_next_compatible(blob, 0, COMPAT_INTEL_IRQ_ROUTER);
if (node 0) {
@@ -330,12 +336,22 @@ static int mptable_add_intsrc(struct mp_config_table *mc,
}
dstirq = mp_determine_pci_dstirq(bus, dev, func, pr.pirq);
+ /*
+* For PIRQ which is connected to I/O APIC interrupt pin#0-15,
+* mark it as occupied so that we can skip it later.
+*/
+ if (dstirq 16)
+ isa_irq_occupied[dstirq] = true;
mp_write_pci_intsrc(mc, MP_INT, bus, dev, pr.pin,
apicid, dstirq);
intsrc_entries++;
cell += sizeof(struct pirq_routing) / sizeof(u32);
}
+ /* Legacy Interrupts */
+ debug(Writing ISA IRQs\n);
+ mptable_add_isa_interrupts(mc, bus_isa, apicid, 0);
+
return 0;
}
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix RTC build error on ivybridge
Hi Albert, On Tue, Jul 21, 2015 at 8:19 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Bin, On Tue, 21 Jul 2015 00:55:13 -0700, Bin Meng bmeng...@gmail.com wrote: For some unknown reason, buildman does not report build error when building commit 06c4b7e. This commit is to correct the build error and needs to be squashed into commit 06c4b7e. Which repository and branch contains this commit 06c4b7e? I cannot find it at all under u-boot/master. It is on the u-boot-x86/master. Besides, fixes are not done by squashing commit. Yep, I know that once something goes into mainline, it is not allowed to change any history. As this is on the u-boot-x86/master and Simon has not asked Tom to pull, I believe it is OK. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] x86: Add MP table support to QEMU
This patch series mainly add MP support to QEMU as well as some other necessary fixes for x86. Verified by booting Linux kernel on QEMU i440FX and Q35, and make sure I/O APIC interrupt is being used by the kernel with the help of MP table provided by U-Boot. This series is the prerequisite for the follow-up ACPI support which is currently being worked on by Saket. It seems that QEMU multicore emulation is sort of random, as the mp_init() does not realibly succeed on different machines with previous patch, this v2 does not include that patch, instead it just enabled MP table with UP mode. Changes in v2: - Drop patches that are already applied - Add a TODO comment above mp_determine_pci_dstirq() - New patch to allow cpu-x86 driver to be probed for UP - Drop QEMU mp_init patch - Change /cpus node to include just one cpu - New patch to reserve PCIe ECAM address range in the E820 table Bin Meng (7): x86: mpspec: Allow platform to determine how PIRQ is connected to I/O APIC x86: mpspec: Move writing ISA interrupt entry after PCI x86: qemu: Enable I/O APIC chip select on PIIX3 x86: Allow cpu-x86 driver to be probed for UP x86: qemu: Enable writing MP table x86: qemu: Turn on PCIe ECAM address range decoding on Q35 x86: Reserve PCIe ECAM address range in the E820 table arch/x86/Kconfig | 10 +++ arch/x86/cpu/cpu.c| 7 + arch/x86/cpu/qemu/pci.c | 45 --- arch/x86/dts/qemu-x86_i440fx.dts | 12 + arch/x86/dts/qemu-x86_q35.dts | 12 + arch/x86/include/asm/arch-qemu/qemu.h | 10 ++- arch/x86/include/asm/mpspec.h | 17 arch/x86/lib/fsp/fsp_dram.c | 6 + arch/x86/lib/mpspec.c | 50 ++- arch/x86/lib/zimage.c | 5 +++- configs/qemu-x86_defconfig| 3 +++ 11 files changed, 159 insertions(+), 18 deletions(-) -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix RTC build error on ivybridge
Hello Bin, On Tue, 21 Jul 2015 00:55:13 -0700, Bin Meng bmeng...@gmail.com wrote: For some unknown reason, buildman does not report build error when building commit 06c4b7e. This commit is to correct the build error and needs to be squashed into commit 06c4b7e. Which repository and branch contains this commit 06c4b7e? I cannot find it at all under u-boot/master. Besides, fixes are not done by squashing commit. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: tegra: Add Tegra20 SPI device nodes
On Mon, Jul 20, 2015 at 01:41:00PM +0200, Mirza Krak wrote:
From: Mirza Krak mirza.k...@hostmobility.com
Add the device tree node for the SPI controllers found on Tegra20 SOCs.
Signed-off-by: Mirza Krak mirza.k...@hostmobility.com
---
arch/arm/dts/tegra20.dtsi | 44
1 file changed, 44 insertions(+)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index b8c8a923017e..82168c9012e3 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -268,6 +268,50 @@
#pwm-cells = 2;
};
+ spi@7000d400 {
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
This can't be correct on Tegra20 since Tegra30 didn't exist at the time.
You'll need to drop the first string in the list for this to be correct.
Also, might be worth copying these from the Linux kernel's copy of the
device tree files, since they are slightly different. That might involve
pulling in a couple of headers too, though, so might not be worth it.
Thierry
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: tegra: Add Tegra20 SPI device nodes
2015-07-21 11:02 GMT+02:00 Thierry Reding tred...@nvidia.com:
On Mon, Jul 20, 2015 at 01:41:00PM +0200, Mirza Krak wrote:
From: Mirza Krak mirza.k...@hostmobility.com
Add the device tree node for the SPI controllers found on Tegra20 SOCs.
Signed-off-by: Mirza Krak mirza.k...@hostmobility.com
---
arch/arm/dts/tegra20.dtsi | 44
1 file changed, 44 insertions(+)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index b8c8a923017e..82168c9012e3 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -268,6 +268,50 @@
#pwm-cells = 2;
};
+ spi@7000d400 {
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
This can't be correct on Tegra20 since Tegra30 didn't exist at the time.
You'll need to drop the first string in the list for this to be correct.
Sent v2 of patch dropping tegra30 compatible string.
Also, might be worth copying these from the Linux kernel's copy of the
device tree files, since they are slightly different. That might involve
pulling in a couple of headers too, though, so might not be worth it.
Thierry
Pulling from Linux kernel's copy of these files is not something I am
up for at the moment.
--
Med Vänliga Hälsningar / Best Regards
***
Mirza Krak
Host Mobility AB
mirza.k...@hostmobility.com
Anders Personsgatan 12, 416 64 Göteborg
Sweden
http://www.hostmobility.com
Direct: +46 31 31 32 704
Phone: +46 31 31 32 700
Fax: +46 31 80 67 51
Mobile: +46 730 28 06 22
***
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] mtd: nand: mxs invalidate dcache before DMA read
On Tuesday, July 21, 2015 at 10:15:21 AM, Peng Fan wrote: Follow linux dma flow: Before DMA read, be sure to invalidate the cache over the address range of DMA buffer to prevent cache coherency problems. After DMA read, invalidate dcache again. Signed-off-by: Peng Fan peng@freescale.com Acked-by: Marek Vasut ma...@denx.de --- Changes v2: Add Marek's Acked by You really don't have to repost patches just because an ACK was added ;-) Patchwork collects those, so don't worry about them getting lost. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: tegra: Add Tegra20 SPI device nodes
From: Mirza Krak mirza.k...@hostmobility.com
Add the device tree node for the SPI controllers found on Tegra20 SOCs.
Signed-off-by: Mirza Krak mirza.k...@hostmobility.com
---
Changes in v2:
* Dropped tegra30-slink compatible string, based on comment from Thierry Reding
on v1 patch
arch/arm/dts/tegra20.dtsi | 44
1 file changed, 44 insertions(+)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index b8c8a923017e..e4d7c7a83473 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -268,6 +268,50 @@
#pwm-cells = 2;
};
+ spi@7000d400 {
+ compatible = nvidia,tegra20-slink;
+ reg = 0x7000d400 0x200;
+ interrupts = 0 59 0x04;
+ nvidia,dma-request-selector = apbdma 15;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = tegra_car 41;
+ status = disabled;
+ };
+
+ spi@7000d600 {
+ compatible = nvidia,tegra20-slink;
+ reg = 0x7000d600 0x200;
+ interrupts = 0 82 0x04;
+ nvidia,dma-request-selector = apbdma 16;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = tegra_car 44;
+ status = disabled;
+ };
+
+ spi@7000d800 {
+ compatible = nvidia,tegra20-slink;
+ reg = 0x7000d480 0x200;
+ interrupts = 0 83 0x04;
+ nvidia,dma-request-selector = apbdma 17;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = tegra_car 46;
+ status = disabled;
+ };
+
+ spi@7000da00 {
+ compatible = nvidia,tegra20-slink;
+ reg = 0x7000da00 0x200;
+ interrupts = 0 93 0x04;
+ nvidia,dma-request-selector = apbdma 18;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = tegra_car 68;
+ status = disabled;
+ };
+
i2c@7000c000 {
#address-cells = 1;
#size-cells = 0;
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] kwbimage: Rename CONFIG_SYS_SPI_U_BOOT_OFFS to CONFIG_SYS_U_BOOT_OFFS
Hello Stefan, On Mon, 20 Jul 2015 11:20:38 +0200, Stefan Roese s...@denx.de wrote: To use this offset for other boot device (like SDIO/MMC), lets rename it to a more generic name. This will be used be the SDIO/MMC SPL boot support for the A38x. Hmm, what if SPL gets support for booting from several sources with different U-Boot offsets for different sources? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fdt
On Mon, Jul 20, 2015 at 08:04:26AM -0600, Simon Glass wrote: Hi Tom, A few things in my queue. I would like to do a sync with upstream libfdt too but have not got to that yet. The following changes since commit 605e15db2b54302364a2528d3c6604fbc57be846: Merge git://git.denx.de/u-boot-x86 (2015-07-15 10:41:20 -0400) are available in the git repository at: git://git.denx.de/u-boot-fdt.git for you to fetch changes up to 73e1e7952a2a629dc071d894594df4852acc11ad: libfdt: fix error code of fdt_count_strings() (2015-07-20 07:21:47 -0600) 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-fsl-qoriq master
On Mon, Jul 20, 2015 at 02:07:27PM -0700, York Sun wrote: Tom, The following changes since commit 605e15db2b54302364a2528d3c6604fbc57be846: Merge git://git.denx.de/u-boot-x86 (2015-07-15 10:41:20 -0400) are available in the git repository at: git://git.denx.de/u-boot-fsl-qoriq.git master for you to fetch changes up to db14f11dfe348550d8c10c6609277488d9f500d6: armv8/fsl-lsch3: Fix TCR_EL3 for the final MMU setup. (2015-07-20 11:44:40 -0700) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/11] spi: ti_qspi: Use DMA to read from qspi flash
On 7/15/2015 12:32 AM, Tom Rini wrote:
On Thu, Jul 09, 2015 at 12:10:03PM +0530, Vignesh R wrote:
On 07/03/2015 05:12 PM, Tom Rini wrote:
On Fri, Jul 03, 2015 at 04:46:10PM +0530, Vignesh R wrote:
ti_qspi uses memory map mode for faster read. Enabling DMA will increase
read speed by 3x @48MHz on DRA74 EVM.
Signed-off-by: Vignesh R vigne...@ti.com
This ignores the feedback from
http://lists.denx.de/pipermail/u-boot/2014-July/183715.html where we
need to model the DMA changes on how it's done for mxs_spi.c
Is the following patch an acceptable solution?
Jagan, are you OK with the SPI side of this? Thanks!
Gentle ping... Any comments? I will send a v2 for this series if the
below patch is acceptable.
8---
Move DMA related initialization code to helper function in ti-edma3
driver. Use this function for scheduling DMA transfer from ti_qspi driver.
diff --git a/arch/arm/include/asm/ti-common/ti-edma3.h
b/arch/arm/include/asm/ti-common/ti-edma3.h
index 5adc1dac0e65..6a7a321c1bdf 100644
--- a/arch/arm/include/asm/ti-common/ti-edma3.h
+++ b/arch/arm/include/asm/ti-common/ti-edma3.h
@@ -117,5 +117,7 @@ void edma3_set_src_addr(u32 base, int slot, u32 src);
void edma3_set_transfer_params(u32 base, int slot, int acnt,
int bcnt, int ccnt, u16 bcnt_rld,
enum edma3_sync_dimension sync_mode);
+void edma3_transfer(unsigned long edma3_base_addr, unsigned int
+edma_slot_num, void *dst, void *src, size_t len);
#endif
diff --git a/drivers/dma/ti-edma3.c b/drivers/dma/ti-edma3.c
index 8184ded9fa81..d6a427f2e21d 100644
--- a/drivers/dma/ti-edma3.c
+++ b/drivers/dma/ti-edma3.c
@@ -382,3 +382,81 @@ void qedma3_stop(u32 base, struct
edma3_channel_config *cfg)
/* Clear the channel map */
__raw_writel(0, base + EDMA3_QCHMAP(cfg-chnum));
}
+
+void edma3_transfer(unsigned long edma3_base_addr, unsigned int
+edma_slot_num, void *dst, void *src, size_t len)
+{
+struct edma3_slot_configslot;
+struct edma3_channel_config edma_channel;
+int b_cnt_value = 1;
+int rem_bytes = 0;
+int a_cnt_value = len;
+unsigned intaddr = (unsigned int) (dst);
+unsigned intmax_acnt = 0x7FFFU;
+
+if (len max_acnt) {
+b_cnt_value = (len / max_acnt);
+rem_bytes = (len % max_acnt);
+a_cnt_value = max_acnt;
+}
+
+slot.opt= 0;
+slot.src= ((unsigned int) src);
+slot.acnt = a_cnt_value;
+slot.bcnt = b_cnt_value;
+slot.ccnt = 1;
+slot.src_bidx = a_cnt_value;
+slot.dst_bidx = a_cnt_value;
+slot.src_cidx = 0;
+slot.dst_cidx = 0;
+slot.link = EDMA3_PARSET_NULL_LINK;
+slot.bcntrld= 0;
+slot.opt= EDMA3_SLOPT_TRANS_COMP_INT_ENB |
+ EDMA3_SLOPT_COMP_CODE(0) |
+ EDMA3_SLOPT_STATIC | EDMA3_SLOPT_AB_SYNC;
+
+edma3_slot_configure(edma3_base_addr, edma_slot_num, slot);
+edma_channel.slot = edma_slot_num;
+edma_channel.chnum = 0;
+edma_channel.complete_code = 0;
+ /* set event trigger to dst update */
+edma_channel.trigger_slot_word = EDMA3_TWORD(dst);
+
+qedma3_start(edma3_base_addr, edma_channel);
+edma3_set_dest_addr(edma3_base_addr, edma_channel.slot, addr);
+
+while (edma3_check_for_transfer(edma3_base_addr, edma_channel))
+;
+qedma3_stop(edma3_base_addr, edma_channel);
+
+if (rem_bytes != 0) {
+slot.opt= 0;
+slot.src=
+(b_cnt_value * max_acnt) + ((unsigned int) src);
+slot.acnt = rem_bytes;
+slot.bcnt = 1;
+slot.ccnt = 1;
+slot.src_bidx = rem_bytes;
+slot.dst_bidx = rem_bytes;
+slot.src_cidx = 0;
+slot.dst_cidx = 0;
+slot.link = EDMA3_PARSET_NULL_LINK;
+slot.bcntrld= 0;
+slot.opt= EDMA3_SLOPT_TRANS_COMP_INT_ENB |
+ EDMA3_SLOPT_COMP_CODE(0) |
+ EDMA3_SLOPT_STATIC | EDMA3_SLOPT_AB_SYNC;
+edma3_slot_configure(edma3_base_addr, edma_slot_num, slot);
+edma_channel.slot = edma_slot_num;
+edma_channel.chnum = 0;
+edma_channel.complete_code = 0;
+/* set event trigger to dst update */
+edma_channel.trigger_slot_word = EDMA3_TWORD(dst);
+
+qedma3_start(edma3_base_addr, edma_channel);
+edma3_set_dest_addr(edma3_base_addr, edma_channel.slot, addr +
+(max_acnt * b_cnt_value));
+
