Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 4月, 2018 5 次提交
    • B
      imx: mx7: Add comment to describe OTP TESTER registers · 1ab1ffde
      由 Bryan O'Donoghue 提交于 
      The tester registers provide a unique chip-level identifier which
get_board_serial() returns in a "struct tag_serialnr".

This patch documents the properties of the registers; in summary.

31:0 OCOTP_TESTER0 (most significant)
- FSL-wide unique, encoded LOT ID STD II/SJC CHALLENGE/ Unique ID

OCOTP_TESTER1 (least significant)
31:24
- The X-coordinate of the die location on the wafer/SJC CHALLENGE/ Unique
  ID
23:16
- The Y-coordinate of the die location on the wafer/SJC CHALLENGE/ Unique
  ID
15:11
- The wafer number of the wafer on which the device was fabricated/SJC
  CHALLENGE/ Unique ID
10:0
- FSL-wide unique, encoded LOT ID STD II/SJC CHALLENGE/ Unique ID

The 64 bits of data generate a unique serial number per-chip.
Signed-off-by: NBryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
      1ab1ffde
    • B
      imx: mx7: Fix CONFIG_SERIAL_TAG compilation · ca831822
      由 Bryan O'Donoghue 提交于 
      Currently when we define CONFIG_SERIAL_TAG we will barf with a failure to
define "struct tag_serialnr".

This structure is defined in <asm/setup.h>, this patch includes
<asm/setup.h> to fix.
Signed-off-by: NBryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
      ca831822
    • M
      ARM: mx6: ddr: Add write leveling correction code · 14eeb683
      由 Marek Vasut 提交于 
      When the DDR calibration is enabled, a situation may happen that it
will fail on a few select boards out of a whole production lot. In
particular, after the first write leveling stage, the MPWLDECTRLx
registers will contain a value 0x1nn , for nn usually being 0x7f or
slightly lower.

What this means is that the HW write leveling detected that the DQS
rising edge on one or more bundles arrives slightly _after_ CLK and
therefore when the DDR DRAM samples CLK on the DQS rising edge, the
CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18).

The HW write leveling then ends up adding almost an entire cycle (thus
the 0x17f) to the DQS delay, which indeed aligns it, but also triggers
subsequent calibration failure in DQS gating due to this massive offset.

There are two observations here:
- If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the
  DQS gating passes, the entire calibration passes as well and the
  DRAM is perfectly stable even under massive load.
- When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so
  in MPWLDECTRx register is not there, but it is replaced by 0x0 as one
  would expect.

Someone from NXP finally explains why, quoting [1]:

    "
    Having said all that, the DDR Stress Test does something that we
    do not advertise to the users. The Stress Test iself looks at the
    values of the MPWLDECTRL0/1 fields before reporting results, and
    if it sees any filed with a value greater than 200/256 delay
    (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR
    Stress test will reset the Write Leveling delay for this lane
    to 0x000 and not report it in the log.

    The reason that the DDR Stress test does this is because a delay
    of more than 78% a clock cycle means that the DQS edge is arriving
    within the JEDEC tolerence of 25% of the clock edge. In most cases,
    DQS is arriving < 5% tCK of the SDCLK edge in the early case, and
    it does not make sense to delay the DQS strobe almost a full clock
    cycle and add extra latency to each Write burst just to make the
    two edges align exactly. In this case, we are guilty of making a
    decision for the customer without telling them we are doing it so
    that we don't have to provide the above explanation to every customer.
    They don't need to know it.
    "

This patch adds the correction described above, that is if the MPWLDECTRx
value is over 0x148, the value is corrected back to 0x0.

[1] https://community.nxp.com/thread/456246Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: NEric Nelson <eric@nelint.com>
Reviewed-by: NStefano Babic <sbabic@denx.de>
      14eeb683
    • R
      tools/imximage: use 0x prefix in HAB Blocks line · 8519c9c9
      由 Rasmus Villemoes 提交于 
      The u-boot-ivt.img.log file contains 0x prefixes in the HAB Blocks line,
while the SPL.log does not. For consistency, and to make it easier to
extract and put into a .csf file for use with NXP's code signing tool,
add 0x prefixes here.
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Tested-by: NBreno Lima <breno.lima@nxp.com>
      8519c9c9
    • R
      Makefile: always preserve output for images that can contain HAB Blocks · 06587617
      由 Rasmus Villemoes 提交于 
      The current makefile logic disables creation of the
SPL.log/u-boot-ivt.img.log etc. files when V=1 is given on the command
line, the rationale presumably being that the user wants and gets the
information on the console.

However, from general principles, I don't think a higher V= level
should affect which build artifacts get generated (and certainly
shouldn't produce fewer). Concretely, it's also a problem that when
doing a V=1 build in a terminal, the relevant HAB blocks lines easily
drown in all the other V=1 output.

Moreover, build systems such as Yocto by default pass V=1, so in that
case the information gets hidden away in the do_compile log file, making
it nigh impossible to create a recipe for creating signed U-boot images
- I don't want to disable V=1, because having verbose output in the log
file is valuable when things go wrong, but OTOH trying to go digging in
the do_compile log file (and getting exactly the right lines) is not
pleasant to even think about.

So change the logic so that for V=0, the mkimage output is redirected
to MKIMAGEOUTPUT (which is also the current behaviour), while for any
other value of V, we _additionally_ write the information to make's
stdout, whatever that might be.
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
Tested-by: NBreno Lima <breno.lima@nxp.com>
      06587617
  3. 29 3月, 2018 11 次提交
  5. 11 3月, 2018 6 次提交
  7. 10 3月, 2018 9 次提交
  9. 09 3月, 2018 7 次提交
    • T
      ARM: Drop unreferenced CONFIG_* defines named after boards · b996b7d4
      由 Tuomas Tynkkynen 提交于 
      The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_AT91SAM9263EK
CONFIG_AT91SAM9RLEK
CONFIG_BARIX_IPAM390
CONFIG_BOARD_H2200
CONFIG_EP9301
CONFIG_KZM_A9_GT
CONFIG_PICOSAM
CONFIG_PLATINUM_PICON
CONFIG_PLATINUM_TITANIUM
CONFIG_PM9261
CONFIG_PM9263
CONFIG_PM9G45
CONFIG_SIEMENS_DRACO
CONFIG_SIEMENS_PXM2
CONFIG_SIEMENS_RUT
CONFIG_SMDKC100
CONFIG_SMDKV310
CONFIG_STM32F4DISCOVERY

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.
Signed-off-by: NTuomas Tynkkynen <tuomas@tuxera.com>
      b996b7d4
    • T
      ARM: Drop unreferenced CONFIG_* defines named after SoCs · 17796171
      由 Tuomas Tynkkynen 提交于 
      The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_ARM926EJS
CONFIG_CPUAT91
CONFIG_EXYNOS5800
CONFIG_SYS_CORTEX_R4

Most of them are config symbols named after the respective SoCs which
seems to have been a standard practice at some point.
Signed-off-by: NTuomas Tynkkynen <tuomas@tuxera.com>
      17796171
    • T
      MIPS: Drop unreferenced CONFIG_* defines · c604f47a
      由 Tuomas Tynkkynen 提交于 
      The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_DBAU1X00
CONFIG_PB1X00

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.
Signed-off-by: NTuomas Tynkkynen <tuomas@tuxera.com>
      c604f47a
    • M
      treewide: Fix gdsys mail addresses · d38826a3
      由 Mario Six 提交于 
      The @gdsys.cc addresses are supposed to be used for mailing lists.
Switch all occurrences of @gdsys.de mail addresses to their @gdsys.cc
equivalent.

Also, Dirk's address was wrong in one place; fix that as well.
Signed-off-by: NMario Six <six@gdsys.cc>
      d38826a3
    • T
      ARM: qemu-arm: Increase CONFIG_SYS_CBSIZE · b771f0b1
      由 Tuomas Tynkkynen 提交于 
      CONFIG_SYS_CBSIZE determines the maximum length of the kernel command
line, and the default value of 256 is too small for booting some Linux
images in the wild.
Signed-off-by: NTuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
      b771f0b1
    • Y
      imx: syscounter: make sure asm is volatile · 314d9f7e
      由 Yasushi SHOJI 提交于 
      Without the volatile attribute, compilers are entitled to optimize out
the same asm().  In the case of __udelay() in syscounter.c, it calls
`get_ticks()` twice, one for the starting time and the second in the
loop to check the current time.  When compilers inline `get_ticks()`
they see the same `mrrc` instructions and optimize out the second one.
This leads to infinite loop since we don't get updated value from the
system counter.

Here is a portion of the disassembly of __udelay:

  88:	428b      	cmp	r3, r1
  8a:	f8ce 20a4 	str.w	r2, [lr, #164]	; 0xa4
  8e:	bf08      	it	eq
  90:	4282      	cmpeq	r2, r0
  92:	f8ce 30a0 	str.w	r3, [lr, #160]	; 0xa0
  96:	d3f7      	bcc.n	88 <__udelay+0x88>
  98:	e8bd 8cf0 	ldmia.w	sp!, {r4, r5, r6, r7, sl, fp, pc}

Note that final jump / loop at 96 to 88, we don't have any `mrrc`.

With a volatile attribute, the above changes to this:

  8a:	ec53 2f0e 	mrrc	15, 0, r2, r3, cr14
  8e:	42ab      	cmp	r3, r5
  90:	f8c1 20a4 	str.w	r2, [r1, #164]	; 0xa4
  94:	bf08      	it	eq
  96:	42a2      	cmpeq	r2, r4
  98:	f8c1 30a0 	str.w	r3, [r1, #160]	; 0xa0
  9c:	d3f5      	bcc.n	8a <__udelay+0x8a>
  9e:	e8bd 8cf0 	ldmia.w	sp!, {r4, r5, r6, r7, sl, fp, pc}
  a2:	bf00      	nop

I'm advised[1] to put volatile on all asm(), so this commit also adds it
to the asm() in timer_init().

[1]: https://lists.denx.de/pipermail/u-boot/2018-March/322062.htmlSigned-off-by: NYasushi SHOJI <yasushi.shoji@gmail.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
      314d9f7e
    • F
      imximage: Remove failure when no IVT offset is found · b5b0e4e3
      由 Fabio Estevam 提交于 
      Sometimes imximage throws the following error:

  CFGS    board/freescale/vf610twr/imximage.cfg.cfgtmp
  CFGS    board/freescale/vf610twr/imximage.cfg.cfgtmp
  MKIMAGE u-boot-dtb.imx
Error: No BOOT_FROM tag in board/freescale/vf610twr/imximage.cfg.cfgtmp
arch/arm/mach-imx/Makefile:100: recipe for target 'u-boot-dtb.imx' failed

Later on, when running mkimage for the u-boot.imx it will succeed in
finding the IVT offset.

Looks like some race condition happening during parallel build when
processing mkimage for u-boot-dtb.imx and u-boot.imx.

A proper fix still needs to be implemented, but as a workaround let's
remove the error when the IVT offset is not found.

It is useful to have such message, especially during bring-up phase,
but the build error that it causes is severe, so better avoid the
build error for now.

The error checking can be re-implemented later when we have a proper
fix.
Reported-by: NBreno Lima <breno.lima@nxp.com>
Reported-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
      b5b0e4e3
  11. 06 3月, 2018 2 次提交