Re: [U-Boot] [PATCH v2] libfdt: replace ARCH_FIXUP_FDT with ARCH_FIXUP_FDT_MEMORY
Hello Masahiro-san,
On Fri, 2016-10-21 at 10:58 +0900, Masahiro Yamada wrote:
> Hi Alexey,
>
> 2016-10-20 20:55 GMT+09:00 Alexey Brodkin :
> >
> > Hello Masahiro-san,
> >
> > On Thu, 2016-10-20 at 09:15 +0900, Masahiro Yamada wrote:
> > >
> > > Commit e2f88dfd2d96 ("libfdt: Introduce new ARCH_FIXUP_FDT option")
> > > allows us to skip memory setup of DTB, but a problem for ARM is that
> > > spin_table_update_dt() and psci_update_dt() are skipped as well if
> > > CONFIG_ARCH_FIXUP_FDT is disabled.
> > >
> > > This commit allows us to skip only fdt_fixup_memory_banks() instead
> > > of the whole of arch_fixup_fdt(). It will be useful when we want to
> > > use a memory node from a kernel DTB as is, but need some fixups for
> > > Spin-Table/PSCI.
> > >
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > Changes in v2:
> > > - Add empty stub to ARC, PowerPC, Microblaze instead of
> > > a weak function common/image-fdt.c
> >
> > [snip]
> >
> > >
> > > diff --git a/arch/arc/lib/bootm.c b/arch/arc/lib/bootm.c
> > > index 04d9d9c..5798149 100644
> > > --- a/arch/arc/lib/bootm.c
> > > +++ b/arch/arc/lib/bootm.c
> > > @@ -37,6 +37,11 @@ void arch_lmb_reserve(struct lmb *lmb)
> > > lmb_reserve(lmb, sp, (CONFIG_SYS_SDRAM_BASE + gd->ram_size - sp));
> > > }
> > >
> > > +int arch_fixup_fdt(void *blob)
> > > +{
> > > + return 0;
> > > +}
> > > +
> >
> > I'm wondering why don't we add weak implementation of arch_fixup_fdt()
> > right in say common/image-fdt.c? This will allow us to not add dummy stubs
> > for those arches that don't really use it.
>
>
> I fully agree with you.
>
>
> I used a weak function in v1:
> http://patchwork.ozlabs.org/patch/678049/
>
> But, it was change-request'ed by Simon.
Ok, thanks for the reference.
Indeed Simon's comments make sense.
So for ARC changes
Acked-by: Alexey Brodkin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Proposal on changing raw boot mode
On 20/10/2016 19:07, Sam Protsenko wrote: > Hi guys, > > I'd like to make two changes on how raw MMC address and size of U-Boot > are represented. But I think it's better to discuss it first, so we > are on the same page about it. > > Basically I want to review two config options here. > > 1. CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS > > Simple grep shows us that noone actually uses this constant > (despite it's being defined for multiple boards). So I'm thinking to > remove it altogether. What do you think about that? > > 2. CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > > For TI boards it's defined in common file: > include/configs/ti_armv7_common.h . So if some board has another > U-Boot partition address (on MMC), it must redefine that option after > including ti_armv7_common.h. I don't understand this part. If you're actually using partitions, just use the partition code rather than the sector code. The main purpose of the sector SPL loading code is to allow loading from somewhere that is *not* a partition, no? > Historical background: actually I tried to change this address > before, because DRA7 EVM and AM57x EVM / X15 boards are broken in > mainline U-Boot right now. My attempt [1] turned out to be > ill-designed, as it broke other boards (IIRC, it was BeagleBone > Black): [2]. Which further led to reverting my patch: [3]. > > It remains to be a problem, though. So I see 2 possible ways how to fix > it: > > (a) Just re-define this address in corresponding board configs (headers). > (b) Convert this option to Kconfig and define it correctly in each > board's defconfig. Converting to Kconfig is always a good idea. So that one's a no-brainer "yes, just do it". As for the overall logic, I find it very hard to follow and terribly crude. We currently mangle "sector offset u-boot starts" with "partition number u-boot is on" with various intransparent combinations of those. Can't we just split CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION and CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR into CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_OFFSET Then just model the whole "TI usually sets SECTOR to x" logic in Kconfig and override it in your board's defconfig. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] dm: Update on serial driver progress
Hi Simon On Thu, 2016-10-20 at 13:06 -0600, Simon Glass wrote: > Only three serial drivers remain to be converted. This series drops > two of those, since the boards appear to be unmaintained. > > With this, only blackfin remains. > > The blackfin driver probably needs to be converted as there is recent > activity with these boards. I am copying the maintainer so that this > work can be completed. Could you please hold off with dropping the PXA serial driver and accompanying PXA270 support. I will have a look at it ASAP. We do actually continue to sell the Colibri PXA270 (as we are the Colibri PXA320) and I have been maintaining it lately with sending patches as recently as last week! It would be rather sad to see it drop like the PXA3xx support did a couple years back when we were too busy with other issues. Cheers Marcel > Simon Glass (8): > arm: Remove colibri_pxa270 board > arm: Remove h2200 board > arm: Remove zipitz2 board > arm: Drop pxa serial driver > serial: Update docs to indicate mcfuart supports DM_SERIAL > arm: Remove smdk2410 board > arm: Remove VCMA9 board > serial: Drop the s3c24x0 serial driver > > arch/arm/Kconfig | 25 -- > board/h2200/Kconfig | 9 - > board/h2200/MAINTAINERS | 6 - > board/h2200/Makefile | 14 - > board/h2200/h2200-header.S| 15 - > board/h2200/h2200.c | 73 > board/mpl/common/common_util.c| 23 -- > board/mpl/vcma9/Kconfig | 15 - > board/mpl/vcma9/MAINTAINERS | 6 - > board/mpl/vcma9/Makefile | 11 - > board/mpl/vcma9/cmd_vcma9.c | 119 -- > board/mpl/vcma9/lowlevel_init.S | 500 > -- > board/mpl/vcma9/vcma9.c | 209 --- > board/mpl/vcma9/vcma9.h | 28 -- > board/samsung/smdk2410/Kconfig| 15 - > board/samsung/smdk2410/MAINTAINERS| 6 - > board/samsung/smdk2410/Makefile | 9 - > board/samsung/smdk2410/lowlevel_init.S| 146 > board/samsung/smdk2410/smdk2410.c | 139 --- > board/toradex/colibri_pxa270/Kconfig | 12 - > board/toradex/colibri_pxa270/MAINTAINERS | 6 - > board/toradex/colibri_pxa270/Makefile | 9 - > board/toradex/colibri_pxa270/colibri_pxa270.c | 107 -- > board/zipitz2/Kconfig | 9 - > board/zipitz2/MAINTAINERS | 6 - > board/zipitz2/Makefile| 10 - > board/zipitz2/zipitz2.c | 217 --- > configs/VCMA9_defconfig | 16 - > configs/colibri_pxa270_defconfig | 19 - > configs/h2200_defconfig | 25 -- > configs/smdk2410_defconfig| 16 - > configs/zipitz2_defconfig | 19 - > doc/driver-model/serial-howto.txt | 3 - > drivers/serial/Makefile | 2 - > drivers/serial/serial_pxa.c | 299 --- > drivers/serial/serial_s3c24x0.c | 208 --- > include/configs/VCMA9.h | 207 --- > include/configs/colibri_pxa270.h | 223 > include/configs/h2200.h | 155 > include/configs/smdk2410.h| 181 -- > include/configs/zipitz2.h | 213 --- > scripts/config_whitelist.txt | 6 - > 42 files changed, 3336 deletions(-) > delete mode 100644 board/h2200/Kconfig > delete mode 100644 board/h2200/MAINTAINERS > delete mode 100644 board/h2200/Makefile > delete mode 100644 board/h2200/h2200-header.S > delete mode 100644 board/h2200/h2200.c > delete mode 100644 board/mpl/vcma9/Kconfig > delete mode 100644 board/mpl/vcma9/MAINTAINERS > delete mode 100644 board/mpl/vcma9/Makefile > delete mode 100644 board/mpl/vcma9/cmd_vcma9.c > delete mode 100644 board/mpl/vcma9/lowlevel_init.S > delete mode 100644 board/mpl/vcma9/vcma9.c > delete mode 100644 board/mpl/vcma9/vcma9.h > delete mode 100644 board/samsung/smdk2410/Kconfig > delete mode 100644 board/samsung/smdk2410/MAINTAINERS > delete mode 100644 board/samsung/smdk2410/Makefile > delete mode 100644 board/samsung/smdk2410/lowlevel_init.S > delete mode 100644 board/samsung/smdk2410/smdk2410.c > delete mode 100644 board/toradex/colibri_pxa270/Kconfig > delete mode 100644 board/toradex/colibri_pxa270/MAINTAINERS > delete mode 100644 board/toradex/colibri_pxa270/Makefile > delete mode 100644 board/toradex/colibri_pxa270/colibri_pxa270.c > delete mode 100644 board/zipitz2/Kconfig > delete mode 100644 board/zipitz2/MAINTAINERS > delete mode 100644 board/zipitz2/Makefile > delete mode 100644 board/zipi
Re: [U-Boot] [PATCH 2/8] travis-ci: Switch to Ubuntu 14.04 'Trusty Tahr'
Hello Tom, Am 20.10.2016 um 21:26 schrieb Tom Rini: In order to make other various improvements, update to the latest environment travis-ci supports. Signed-off-by: Tom Rini --- .travis.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Heiko Schocher bye, Heiko diff --git a/.travis.yml b/.travis.yml index 18bf2ed4fcdb..845f6cad9400 100644 --- a/.travis.yml +++ b/.travis.yml @@ -3,7 +3,8 @@ # build U-Boot on Travis CI - https://travis-ci.org/ -sudo: true +sudo: required +dist: trusty language: c -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] travis-ci: Use a git URI for dtc.git
Hello Tom, Am 20.10.2016 um 21:26 schrieb Tom Rini: Currently we fail to fetch the dtc.git tree due to an SSL issue within the travis-ci environment. The easiest fix here is to switch to a git URI. Signed-off-by: Tom Rini --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Heiko Schocher bye, Heiko diff --git a/.travis.yml b/.travis.yml index 845f6cad9400..2f1d05d443f5 100644 --- a/.travis.yml +++ b/.travis.yml @@ -25,7 +25,7 @@ cache: install: # install latest device tree compiler - - git clone --depth=1 https://git.kernel.org/pub/scm/utils/dtc/dtc.git /tmp/dtc + - git clone --depth=1 git://git.kernel.org/pub/scm/utils/dtc/dtc.git /tmp/dtc - make -j4 -C /tmp/dtc # prepare buildman environment - export BUILDMAN_ROOT="root:" -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] travis-ci: Do not make buildman warnings fatal
Hello Tom,
Am 20.10.2016 um 21:26 schrieb Tom Rini:
We currently will always see a number of warnings due to device tree
issues. These (and other warnings) should not make the build be marked
as failure so catch exit status 129 specifically and return 0 in that
case.
Cc: Heiko Schocher
Signed-off-by: Tom Rini
You mean here this "Warning (unit_address_vs_reg):" warnings?
IIRC I posted some month ago a patch, which suppress them ... the
patch was rejected, with the plausible reason, that we should fix
this issues ... so I started and posted some dts fix patches, also
rejected with the reason that this should come from linux syncs ...
Hmm.. do we syncs for our DTS files with linux?
Nevertheless: we should at least fix this for travis, so:
Reviewed-by: Heiko Schocher
bye,
Heiko
---
.travis.yml | 7 +++
1 file changed, 7 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 2f1d05d443f5..d93efe02b0b1 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -69,8 +69,15 @@ script:
- if [[ "${TEST_CMD}" != "" ]]; then
${TEST_CMD};
fi
+ # Exit code 129 means warnings only.
- if [[ "${BUILDMAN}" != "" ]]; then
+ set +e;
tools/buildman/buildman ${BUILDMAN};
+ if [[ "$?" == "0" || "$?" == "129" ]]; then
+ exit 0;
+ else
+ exit $?;
+ fi
fi
matrix:
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading kernel from SD card slow on MinnowBoard Turbot since v2016.09
Hi,
On 10/21/2016 03:32 PM, Bin Meng wrote:
> +Simon, Stefan,
>
> On Fri, Oct 21, 2016 at 12:36 PM, Jaehoon Chung
> wrote:
>> Hi,
>>
>> On 10/21/2016 01:27 AM, Raschen Josef wrote:
>>> Hi,
>>>
>>> Reading a kernel image from an SD card via the fatload command on the
>>> MinnowBoard Turbot seems to be significantly slower since v2016.09 compared
>>> to v2016.07:
>>>
>>> v2016.07
>>> => fatload mmc 1:1 ${loadaddr} bzImage ; zboot ${loadaddr}
>>> reading bzImage
>>> 5749232 bytes read in 129 ms (42.5 MiB/s)
>>>
>>> v2016.09
>>> => fatload mmc 1:1 ${loadaddr} bzImage ; zboot ${loadaddr}
>>> reading bzImage
>>> 5749232 bytes read in 249 ms (22 MiB/s)
>>>
>>> The same for v2016.11-rc1.
>>>
>>> I am using U-Boot in bare mode on the board. Any idea what causes this?
>>
>> Could you share which driver you use?
>>
>
> Could you bisect to see which commit introduced this regression?
I did..but i didn't see this issue on my boards. :(
So as Bin's suggestion, could you try to bisect..?
Best Regards,
Jaehoon Chung
>
> Regards,
> Bin
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] travis-ci: Update toolchain and buildman usage
Hello Tom,
Am 20.10.2016 um 21:26 schrieb Tom Rini:
- Drop the 'cache' line, travis-ci says to not cache apt packages (and
does not).
- Get the Ubuntu provided toolchain for ARM and PowerPC.
- Add more toolchain options that buildman can fetch.
Signed-off-by: Tom Rini
---
.travis.yml | 59 +++
1 file changed, 15 insertions(+), 44 deletions(-)
Reviewed-by: Heiko Schocher
bye,
Heiko
diff --git a/.travis.yml b/.travis.yml
index d93efe02b0b1..8d1a90eb164b 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -19,9 +19,9 @@ addons:
- libsdl1.2-dev
- python
- python-virtualenv
-
-cache:
- - apt
+- gcc-powerpc-linux-gnu
+- gcc-arm-linux-gnueabihf
+- iasl
install:
# install latest device tree compiler
@@ -29,17 +29,8 @@ install:
- make -j4 -C /tmp/dtc
# prepare buildman environment
- export BUILDMAN_ROOT="root:"
- - export BUILDMAN_PPC="ppc:"
- - export BUILDMAN_ARM="arm:"
- - export BUILDMAN_SANDBOX="sandbox:"
- - echo -e "[toolchain]\n${BUILDMAN_ROOT} /\n" > ~/.buildman
- - echo -e "${BUILDMAN_PPC}
/opt/eldk-5.4/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/\n" >>
~/.buildman
- - echo -e "${BUILDMAN_ARM}
/opt/eldk-5.4/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi/\n" >>
~/.buildman
- - echo -e "${BUILDMAN_SANDBOX} /usr/bin/gcc\n" >> ~/.buildman
- - export BUILDMAN_ALIAS="x86:"
- - export BUILDMAN_ALIAS_ARM="arm:"
- - echo -e "\n\n[toolchain-alias]\n${BUILDMAN_ALIAS} i386\n" >> ~/.buildman
- - echo -e "${BUILDMAN_ALIAS_ARM} armv5te\n" >> ~/.buildman
+ - echo -e "[toolchain]\n${BUILDMAN_ROOT} /usr" > ~/.buildman
+ - echo -e "\n[toolchain-alias]\nblackfin = bfin\nsh = sh4\nopenrisc = or32"
>> ~/.buildman
- cat ~/.buildman
- virtualenv /tmp/venv
- . /tmp/venv/bin/activate
@@ -55,14 +46,15 @@ env:
before_script:
# install toolchains based on TOOLCHAIN} variable
- if [[ "${TOOLCHAIN}" == *aarch64* ]]; then ./tools/buildman/buildman
--fetch-arch aarch64 ; fi
- - if [[ "${TOOLCHAIN}" == *arm* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/armv5te/eldk-eglibc-i686-arm-toolchain-gmae-5.4.sh
; fi
- - if [[ "${TOOLCHAIN}" == *arm* ]]; then sh
eldk-eglibc-i686-arm-toolchain-gmae-5.4.sh -y ; fi
- if [[ "${TOOLCHAIN}" == *avr32* ]]; then ./tools/buildman/buildman
--fetch-arch avr32 ; fi
- - if [[ "${TOOLCHAIN}" == *i386* ]]; then ./tools/buildman/buildman sandbox
--fetch-arch i386 ; fi
+ - if [[ "${TOOLCHAIN}" == *bfin* ]]; then ./tools/buildman/buildman
--fetch-arch bfin ; fi
- if [[ "${TOOLCHAIN}" == *m68k* ]]; then ./tools/buildman/buildman
--fetch-arch m68k ; fi
+ - if [[ "${TOOLCHAIN}" == *microblaze* ]]; then ./tools/buildman/buildman
--fetch-arch microblaze ; fi
- if [[ "${TOOLCHAIN}" == *mips* ]]; then ./tools/buildman/buildman
--fetch-arch mips ; fi
- - if [[ "${TOOLCHAIN}" == *ppc* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/powerpc/eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh
; fi
- - if [[ "${TOOLCHAIN}" == *ppc* ]]; then sh
eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh -y ; fi
+ - if [[ "${TOOLCHAIN}" == *or32* ]]; then ./tools/buildman/buildman
--fetch-arch or32 ; fi
+ - if [[ "${TOOLCHAIN}" == *sh4* ]]; then ./tools/buildman/buildman
--fetch-arch sh4 ; fi
+ - if [[ "${TOOLCHAIN}" == *x86_64* ]]; then ./tools/buildman/buildman
--fetch-arch x86_64 ; fi
+ - if [[ "${TOOLCHAIN}" == *xtensa* ]]; then ./tools/buildman/buildman
--fetch-arch xtensa ; fi
script:
# the execution sequence for each test
@@ -86,40 +78,33 @@ matrix:
# each env setting here is a dedicated build
- env:
- BUILDMAN="arm1136"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="arm1136"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="arm1176"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="arm720t"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="arm920t"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="atmel -x avr32"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="avr32"
TOOLCHAIN="avr32"
- env:
- BUILDMAN="davinci"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="denx"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="freescale -x powerpc,m68k,aarch64"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="sandbox x86"
- TOOLCHAIN="i386"
+ TOOLCHAIN="x86_64"
+ script:
+- export BUILDMAN_X86="x86:";
+ echo -e "\n[toolchain-prefix]\n${BUILDMAN_X86}
${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-" >>
~/.buildman
- env:
- BUILDMAN="kirkwood"
- TOOLCHAIN="arm"
- env:
- BUILDMAN="m68k"
TOOLCHAIN="m68k"
@@ -128,46 +113,32 @@ matrix:
TOOLCHAIN="mips"
- env:
- BUILDMAN="mpc512x"
- TOOLCHAIN="ppc"
- env:
-
Re: [U-Boot] [PATCH 6/8] travis-ci: Add more architectures
Hello Tom, Am 20.10.2016 um 21:26 schrieb Tom Rini: We can now build for microblaze, sh4 and xtensa. Signed-off-by: Tom Rini --- .travis.yml | 9 + 1 file changed, 9 insertions(+) Reviewed-by: Heiko Schocher bye, Heiko diff --git a/.travis.yml b/.travis.yml index 8d1a90eb164b..8ebcfaf996ab 100644 --- a/.travis.yml +++ b/.travis.yml @@ -109,6 +109,9 @@ matrix: - BUILDMAN="m68k" TOOLCHAIN="m68k" - env: +- BUILDMAN="microblaze" + TOOLCHAIN="microblaze" +- env: - BUILDMAN="mips" TOOLCHAIN="mips" - env: @@ -142,6 +145,12 @@ matrix: - env: - BUILDMAN="aarch64" TOOLCHAIN="aarch64" +- env: +- BUILDMAN="sh4" + TOOLCHAIN="sh4" +- env: +- BUILDMAN="xtensa" + TOOLCHAIN="xtensa" # QA jobs for code analytics # static code analysis with cppcheck (we can add --enable=all later) -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] travis-ci: Drop 'TEST_CMD'
Hello Tom,
Am 20.10.2016 um 21:26 schrieb Tom Rini:
We don't need to use TEST_CMD in order to run tests. We need a BUILDMAN
and TOOLCHAIN variable to avoid having to duplicate logic or write some
wrapper function. But this makes the tests harder as we add more
complex examples.
Signed-off-by: Tom Rini
---
.travis.yml | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
Reviewed-by: Heiko Schocher
bye,
Heiko
diff --git a/.travis.yml b/.travis.yml
index 8ebcfaf996ab..25b0023d631b 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -57,10 +57,6 @@ before_script:
- if [[ "${TOOLCHAIN}" == *xtensa* ]]; then ./tools/buildman/buildman
--fetch-arch xtensa ; fi
script:
- # the execution sequence for each test
- - if [[ "${TEST_CMD}" != "" ]]; then
- ${TEST_CMD};
- fi
# Exit code 129 means warnings only.
- if [[ "${BUILDMAN}" != "" ]]; then
set +e;
@@ -154,24 +150,22 @@ matrix:
# QA jobs for code analytics
# static code analysis with cppcheck (we can add --enable=all later)
-- env:
-- TEST_CMD="cppcheck --force --quiet --inline-suppr ."
+- script:
+- cppcheck --force --quiet --inline-suppr .
# search for TODO within source tree
-- env:
-- TEST_CMD="grep -r TODO ."
+- script:
+- grep -r TODO .
# search for FIXME within source tree
-- env:
-- TEST_CMD="grep -r FIXME ."
+- script:
+- grep -r FIXME .
# search for HACK within source tree and ignore HACKKIT board
-- env:
-- TEST_CMD="grep -r HACK . | grep -v HACKKIT"
script:
- grep -r HACK . | grep -v HACKKIT
# some statistics about the code base
-- env:
-- TEST_CMD="sloccount ."
+- script:
+- sloccount .
# test/py
-- env:
-- TEST_CMD="./test/py/test.py --bd sandbox --build"
+- script:
+- ./test/py/test.py --bd sandbox --build
# TODO make it perfect ;-r
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] dm: Update on serial driver progress
On 10/21/2016 08:52 AM, Marcel Ziswiler wrote: > Hi Simon > > On Thu, 2016-10-20 at 13:06 -0600, Simon Glass wrote: >> Only three serial drivers remain to be converted. This series drops >> two of those, since the boards appear to be unmaintained. >> >> With this, only blackfin remains. >> >> The blackfin driver probably needs to be converted as there is recent >> activity with these boards. I am copying the maintainer so that this >> work can be completed. > > Could you please hold off with dropping the PXA serial driver and > accompanying PXA270 support. I will have a look at it ASAP. We do > actually continue to sell the Colibri PXA270 (as we are the Colibri > PXA320) and I have been maintaining it lately with sending patches as > recently as last week! It would be rather sad to see it drop like the > PXA3xx support did a couple years back when we were too busy with other > issues. > > Cheers > > Marcel > >> Simon Glass (8): >> arm: Remove colibri_pxa270 board >> arm: Remove h2200 board >> arm: Remove zipitz2 board >> arm: Drop pxa serial driver Whoa, would be nice to keep me on Cc regarding PXA stuff. Thanks for CCing me, Marcel. And I would like to NAK these first four patches. >> serial: Update docs to indicate mcfuart supports DM_SERIAL >> arm: Remove smdk2410 board >> arm: Remove VCMA9 board >> serial: Drop the s3c24x0 serial driver -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] armv8/ls1043a: fixup GIC offset according to SVR and SCFG_GIC400_ALIGN[GIC_ADDR_BIT]
The LS1043A rev1.1 silicon supports two types of GIC offset: 4K alignment and 64K alignment. The bit SCFG_GIC400_ALIGN[GIC_ADDR_BIT] is used to choose which offset will be used. If GIC_ADDR_BIT bit is set, 4K alignment is used, or else 64K alignment is used. 64K alignment is the default setting. Overriding the weekly smp_kick_all_cpus, the new impletment is able to detect GIC offset. Signed-off-by: Wenbin Song Signed-off-by: Mingkai Hu --- Changes in v3: Add description about smp_kick_all_cpus on commit message. Rename the macros on commit message to match with them used in the change. Replace CONFIG_LS1043A with HAS_FEATURE_GIC4K_ALIGN. Changes in v2: None --- arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4 ++ arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 47 +++ arch/arm/include/asm/arch-fsl-layerscape/config.h | 12 +- 3 files changed, 61 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index 94ec8d5..c66c497 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -12,6 +12,7 @@ config ARCH_LS1043A select SYS_FSL_DDR_VER_50 select SYS_FSL_ERRATUM_A010315 select SYS_FSL_ERRATUM_A010539 + select HAS_FEATURE_GIC4K_ALIGN config ARCH_LS1046A bool @@ -135,4 +136,7 @@ config SYS_FSL_DDR4 help Enable Freescale DDR4 controller. +config HAS_FEATURE_GIC4K_ALIGN + bool + endmenu diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S index 5d0b7a4..f0da559 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S @@ -14,6 +14,40 @@ #include #endif +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN + +/* fixup GIC offset */ +ENTRY(fix_gic_offset) + ldr x0, =GICD_BASE + ldr x1, =GICC_BASE + ldr x3, =DCFG_CCSR_SVR + ldr w3, [x3] + rev w3, w3 + andsw3, w3, #0xff + cmp w3, #REV1_0 + b.eq1f + ldr x3, =SCFG_GIC400_ALIGN + ldr w3, [x3] + rev w3, w3 + tbnzw3, #GIC_ADDR_BIT, 1f + ret +1: + ldr x0, =GICD_BASE_4K + ldr x1, =GICC_BASE_4K + ret +ENDPROC(fix_gic_offset) + +ENTRY(smp_kick_all_cpus) + /* Kick secondary cpus up by SGI 0 interrupt */ + mov x29, lr /* Save LR */ + bl fix_gic_offset + bl gic_kick_secondary_cpus + mov lr, x29 /* Restore LR */ + ret +ENDPROC(smp_kick_all_cpus) + +#endif + ENTRY(lowlevel_init) mov x29, lr /* Save LR */ @@ -105,15 +139,23 @@ ENTRY(lowlevel_init) /* Initialize GIC Secure Bank Status */ #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) branch_if_slave x0, 1f +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN + bl fix_gic_offset +#else ldr x0, =GICD_BASE +#endif bl gic_init_secure 1: #ifdef CONFIG_GICV3 ldr x0, =GICR_BASE bl gic_init_secure_percpu #elif defined(CONFIG_GICV2) +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN + bl fix_gic_offset +#else ldr x0, =GICD_BASE ldr x1, =GICC_BASE +#endif bl gic_init_secure_percpu #endif #endif @@ -335,7 +377,12 @@ ENTRY(secondary_boot_func) #if defined(CONFIG_GICV3) gic_wait_for_interrupt_m x0 #elif defined(CONFIG_GICV2) +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN + bl fix_gic_offset + mov x0, x1 +#else ldr x0, =GICC_BASE +#endif gic_wait_for_interrupt_m x0, w1 #endif diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h b/arch/arm/include/asm/arch-fsl-layerscape/config.h index 4201e0f..eb6e58d 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h @@ -172,8 +172,16 @@ #define SMMU_BASE 0x0900 /* Generic Interrupt Controller Definitions */ -#define GICD_BASE 0x01401000 -#define GICC_BASE 0x01402000 +#define GICD_BASE 0x0141 +#define GICC_BASE 0x0142 +#define GICD_BASE_4K0x01401000 +#define GICC_BASE_4K0x01402000 + +#define DCFG_CCSR_SVR 0x1ee00a4 +#define REV1_0 0x10 +#define REV1_1 0x11 +#define GIC_ADDR_BIT 31 +#define SCFG_GIC400_ALIGN 0x1570188 #define CONFIG_SYS_FSL_ERRATUM_A008850 #define CONFIG_SYS_FSL_ERRATUM_A009663 -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 MSI node
The default MSI node in kernel tree is for LS1043A rev1.1 silicon,
if rev1.0 silicon used, need to fixup the MSI node to match it.
Signed-off-by: Wenbin Song
Signed-off-by: Mingkai Hu
---
Changes for v3:
Replace CONFIG_LS1043A with HAS_FEATURE_ENHACED_MSI.
---
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 3 +
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 94 +++
2 files changed, 97 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index c66c497..d2537bb 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -13,6 +13,7 @@ config ARCH_LS1043A
select SYS_FSL_ERRATUM_A010315
select SYS_FSL_ERRATUM_A010539
select HAS_FEATURE_GIC4K_ALIGN
+ select HAS_FEATURE_ENHANCED_MSI
config ARCH_LS1046A
bool
@@ -138,5 +139,7 @@ config SYS_FSL_DDR4
config HAS_FEATURE_GIC4K_ALIGN
bool
+config HAS_FEATURE_ENHANCED_MSI
+ bool
endmenu
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 54f8492..7a1e445 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -171,6 +171,97 @@ static void fdt_fixup_gic(void *blob)
return;
}
#endif
+#ifdef CONFIG_HAS_FEATURE_ENHANCED_MSI
+static int _fdt_fixup_msi_subnode(void *blob, int parentoffset,
+ const char *name, int irq_no)
+{
+ int err, offset;
+ u32 tmp[3];
+
+ offset = fdt_subnode_offset(blob, parentoffset, name);
+ if (offset < 0) {
+ printf("WARNING: fdt_subnode_offset can't find %s: %s\n",
+ name, fdt_strerror(offset));
+ return 0;
+ }
+
+ tmp[0] = cpu_to_fdt32(0x0);
+ tmp[1] = cpu_to_fdt32(irq_no);
+ tmp[2] = cpu_to_fdt32(0x4);
+
+ err = fdt_setprop(blob, offset, "interrupts", tmp, sizeof(tmp));
+ if (err < 0) {
+ printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
+ "interrupts", name, fdt_strerror(err));
+ return 0;
+ }
+
+ return 1;
+}
+
+static int _fdt_fixup_pci_msi(void *blob, const char *name)
+{
+ int offset, len, err;
+ void *p;
+ int val;
+ u32 tmp[4][8];
+
+ offset = fdt_path_offset(blob, name);
+ if (offset < 0) {
+ printf("WARNING: fdt_path_offset can't find path %s: %s\n",
+ name, fdt_strerror(offset));
+ return 0;
+ }
+
+ p = (char *)fdt_getprop(blob, offset, "interrupt-map", &len);
+ if (!p || len != sizeof(tmp)) {
+ printf("WARNING: fdt_getprop can't get %s from node %s\n",
+ "interrupt-map", name);
+ return 0;
+ }
+
+ memcpy((char *)tmp, p, len);
+ val = fdt32_to_cpu(tmp[0][6]);
+ tmp[1][6] = cpu_to_fdt32(val + 1);
+ tmp[2][6] = cpu_to_fdt32(val + 2);
+ tmp[3][6] = cpu_to_fdt32(val + 3);
+
+ err = fdt_setprop(blob, offset, "interrupt-map", tmp, sizeof(tmp));
+ if (err < 0) {
+ printf("WARNING: fdt_setprop can't set %s from node %s: %s.\n",
+ "interrupt-map", name, fdt_strerror(err));
+ return 0;
+ }
+ return 1;
+}
+
+/* Fixup msi to v1_0*/
+
+static void fdt_fixup_msi(void *blob)
+{
+ int nodeoffset;
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+ unsigned int val;
+
+ val = gur_in32(&gur->svr) & 0xff;
+ if (val == REV1_1)
+ return;
+
+ nodeoffset = fdt_path_offset(blob, "/soc/msi-controller");
+ if (nodeoffset < 0) {
+ printf("WARNING: fdt_path_offset can't find path %s: %s\n",
+ "/soc/msi-controller", fdt_strerror(nodeoffset));
+ return;
+ }
+ _fdt_fixup_msi_subnode(blob, nodeoffset, "msi0@1571000", 116);
+ _fdt_fixup_msi_subnode(blob, nodeoffset, "msi1@1572000", 126);
+ _fdt_fixup_msi_subnode(blob, nodeoffset, "msi2@1573000", 160);
+
+ _fdt_fixup_pci_msi(blob, "/soc/pcie@340");
+ _fdt_fixup_pci_msi(blob, "/soc/pcie@350");
+ _fdt_fixup_pci_msi(blob, "/soc/pcie@360");
+}
+#endif
void ft_cpu_setup(void *blob, bd_t *bd)
{
@@ -219,4 +310,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN
fdt_fixup_gic(blob);
#endif
+#ifdef CONFIG_HAS_FEATURE_ENHANCED_MSI
+ fdt_fixup_msi(blob);
+#endif
}
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] armv8/fsl-layerscape: fdt: fixup GIC node for LS1043A rev1.0
The LS1043A rev1.1 silicon supports two types of GIC offset: 4K alignment
and 64K alignment. 4K alignment is consistent with rev1.0 implement.
The default GIC offset in kernel device tree is using 64K alignment,
if rev1.0 silicon used, need to fixup the GIC node to use 4K alignment.
Signed-off-by: Wenbin Song
Signed-off-by: Mingkai Hu
---
Changes for v3:
Replace CONFIG_LS1043A with HAS_FEATURE_GIC4K_ALIGN.
---
arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 49 ++
.../include/asm/arch-fsl-layerscape/immap_lsch2.h | 3 +-
2 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 1a8321b..54f8492 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -126,6 +126,52 @@ void fsl_fdt_disable_usb(void *blob)
}
}
+#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN
+/* Fixup gic node align with 4K */
+static void fdt_fixup_gic(void *blob)
+{
+ int offset, err;
+ u64 reg[8];
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+ unsigned int val;
+ struct ccsr_scfg __iomem *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
+
+ val = gur_in32(&gur->svr) & 0xff;
+
+ if (val == REV1_1) {
+ val = scfg_in32(&scfg->gic_align) & (0x01 << GIC_ADDR_BIT);
+ if (!val)
+ return;
+ }
+
+ offset = fdt_subnode_offset(blob, 0, "interrupt-controller@140");
+ if (offset < 0) {
+ printf("WARNING: fdt_subnode_offset can't find node %s: %s\n",
+ "interrupt-controller@140", fdt_strerror(offset));
+ return;
+ }
+
+ reg[0] = cpu_to_fdt64(0x1401000);
+ reg[1] = cpu_to_fdt64(0x1000);
+ reg[2] = cpu_to_fdt64(0x1402000);
+ reg[3] = cpu_to_fdt64(0x2000);
+ reg[4] = cpu_to_fdt64(0x1404000);
+ reg[5] = cpu_to_fdt64(0x2000);
+ reg[6] = cpu_to_fdt64(0x1406000);
+ reg[7] = cpu_to_fdt64(0x2000);
+
+ err = fdt_setprop(blob, offset, "reg", reg, sizeof(reg));
+ if (err < 0) {
+ printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
+ "reg", "interrupt-controller@140",
+ fdt_strerror(err));
+ return;
+ }
+
+ return;
+}
+#endif
+
void ft_cpu_setup(void *blob, bd_t *bd)
{
#ifdef CONFIG_FSL_LSCH2
@@ -170,4 +216,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#endif
fsl_fdt_disable_usb(blob);
+#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN
+ fdt_fixup_gic(blob);
+#endif
}
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index d88543d..1dfef53 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -359,7 +359,8 @@ struct ccsr_scfg {
u32 qspi_cfg;
u8 res_160[0x180-0x160];
u32 dmamcr;
- u8 res_184[0x18c-0x184];
+ u8 res_184[0x188-0x184];
+ u32 gic_align;
u32 debug_icid;
u8 res_190[0x1a4-0x190];
u32 snpcnfgcr;
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] travis-ci: Add test.py for various qemu platforms
Hello Tom,
Am 20.10.2016 um 21:26 schrieb Tom Rini:
- Add a PPA for a more recent qemu (required for PowerPC to work)
- Add tests to run test.py for various QEMU platforms. This relies on
swarren's uboot-test-hooks repository to provide the abstractions.
Signed-off-by: Tom Rini
---
.travis.yml | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
Great!
Reviewed-by: Heiko Schocher
bye,
Heiko
diff --git a/.travis.yml b/.travis.yml
index 25b0023d631b..77025128ecd5 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -10,6 +10,8 @@ language: c
addons:
apt:
+sources:
+- sourceline: 'ppa:gns3/qemu'
packages:
- cppcheck
- sloccount
@@ -19,6 +21,10 @@ addons:
- libsdl1.2-dev
- python
- python-virtualenv
+- qemu-system-arm
+- qemu-system-mips
+- qemu-system-ppc
+- qemu-system-x86
- gcc-powerpc-linux-gnu
- gcc-arm-linux-gnueabihf
- iasl
@@ -27,6 +33,9 @@ install:
# install latest device tree compiler
- git clone --depth=1 git://git.kernel.org/pub/scm/utils/dtc/dtc.git /tmp/dtc
- make -j4 -C /tmp/dtc
+ # Clone uboot-test-hooks
+ - git clone --depth=1 git://github.com/trini/uboot-test-hooks.git
/tmp/uboot-test-hooks
+ - ln -s travis-ci /tmp/uboot-test-hooks/bin/`hostname`
# prepare buildman environment
- export BUILDMAN_ROOT="root:"
- echo -e "[toolchain]\n${BUILDMAN_ROOT} /usr" > ~/.buildman
@@ -38,7 +47,7 @@ install:
env:
global:
-- PATH=/tmp/dtc:$PATH
+- PATH=/tmp/dtc:/tmp/uboot-test-hooks/bin:$PATH
- BUILD_DIR=build
- HOSTCC="cc"
- HOSTCXX="c++"
@@ -167,5 +176,29 @@ matrix:
# test/py
- script:
- ./test/py/test.py --bd sandbox --build
+- env:
+- CROSS_COMPILE="/usr/bin/arm-linux-gnueabihf-"
+ script:
+- ./test/py/test.py --bd vexpress_ca15_tc2 --id qemu --build;
+ ./test/py/test.py --bd vexpress_ca9x4 --id qemu --build;
+ ./test/py/test.py --bd integratorcp_cm926ejs --id qemu --build;
+- env:
+- TOOLCHAIN="mips"
+
CROSS_COMPILE="${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-"
+ script:
+- ./test/py/test.py --bd qemu_mips --build -k 'not sleep';
+ ./test/py/test.py --bd qemu_mipsel --build -k 'not sleep';
+ ./test/py/test.py --bd qemu_mips64 --build -k 'not sleep';
+ ./test/py/test.py --bd qemu_mips64el --build -k 'not sleep';
+- env:
+- CROSS_COMPILE="/usr/bin/powerpc-linux-gnu-"
+ script:
+- ./test/py/test.py --bd qemu-ppce500 --build -k 'not sleep'
+- env:
+- TOOLCHAIN="x86_64"
+ BUILD_ROM=yes
+
CROSS_COMPILE="${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-"
+ script:
+- ./test/py/test.py --bd qemu-x86 --build -k 'not sleep'
# TODO make it perfect ;-r
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: dts: Pine64: add Ethernet alias
On Fri, Oct 21, 2016 at 5:41 AM, Andre Przywara wrote:
> The sun8i-emac driver works fine with the A64 Ethernet IP, but we are
> missing an alias entry to trigger the driver instantiation by U-Boot.
> Add the line to point U-Boot to the Ethernet DT node.
> This enables TFTP boot on the Pine64.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/dts/sun50i-a64-pine64-common.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
> b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
> index d5a7249..c0fde44 100644
> --- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
> +++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
> @@ -46,6 +46,7 @@
>
> aliases {
> serial0 = &uart0;
> + ethernet0 = &emac;
I think alias doesn’t require for probing emac, it will straight away
probed like
> dm tree
eth [ + ] ethernet@01c3
Did you find any issue while detecting eth?
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: A64: enable USB support
On Fri, Oct 21, 2016 at 6:54 AM, Andre Przywara wrote:
> From: Amit Singh Tomar
>
> Mostly by adding MACH_SUN50I to some existing #ifdefs enable support
> for the the HCI0 USB host controller on the A64.
> Fix up some minor 64-bit hiccups on the way.
> Add the bare minimum DT bits to the A64 .dtsi and enable the controllers
> and the PHY on the Pine64.
> This is limited to the first USB controller at the moment, which is
> connected to the lower USB socket on the Pine64 board.
> [Andre: remove unneeded defines, enable OHCI, add commit message]
>
> Signed-off-by: Amit Singh Tomar
> Signed-off-by: Andre Przywara
> ---
> arch/arm/dts/sun50i-a64-pine64-common.dtsi | 12
> arch/arm/dts/sun50i-a64.dtsi| 29
> +
> arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 2 +-
> arch/arm/mach-sunxi/usb_phy.c | 5 +++--
> configs/pine64_plus_defconfig | 1 +
> drivers/usb/host/ehci-sunxi.c | 7 ---
> drivers/usb/host/ohci-sunxi.c | 1 +
> include/configs/sun50i.h| 5 +
> 8 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
> b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
> index c0fde44..9ec81c6 100644
> --- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
> +++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
> @@ -79,3 +79,15 @@
> pinctrl-0 = <&i2c1_pins>;
> status = "okay";
> };
> +
> +&usbphy {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/sun50i-a64.dtsi b/arch/arm/dts/sun50i-a64.dtsi
> index 7d0dc76..bef0d00 100644
> --- a/arch/arm/dts/sun50i-a64.dtsi
> +++ b/arch/arm/dts/sun50i-a64.dtsi
> @@ -653,5 +653,34 @@
> #address-cells = <1>;
> #size-cells = <0>;
> };
> +
> + usbphy: phy@1c1b810 {
> + compatible = "allwinner,sun50i-a64-usb-phy",
> +"allwinner,sun8i-a33-usb-phy";
> + reg = <0x01c1b810 0x14>, <0x01c1b800 0x4>;
> + reg-names = "phy_ctrl", "pmu1";
> + status = "disabled";
> + #phy-cells = <1>;
> + };
> +
> + ehci1: usb@01c1b000 {
> + compatible = "allwinner,sun50i-a64-ehci",
> +"generic-ehci";
> + reg = <0x01c1b000 0x100>;
> + interrupts = ;
> + phys = <&usbphy 1>;
> + phy-names = "usb";
> + status = "disabled";
> + };
> +
> + ohci1: usb@01c1b400 {
> + compatible = "allwinner,sun50i-a64-ohci",
> +"generic-ohci";
> + reg = <0x01c1b400 0x100>;
> + interrupts = ;
> + phys = <&usbphy 1>;
> + phy-names = "usb";
> + status = "enabled";
> + };
> };
> };
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> index 5f93830..7232f6d 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> @@ -56,7 +56,7 @@
> #define SUNXI_USB2_BASE0x01c1c000
> #endif
> #ifdef CONFIG_SUNXI_GEN_SUN6I
> -#ifdef CONFIG_MACH_SUN8I_H3
> +#if defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
> #define SUNXI_USBPHY_BASE 0x01c19000
> #define SUNXI_USB0_BASE0x01c1a000
> #define SUNXI_USB1_BASE0x01c1b000
> diff --git a/arch/arm/mach-sunxi/usb_phy.c b/arch/arm/mach-sunxi/usb_phy.c
> index bd1bbee..278587b 100644
> --- a/arch/arm/mach-sunxi/usb_phy.c
> +++ b/arch/arm/mach-sunxi/usb_phy.c
> @@ -146,12 +146,13 @@ __maybe_unused static void usb_phy_write(struct
> sunxi_usb_phy *phy, int addr,
> }
> }
>
> -#if defined CONFIG_MACH_SUN8I_H3
> +#if defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
> static void sunxi_usb_phy_config(struct sunxi_usb_phy *phy)
> {
> +#if defined CONFIG_MACH_SUN8I_H3
> if (phy->id == 0)
> clrbits_le32(SUNXI_USBPHY_BASE + REG_PHY_UNK_H3, 0x01);
> -
> +#endif
> clrbits_le32(phy->base + REG_PMU_UNK_H3, 0x02);
> }
> #elif defined CONFIG_MACH_SUN8I_A83T
> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
> index 6f82190..bd3e2e6 100644
> --- a/configs/pine64_plus_defconfig
> +++ b/configs/pine64_plus_defconfig
> @@ -10,3 +10,4 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
> # CONFIG_CMD_FLASH is not set
> # CONFIG_CMD_FPGA is not set
> CONFIG_SUN8I_EMAC=y
> +CONFIG_USB_EHCI_HCD=y
> d
Re: [U-Boot] [PATCH] arm: dts: Pine64: add Ethernet alias
Hi,
On 21/10/16 10:31, Jagan Teki wrote:
> On Fri, Oct 21, 2016 at 5:41 AM, Andre Przywara
> wrote:
>> The sun8i-emac driver works fine with the A64 Ethernet IP, but we are
>> missing an alias entry to trigger the driver instantiation by U-Boot.
>> Add the line to point U-Boot to the Ethernet DT node.
>> This enables TFTP boot on the Pine64.
>>
>> Signed-off-by: Andre Przywara
>> ---
>> arch/arm/dts/sun50i-a64-pine64-common.dtsi | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
>> b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
>> index d5a7249..c0fde44 100644
>> --- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
>> +++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
>> @@ -46,6 +46,7 @@
>>
>> aliases {
>> serial0 = &uart0;
>> + ethernet0 = &emac;
>
> I think alias doesn’t require for probing emac, it will straight away
> probed like
>
>> dm tree
>
> eth [ + ] ethernet@01c3
>
> Did you find any issue while detecting eth?
Yes, it just didn't work ;-) I don't have a board here, but can post the
error message later tonight.
In fact I was wondering about that already, maybe it's worth
investigating this further.
But aside from that I think the MAC address calculation based on the SID
serial number does not get triggered without an alias, so we need this
line anyway.
Cheers,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: dts: Pine64: add Ethernet alias
Hi,
On 21-10-16 12:06, Andre Przywara wrote:
Hi,
On 21/10/16 10:31, Jagan Teki wrote:
On Fri, Oct 21, 2016 at 5:41 AM, Andre Przywara wrote:
The sun8i-emac driver works fine with the A64 Ethernet IP, but we are
missing an alias entry to trigger the driver instantiation by U-Boot.
Add the line to point U-Boot to the Ethernet DT node.
This enables TFTP boot on the Pine64.
Signed-off-by: Andre Przywara
---
arch/arm/dts/sun50i-a64-pine64-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
index d5a7249..c0fde44 100644
--- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
+++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
@@ -46,6 +46,7 @@
aliases {
serial0 = &uart0;
+ ethernet0 = &emac;
I think alias doesn’t require for probing emac, it will straight away
probed like
dm tree
eth [ + ] ethernet@01c3
Did you find any issue while detecting eth?
Yes, it just didn't work ;-) I don't have a board here, but can post the
error message later tonight.
In fact I was wondering about that already, maybe it's worth
investigating this further.
But aside from that I think the MAC address calculation based on the SID
serial number does not get triggered without an alias, so we need this
line anyway.
Correct, the MAC address code relies on the alias.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading kernel from SD card slow on MinnowBoard Turbot since v2016.09
Hi
On 10/21/2016 04:40 PM, Jaehoon Chung wrote:
> Hi,
>
> On 10/21/2016 03:32 PM, Bin Meng wrote:
>> +Simon, Stefan,
>>
>> On Fri, Oct 21, 2016 at 12:36 PM, Jaehoon Chung
>> wrote:
>>> Hi,
>>>
>>> On 10/21/2016 01:27 AM, Raschen Josef wrote:
Hi,
Reading a kernel image from an SD card via the fatload command on the
MinnowBoard Turbot seems to be significantly slower since v2016.09
compared to v2016.07:
v2016.07
=> fatload mmc 1:1 ${loadaddr} bzImage ; zboot ${loadaddr}
reading bzImage
5749232 bytes read in 129 ms (42.5 MiB/s)
v2016.09
=> fatload mmc 1:1 ${loadaddr} bzImage ; zboot ${loadaddr}
reading bzImage
5749232 bytes read in 249 ms (22 MiB/s)
The same for v2016.11-rc1.
I am using U-Boot in bare mode on the board. Any idea what causes this?
>>>
>>> Could you share which driver you use?
>>>
>>
>> Could you bisect to see which commit introduced this regression?
>
> I did..but i didn't see this issue on my boards. :(
> So as Bin's suggestion, could you try to bisect..?
I think this is related with below commit...
commit 6dffdbc3a5911e768be21850a612bfb4871a23ef
Author: Wenyou Yang
Date: Sun Sep 18 09:01:22 2016 +0800
mmc: sdhci: Add the programmable clock mode support
Add the programmable clock mode for the clock generator.
Signed-off-by: Wenyou Yang
I'm checking with SD3.0..If this patch cause this issue..i will fix it.
Best Regards,
Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
>>
>> Regards,
>> Bin
>>
>>
>>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ti_omap5_common: Respect USB controller number in fastboot
On Thu, Oct 20, 2016 at 06:58:29PM +0300, Sam Protsenko wrote: > On "fastboot reboot-bootloader" we check "dofastboot" variable and do > "fastboot 0" command in U-Boot if it's 1. But there are boards which have > USB controller number other than 0, so it should be respected when > performing "fastboot" command. > > This patch reuses CONFIG_FASTBOOT_USB_DEV option toprovide correct USB > controller number to "fastboot" command. > > Signed-off-by: Sam Protsenko > --- > include/configs/ti_omap5_common.h | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/include/configs/ti_omap5_common.h > b/include/configs/ti_omap5_common.h > index 29b7d96..144a880 100644 > --- a/include/configs/ti_omap5_common.h > +++ b/include/configs/ti_omap5_common.h > @@ -110,11 +110,15 @@ > DFUARGS \ > NETARGS \ > > +#ifndef CONFIG_FASTBOOT_USB_DEV > +#define CONFIG_FASTBOOT_USB_DEV 0 > +#endif We don't need this hunk, it will always be defined now. -- 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 3/4] configs: am57xx: Enable download gadget
On Thu, Oct 20, 2016 at 06:58:30PM +0300, Sam Protsenko wrote: > Enable USB download gadget (needed for fastboot support) and all > dependencies. > > Signed-off-by: Sam Protsenko Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] fastboot: Add CONFIG_FASTBOOT_USB_DEV option
On Thu, Oct 20, 2016 at 06:58:28PM +0300, Sam Protsenko wrote: > Some boards (like AM57x EVM) has USB OTG controller other than 0. So in > order to use correct controller number in compiled environment we should > define CONFIG_FASTBOOT_USB_DEV option. > > For example, when doing "fastboot reboot-bootloader" we want to enter > fastboot mode automatically. But to do so we need to provide controller > number to "fastboot" command. If this procedure is defined in some config > which is common to bunch of boards, and boards have different USB > controller numbers, we can't just hardcode "fastboot 0" in the > environment. We need to use configurable option, which this patch adds. > > Signed-off-by: Sam Protsenko Reviewed-by: Tom Rini -- 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 4/8] travis-ci: Do not make buildman warnings fatal
On Fri, Oct 21, 2016 at 09:39:28AM +0200, Heiko Schocher wrote: > Hello Tom, > > Am 20.10.2016 um 21:26 schrieb Tom Rini: > >We currently will always see a number of warnings due to device tree > >issues. These (and other warnings) should not make the build be marked > >as failure so catch exit status 129 specifically and return 0 in that > >case. > > > >Cc: Heiko Schocher > >Signed-off-by: Tom Rini > > You mean here this "Warning (unit_address_vs_reg):" warnings? And a few others as well, depending on toolchain. > IIRC I posted some month ago a patch, which suppress them ... the > patch was rejected, with the plausible reason, that we should fix > this issues ... so I started and posted some dts fix patches, also > rejected with the reason that this should come from linux syncs ... > > Hmm.. do we syncs for our DTS files with linux? Yes. I suppose that for example for x86/sandbox we should take your patches. But yes, for other platforms where we are not the authoritative source the fixes need to be pushed to Linux first and merged in. Some platforms sync more often with upstream than others in this regard. > Nevertheless: we should at least fix this for travis, so: > > Reviewed-by: Heiko Schocher 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 4/4] configs: am57xx: Enable fastboot
On Thu, Oct 20, 2016 at 06:58:31PM +0300, Sam Protsenko wrote: > Signed-off-by: Sam Protsenko Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: mkimage: Check if file is regular file
Current Makefile.spl passes -R parameter which is not empty
and pointing to ./ folder.
"./tools/mkimage -T zynqmpimage -R ./"" -d spl/u-boot-spl.bin
spl/boot.bin"
That's why mkimage is trying to parse ./ file and generate
register init which is wrong.
Check that passed filename is regular file. If not do not work with it.
Signed-off-by: Michal Simek
---
tools/zynqmpimage.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/zynqmpimage.c b/tools/zynqmpimage.c
index d08144c2bdfd..202faea07295 100644
--- a/tools/zynqmpimage.c
+++ b/tools/zynqmpimage.c
@@ -237,12 +237,18 @@ static int zynqmpimage_check_image_types(uint8_t type)
static void zynqmpimage_parse_initparams(struct zynqmp_header *zynqhdr,
const char *filename)
{
- /* Expect a table of register-value pairs, e.g. "0x12345678 0x4321" */
- FILE *fp = fopen(filename, "r");
+ FILE *fp;
struct zynqmp_reginit reginit;
unsigned int reg_count = 0;
int r;
+ struct stat path_stat;
+
+ stat(filename, &path_stat);
+ if (!S_ISREG(path_stat.st_mode))
+ return;
+ /* Expect a table of register-value pairs, e.g. "0x12345678 0x4321" */
+ fp = fopen(filename, "r");
if (!fp) {
fprintf(stderr, "Cannot open initparams file: %s\n", filename);
exit(1);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Proposal on changing raw boot mode
Hi, On Thu, 20 Oct 2016 20:07:24 +0300 Sam Protsenko semen.protse...@linaro.org wrote: ... > 1. CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS > > Simple grep shows us that noone actually uses this constant > (despite it's being defined for multiple boards). So I'm thinking to > remove it altogether. What do you think about that? it is not directly used, but config files including imx6_spl.h define CONFIG_SYS_MONITOR_LEN depending on CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS. When removing, take care to update CONFIG_SYS_MONITOR_LEN there. -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ls2080: Add USB boot to distro boot order
The LS2080 chips have USB available, so we can easily add USB boot support to the distro boot order. Signed-off-by: Alexander Graf --- include/configs/ls2080ardb.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h index 045cee6..79b15f2 100644 --- a/include/configs/ls2080ardb.h +++ b/include/configs/ls2080ardb.h @@ -322,6 +322,7 @@ unsigned long get_board_sys_clk(void); #include #define BOOT_TARGET_DEVICES(func) \ + func(USB, usb, 0) \ func(MMC, mmc, 0) \ func(SCSI, scsi, 0) \ func(DHCP, dhcp, na) -- 1.8.5.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: sdhci: assign to clk_mul when host version is upper than SD3.0
To prevent the wrong value check the SD version.
Signed-off-by: Jaehoon Chung
---
drivers/mmc/sdhci.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 10ff57e..766e9ee 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -608,9 +608,11 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
sdhci_host *host,
* In case of Host Controller v3.00, find out whether clock
* multiplier is supported.
*/
- caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
- host->clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >>
- SDHCI_CLOCK_MUL_SHIFT;
+ if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_300) {
+ caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host->clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >>
+ SDHCI_CLOCK_MUL_SHIFT;
+ }
return 0;
}
--
2.10.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: mx6: add MMC2 boot device detection support in SPL
Check BOOT_CFG2[3:4] to determine which SD/MMC port is selected to boot
from. If MMC2 is selected return BOOT_DEVICE_MMC2. In all other cases
return BOOT_DEVICE_MMC1, as we do not have corresponding macro for MMC3
and MMC4.
Signed-off-by: Marcin Niestroj
---
arch/arm/imx-common/spl.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/imx-common/spl.c b/arch/arm/imx-common/spl.c
index bdcda7d..325ba26 100644
--- a/arch/arm/imx-common/spl.c
+++ b/arch/arm/imx-common/spl.c
@@ -14,6 +14,9 @@
#include
#if defined(CONFIG_MX6)
+#define MX6_MMC_PORT_MASK GENMASK(12, 11)
+#define MX6_MMC_PORT_2 BIT(11)
+
/* determine boot device from SRC_SBMR1 (BOOT_CFG[4:1]) or SRC_GPR9 register */
u32 spl_boot_device(void)
{
@@ -55,10 +58,11 @@ u32 spl_boot_device(void)
/* SD/eSD: 8.5.3, Table 8-15 */
case 0x4:
case 0x5:
- return BOOT_DEVICE_MMC1;
/* MMC/eMMC: 8.5.3 */
case 0x6:
case 0x7:
+ if ((reg & MX6_MMC_PORT_MASK) == MX6_MMC_PORT_2)
+ return BOOT_DEVICE_MMC2;
return BOOT_DEVICE_MMC1;
/* NAND Flash: 8.5.2 */
case 0x8 ... 0xf:
--
2.10.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading kernel from SD card slow on MinnowBoard Turbot since v2016.09
Hi On 10/21/2016 08:52 PM, Raschen Josef wrote: > >> I think this is related with below commit... > >> commit 6dffdbc3a5911e768be21850a612bfb4871a23ef >> Author: Wenyou Yang >> Date: Sun Sep 18 09:01:22 2016 +0800 >> >>mmc: sdhci: Add the programmable clock mode support >> >>Add the programmable clock mode for the clock generator. >> >> Signed-off-by: Wenyou Yang >> >> I'm checking with SD3.0..If this patch cause this issue..i will fix it. > >>From my tests it should be somewhere between these two commits: > 1c62d999528da1f052cb4b07cbb540b148c52537OK > ceec08f50b66df0c988033842ec057a32658cfe0NOK Thanks for checking..Could you share which controller you use? I needs to check the driver codes for this...but i didn't know which driver you use.. It should be helpful to me.. Best Regards, Jaehoon Chung > >> >> Best Regards, >> Jaehoon Chung > > Thanks, > Josef > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Proposal on changing raw boot mode
On Thu, Oct 20, 2016 at 08:07:24PM +0300, Sam Protsenko wrote: > Hi guys, > > I'd like to make two changes on how raw MMC address and size of U-Boot > are represented. But I think it's better to discuss it first, so we > are on the same page about it. > > Basically I want to review two config options here. > > 1. CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS > > Simple grep shows us that noone actually uses this constant > (despite it's being defined for multiple boards). So I'm thinking to > remove it altogether. What do you think about that? With the one exception that's been pointed out, yes. > 2. CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > > For TI boards it's defined in common file: > include/configs/ti_armv7_common.h . So if some board has another > U-Boot partition address (on MMC), it must redefine that option after > including ti_armv7_common.h. > > Historical background: actually I tried to change this address > before, because DRA7 EVM and AM57x EVM / X15 boards are broken in > mainline U-Boot right now. My attempt [1] turned out to be > ill-designed, as it broke other boards (IIRC, it was BeagleBone > Black): [2]. Which further led to reverting my patch: [3]. > > It remains to be a problem, though. So I see 2 possible ways how to fix > it: > > (a) Just re-define this address in corresponding board configs (headers). > (b) Convert this option to Kconfig and define it correctly in each > board's defconfig. This, and a few other options, are SPL-specific things that didn't have SPL in the prefix and weren't converted along with Simon's series that covered almost everything else. So yes, please convert this to Kconfig, put it in common/spl/Kconfig, and have sane defaults for various platforms. But also note that when we modify the TI platforms we will have to be careful to not break other use-cases as, iirc, part of the problem was that you want make the Android values the default values for platforms that quite often also run not-Android. 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] ls2080: Add USB boot to distro boot order
On 10/21/2016 06:43 AM, Alexander Graf wrote: > The LS2080 chips have USB available, so we can easily add USB boot > support to the distro boot order. > > Signed-off-by: Alexander Graf > --- > include/configs/ls2080ardb.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h > index 045cee6..79b15f2 100644 > --- a/include/configs/ls2080ardb.h > +++ b/include/configs/ls2080ardb.h > @@ -322,6 +322,7 @@ unsigned long get_board_sys_clk(void); > #include > > #define BOOT_TARGET_DEVICES(func) \ > + func(USB, usb, 0) \ > func(MMC, mmc, 0) \ > func(SCSI, scsi, 0) \ > func(DHCP, dhcp, na) > Reviewed-by: York Sun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] armv8/ls1043a: fixup GIC offset according to SVR and SCFG_GIC400_ALIGN[GIC_ADDR_BIT]
On 10/21/2016 03:28 AM, Wenbin song wrote: > The LS1043A rev1.1 silicon supports two types of GIC offset: 4K alignment > and 64K alignment. The bit SCFG_GIC400_ALIGN[GIC_ADDR_BIT] is used to choose > which offset will be used. > > If GIC_ADDR_BIT bit is set, 4K alignment is used, or else 64K alignment is > used. > 64K alignment is the default setting. > > Overriding the weekly smp_kick_all_cpus, the new impletment is able to detect > GIC offset. > > Signed-off-by: Wenbin Song > Signed-off-by: Mingkai Hu > --- > Changes in v3: > Add description about smp_kick_all_cpus on commit message. > Rename the macros on commit message to match with them used in the > change. > Replace CONFIG_LS1043A with HAS_FEATURE_GIC4K_ALIGN. > Changes in v2: > None > --- > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4 ++ > arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 47 > +++ > arch/arm/include/asm/arch-fsl-layerscape/config.h | 12 +- > 3 files changed, 61 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > index 94ec8d5..c66c497 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > @@ -12,6 +12,7 @@ config ARCH_LS1043A > select SYS_FSL_DDR_VER_50 > select SYS_FSL_ERRATUM_A010315 > select SYS_FSL_ERRATUM_A010539 > + select HAS_FEATURE_GIC4K_ALIGN > > config ARCH_LS1046A > bool > @@ -135,4 +136,7 @@ config SYS_FSL_DDR4 > help > Enable Freescale DDR4 controller. > > +config HAS_FEATURE_GIC4K_ALIGN > + bool > + > endmenu > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S > b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S > index 5d0b7a4..f0da559 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S > +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S > @@ -14,6 +14,40 @@ > #include > #endif > > +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN > + > +/* fixup GIC offset */ > +ENTRY(fix_gic_offset) Nitpick. It would be easier to understand if you have some comments to show the input and output of such function. > + ldr x0, =GICD_BASE > + ldr x1, =GICC_BASE > + ldr x3, =DCFG_CCSR_SVR > + ldr w3, [x3] > + rev w3, w3 > + andsw3, w3, #0xff > + cmp w3, #REV1_0 > + b.eq1f > + ldr x3, =SCFG_GIC400_ALIGN > + ldr w3, [x3] > + rev w3, w3 > + tbnzw3, #GIC_ADDR_BIT, 1f > + ret > +1: > + ldr x0, =GICD_BASE_4K > + ldr x1, =GICC_BASE_4K > + ret > +ENDPROC(fix_gic_offset) > + > +ENTRY(smp_kick_all_cpus) > + /* Kick secondary cpus up by SGI 0 interrupt */ > + mov x29, lr /* Save LR */ > + bl fix_gic_offset > + bl gic_kick_secondary_cpus > + mov lr, x29 /* Restore LR */ > + ret > +ENDPROC(smp_kick_all_cpus) > + > +#endif > + > ENTRY(lowlevel_init) > mov x29, lr /* Save LR */ > > @@ -105,15 +139,23 @@ ENTRY(lowlevel_init) > /* Initialize GIC Secure Bank Status */ > #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) > branch_if_slave x0, 1f > +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN > + bl fix_gic_offset > +#else > ldr x0, =GICD_BASE > +#endif > bl gic_init_secure > 1: > #ifdef CONFIG_GICV3 > ldr x0, =GICR_BASE > bl gic_init_secure_percpu > #elif defined(CONFIG_GICV2) > +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN > + bl fix_gic_offset > +#else > ldr x0, =GICD_BASE > ldr x1, =GICC_BASE > +#endif > bl gic_init_secure_percpu > #endif > #endif > @@ -335,7 +377,12 @@ ENTRY(secondary_boot_func) > #if defined(CONFIG_GICV3) > gic_wait_for_interrupt_m x0 > #elif defined(CONFIG_GICV2) > +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN > + bl fix_gic_offset > + mov x0, x1 > +#else > ldr x0, =GICC_BASE > +#endif > gic_wait_for_interrupt_m x0, w1 > #endif > > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h > b/arch/arm/include/asm/arch-fsl-layerscape/config.h > index 4201e0f..eb6e58d 100644 > --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h > +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h > @@ -172,8 +172,16 @@ > #define SMMU_BASE0x0900 > > /* Generic Interrupt Controller Definitions */ > -#define GICD_BASE0x01401000 > -#define GICC_BASE0x01402000 > +#define GICD_BASE0x0141 > +#define GICC_BASE0x0142 > +#define GICD_BASE_4K0x01401000 > +#define GICC_BASE_4K0x01402000 > + > +#define DCFG_CCSR_SVR0x1ee00a4 > +#define REV1_0 0x10 > +#define REV1_1 0x11 > +#define GIC_ADDR_BIT 31 > +#define SCFG_GIC400_ALIGN0x1570188 > > #define C
Re: [U-Boot] [PATCH] Kconfig: ifc: Moving IFC_BANK_COUNT from Kconfig to config.h
On 10/20/2016 11:37 PM, Prabhakar Kushwaha wrote: > Migration of IFC_BANK_COUNT from Kconfig to config.h avoids adding > SoC name in Kconfig as Dependencies. It will help in having > all SoC related defines in config.h - easy to maintain. > Prabhakar, Why do you want to go back to config.h? I think we are going with Kconfig. Having everything in one config file conflicts with Kconfig. The former has centralized config per SoC, the latter has centralized config per feature. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/8] travis-ci: Add test.py for various qemu platforms
On 10/20/2016 01:40 PM, Tom Rini wrote: - Add a PPA for a more recent qemu (required for PowerPC to work) - Add tests to run test.py for various QEMU platforms. This relies on swarren's uboot-test-hooks repository to provide the abstractions. Overall, the series, Acked-by: Stephen Warren A few comments on this particular patch below: diff --git a/.travis.yml b/.travis.yml addons: apt: +sources: +- sourceline: 'ppa:gns3/qemu' Have you co-ordinated with "qns3" to ensure that PPA is always going to be available, and host binaries for Ubuntuy 16.04 (some PPAs eventually disappear as the owner moves on to other things, or change the set of distro releases they support at the owner's whim). + # Clone uboot-test-hooks + - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git /tmp/uboot-test-hooks Does it make sense to rely on my copy of the repo being around all the time? I have no intention of removing it, but when I created it I'd assumed others would create their own clones for their own infra-structure. I wonder if all the dependencies for U-Boot's testing should be hosted on U-Boot infra-structure? That all said, this should be fine; just something to ponder. + - ln -s travis-ci /tmp/uboot-test-hooks/bin/`hostname` It may be useful to add the following too: - ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname` That way, if we ever need per-board test configuration files, the path to access them will already be available. +- env: +- CROSS_COMPILE="/usr/bin/arm-linux-gnueabihf-" + script: +- ./test/py/test.py --bd vexpress_ca15_tc2 --id qemu --build; + ./test/py/test.py --bd vexpress_ca9x4 --id qemu --build; + ./test/py/test.py --bd integratorcp_cm926ejs --id qemu --build; Does it make sense to make that 3 separate scripts? I assume that would (a) allow the individual status of the 3 test.py invocations to be seen separately (b) might allow/cause travis-ci to run them in parallel; I'm not sure if this Travis config file is a sequential list of commands, or a list of potentially parallel actions. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add driver for Synopsys Ethernet QoS device
On 10/20/2016 01:30 PM, Joe Hershberger wrote: On Thu, Oct 20, 2016 at 2:19 PM, Stephen Warren wrote: On 10/20/2016 12:48 PM, Simon Glass wrote: Hi, On 19 October 2016 at 15:14, Stephen Warren wrote: On 10/19/2016 12:29 PM, Joe Hershberger wrote: Hi Stephen, On Mon, Oct 17, 2016 at 1:32 PM, Stephen Warren wrote: On 10/13/2016 05:46 PM, Joe Hershberger wrote: On Fri, Oct 14, 2016 at 1:35 AM, Stephen Warren wrote: On 10/11/2016 04:48 PM, Joe Hershberger wrote: On Tue, Oct 4, 2016 at 12:13 AM, Stephen Warren wrote: On 09/23/2016 03:49 PM, Joe Hershberger wrote: On Mon, Sep 12, 2016 at 12:48 PM, Stephen Warren wrote: This driver supports the Synopsys Designware Ethernet QoS (Quality of Service) a/k/a eqos IP block, which is a different design than the HW supported by the existing designware.c driver. The IP supports many options for bus type, clocking/reset structure, and feature list. This driver currently supports the specific configuration used in NVIDIA's Tegra186 chip, but should be extensible to other combinations quite easily, as explained in the source. ... +static int eqos_start(struct udevice *dev) ... + /* Update the MAC address */ + val = (plat->enetaddr[5] << 8) | + (plat->enetaddr[4]); + writel(val, eqos->regs + EQOS_MAC_ADDRESS0_HIGH); + val = (plat->enetaddr[3] << 24) | + (plat->enetaddr[2] << 16) | + (plat->enetaddr[1] << 8) | + (plat->enetaddr[0]); + writel(val, eqos->regs + EQOS_MAC_ADDRESS0_LOW); This should be implemented in write_hwaddr() op. ... Anyway, I still don't believe using write_hwaddr() is correct for this HW. It's marked optional in include/net.h; it would be implemented in cases where the MAC address should be passed to subsequent SW in Ethernet controller registers. That's not the case here. The master location for the MAC address is in an unrelated EEPROM that all drivers must read. That sounds more like a NV storage location for a read_rom_hwaddr() op to get a default mac addr that can be overridden with the env. If the EQoS HW module contained the interface to this EEPROM, such that all instances of the HW module always accessed the EEPROM in the same way and the layout of data in the EEPROM was fixed by the HW module, then yes. However, the EqoS HW module doesn't define any mechanism for non-volatile MAC address storage; only the runtime registers. So, we can't implement read_rom_hwaddr() inside the EQoS driver unfortunately. OK. The write_hwaddr is about what the mac uses to filter for limiting packet ingress. One reason to support it as an op is so that when the env var for the mac address is changed, the mac filter in the hw is also updated. I believe that every time the Ethernet device is used, the start() op is called first, followed by packet transfer, followed by the stop() op. If start() always programs the MAC address, the driver will always end up using the value requested by the user. That may be. I still don't understand the reluctance to implement it. I don't want to implement it because it can't work. write_hwaddr() is called before start() is called. At that point, clocks to the EQoS HW are not running and the EQoS HW is in reset, and hence it cannot accept any register accesses; attempting any accesses will hang the bus and CPU. These are the possible solutions: a) Don't implement write_hwaddr() b) Make write_hwaddr() turn on the clock and clear the reset, program the register, then reset the device and assert the reset. Re-asserting reset is required so that setting the MAC address doesn't leave the clock running even when the device isn't in use.This is pointless since the written value will not last beyond the end of the function. c) Make probe() start the clock and clear the reset. Then write_hwaddr() can successfully write the MAC address registers at any time. This would waste power running the clock to the device when it's not in use. Also, Simon Glass continually asks that U-Boot not initialize HW that the user hasn't attempted to use. I believe turning on the clocks in probe() violates this. Not quite...or at least if I did I was mistaken. Of course we should limit init in probe() to what is necessary, but it is the bind() method which must not touch hardware. It is fine to turn clocks on in probe if you want to. Even for a device that the user never ultimately makes use of? If so, this might be a reasonable solution. It feels like U-Boot should turn off the clocks before booting an OS though so that the overall system state isn't any different between the cases where this driver is present and enabled vs not. With the clocks manipulated by start()/stop() we already do this. If the clocks are enabled in probe() instead, this won't be the case. However I am wondering whether we have something wrong in the Ethernet uclass interface. Should we move the MAC setting t
Re: [U-Boot] [PATCH 2/2] net: add driver for Synopsys Ethernet QoS device
On 10/11/2016 05:24 PM, Joe Hershberger wrote: Hi Stephen, On Tue, Sep 27, 2016 at 12:02 AM, Stephen Warren wrote: On 09/23/2016 03:49 PM, Joe Hershberger wrote: Hi Stephen, Thanks for sending this! I have some comments below. Cheers, -Joe On Mon, Sep 12, 2016 at 12:48 PM, Stephen Warren wrote: From: Stephen Warren This driver supports the Synopsys Designware Ethernet QoS (Quality of Service) a/k/a eqos IP block, which is a different design than the HW supported by the existing designware.c driver. The IP supports many options for bus type, clocking/reset structure, and feature list. This driver currently supports the specific configuration used in NVIDIA's Tegra186 chip, but should be extensible to other combinations quite easily, as explained in the source. diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c +/* Core registers */ Why are registers not defined as a struct? That is the common way that is accepted to represent registers in a driver. It is common, but I find using structs has significant disadvantages, which outweigh any advantages, so I strongly prefer not to use them. Disadvantages of structs: * Drivers often have to deal with different but similar HW variants. Similar enough that it makes sense to use the same driver for them, but different enough that certain registers are placed differently in the memory map. With structs, there's little choice but to use ifdefs to pick a particular HW variant and bake that into the driver. This doesn't work well for drivers that must pick the variant at run-time rather than compile-time, e.g. drivers for USB or PCIe devices, or when you wish to build a single SW image that can run on multiple SoCs. Is that really the case here or are you just making a broad statement? Are registers really moving based on IP configuration? That sounds like broken IP / IP generator. I think we should choose the best techniques and use them globally, even if a particular disadvantage of a non-optimal technique isn't relevant to a particular device. Thus, I don't think whether I'm making a broad statement is too relevant. I know there are multiple versions of this HW block in existence. I don't know the details of the register compatibility between the different versions for sure. There are many broken IPs and IP generators in existence, and I believe we need to accomodate that. A common variant on this theme is device with different register layouts due to IP integration issues, such as a UART with byte-wide registers that appear at consecutive byte offsets in some SoCs, but at separate word addresses in other SoCs. Again, this sounds like a generic argument that doesn't apply here. I don't believe the distinction is appropriate. This issue is relevant here since the EQoS block is a generic IP block with many options that may have different SoC- or IP-version-specific differences between SoCs. But simply additive, no? Included features add registers or bitfields. As far as I know, NVIDIA's register additions to this particular version of this particular HW block are purely additions in a well segregated register block. This certainly isn't true for other HW blocks in Tegra though (e.g. consider the Synopsys USB2 controller Tegra uses), and I'm sure the same applies to many other HW blocks in many other SoCs. I wouldn't be at all surprised if some SoC vendor does the same thing to this IP block. There's no way to tell until someone appears to integrate driver support into U-Boot. * The register space for the EQoS driver is quite sparse, and U-Boot uses a subset of the registers effectively making it even more sparse. Defining a struct to describe this will be a frustrating exercise in calculating the right amount of padding to place into the struct to get the correct offsets. Mistakes will be made and it will be annoying. It's also organized into a few blocks. It's preferable to group registers into a struct that represents each block instead of one huge struct. That will certainly help. It also hurts nothing to have registers defined in the struct that apply to configurations that may not be enabled in a given instance... the switching can be done at the spot where the register is accessed. And the accesses don't have to be compile-time options so you can have your built-in and your PCIe variants. So long as there aren't conflicting register definitions, which is certainly not guaranteed in any way, what you say is true. Anyway, I'll rewrite the driver using structs for now in the interests of moving it forward. If this causes issue down the road, whomever is adding the support for additional devices can worry about how to solve any issues that arise then. +static int eqos_start_clks_tegra(struct udevice *dev) Why is this not in a board file and a separate patch? The clocks (and other resources) that this driver operates on are directly related to the EQoS IP block itse
Re: [U-Boot] [PATCH v3 2/3] armv8/fsl-layerscape: fdt: fixup GIC node for LS1043A rev1.0
On 10/21/2016 03:28 AM, Wenbin song wrote:
> The LS1043A rev1.1 silicon supports two types of GIC offset: 4K alignment
> and 64K alignment. 4K alignment is consistent with rev1.0 implement.
>
> The default GIC offset in kernel device tree is using 64K alignment,
> if rev1.0 silicon used, need to fixup the GIC node to use 4K alignment.
>
> Signed-off-by: Wenbin Song
> Signed-off-by: Mingkai Hu
> ---
> Changes for v3:
> Replace CONFIG_LS1043A with HAS_FEATURE_GIC4K_ALIGN.
> ---
> arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 49
> ++
> .../include/asm/arch-fsl-layerscape/immap_lsch2.h | 3 +-
> 2 files changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index 1a8321b..54f8492 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -126,6 +126,52 @@ void fsl_fdt_disable_usb(void *blob)
> }
> }
>
> +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN
> +/* Fixup gic node align with 4K */
> +static void fdt_fixup_gic(void *blob)
> +{
> + int offset, err;
> + u64 reg[8];
> + struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
> + unsigned int val;
> + struct ccsr_scfg __iomem *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
> +
> + val = gur_in32(&gur->svr) & 0xff;
> +
> + if (val == REV1_1) {
> + val = scfg_in32(&scfg->gic_align) & (0x01 << GIC_ADDR_BIT);
> + if (!val)
> + return;
> + }
For rev 1.0 SoC, it runs through here, right? If that what you want?
> +
> + offset = fdt_subnode_offset(blob, 0, "interrupt-controller@140");
> + if (offset < 0) {
> + printf("WARNING: fdt_subnode_offset can't find node %s: %s\n",
> +"interrupt-controller@140", fdt_strerror(offset));
> + return;
> + }
> +
> + reg[0] = cpu_to_fdt64(0x1401000);
> + reg[1] = cpu_to_fdt64(0x1000);
> + reg[2] = cpu_to_fdt64(0x1402000);
> + reg[3] = cpu_to_fdt64(0x2000);
> + reg[4] = cpu_to_fdt64(0x1404000);
> + reg[5] = cpu_to_fdt64(0x2000);
> + reg[6] = cpu_to_fdt64(0x1406000);
> + reg[7] = cpu_to_fdt64(0x2000);
What are these magic numbers?
> +
> + err = fdt_setprop(blob, offset, "reg", reg, sizeof(reg));
> + if (err < 0) {
> + printf("WARNING: fdt_setprop can't set %s from node %s: %s\n",
> +"reg", "interrupt-controller@140",
> +fdt_strerror(err));
> + return;
> + }
> +
> + return;
> +}
> +#endif
> +
> void ft_cpu_setup(void *blob, bd_t *bd)
> {
> #ifdef CONFIG_FSL_LSCH2
> @@ -170,4 +216,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> #endif
> fsl_fdt_disable_usb(blob);
>
> +#ifdef CONFIG_HAS_FEATURE_GIC4K_ALIGN
> + fdt_fixup_gic(blob);
> +#endif
> }
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> index d88543d..1dfef53 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> @@ -359,7 +359,8 @@ struct ccsr_scfg {
> u32 qspi_cfg;
> u8 res_160[0x180-0x160];
> u32 dmamcr;
> - u8 res_184[0x18c-0x184];
> + u8 res_184[0x188-0x184];
> + u32 gic_align;
> u32 debug_icid;
> u8 res_190[0x1a4-0x190];
> u32 snpcnfgcr;
>
Would it be reasonable to squash this patch with previous one in this
set? They both deal with the same thing. If you run git bisect between
this two, you don't get correct gic offset in device tree, do you?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function
On 10/20/2016 01:34 PM, Stephen Warren wrote: > On 10/19/2016 11:06 PM, york sun wrote: >> On 10/19/2016 06:01 PM, Stephen Warren wrote: >>> On 10/19/2016 04:32 PM, york sun wrote: On 10/19/2016 12:18 PM, Stephen Warren wrote: > On 10/19/2016 09:25 AM, Stephen Warren wrote: >> On 10/14/2016 02:17 PM, York Sun wrote: >>> Current code turns off d-cache first, then flush all levels of cache. >>> This results data loss. As soon as d-cache is off, the dirty cache >>> is discarded according to the test on LS2080A. This issue was not >>> seen as long as external L3 cache was flushed to push the data to >>> main memory. However, external L3 cache is not guaranteed to have >>> the data. To fix this, flush the d-cache by way/set first to make >>> sure cache is clean before turning it off. >> >>> diff --git a/arch/arm/cpu/armv8/cache_v8.c >>> b/arch/arm/cpu/armv8/cache_v8.c >> >>> @@ -478,9 +478,9 @@ void dcache_disable(void) >> >>> +flush_dcache_all(); >>> set_sctlr(sctlr & ~(CR_C|CR_M)); >>> >>> -flush_dcache_all(); >>> __asm_invalidate_tlb_all(); >> >> I talked to Mark Rutland at ARM, and I believe the current code is >> correct. Here's my interpretation of what he said: >> >> The dcache must be disabled first. This prevents allocation of new >> entries in the cache during the flush operation, which prevents the race >> conditions that were mentioned in the other thread. >> >> Then, the flush operation must be invoked. Since the cache is now >> disabled, this can fully flush the cache without worrying about racing >> with things being added to the cache. >> >> This all implies that the implementation of dcache_disable(), >> set_sctlr(), flush_dcache_all(), and any code they call must not access >> data in DRAM at all; since because the dcache is off, any DRAM access >> will[1] read potentially stale data from DRAM, rather than any dirty >> data that might be in the cache. >> >> [1] I'm not sure if that's "will" or "may", i.e. whether this is >> architecturally guaranteed in ARMv8 or is implementation defined. At >> least the Cortex A72 TRM says "will" for that CPU; not sure about others. >> >> Perhaps the most obvious upshot of this is that the stack can't be used. >> This implies to me that we need to recode all those functions purely in >> assembly, or just possibly play some tricks to 100% force gcc not to >> touch memory anywhere inside dcache_disable() or the functions it calls. >> We're just getting lucky here right now since everything happens to be >> inlined, but I don't think we're doing anything to 100% guarantee this. >> >> What worries me here is that at least on Tegra, a "flush the entire >> dcache" operation requires an SMC call to the secure monitor. That will >> certainly access DRAM when the secure monitor runs, but perhaps this >> doesn't matter since that's at a different exception level, and we know >> the secure monitor accesses DRAM regions that are separate from U-Boot's >> DRAM? I suspect life isn't that convenient. I'm wondering if this all >> implies that, like patch 2 in this series, we need to get 100% away from >> flush-by-set/way, even with SoC-specific hooks to make that work >> reliably, and just flush everything by VA, which IIRC is architecturally >> guaranteed to work without SoC-specific logic. That way, we can >> encapsulate everything into an assembly function without worrying about >> calling SMCs or SoC-specific hook functions without using DRAM. Of >> course, how that assembly function knows which VAs to flush without >> decoding the page tables or other data structure is another matter:-( > > Re: the last paragraph there: > > After reading the ARMv8 ARM, I see that EL1, EL2, and EL3 all have > separate cache enable bits in SCTLR_ELx. I believe U-Boot only needs to > flush/... its own RAM out of the dcache, since that's all that's > relevant at the EL U-Boot is running at, and doesn't care about anything > EL3 might have mapped cached. So, it's safe to invoke SMCs from the > cache flush code in U-Boot even if the EL3 code touches its own DRAM. > There might be a corner case where this isn't true if EL3 has some > EL1/EL2-owned RAM mapped, but I don't expect that to be the case here. > > Re: my other series to add more cache hooks: I'll re-implement the Tegra > hook in assembly so it's guaranteed not to touch RAM, retest, and > resumbit. > > If it turns out that dcache_disable() ever starts touching DRAM at the > wrong time, we can deal with that then; it doesn't now at least. > Stephen, I think one of our difference is whether the data is returned correctly with dirty dcache being disabled. With current
Re: [U-Boot] [PATCH] armv8/ls1043a: Add the OCRAM initialization
On 10/16/2016 10:35 PM, Prabhakar Kushwaha wrote: > Hi Mingkai, > >> -Original Message- >> From: Pratiyush Srivastava [mailto:pratiyush.srivast...@nxp.com] >> Sent: Wednesday, October 12, 2016 5:46 PM >> To: u-boot@lists.denx.de >> Cc: york sun ; Prabhakar Kushwaha >> ; Pratiyush Srivastava >> ; Hou Zhiqiang >> Subject: [PATCH] armv8/ls1043a: Add the OCRAM initialization >> >> Clear the content to zero and the ECC error bit of OCRAM1/2. >> >> The OCRAM must be initialized to ZERO by the unit of 8-Byte before >> accessing it, or else it will generate ECC error. And the IBR has >> accessed the OCRAM before this initialization, so the ECC error >> status bit should to be cleared. >> >> Signed-off-by: Pratiyush Srivastava >> Signed-off-by: Hou Zhiqiang >> Signed-off-by: Prabhakar Kushwaha >> --- > > This requirement is for both ls1043 and ls1088a. was this patch taken care > during ls1043a upstreaming > If not, how it is being taken care for ls1043a. Same approach can be used > for ls1088a > I wonder why we don't see ECC errors before this patch. We have LS1043A boots on NAND, SD. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/2] net: add driver for Synopsys Ethernet QoS device
From: Stephen Warren
This driver supports the Synopsys Designware Ethernet QoS (Quality of
Service) a/k/a eqos IP block, which is a different design than the HW
supported by the existing designware.c driver. The IP supports many
options for bus type, clocking/reset structure, and feature list. This
driver currently supports the specific configuration used in NVIDIA's
Tegra186 chip, but should be extensible to other combinations quite
easily, as explained in the source.
Signed-off-by: Stephen Warren
Reviewed-by: Simon Glass # V1
---
v3:
* Use structs to describe register layout.
* Implement write_hwaddr(). This requires tracking whether registers are
accessible and knowing for which configurations this matters.
* Add full description of Tegra186 HW block configuration.
* s/tegra/tegra186/ in symbol names.
* Use a single struct type for all descriptors, with field names that
match the HW documentation.
v2:
* Add note about x86 IO coherency.
* Use wait_bit() where possible.
* Use a struct definition of the RX and TX descriptors.
---
drivers/net/Kconfig | 11 +
drivers/net/Makefile |1 +
drivers/net/dwc_eth_qos.c | 1552 +
3 files changed, 1564 insertions(+)
create mode 100644 drivers/net/dwc_eth_qos.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 302c005aa132..d18295a28655 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -64,6 +64,17 @@ config ALTERA_TSE
Please find details on the "Triple-Speed Ethernet MegaCore Function
Resource Center" of Altera.
+config DWC_ETH_QOS
+ bool "Synopsys DWC Ethernet QOS device support"
+ depends on DM_ETH
+ select PHYLIB
+ help
+ This driver supports the Synopsys Designware Ethernet QOS (Quality
+ Of Service) IP block. The IP supports many options for bus type,
+ clocking/reset structure, and feature list. This driver currently
+ supports the specific configuration used in NVIDIA's Tegra186 chip,
+ but should be extensible to other combinations quite easily.
+
config E1000
bool "Intel PRO/1000 Gigabit Ethernet support"
help
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index a4485266d457..9a7bfc6d5b05 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -76,3 +76,4 @@ obj-$(CONFIG_FSL_MC_ENET) += ldpaa_eth/
obj-$(CONFIG_FSL_MEMAC) += fm/memac_phy.o
obj-$(CONFIG_VSC9953) += vsc9953.o
obj-$(CONFIG_PIC32_ETH) += pic32_mdio.o pic32_eth.o
+obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
new file mode 100644
index ..81eeba2e051a
--- /dev/null
+++ b/drivers/net/dwc_eth_qos.c
@@ -0,0 +1,1552 @@
+/*
+ * Copyright (c) 2016, NVIDIA CORPORATION.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Portions based on U-Boot's rtl8169.c.
+ */
+
+/*
+ * This driver supports the Synopsys Designware Ethernet QOS (Quality Of
+ * Service) IP block. The IP supports multiple options for bus type, clocking/
+ * reset structure, and feature list.
+ *
+ * The driver is written such that generic core logic is kept separate from
+ * configuration-specific logic. Code that interacts with configuration-
+ * specific resources is split out into separate functions to avoid polluting
+ * common code. If/when this driver is enhanced to support multiple
+ * configurations, the core code should be adapted to call all configuration-
+ * specific functions through function pointers, with the definition of those
+ * function pointers being supplied by struct udevice_id eqos_ids[]'s .data
+ * field.
+ *
+ * The following configurations are currently supported:
+ * tegra186:
+ *NVIDIA's Tegra186 chip. This configuration uses an AXI master/DMA bus, an
+ *AHB slave/register bus, contains the DMA, MTL, and MAC sub-blocks, and
+ *supports a single RGMII PHY. This configuration also has SW control over
+ *all clock and reset signals to the HW block.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Core registers */
+
+#define EQOS_MAC_REGS_BASE 0x000
+struct eqos_mac_regs {
+ uint32_t configuration; /* 0x000 */
+ uint32_t unused_004[(0x070 - 0x004) / 4]; /* 0x004 */
+ uint32_t q0_tx_flow_ctrl; /* 0x070 */
+ uint32_t unused_070[(0x090 - 0x074) / 4]; /* 0x074 */
+ uint32_t rx_flow_ctrl; /* 0x090 */
+ uint32_t unused_094;/* 0x094 */
+ uint32_t txq_prty_map0; /* 0x098 */
+ uint32_t unused_09c;/* 0x09c */
+ uint32_t rxq_ctrl0; /* 0x0a0 */
+ uint32_t unused_0a4;/* 0x0a4 */
+ uint32_t rxq_ctrl2; /* 0x0a8 */
[U-Boot] [PATCH V3 1/2] dt: net: add DWC EQoS binding
From: Stephen Warren The Synopsys DWC EQoS is a configurable Ethernet MAC/DMA IP block which supports multiple options for bus type, clocking and reset structure, and feature list. This patch imports the binding from the Linux kernel, including my V3 patch to extend the binding to cover the Tegra186, which is applied for next-20160912. So far, my changes have been acked by Lars Persson, the original author of the binding. Signed-off-by: Stephen Warren Reviewed-by: Simon Glass --- v2: No change. --- .../net/snps,dwc-qos-ethernet.txt | 166 + 1 file changed, 166 insertions(+) create mode 100644 doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt diff --git a/doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt b/doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt new file mode 100644 index ..d93f71ce8346 --- /dev/null +++ b/doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt @@ -0,0 +1,166 @@ +* Synopsys DWC Ethernet QoS IP version 4.10 driver (GMAC) + +This binding supports the Synopsys Designware Ethernet QoS (Quality Of Service) +IP block. The IP supports multiple options for bus type, clocking and reset +structure, and feature list. Consequently, a number of properties and list +entries in properties are marked as optional, or only required in specific HW +configurations. + +Required properties: +- compatible: One of: + - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10" +Represents the IP core when integrated into the Axis ARTPEC-6 SoC. + - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10" +Represents the IP core when integrated into the NVIDIA Tegra186 SoC. + - "snps,dwc-qos-ethernet-4.10" +This combination is deprecated. It should be treated as equivalent to +"axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10". It is supported to be +compatible with earlier revisions of this binding. +- reg: Address and length of the register set for the device +- clocks: Phandle and clock specifiers for each entry in clock-names, in the + same order. See ../clock/clock-bindings.txt. +- clock-names: May contain any/all of the following depending on the IP + configuration, in any order: + - "tx" +The EQOS transmit path clock. The HW signal name is clk_tx_i. +In some configurations (e.g. GMII/RGMII), this clock also drives the PHY TX +path. In other configurations, other clocks (such as tx_125, rmii) may +drive the PHY TX path. + - "rx" +The EQOS receive path clock. The HW signal name is clk_rx_i. +In some configurations (e.g. GMII/RGMII), this clock is derived from the +PHY's RX clock output. In other configurations, other clocks (such as +rx_125, rmii) may drive the EQOS RX path. +In cases where the PHY clock is directly fed into the EQOS receive path +without intervening logic, the DT need not represent this clock, since it +is assumed to be fully under the control of the PHY device/driver. In +cases where SoC integration adds additional logic to this path, such as a +SW-controlled clock gate, this clock should be represented in DT. + - "slave_bus" +The CPU/slave-bus (CSR) interface clock. This applies to any bus type; +APB, AHB, AXI, etc. The HW signal name is hclk_i (AHB) or clk_csr_i (other +buses). + - "master_bus" +The master bus interface clock. Only required in configurations that use a +separate clock for the master and slave bus interfaces. The HW signal name +is hclk_i (AHB) or aclk_i (AXI). + - "ptp_ref" +The PTP reference clock. The HW signal name is clk_ptp_ref_i. + - "phy_ref_clk" +This clock is deprecated and should not be used by new compatible values. +It is equivalent to "tx". + - "apb_pclk" +This clock is deprecated and should not be used by new compatible values. +It is equivalent to "slave_bus". + + Note: Support for additional IP configurations may require adding the + following clocks to this list in the future: clk_rx_125_i, clk_tx_125_i, + clk_pmarx_0_i, clk_pmarx1_i, clk_rmii_i, clk_revmii_rx_i, clk_revmii_tx_i. + Configurations exist where multiple similar clocks are used at once, e.g. all + of clk_rx_125_i, clk_pmarx_0_i, clk_pmarx1_i. For this reason it is best to + extend the binding with a separate clock-names entry for each of those RX + clocks, rather than repurposing the existing "rx" clock-names entry as a + generic/logical clock in a similar fashion to "master_bus" and "slave_bus". + This will allow easy support for configurations that support multiple PHY + interfaces using a mux, and hence need to have explicit control over + specific RX clocks. + + The following compatible values require the following set of clocks: + - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10": +- "slave_bus" +- "master_bus" +- "rx" +- "tx" +- "ptp_ref" + - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10": +- "slave_bus" +- "master_bus" +- "tx" +- "ptp_re
[U-Boot] [PATCH] net: phy: micrel: center FLP burst timing at 16ms
Like [1], reset the FLP burst timing for the KSZ9031 to the 16ms
specified by the IEEE802.3 standard from the chip's default of 8ms.
For more details, see the "Auto-Negotiation Timing" section of the
KSZ9031RNX datasheet.
[1] https://patchwork.kernel.org/patch/6558371/
Change-Id: I122ee33300db3a617cc527070b4e97b88563d7a7
Signed-off-by: Ash Charles
---
drivers/net/phy/micrel.c | 23 +++
include/micrel.h | 3 +++
2 files changed, 26 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 6b313a9..28a1401 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -415,11 +415,31 @@ static int ksz9031_of_config(struct phy_device *phydev)
return 0;
}
+
+static int ksz9031_center_flp_timing(struct phy_device *phydev)
+{
+ struct phy_driver *drv = phydev->drv;
+ int ret = 0;
+
+ if (!drv || !drv->writeext)
+ return -EOPNOTSUPP;
+
+ ret = drv->writeext(phydev, 0, 0, MII_KSZ9031_FLP_BURST_TX_LO, 0x1A80);
+ if (ret)
+ return ret;
+
+ ret = drv->writeext(phydev, 0, 0, MII_KSZ9031_FLP_BURST_TX_HI, 0x6);
+ return ret;
+}
#else
static int ksz9031_of_config(struct phy_device *phydev)
{
return 0;
}
+static int ksz9031_center_flp_timing(struct phy_device *phydev)
+{
+ return 0;
+}
#endif
/* Accessors to extended registers*/
@@ -472,6 +492,9 @@ static int ksz9031_config(struct phy_device *phydev)
ret = ksz9031_of_config(phydev);
if (ret)
return ret;
+ ret = ksz9031_center_flp_timing(phydev);
+ if (ret)
+ return ret;
return genphy_config(phydev);
}
diff --git a/include/micrel.h b/include/micrel.h
index e6d145d..3e6b531 100644
--- a/include/micrel.h
+++ b/include/micrel.h
@@ -20,6 +20,9 @@
#define MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW 0x6
#define MII_KSZ9031_EXT_RGMII_CLOCK_SKEW 0x8
+#define MII_KSZ9031_FLP_BURST_TX_LO0x3
+#define MII_KSZ9031_FLP_BURST_TX_HI0x4
+
/* Registers */
#define MMD_ACCESS_CONTROL 0xd
#define MMD_ACCESS_REG_DATA0xe
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] net: phy: micrel: center FLP burst timing at 16ms
Like [1], reset the FLP burst timing for the KSZ9031 to the 16ms
specified by the IEEE802.3 standard from the chip's default of 8ms.
For more details, see the "Auto-Negotiation Timing" section of the
KSZ9031RNX datasheet.
[1] https://patchwork.kernel.org/patch/6558371/
Signed-off-by: Ash Charles
---
drivers/net/phy/micrel.c | 23 +++
include/micrel.h | 3 +++
2 files changed, 26 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 6b313a9..28a1401 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -415,11 +415,31 @@ static int ksz9031_of_config(struct phy_device *phydev)
return 0;
}
+
+static int ksz9031_center_flp_timing(struct phy_device *phydev)
+{
+ struct phy_driver *drv = phydev->drv;
+ int ret = 0;
+
+ if (!drv || !drv->writeext)
+ return -EOPNOTSUPP;
+
+ ret = drv->writeext(phydev, 0, 0, MII_KSZ9031_FLP_BURST_TX_LO, 0x1A80);
+ if (ret)
+ return ret;
+
+ ret = drv->writeext(phydev, 0, 0, MII_KSZ9031_FLP_BURST_TX_HI, 0x6);
+ return ret;
+}
#else
static int ksz9031_of_config(struct phy_device *phydev)
{
return 0;
}
+static int ksz9031_center_flp_timing(struct phy_device *phydev)
+{
+ return 0;
+}
#endif
/* Accessors to extended registers*/
@@ -472,6 +492,9 @@ static int ksz9031_config(struct phy_device *phydev)
ret = ksz9031_of_config(phydev);
if (ret)
return ret;
+ ret = ksz9031_center_flp_timing(phydev);
+ if (ret)
+ return ret;
return genphy_config(phydev);
}
diff --git a/include/micrel.h b/include/micrel.h
index e6d145d..3e6b531 100644
--- a/include/micrel.h
+++ b/include/micrel.h
@@ -20,6 +20,9 @@
#define MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW 0x6
#define MII_KSZ9031_EXT_RGMII_CLOCK_SKEW 0x8
+#define MII_KSZ9031_FLP_BURST_TX_LO0x3
+#define MII_KSZ9031_FLP_BURST_TX_HI0x4
+
/* Registers */
#define MMD_ACCESS_CONTROL 0xd
#define MMD_ACCESS_REG_DATA0xe
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t2080: DDR controller erratum A-009942
On 10/18/2016 07:48 PM, Hamish Martin wrote:
> This erratum is already implemented for other ARM based QorIQ
> platforms with the Gen4 DDR controller. Port the fix to the Gen3
> controller and enable it for T2080 and T2081.
>
> Reviewed-by: Chris Packham
> Signed-off-by: Hamish Martin
> Cc: York Sun
> ---
> arch/powerpc/cpu/mpc85xx/cmd_errata.c | 3 +++
> arch/powerpc/include/asm/config_mpc85xx.h | 1 +
> drivers/ddr/fsl/mpc85xx_ddr_gen3.c| 17 +
> 3 files changed, 21 insertions(+)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> index 3b06ae42e4bc..94b6dcca96b6 100644
> --- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> +++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> @@ -329,6 +329,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> #ifdef CONFIG_SYS_FSL_ERRATUM_A009663
> puts("Work-around for Erratum A009663 enabled\n");
> #endif
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A009942
> + puts("Work-around for Erratum A009942 enabled\n");
> +#endif
>
> return 0;
> }
> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
> b/arch/powerpc/include/asm/config_mpc85xx.h
> index 6d845e859f4a..9e1cd80e16e0 100644
> --- a/arch/powerpc/include/asm/config_mpc85xx.h
> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
> @@ -910,6 +910,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
> #define CONFIG_SYS_FSL_ERRATUM_A006593
> #define CONFIG_SYS_FSL_ERRATUM_A007186
> #define CONFIG_SYS_FSL_ERRATUM_A006379
> +#define CONFIG_SYS_FSL_ERRATUM_A009942
> #define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
> #define CONFIG_SYS_FSL_SFP_VER_3_0
>
Thanks for fixing it. Please also enable this workaround for T1024,
T2080, T1040, B4420, B4860, T4240 (and change the subject accordingly).
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t2080: CPU erratum A-007907
On 10/18/2016 09:28 PM, Darwin Dingel wrote:
> Core hang occurs when using L1 stashes. Workaround is to disable L1
> stashes so software uses L2 cache for stashes instead.
>
This patch is missing the signed-off-by signature from the author.
> Reviewed-by: Chris Packham
> Cc: York Sun
> ---
> arch/powerpc/cpu/mpc85xx/cmd_errata.c | 4 +++-
> arch/powerpc/cpu/mpc85xx/cpu_init.c | 7 +++
> arch/powerpc/include/asm/config_mpc85xx.h | 1 +
> arch/powerpc/include/asm/processor.h | 1 +
> 4 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> index 3b06ae4..197eb2f 100644
> --- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> +++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
> @@ -329,7 +329,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> #ifdef CONFIG_SYS_FSL_ERRATUM_A009663
> puts("Work-around for Erratum A009663 enabled\n");
> #endif
> -
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A007907
> + puts("Work-around for Erratum A007907 enabled\n");
> +#endif
> return 0;
> }
>
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> index 53b3729..0e744f0 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> @@ -775,6 +775,13 @@ int cpu_init_r(void)
> sync();
> }
> #endif
> +
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A007907
> + flush_dcache();
> + mtspr(L1CSR2, (mfspr(L1CSR2) & ~L1CSR2_DCSTASHID));
Have you hit this erratum? Does this workaround seem to be effective?
> + sync();
> +#endif
> +
> #ifdef CONFIG_SYS_FSL_ERRATUM_A005812
> /*
>* A-005812 workaround sets bit 32 of SPR 976 for SoCs running
> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
> b/arch/powerpc/include/asm/config_mpc85xx.h
> index 6d845e8..3d0ce2e 100644
> --- a/arch/powerpc/include/asm/config_mpc85xx.h
> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
> @@ -910,6 +910,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
> #define CONFIG_SYS_FSL_ERRATUM_A006593
> #define CONFIG_SYS_FSL_ERRATUM_A007186
> #define CONFIG_SYS_FSL_ERRATUM_A006379
> +#define CONFIG_SYS_FSL_ERRATUM_A007907
Can you enable this erratum workaround to T4240 and B4860 as well?
York
> #define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
> #define CONFIG_SYS_FSL_SFP_VER_3_0
>
> diff --git a/arch/powerpc/include/asm/processor.h
> b/arch/powerpc/include/asm/processor.h
> index fdfca90..6f9b297 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -501,6 +501,7 @@
> #define L1CSR1_ICE 0x0001 /* Instruction Cache Enable */
> #define SPRN_L1CSR2 0x25e /* L1 Data Cache Control and Status Register 2
> */
> #define L1CSR2_DCWS0x4000 /* Data Cache Write
> Shadow */
> +#define L1CSR2_DCSTASHID 0x03ff /* Data Cache Stash ID */
> #define SPRN_L2CSR0 0x3f9 /* L2 Data Cache Control and Status Register 0
> */
> #define L2CSR0_L2E 0x8000 /* L2 Cache Enable */
> #define L2CSR0_L2PE0x4000 /* L2 Cache Parity/ECC
> Enable */
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] kwbimage use after free
I didn't see a dedicated list to send bug reports so sending it here: There is a use after free in kwbimage, found by building u-boot with the use after free detection enabled with OpenBSD's malloc. When building the clearfog target: MKIMAGE u-boot-spl.kwb Segmentation fault (core dumped) kwbimage_generate -> image_version_file (alloc and free image_cfg global) kwbimage_generate -> image_headersz_v1 -> image_count_options (image_cfg used) It isn't clear to me if image_version_file should be inlined or another approach taken, but as it stands it is clearly wrong. The result of image_version_file is also never checked for -1 which multiple paths in the function return. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
