Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

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

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

切换分支/标签
  1. 20 7月, 2016 1 次提交
    • A
      wandboard: move environment partition farther from u-boot.img · 67ff9e11
      由 Alexey Brodkin 提交于 
      Recently I started to notice that u-boot.img built for Wandboard
by some toolchains becomes so large that it basically overlaps with
U-Boot environment area on SD-card.

According to
http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
Wandboard's SD-card layout is as follows:
------------------------------>8---------------------------
Acked-by: NOtavio Salvador <otavio@ossystems.com.br>
Acked-by: NFabio Estevam <fabio.estevam@nxp.com>

==========================================================
1. 0x00000000           Reserved For MBR
2. 0x00000200   512     Secondary Image Table (optional)
3. 0x00000400   1024    uBoot Image (Starting From IVT)
4. 0x00060000   393216  start of uboot env (size:8k)
5. 0x00062000           end of uboot env
6. 0x00100000   1048576 Linux kernel start
7. 0x0076AC00   7777280 start of partition 1
------------------------------>8---------------------------

So for U-Boot we have 383kB (392192 bytes).

But in up to date U-Boot for Wandboard we build separately
 a) SPL
 b) u-boot.img

which gives us a bit more detailed SD-card layout:
------------------------------>8---------------------------
==========================================================
1. 0x00000000           Reserved For MBR
2. 0x00000200   512     Secondary Image Table (optional)
3. 0x00000400   1024    SPL
4. 0x00011400   70656   u-boot.img
5. 0x00060000   393216  start of uboot env (size:8k)
6. 0x00062000           end of uboot env
...
------------------------------>8---------------------------

>From that layout we may calculate amount of space reserved for
u-boot.img. It's just 315kb (322560 bytes).

Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
u-boot.img is already more than we expected
(323840 bytes instead of "< 322560"):
------------------------------>8---------------------------
ls -la u-boot.img
-rw-rw-r-- 1 user user 323840 Jul  5 07:38 u-boot.img
------------------------------>8---------------------------

Funny enough if I rebuild U-Boot with ARM toolchain available in
my Fedora 23 distro u-boot.img becomes a little bit smaller:
------------------------------>8---------------------------
ls -la u-boot.img
-rw-rw-r-- 1 user user 322216 Jul  5 07:39 u-boot.img
------------------------------>8---------------------------

What's worse this problem might not affect people most of the time
because what happens people would just copy u-boot.img on SD-card and
live in happiness with it... well until somebody attempts to save
environment in U-Boot with "saveenv" command which will simply
overwrite the very end of u-boot.img.
That will lead to unusable SD-card until user dd u-boot.img on
SD-card again.

I may foresee this issue in the future to become more visible once we
add more features in U-Boot for Wandboard or just existing code base
becomes bulkier and people will consistently get larger u-boot.img
files produced.

IMHO there's an obvious solution for all that - just move U-Boot's env
to the very end of the gap between U-Boot and the first real partition
on the SD-card. This patch will follow
8fb9eea5 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
So env is still not in the very end of the gap (obviously 256kb is way
too much for U-Boot's env) but at least we have now the same
partitioning for i.MX6 boards.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Wolfgang Denk <wd@denx.de>
      67ff9e11
  3. 12 7月, 2016 23 次提交
  5. 11 7月, 2016 3 次提交
  7. 09 7月, 2016 6 次提交
    • M
      armv8: Enable CPUECTLR.SMPEN for coherency · d73718f3
      由 Mingkai Hu 提交于 
      For A53, data coherency is enabled only when the CPUECTLR.SMPEN bit is
set. The SMPEN bit should be set before enabling the data cache.
If not enabled, the cache is not coherent with other cores and
data corruption could occur.

For A57/A72, SMPEN bit enables the processor to receive instruction
cache and TLB maintenance operations broadcast from other processors
in the cluster. This bit should be set before enabling the caches and
MMU, or performing any cache and TLB maintenance operations.
Signed-off-by: NMingkai Hu <mingkai.hu@nxp.com>
Signed-off-by: NGong Qianyu <Qianyu.Gong@nxp.com>
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      d73718f3
    • D
      test/py: support 'memstart =' in u_boot_utils.find_ram_base() · d56dd0b1
      由 Daniel Schwierzeck 提交于 
      Some archs like MIPS or PPC have a different 'bdinfo' output
than ARM regarding the memory configuration. Also support
'memstart = 0x*' in u_boot_utils.find_ram_base() to make
all tests requiring the RAM base working on those archs.
Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
      d56dd0b1
    • S
      test/py: strip VT100 codes from match buffer · 085e64dd
      由 Stephen Warren 提交于 
      Prior to this patch, any VT100 codes emitted by U-Boot are considered part
of a command's output, which often causes tests to fail. For example,
test_env_echo_exists executes printenv, and then considers any text on a
line before an = sign as a valid U-Boot environment variable name. This
includes any VT100 codes emitted. When the test later attempts to use that
variable, the name would be invalid since it includes the VT100 codes.
Solve this by stripping VT100 codes from the match buffer, so they are
never seen by higher level test code.

The codes are still logged unmodified, so that users can expect U-Boot's
exact output without interference. This does clutter the log file a bit.
However, it allows users to see exactly what U-Boot emitted rather than a
modified version, which hopefully is better for debugging. It's also much
simpler to implement, since logging happens as soon as text is received,
and so stripping the VT100 codes from the log would require handling
reception and stripping of partial VT100 codes.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      085e64dd
    • A
      arm: Fix setjmp (again) · 0de02de7
      由 Alexander Graf 提交于 
      Commit e6777248 (arm: Fix setjmp) added code to fix compilation of the setjmp
code path with thumv1. Unfortunately it missed a constraint that the adr
instruction can only refer to 4 byte aligned offsets.

So this patch adds the required alignment hooks to make compilation
work again even when setjmp doesn't happen to be 4 byte aligned.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Tested-by: NTom Rini <trini@konsulko.com>
      0de02de7
    • A
      SPL: tiny-printf: avoid any BSS usage · 59d07ee0
      由 Andre Przywara 提交于 
      As printf calls may be executed quite early, we should avoid using any
BSS stored variables, since some boards put BSS in DRAM, which may not
have been initialised yet.
Explicitly mark those "static global" variables as belonging to the
.data section, to keep tiny-printf clear of any BSS usage.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
      59d07ee0
    • S
      test/py: fix CONFIG_ tests · a82642f3
      由 Stephen Warren 提交于 
      Some CONFIG_ variables were recently renamed, but test/py wasn't updated
to match. This causes some tests to be skipped. Fix test/py so the tests
are run.

Fixes: 11636258 ("Rename reset to sysreset")
Fixes: f1f9d4fa ("hush: complete renaming CONFIG_SYS_HUSH_PARSER to CONFIG_HUSH_PARSER")
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      a82642f3
  9. 08 7月, 2016 1 次提交
  11. 07 7月, 2016 4 次提交
  13. 06 7月, 2016 2 次提交