Re: [U-Boot] Marvell Armada-38x DDR training code
Hi Chris, sorry for the late reply - I just returned from vacation. On 04.04.2018 03:31, Chris Packham wrote: On Thu, Mar 29, 2018 at 4:01 PM, Chris Packham wrote: Hi, I've posted a couple of improvements to the in-tree ddr training code but we've known for a while that u-boot proper is a bit behind Marvell's code for ddr training. And now I really do have a problem on my board that is fixed by using Marvell's code. Yesterday I got hold of patches from Marvell for their "standalone" mv_ddr code. It's under a tri-license Proprietary/GPL/BSD-3c so I've exercised my rights under the GPL and made it available on github https://github.com/cpackham/mv_ddr.git Actually looks like Marvell have their own official one https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git so there's no need for mine. I'll take it down to avoid confusion. Understood. This standalone code looks the most u-boot-ish of any code I've gotten out of Marvell. In fact I suspect it was based on the work that Stefan did initially. The question how do I get this upstream I could submit 475 odd patches preserving the authorship, I could submit one big roll-up of changes. Neither option is particularly appealing. It would be hard to narrow down the subset of changes that fixes my particular problem. Any suggestions on how to proceed? Are you still interested in porting / pushing those patches into mainline? I would very much welcome this. And yes, its not easy to decide, how this should be done. Both options have some drawbacks. Do you have a preference? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] tools: buildman: Don't use the working dir as build dir
From: Lothar Waßmann
When the U-Boot base directory happens to have the same name as the branch
that buildman is directed to use via the '-b' option and no output
directory is specified with '-o', buildman happily starts removing the
whole U-Boot sources eventually only stopped with the error message:
OSError: [Errno 20] Not a directory: '..//boards.cfg
Add a check to avoid this and also deal with the case where '-o' points
to the source directory, or any subdirectory of it.
Finally, tidy up the confusing logic for removing the old tree when using
-b. This is only done when building a branch.
Signed-off-by: Lothar Waßmann
Signed-off-by: Simon Glass
---
Changes in v3:
- Avoid splitting the error string in CheckOutputDir()
Changes in v2:
- Updated to check directories on start-up as per comments on v1 patch
- Added a test
- Expanded check to handle subdirectories
tools/buildman/builderthread.py | 4
tools/buildman/control.py | 28 +---
tools/buildman/func_test.py | 9 +
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index 9ac101a5a4..16a3fa452d 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -7,6 +7,7 @@ import errno
import glob
import os
import shutil
+import sys
import threading
import command
@@ -27,6 +28,9 @@ def Mkdir(dirname, parents = False):
os.mkdir(dirname)
except OSError as err:
if err.errno == errno.EEXIST:
+if os.path.realpath('.') == os.path.realpath(dirname):
+print "Cannot create the current working directory '%s'!" %
dirname
+sys.exit(1)
pass
else:
raise
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 3cac9f7cf6..e2037c3f61 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -81,6 +81,28 @@ def ShowActions(series, why_selected, boards_selected,
builder, options):
print ('Total boards to build for each commit: %d\n' %
len(why_selected['all']))
+def CheckOutputDir(output_dir):
+"""Make sure that the output directory is not within the current directory
+
+If we try to use an output directory which is within the current directory
+(which is assumed to hold the U-Boot source) we may end up deleting the
+U-Boot source code. Detect this and print an error in this case.
+
+Args:
+output_dir: Output directory path to check
+"""
+path = os.path.realpath(output_dir)
+cwd_path = os.path.realpath('.')
+while True:
+if os.path.realpath(path) == cwd_path:
+Print("Cannot use output directory '%s' since it is within the
current directtory '%s'" %
+ (path, cwd_path))
+sys.exit(1)
+parent = os.path.dirname(path)
+if parent == path:
+break
+path = parent
+
def DoBuildman(options, args, toolchains=None, make_func=None, boards=None,
clean_dir=False):
"""The main control code for buildman
@@ -252,9 +274,9 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, boards=None,
# output directory itself rather than any subdirectory.
if not options.no_subdirs:
output_dir = os.path.join(options.output_dir, dirname)
-if (clean_dir and output_dir != options.output_dir and
-os.path.exists(output_dir)):
-shutil.rmtree(output_dir)
+if clean_dir and os.path.exists(output_dir):
+shutil.rmtree(output_dir)
+CheckOutputDir(output_dir)
builder = Builder(toolchains, output_dir, options.git_dir,
options.threads, options.jobs, gnu_make=gnu_make, checkout=True,
show_unknown=options.show_unknown, step=options.step,
diff --git a/tools/buildman/func_test.py b/tools/buildman/func_test.py
index eec0f9bd37..4df1679842 100644
--- a/tools/buildman/func_test.py
+++ b/tools/buildman/func_test.py
@@ -521,3 +521,12 @@ class TestFunctional(unittest.TestCase):
self._RunControl('-b', self._test_branch, clean_dir=False)
self.assertEqual(self._builder.count, self._total_builds)
self.assertEqual(self._builder.fail, 0)
+
+def testBadOutputDir(self):
+"""Test building with an output dir the same as out current dir"""
+self._test_branch = '/__dev/__testbranch'
+with self.assertRaises(SystemExit):
+self._RunControl('-b', self._test_branch, '-o', os.getcwd())
+with self.assertRaises(SystemExit):
+self._RunControl('-b', self._test_branch, '-o',
+ os.path.join(os.getcwd(), 'test'))
--
2.17.0.484.g0c8726318c-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] tools: buildman: Don't use the working dir as build dir
On 8 April 2018 at 19:14, Simon Glass wrote: > From: Lothar Waßmann > > When the U-Boot base directory happens to have the same name as the branch > that buildman is directed to use via the '-b' option and no output > directory is specified with '-o', buildman happily starts removing the > whole U-Boot sources eventually only stopped with the error message: > > OSError: [Errno 20] Not a directory: '..//boards.cfg > > Add a check to avoid this and also deal with the case where '-o' points > to the source directory, or any subdirectory of it. > > Finally, tidy up the confusing logic for removing the old tree when using > -b. This is only done when building a branch. > > Signed-off-by: Lothar Waßmann > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Avoid splitting the error string in CheckOutputDir() Adding the test tag from v2, which I missed: Tested-by: Lothar Waßmann ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] tools: buildman: Don't use the working dir as build dir
Hi Lothar,
On 3 April 2018 at 16:16, Lothar Waßmann wrote:
> Hi,
>
> On Mon, 2 Apr 2018 02:43:12 -0600 Simon Glass wrote:
>> From: Lothar Waßmann
>>
>> When the U-Boot base directory happens to have the same name as the branch
>> that buildman is directed to use via the '-b' option and no output
>> directory is specified with '-o', buildman happily starts removing the
>> whole U-Boot sources eventually only stopped with the error message:
>>
>> OSError: [Errno 20] Not a directory: '..//boards.cfg
>>
>> Add a check to avoid this and also deal with the case where '-o' points
>> to the source directory, or any subdirectory of it.
>>
>> Finally, tidy up the confusing logic for removing the old tree when using
>> -b. This is only done when building a branch.
>>
>> Signed-off-by: Lothar Waßmann
>> Signed-off-by: Simon Glass
>> ---
>>
>> Changes in v2:
>> - Updated to check directories on start-up as per comments on v1 patch
>> - Added a test
>> - Expanded check to handle subdirectories
>>
>> tools/buildman/builderthread.py | 4
>> tools/buildman/control.py | 28 +---
>> tools/buildman/func_test.py | 9 +
>> 3 files changed, 38 insertions(+), 3 deletions(-)
>>
> [...]
[...]
>> +def CheckOutputDir(output_dir):
>> +"""Make sure that the output directory is not within the current
>> directory
>> +
>> +If we try to use an output directory which is within the current
>> directory
>> +(which is assumed to hold the U-Boot source) we may end up deleting the
>> +U-Boot source code. Detect this and print an error in this case.
>> +
>> +Args:
>> +output_dir: Output directory path to check
>> +"""
>> +path = os.path.realpath(output_dir)
>> +cwd_path = os.path.realpath('.')
>> +while True:
>> +if os.path.realpath(path) == cwd_path:
>> +Print("Cannot use output directory '%s' since it is within the "
>> + "current directtory '%s'" % (path, cwd_path))
> s/directtory/directory/
> NB: IMO its a bad habit to split format strings across multiple lines,
> since it makes it harder to grep the source code for a message
> that was printed on the terminal.
>
> Otherwise, looks good to me.
>
> Tested-by: Lothar Waßmann
Yes I agree although for some reason I have tended to stick strictly
to 80 columns in Python. I'm not sure why though, so will change it.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/17] warp7: Print out the OPTEE DRAM region
On 07/04/18 13:36, Breno Matheus Lima wrote:
Hi Bryan,
2018-04-02 19:42 GMT-03:00 Bryan O'Donoghue :
Right now a region of 0x30 bytes is allocated at the end of DRAM for
the purposes of loading an OPTEE firmware inside of it. This patch adds the
printout of the relevant address ranges.
Signed-off-by: Bryan O'Donoghue
Just a quick question here, It was your intention to do not add
CONFIG_OPTEE_TZDRAM_SIZE=0x30 in your series? So users can setup
according their requirements?
d89a5aa6d086e4b3242dbdbe97183f5b25468299 ("optee: Add
CONFIG_OPTEE_TZDRAM_SIZE") defaults to 0x30 but you can set the size
to whatever you like in your defconfig.
The important thing is to make sure u-boot and optee agree what the size
of the eaten chunk is.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/17] warp7: defconfig: Enable CONFIG_BOOTM_TEE
On 07/04/18 13:32, Breno Matheus Lima wrote: Hi Bryan, 2018-04-02 19:42 GMT-03:00 Bryan O'Donoghue : This patch enables CONFIG_BOOTM_TEE. Once enabled its possible to chain-load Linux through OPTEE. Loading kernel to 0x8080 => run loadimage Load FDT to 0x8300 => run loadfdt Load OPTEE to 0x8400 => fatload mmc 0:5 0x8400 /lib/firmware/uTee.optee Then chain-load to the kernel via OPTEE => bootm 0x8400 - 0x8300 Image Name: Image Type: ARM Trusted Execution Environment Kernel Image (uncompressed) Data Size:249844 Bytes = 244 KiB Load Address: 9de4 Entry Point: 9e00 Verifying Checksum ... OK Loading Kernel Image ... OK I'm seeing the following cache misaligned operation warning in my environment, did I miss something on my OPTEE build? => bootm 0x8400 - 0x8300 ## Booting kernel from Legacy Image at 8400 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size:274844 Bytes = 268.4 KiB Load Address: 9de4 Entry Point: 9e00 Verifying Checksum ... OK ## Flattened Device Tree blob at 8300 Booting using the fdt blob at 0x8300 Loading Kernel Image ... OK CACHE: Misaligned operation at range [9de4, 9e0431a4] Using Device Tree in place at 8300, end 830095b6 No. I hadn't paid too much attention to this but - yeah, I'll add something to this series to flush the range starting at (9e00 - cache_line_size). The alternative is to change the entry point address which requires an OPTEE change ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 2/2] ARM: meson: Add cpu info display for GX SoCs
Hi, On 28 March 2018 at 05:54, Neil Armstrong wrote: > The Amlogic SoCs have a registers containing the die revision > and packaging type to determine the SoC family and package marketing > name like S905X for the GXL SoC Family. > This code is taken for the Linux meson-gx-socinfo driver and adapted > to U-Boot printing. > > Signed-off-by: Neil Armstrong > --- > arch/arm/include/asm/arch-meson/gx.h | 1 + > arch/arm/mach-meson/Makefile | 2 +- > arch/arm/mach-meson/cpu_info.c | 105 > +++ > configs/khadas-vim_defconfig | 2 +- > configs/libretech-cc_defconfig | 2 +- > configs/odroid-c2_defconfig | 2 +- > configs/odroid_defconfig | 1 + > configs/p212_defconfig | 2 +- > 8 files changed, 112 insertions(+), 5 deletions(-) > create mode 100644 arch/arm/mach-meson/cpu_info.c Please can you use driver model's CPU interface for this? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: Add SMC and HVC commands
Hi, On 6 April 2018 at 18:06, Michalis Pappas wrote: > This patch adds smc and hvc commands, that allow issuing Secure Monitor > Calls and Hypervisor Calls conforming to the ARM SMC Calling Convention. > > Add Kconfig items to allow each command to be individually enabled. > > Signed-off-by: Michalis Pappas > --- > > cmd/Kconfig | 14 ++ > cmd/Makefile | 2 ++ > cmd/smccc.c | 72 > 3 files changed, 88 insertions(+) > create mode 100644 cmd/smccc.c > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 136836d146..bed6835eca 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1348,6 +1348,20 @@ config CMD_HASH > saved to memory or to an environment variable. It is also possible > to verify a hash against data in memory. > > +config CMD_HVC > + bool "Support the 'hvc' command" > + depends on ARM64 > + default n > + help > + Allows issuing Hypervisor Calls (HVCs) Please expand on this. Why do you want to do this, what sort of things can you do? Other than that: Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/17] dm: core: add functions to get memory-mapped I/O addreses
Hi Daniel, On 6 April 2018 at 20:45, Daniel Schwierzeck wrote: > Hi Simon, > > On 22.03.2018 19:39, Álvaro Fernández Rojas wrote: >> Signed-off-by: Álvaro Fernández Rojas >> --- >> drivers/core/fdtaddr.c | 12 >> drivers/core/read.c| 12 >> include/dm/fdtaddr.h | 22 ++ >> include/dm/read.h | 32 >> 4 files changed, 78 insertions(+) > > are you okay with these changes? I'd like to have your ACK for this > patch before applying. Thanks. It looks fine to me. I'd like to see these functions called from a sandbox test though - e.g. test/dm/test-fdt.c Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] dm: led: Support "default-state" property
On 4 April 2018 at 04:01, wrote: > From: Patrick Bruenn > > Add support for the device tree property "default-state". This feature > might be useful for LEDs indicating "power on" or similar states. > > Note: Even with this commit gpio-leds remain in reset state. That's > because the led_gpio is not probed until DM_FLAG_ACTIVATED is set. > > Signed-off-by: Patrick Bruenn > > --- > > Changes in v3: > - use ofnode_read_bool() instead of ofnode_read_string() to determine if > LED node has the default-state property > > Changes in v2: > - rebase to v2018.05-rc1 > - add dm_test_led_default_state() to tests/dm/led.c > > drivers/led/led_gpio.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] dm: led: add testcase for "default-state" property
On 4 April 2018 at 04:01, wrote: > From: Patrick Bruenn > > Add two more gpio-leds to sandbox test device tree with default-state > property set to "on"/"off". > Add dm_test_led_default_state() to check that these new LED's are set to > LEDST_ON and LEDST_OFF. > > Signed-off-by: Patrick Bruenn > --- > patman complains about: test/dm/led.c:45: check: Please use a blank line > after function/struct/union/enum declarations. > I compared with other DM_TEST() usage and decided to ignore this check. > Should we fix the macro, patman or keep ignoring this? Yes you can ignore it. The warning is coming from checkpatch.pl. I suppose we could update that. I think the macro should be next to the function it references, otherwise it gets a bit confusing. > > Changes in v3: None > Changes in v2: None > > arch/sandbox/dts/test.dts | 12 > test/dm/led.c | 16 > 2 files changed, 28 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] dm: led: auto probe() LEDs with "default-state"
On 4 April 2018 at 04:01, wrote: > From: Patrick Bruenn > > To avoid board specificy LED activation code, automatically > activate gpio-leds with "default-state" property during bind(). > > Signed-off-by: Patrick Bruenn > --- > > Changes in v3: None > Changes in v2: None > > drivers/led/led_gpio.c | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 u-boot 2/2] reset: add sandbox test for bulk API
Hi Neil, On 4 April 2018 at 04:45, Neil Armstrong wrote: > On 03/04/2018 19:53, Simon Glass wrote: >> On 3 April 2018 at 17:40, Neil Armstrong wrote: >>> This patch adds the bulk reset API tests for the sandbox test suite. >>> >>> Unlike the main test, it also check the "other" reset signal using the bulk >>> API >>> and checks if the resets are correctly asserted/deasserted. >>> >>> To allow the bulk API to work, and avoid changing the DT, the number of >>> resets >>> of the sandbox reset controller has been bumped to 101 for the "other" reset >>> line to be valid. >> >> Does it need to be 101, or would, say, 5 be enough? > > It could stay at 3, but a dts change should be needed since it declares : > > resets = <&resetc 100>, <&resetc 2>; > reset-names = "other", "test"; Well that is fine if you want to change test.dts - you just need to make sure you keep the intent. But you've explained the reason, and it's fine to keep this patch as is, if you like. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] kconfig: add CONFIG_CC_COVERAGE
On Thu, Mar 29, 2018 at 09:49:30AM +0200, Christian Gmeiner wrote: > Make it possible to use gcc code coverage analysis. > > Signed-off-by: Christian Gmeiner > --- > .gitignore | 4 > Kconfig| 8 > Makefile | 6 ++ > 3 files changed, 18 insertions(+) > > diff --git a/.gitignore b/.gitignore > index 29757aa51e..f1b801579c 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -85,3 +85,7 @@ GTAGS > *.orig > *~ > \#*# > + > +# gcc code coverage files > +*.gcda > +*.gcno > diff --git a/Kconfig b/Kconfig > index 6670913799..f092f72b25 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -59,6 +59,14 @@ config CC_OPTIMIZE_FOR_SIZE > > This option is enabled by default for U-Boot. > > +config CC_COVERAGE > + bool "Enable code coverage analysis" > + default n > + depends on SANDBOX > + help > + Enabling this option will pass "--coverage" to gcc to compile > + and link code instrumented for coverage analysis. We shouldn't need default n, as that is the normal default. And why is this only on SANDBOX? > + > config DISTRO_DEFAULTS > bool "Select defaults suitable for booting general purpose Linux > distributions" > default y if ARCH_SUNXI || TEGRA > diff --git a/Makefile b/Makefile > index 5fa14789d9..d06193e8f4 100644 > --- a/Makefile > +++ b/Makefile > @@ -720,6 +720,12 @@ else > PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) > -print-libgcc-file-name`) -lgcc > endif > PLATFORM_LIBS += $(PLATFORM_LIBGCC) > + > +ifdef CONFIG_CC_COVERAGE > +KBUILD_CFLAGS+= --coverage > +PLATFORM_LIBGCC += -lgcov Consistent spacing please, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FIT Image with same kernel but different load/entry point
On Tue, Apr 03, 2018 at 07:17:13PM +0200, Clément Péron wrote: > Hi, > > Is it possible to have one kernel entry in a FIT image with two > different load/entry point. > > I have 2 boards which share the same kernel but doesn't have the same > entry/load point. I think what you want is to use kernel_noload and then load/entry values are ignored and we use the kernel in-place. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mmc: uniphier-sd: Add compatible strings for RCar Gen2
On 02/20/2018 01:31 PM, Marek Vasut wrote: > On 02/20/2018 01:54 AM, Jaehoon Chung wrote: >> On 02/20/2018 02:02 AM, Marek Vasut wrote: >>> On 02/19/2018 12:23 PM, Jaehoon Chung wrote: On 02/01/2018 12:21 AM, Marek Vasut wrote: > Add DT compatible strings for RCar Gen2 SoCs, so that this driver > can bind with them. Unlike Gen3, which uses 64bit FIFO, the Gen2 > uses 16bit FIFO. > > Signed-off-by: Marek Vasut > Cc: Jaehoon Chung > Cc: Masahiro Yamada Applied to u-boot-mmc. Thanks! Sorry for late. I have checked the previous version.. >>> >>> Yes, this is so late that it has to be scheduled for 2018.05 cycle. >>> Another cycle missed, sigh. >> >> >> I will revert your patch on master. instead i will apply this patch on next >> branch. >> Is it ok? > > Why would you revert it ? Just drop it from the PR and resend the PR. > > And then apply it for -next branch, yes. Which presumably never happened, since those patches are not in -rc1 ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mmc: uniphier-sd: Add compatible strings for RCar Gen2
On 04/08/2018 06:41 PM, Marek Vasut wrote: > On 02/20/2018 01:31 PM, Marek Vasut wrote: >> On 02/20/2018 01:54 AM, Jaehoon Chung wrote: >>> On 02/20/2018 02:02 AM, Marek Vasut wrote: On 02/19/2018 12:23 PM, Jaehoon Chung wrote: > On 02/01/2018 12:21 AM, Marek Vasut wrote: >> Add DT compatible strings for RCar Gen2 SoCs, so that this driver >> can bind with them. Unlike Gen3, which uses 64bit FIFO, the Gen2 >> uses 16bit FIFO. >> >> Signed-off-by: Marek Vasut >> Cc: Jaehoon Chung >> Cc: Masahiro Yamada > > Applied to u-boot-mmc. Thanks! Sorry for late. > I have checked the previous version.. Yes, this is so late that it has to be scheduled for 2018.05 cycle. Another cycle missed, sigh. >>> >>> >>> I will revert your patch on master. instead i will apply this patch on next >>> branch. >>> Is it ok? >> >> Why would you revert it ? Just drop it from the PR and resend the PR. >> >> And then apply it for -next branch, yes. > > Which presumably never happened, since those patches are not in -rc1 ? I will update the patchset and resubmit it, sigh ... -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: Add SMC and HVC commands
On Sun, Apr 08, 2018 at 07:47:20PM +0300, Michalis Pappas wrote: > > On 04/08/2018 04:50 PM, Simon Glass wrote: > >Please expand on this. Why do you want to do this, what sort of things > >can you do? > > > >Other than that: > > > >Reviewed-by: Simon Glass > The main usecase is development / testing. > > My motivation was testing the Secure Payload of ARM Trusted Firmware on > QEMU. > For HVC, I don't have a usecase TBH, but I still think it's useful (at a > minimum, one can perform Call Count, UID and Revision queries). Please word that into an updated help message, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform
On Sun, Apr 08, 2018 at 09:45:22AM +0800, Kever Yang wrote: > Philipp, > > > On 04/02/2018 05:28 AM, Philipp Tomsich wrote: > > > > > > On Tue, 27 Mar 2018, Kever Yang wrote: > > > >> We use common board/spl/tpl file for all rockchip SoCs, > >> - all the SoC spec setting should move into SoC file like rk3288.c; > >> - tpl is option and only purpose to init DRAM, clock, uart(option); > >> - spl do secure relate one time init, boot device select, boot into > >> U-Boot or trust or OS in falcon mode; > >> - board do boot mode detect, enable regulator, usb init and so on. > > > > There's too much going on in a single commit/single series. > > This needs to be split up into multiple, independent steps (e.g. one > > for the timer changes, another one for the UART changes)... > > I understand review the patches piece by piece is much more comfortable, > and this patch including "too much" things. And I never expect this > patch set > can be merge quickly, but we have to do this ASAP before more SoC coming. > I have do a lot of test and re-work in my local branch and at last make > it landed in > rockchip vendor U-Boot, with testing in most of SoCs(not including > rk3066/rk3188). > Well, I do try to split it into pieces, but I found that actually not > help very much > except waste much more time: > - The target is(very clear) to make rockchip soc board file in a good > shape with common files, > instead of copy-paste for each soc(more than 10 of them now) > - then we need to identify what's common and what should go to soc and > board; > - remove using common rockchip timer and use arm generic timer instead > for armv7 > SoCs(rk3066 and rk3188 need still using rockchip timer) > - most soc need to do uart init, boot order select, and some > arch_cpu_init(). > - don't break the boards already working, so I still leave some code > which not so common > in board file, but I would like to remove or move them into right > place if I got a board > to verify; > > @Simon, @Tom, > This patch set is to remove some common files and add some other common > files for > all Rockchip SoCs, I have to make sure the whole patch set can running > good for all SoCs, > but it's really hard to make every patch to build and work perfect for > all SoCs, is there > any mandatory rules for this? So you mean possibly breaking some existing platforms? I don't like the idea of doing that... -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/7] treewide: Migrate CONFIG_SYS_ALT_MEMTEST to Kconfig
On Wed, Mar 28, 2018 at 02:38:14PM +0200, Mario Six wrote: > Migrate the CONFIG_SYS_ALT_MEMTEST option to Kconfig. > > Signed-off-by: Mario Six Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/7] treewide: Migrate CONFIG_BOARD_EARLY_INIT_R to Kconfig
On Wed, Mar 28, 2018 at 02:38:15PM +0200, Mario Six wrote: > Migrate the CONFIG_BOARD_EARLY_INIT_R option to Kconfig. > > Signed-off-by: Mario Six Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/7] treewide: Migrate CONFIG_LAST_STAGE_INIT to Kconfig
On Wed, Mar 28, 2018 at 02:38:16PM +0200, Mario Six wrote: > Migrate the CONFIG_LAST_STAGE_INIT option to Kconfig. > > Signed-off-by: Mario Six Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 6/7] treewide: Migrate CONFIG_FSL_ESDHC to Kconfig
On Wed, Mar 28, 2018 at 02:38:19PM +0200, Mario Six wrote: > Migrate the CONFIG_FSL_ESDHC option to Kconfig. > > Signed-off-by: Mario Six Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 5/7] treewide: Migrate CONFIG_TSEC_ENET to Kconfig
On Wed, Mar 28, 2018 at 02:38:18PM +0200, Mario Six wrote: > Migrate the CONFIG_TSEC_ENET option to Kconfig. > > Signed-off-by: Mario Six Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 7/7] treewide: Convert CONFIG_HOSTNAME to a string option
On Wed, Mar 28, 2018 at 02:38:20PM +0200, Mario Six wrote: > CONFIG_HOSTNAME is defined as a "plain" preprocessor string, but every > use is couched by __stringify(...). > > Hence, convert it to a proper string option. > > Signed-off-by: Mario Six Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/7] treewide: Migrate CONFIG_DISPLAY_BOARDINFO_LATE to Kconfig
On Wed, Mar 28, 2018 at 02:38:17PM +0200, Mario Six wrote: > Migrate the CONFIG_DISPLAY_BOARDINFO_LATE option to Kconfig. > > Signed-off-by: Mario Six Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: Add SMC and HVC commands
On 04/08/2018 04:50 PM, Simon Glass wrote: Please expand on this. Why do you want to do this, what sort of things can you do? Other than that: Reviewed-by: Simon Glass The main usecase is development / testing. My motivation was testing the Secure Payload of ARM Trusted Firmware on QEMU. For HVC, I don't have a usecase TBH, but I still think it's useful (at a minimum, one can perform Call Count, UID and Revision queries). Michalis ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] timer: Add High Precision Event Timers (HPET) support
Hi Ivan,
On Sat, Apr 7, 2018 at 3:18 AM, Ivan Gorinov wrote:
> Add HPET driver as an alternative timer for x86 (default is TSC).
> HPET counter has constant frequency and does not need calibration.
> This change also makes TSC timer driver optional on x86.
> New HPET driver can also be selected as the early timer on x86.
>
> HPET can be selected as the tick timer in the Device Tree "chosen" node:
>
> /include/ "hpet.dtsi"
>
> ...
>
> chosen {
> tick-timer = "/hpet";
> };
>
> Signed-off-by: Ivan Gorinov
> ---
> arch/Kconfig | 2 +-
> arch/x86/Kconfig | 21 ++
> arch/x86/dts/hpet.dtsi | 7 ++
> drivers/timer/Kconfig | 9 +++
> drivers/timer/Makefile | 1 +
> drivers/timer/hpet_timer.c | 179
> +
> drivers/timer/tsc_timer.c | 8 ++
> 7 files changed, 226 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/dts/hpet.dtsi
> create mode 100644 drivers/timer/hpet_timer.c
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index e599e7a..37dabae 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -104,7 +104,7 @@ config X86
> select DM_PCI
> select PCI
> select TIMER
> - select X86_TSC_TIMER
> + imply X86_TSC_TIMER
> imply BLK
> imply DM_ETH
> imply DM_GPIO
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 5c23b2c..2fe5b6a 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -119,6 +119,27 @@ source "arch/x86/cpu/tangier/Kconfig"
>
> # architecture-specific options below
>
> +choice
> + prompt "Select which timer to use early on x86"
nits: "on x86" is not needed since this option is only visible in the
x86 sub-menu
> + depends on X86
This depends is not necessary as this option is already included in
arch/x86/Kconfig.
But it should really depend on CONFIG_TIMER_EARLY
> + default X86_EARLY_TIMER_TSC
> +
> +config X86_EARLY_TIMER_TSC
> + bool "TSC"
> + depends on X86_TSC_TIMER
> + help
> + This selects x86 Time Stamp Counter (TSC) as the early timer.
> + See CONFIG_TIMER_EARLY for the early timer description.
> +
> +config X86_EARLY_TIMER_HPET
> + bool "HPET"
> + depends on HPET_TIMER
> + help
> + This selects High Precision Event Timers as the early timer.
> + Early HPET base address is specified by CONFIG_HPET_ADDRESS.
> +
> +endchoice
> +
> config AHCI
> default y
>
> diff --git a/arch/x86/dts/hpet.dtsi b/arch/x86/dts/hpet.dtsi
> new file mode 100644
> index 000..a74f739
> --- /dev/null
> +++ b/arch/x86/dts/hpet.dtsi
> @@ -0,0 +1,7 @@
> +/ {
> + hpet: hpet@fed0 {
> + compatible = "hpet-x86";
> + u-boot,dm-pre-reloc;
> + reg = <0xfed0 0x1000>;
> + };
> +};
> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
> index 2c96896..26743b7 100644
> --- a/drivers/timer/Kconfig
> +++ b/drivers/timer/Kconfig
> @@ -65,6 +65,15 @@ config X86_TSC_TIMER
> help
> Select this to enable Time-Stamp Counter (TSC) timer for x86.
>
> +config HPET_TIMER
> + bool "High Precision Event Timers (HPET) support"
> + depends on TIMER
> + default y if X86
> + help
> + Select this to enable High Precision Event Timers (HPET) on x86.
> + HPET main counter increments at constant rate and does not need
> + calibration.
> +
> config OMAP_TIMER
> bool "Omap timer support"
> depends on TIMER
> diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
> index a6e7832..557fecc 100644
> --- a/drivers/timer/Makefile
> +++ b/drivers/timer/Makefile
> @@ -8,6 +8,7 @@ obj-y += timer-uclass.o
> obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o
> obj-$(CONFIG_SANDBOX_TIMER)+= sandbox_timer.o
> obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
> +obj-$(CONFIG_HPET_TIMER) += hpet_timer.o
> obj-$(CONFIG_OMAP_TIMER) += omap-timer.o
> obj-$(CONFIG_AST_TIMER)+= ast_timer.o
> obj-$(CONFIG_STI_TIMER)+= sti-timer.o
> diff --git a/drivers/timer/hpet_timer.c b/drivers/timer/hpet_timer.c
> new file mode 100644
> index 000..b1ce226
> --- /dev/null
> +++ b/drivers/timer/hpet_timer.c
> @@ -0,0 +1,179 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define HPET_PERIOD_REG 0x004
> +#define HPET_CONFIG_REG 0x010
> +#define HPET_MAIN_COUNT 0x0f0
> +
> +#define ENABLE_CNF 1
> +
> +#define HPET_MAX_PERIOD 1
> +
> +struct hpet_timer_priv {
> + void *regs;
> +};
> +
> +/*
> + * Returns HPET clock frequency in HZ
> + * (rounding to the nearest integer),
> + * or 0 if HPET is not available.
> + */
> +static inline u32 get_clock_frequency(void *regs)
> +{
> + u64 d = 1000ull;
> + u32 perio
Re: [U-Boot] [PATCH] arm64: Add SMC and HVC commands
On Fri, Apr 6, 2018 at 7:06 AM, Michalis Pappas wrote: > +config CMD_HVC > + bool "Support the 'hvc' command" > + depends on ARM64 > + default n No need to pass 'default n' as this is already the default behavior. > + help > + Allows issuing Hypervisor Calls (HVCs) > + > +config CMD_SMC > + bool "Support the 'smc' command" > + depends on ARM64 > + default n Ditto. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6] x86: Add 64-bit memory-mapped I/O functions
On Sun, Apr 8, 2018 at 1:47 PM, Bin Meng wrote: > On Sat, Apr 7, 2018 at 5:43 AM, Ivan Gorinov wrote: >> Add readq() and writeq() definitions for x86. >> >> Please note: in 32-bit code readq/writeq will generate two 32-bit >> memory access instructions instead of one atomic 64-bit operation. >> >> Signed-off-by: Ivan Gorinov >> --- >> arch/x86/include/asm/io.h | 4 >> 1 file changed, 4 insertions(+) >> > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Marvell Armada-38x DDR training code
On Sun, Apr 8, 2018 at 10:24 PM, Stefan Roese wrote: > Hi Chris, > > sorry for the late reply - I just returned from vacation. No problem. I'm about to head off on vacation next week myself. > On 04.04.2018 03:31, Chris Packham wrote: >> >> On Thu, Mar 29, 2018 at 4:01 PM, Chris Packham >> wrote: >>> >>> Hi, >>> >>> I've posted a couple of improvements to the in-tree ddr training code >>> but we've known for a while that u-boot proper is a bit behind >>> Marvell's code for ddr training. And now I really do have a problem on >>> my board that is fixed by using Marvell's code. >>> >>> Yesterday I got hold of patches from Marvell for their "standalone" >>> mv_ddr code. It's under a tri-license Proprietary/GPL/BSD-3c so I've >>> exercised my rights under the GPL and made it available on github >>> https://github.com/cpackham/mv_ddr.git >> >> >> Actually looks like Marvell have their own official one >> https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git so >> there's no need for mine. I'll take it down to avoid confusion. > > > Understood. > >>> This standalone code looks the most u-boot-ish of any code I've gotten >>> out of Marvell. In fact I suspect it was based on the work that Stefan >>> did initially. >>> >>> The question how do I get this upstream I could submit 475 odd patches >>> preserving the authorship, I could submit one big roll-up of changes. >>> Neither option is particularly appealing. It would be hard to narrow >>> down the subset of changes that fixes my particular problem. >>> >>> Any suggestions on how to proceed? > > > Are you still interested in porting / pushing those patches into > mainline? I would very much welcome this. And yes, its not easy to > decide, how this should be done. Both options have some drawbacks. > Do you have a preference? Yes I'm still keen for them to go in, I should have something ready either today or tomorrow. I'm not sure if it's something that can go in 2018.05 or if we should leave it for .07 to give the other board maintainers a chance to test. I've settled on treating it as a "sync with upstream" since many of the commits just fix something done earlier. I'll do what I can to reduce the delta (e.g. remove unused code that gets deleted in the next step) but there will be at least one big-ish patch which may trip over the mailing lists size limit. Also because there are changes to the topology_map structure that large patch will need touch files outside of drivers/ddr/marvell to preserve bisect-ability. I'll also have to look into re-doing Marek B's 2T timing changes. I can probably do that on-top of the new code since the new code defaults to 2T for a38x. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: s32v234evb: Set CONFIG_DM & CONFIG_DM_SERIAL in Kconfig
These symbols are declared in Kconfig, so it's wrong to set them in header files. Note that this is not size-neutral - some 'default y' options will now get turned on by Kconfig, such as CONFIG_CMD_DM=y and CONFIG_DM_STDIO=y. Signed-off-by: Tuomas Tynkkynen --- configs/s32v234evb_defconfig | 3 ++- include/configs/s32v234evb.h | 2 -- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/configs/s32v234evb_defconfig b/configs/s32v234evb_defconfig index a28d24ce0b..5d98d15324 100644 --- a/configs/s32v234evb_defconfig +++ b/configs/s32v234evb_defconfig @@ -2,11 +2,12 @@ CONFIG_ARM=y CONFIG_TARGET_S32V234EVB=y CONFIG_SYS_TEXT_BASE=0x3E80 CONFIG_DISTRO_DEFAULTS=y -CONFIG_SYS_MALLOC_F=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/s32v234evb/s32v234evb.cfg" CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyLF0 root=/dev/ram rw" CONFIG_BOARD_EARLY_INIT_F=y CONFIG_CMD_BOOTZ=y CONFIG_ENV_IS_IN_MMC=y +CONFIG_DM=y +CONFIG_DM_SERIAL=y CONFIG_OF_LIBFDT=y diff --git a/include/configs/s32v234evb.h b/include/configs/s32v234evb.h index 4dc098b828..e5265a7362 100644 --- a/include/configs/s32v234evb.h +++ b/include/configs/s32v234evb.h @@ -12,7 +12,6 @@ #include #define CONFIG_S32V234 -#define CONFIG_DM /* Config GIC */ #define CONFIG_GICV2 @@ -58,7 +57,6 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2 * 1024 * 1024) #endif -#define CONFIG_DM_SERIAL #define CONFIG_FSL_LINFLEXUART #define LINFLEXUART_BASE LINFLEXD0_BASE_ADDR -- 2.16.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] serial: Migrate CONFIG_FSL_LINFLEXUART to Kconfig
Signed-off-by: Tuomas Tynkkynen
---
configs/s32v234evb_defconfig| 1 +
drivers/serial/Kconfig | 7 +++
drivers/serial/serial_linflexuart.c | 4
include/configs/s32v234evb.h| 1 -
scripts/config_whitelist.txt| 1 -
5 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/configs/s32v234evb_defconfig b/configs/s32v234evb_defconfig
index 5d98d15324..77e6faf146 100644
--- a/configs/s32v234evb_defconfig
+++ b/configs/s32v234evb_defconfig
@@ -10,4 +10,5 @@ CONFIG_CMD_BOOTZ=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_DM=y
CONFIG_DM_SERIAL=y
+CONFIG_FSL_LINFLEXUART=y
CONFIG_OF_LIBFDT=y
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 975e6d3d58..c32e46a0f8 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -466,6 +466,13 @@ config BCM6345_SERIAL
help
Select this to enable UART on BCM6345 SoCs.
+config FSL_LINFLEXUART
+ bool "Freescale Linflex UART support"
+ depends on DM_SERIAL
+ help
+ Select this to enable the Linflex serial module found on some
+ NXP SoCs like S32V234.
+
config FSL_LPUART
bool "Freescale LPUART support"
help
diff --git a/drivers/serial/serial_linflexuart.c
b/drivers/serial/serial_linflexuart.c
index fbb39592d6..b706fdb398 100644
--- a/drivers/serial/serial_linflexuart.c
+++ b/drivers/serial/serial_linflexuart.c
@@ -35,10 +35,6 @@
DECLARE_GLOBAL_DATA_PTR;
-#ifndef CONFIG_DM_SERIAL
-#error "The linflex serial driver does not have non-DM support."
-#endif
-
static void _linflex_serial_setbrg(struct linflex_fsl *base, int baudrate)
{
u32 clk = mxc_get_clock(MXC_UART_CLK);
diff --git a/include/configs/s32v234evb.h b/include/configs/s32v234evb.h
index e5265a7362..7aa1e88a27 100644
--- a/include/configs/s32v234evb.h
+++ b/include/configs/s32v234evb.h
@@ -57,7 +57,6 @@
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
#endif
-#define CONFIG_FSL_LINFLEXUART
#define LINFLEXUART_BASE LINFLEXD0_BASE_ADDR
#define CONFIG_DEBUG_UART_LINFLEXUART
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 843e98124f..a281c12e17 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -680,7 +680,6 @@ CONFIG_FSL_IIM
CONFIG_FSL_ISBC_KEY_EXT
CONFIG_FSL_LAYERSCAPE
CONFIG_FSL_LBC
-CONFIG_FSL_LINFLEXUART
CONFIG_FSL_MC9SDZ60
CONFIG_FSL_MEMAC
CONFIG_FSL_NGPIXIS
--
2.16.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Update the io.h file to use {out|in}_{be|le}X macros
On Thu, Mar 29, 2018 at 10:41 PM, Lukasz Majewski wrote:
> The commit 3f70a6f57734 ("x86: Add clr/setbits functions")
> introduced the {read|write}_ macros to manipulate data.
>
> Those macros are not used by any code in the u-boot project (despite the
> io.h itself). Other architectures use io.h with {in|out}_* macros.
>
> This commit brings some unification across u-boot supported architectures.
>
> Signed-off-by: Lukasz Majewski
> ---
>
> arch/x86/include/asm/io.h | 34 +-
> 1 file changed, 17 insertions(+), 17 deletions(-)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Update the io.h file to use {out|in}_{be|le}X macros
On Mon, Apr 9, 2018 at 9:47 AM, Bin Meng wrote:
> On Thu, Mar 29, 2018 at 10:41 PM, Lukasz Majewski wrote:
>> The commit 3f70a6f57734 ("x86: Add clr/setbits functions")
>> introduced the {read|write}_ macros to manipulate data.
>>
>> Those macros are not used by any code in the u-boot project (despite the
>> io.h itself). Other architectures use io.h with {in|out}_* macros.
>>
>> This commit brings some unification across u-boot supported architectures.
>>
>> Signed-off-by: Lukasz Majewski
>> ---
>>
>> arch/x86/include/asm/io.h | 34 +-
>> 1 file changed, 17 insertions(+), 17 deletions(-)
>>
>
> Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] net: phy: Don't limit phy addresses by default
On Sat, Mar 31, 2018 at 12:52 AM, Joe Hershberger wrote: > Some boards expect to find more than one phy while other boards are old > and need to be limited to a specific phy address. Only limit the phy > address for boards that opt in. > > Signed-off-by: Joe Hershberger > > --- > > configs/am335x_baltos_defconfig| 1 + > configs/am335x_shc_defconfig | 1 + > configs/am335x_shc_ict_defconfig | 1 + > configs/am335x_shc_netboot_defconfig | 1 + > configs/am335x_shc_prompt_defconfig| 1 + > configs/am335x_shc_sdboot_defconfig| 1 + > configs/am335x_shc_sdboot_prompt_defconfig | 1 + > configs/devkit3250_defconfig | 1 + > configs/ds414_defconfig| 1 + > configs/khadas-vim_defconfig | 1 + > configs/libretech-cc_defconfig | 1 + > configs/p212_defconfig | 1 + > configs/pepper_defconfig | 1 + > configs/work_92105_defconfig | 1 + > configs/x600_defconfig | 1 + > drivers/net/phy/Kconfig| 8 > 16 files changed, 23 insertions(+) > Looks no one has any comments, let's do this to unblock Intel Galileo board. In the long term, PHY address should be read from DTS instead. Tested on Intel Galileo Tested-by: Bin Meng Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] Fix DM_SCSI on DRA7 platforms
On 6.4.2018 15:58, Jean-Jacques Hiblot wrote: > > > On 06/04/2018 14:00, Michal Simek wrote: >> Hi, >> >> On 6.4.2018 11:13, Jean-Jacques Hiblot wrote: >>> Enhancements to SCSI support for driver model have broken the support >>> for >>> DM_SCSI on DRA7 platforms. This series fixes it. >>> >>> Tested on: >>> - dra76 evm >>> >>> >>> Jean-Jacques Hiblot (2): >>> dwc_ahci: Fix breakage >>> configs: dra7xx_evm/dra7xx_hs_evm: Enable AHCI and PIPE3 >>> >>> configs/dra7xx_evm_defconfig | 2 ++ >>> configs/dra7xx_hs_evm_defconfig | 2 ++ >>> drivers/ata/dwc_ahci.c | 23 ++- >>> 3 files changed, 14 insertions(+), 13 deletions(-) >>> >> I have seen similar issue with 2018.01 release but I have just tested it >> with sata_ceva.c on latest on zcu102 and I can't see any issue. >> >> Here was my quick hack. >> https://github.com/Xilinx/u-boot-xlnx/commit/df365a0d76352c4b675444c660cc4eb53b36d51e >> >> >> Anyway I have used your patch as source of changes for ceva sata and I >> have tested it on the top of latest and also on xilinx v2018.1(+ revert >> of my hack) and it is working properly. >> >> Anyway I think that will be good if you can retest driver on the HEAD > I'm not sure I understand what you mean by HEAD. > I had tested the disk with commit > e294ba0678359bc32085c1714329af37e33e8f16 (4th april, so pretty recent), > it didn't work. HEAD - latest u-boot commit in master branch. > Honestly I haven't tried to understand the reason why it broke, I just > modified the driver to match was is done in the straightforward PCI driver. Ok. I get it. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2] imx: nitrogen6x: Convert Sabrelite to distro boot support
Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.
Signed-off-by: Guillaume GARDET
Cc: Troy Kisky
Cc: Stefano Babic
Cc: Fabio Estevam
---
Changes in V2:
* add mx6qsabrelite_defconfig update
configs/mx6qsabrelite_defconfig | 16 ++--
include/configs/nitrogen6x.h| 86 +
2 files changed, 22 insertions(+), 80 deletions(-)
diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..c644754929 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,17 +3,15 @@ CONFIG_ARCH_MX6=y
CONFIG_SYS_TEXT_BASE=0x1780
CONFIG_TARGET_NITROGEN6X=y
CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
CONFIG_FASTBOOT=y
CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
CONFIG_CMD_MEMTEST=y
-CONFIG_SYS_ALT_MEMTEST=y
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_GPIO=y
CONFIG_CMD_I2C=y
@@ -22,21 +20,15 @@ CONFIG_CMD_SATA=y
CONFIG_CMD_SF=y
CONFIG_CMD_USB=y
CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
CONFIG_CMD_BMP=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
CONFIG_ENV_IS_IN_MMC=y
CONFIG_DM=y
CONFIG_DWC_AHSATA=y
-CONFIG_FSL_ESDHC=y
CONFIG_SPI_FLASH=y
CONFIG_SPI_FLASH_SST=y
CONFIG_PHYLIB=y
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..3161b1dd79 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -102,82 +102,32 @@
#define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
#if defined(CONFIG_SABRELITE)
+#define BOOT_TARGET_DEVICES(func) \
+ func(MMC, mmc, 0) \
+ func(MMC, mmc, 1) \
+ func(SATA, sata, 0) \
+ func(USB, usb, 0) \
+ func(PXE, pxe, na) \
+ func(DHCP, dhcp, na)
+
+#include
+
#define CONFIG_EXTRA_ENV_SETTINGS \
- "script=boot.scr\0" \
- "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
- "fdt_file=imx6q-sabrelite.dtb\0" \
+ "fdtfile=imx6q-sabrelite.dtb\0" \
"fdt_addr=0x1800\0" \
- "boot_fdt=try\0" \
+ "fdt_addr_r=0x1800\0" \
+ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+ "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+ "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+ "ramdisk_addr_r=0x1300\0" \
+ "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
- "mmcdevs=0 1\0" \
- "mmcpart=1\0" \
- "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
- "mmcargs=setenv bootargs console=${console},${baudrate} " \
- "root=${mmcroot}\0" \
- "loadbootscript=" \
- "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
- "bootscript=echo Running bootscript from mmc ...; " \
- "source\0" \
- "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
- "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
- "mmcboot=echo Booting from mmc ...; " \
- "run mmcargs; " \
- "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
- "if run loadfdt; then " \
- "bootm ${loadaddr} - ${fdt_addr}; " \
- "else " \
- "if test ${boot_fdt} = try; then " \
- "bootm; " \
- "else " \
- "echo WARN: Cannot load the DT; " \
- "fi; " \
- "fi; " \
- "else " \
- "bootm; " \
- "fi;\0" \
- "netargs=setenv bootargs console=${console},${baudrate} " \
- "root=/dev/nfs " \
- "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
- "netboot=echo Booting from net ...; " \
- "run netargs; " \
- "if test ${ip_dyn} = yes; then " \
- "setenv get_cmd dhcp; " \
- "else " \
- "setenv get_cmd tftp; " \
- "fi; " \
- "${get_cmd} ${uimage}; " \
- "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
- "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
- "bootm ${loadaddr} - ${fdt_addr}; " \
- "else " \
-
