Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

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

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

切换分支/标签
  1. 24 4月, 2019 10 次提交
    • S
      sandbox: Move pre-console buffer out of the way of tracing · a1396cdc
      由 Simon Glass 提交于 
      These two buffers currently conflict if tracing is enabled. Move the
pre-console buffer and update the documentation.
Signed-off-by: NSimon Glass <sjg@chromium.org>
      a1396cdc
    • S
      sandbox: Drop the printf() in setup_ram_buf() · 5dbe794d
      由 Simon Glass 提交于 
      This was really intended for debugging. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
      5dbe794d
    • S
      sandbox: Correct maths in allocation routines · 4a6409b7
      由 Simon Glass 提交于 
      Allocation routines were adjusted to ensure that the returned addresses
are a multiple of the page size, but the header code was not updated to
take account of this. These routines assume that the header size is the
same as the page size which is unlikely.

At present os_realloc() does not work correctly due to this bug. The only
user is the hostfs 'ls' command, and only if the directory contains a
unusually long filename, which likely explains why this bug was not
caught earlier.

Fix this by doing the calculations using the obtained page size.
Signed-off-by: NSimon Glass <sjg@chromium.org>
      4a6409b7
    • S
      sandbox: Improve debugging in initcall_run_list() · 001d1885
      由 Simon Glass 提交于 
      At present if one of the initcalls fails on sandbox the address printing
is not help, e.g.:

  initcall sequence 0000557678967c80 failed at call 00005576709dfe1f (err=-96)

This is because U-Boot gets relocated high into memory and the relocation
offset (gd->reloc_off) does not work correctly for sandbox.

Add support for finding the base address of the text region (at least on
Linux) and use that to set the relocation offset. This makes the output
better:

  initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96)

Then you use can use grep to see which init call failed, e.g.:

   $ grep 0000000000048134 u-boot.map
   stdio_add_devices

Of course another option is to run it with a debugger such as gdb:

   $ gdb u-boot
   ...
   (gdb) br initcall.h:41
   Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations)

Note that two locations are reported, since this function is used in both
board_init_f() and board_init_r().

   (gdb) r
   Starting program: /tmp/b/sandbox/u-boot
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

   U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600)

   DRAM:  128 MiB
   MMC:

Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 <init_sequence_f>)
    at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41
41				printf("initcall sequence %p failed at call %p (err=%d)\n",
   (gdb) print *init_fnc_ptr
   $1 = (const init_fnc_t) 0x55555559c114 <stdio_add_devices>
   (gdb)
Signed-off-by: NSimon Glass <sjg@chromium.org>
      001d1885
    • C
      common: command: Add command execution tracer. · 7ae31fcc
      由 Christoph Muellner 提交于 
      When using boot scripts it can become quite hard to understand
which commands are actually executed during bootup (e.g. where
is a kernel image loaded from or which DTB is in use).

Shell scripts suffer from a similar problem and many shells address
this problem with a command execution tracer (e.g. BASH has xtrace,
which can be enabled by "set -x").

This patch introduces a command tracer for U-Boot, which prints
every command with its arguments before it is executed.
Signed-off-by: NChristoph Muellner <christoph.muellner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
      7ae31fcc
    • E
      fdt: boot_get_fdt: android: use ENV 'fdtaddr' as fallback · 62392675
      由 Eugeniu Rosca 提交于 
      Our platform doesn't store the DTB into the Android image second area,
but rather copies the DTB to RAM from a dedicated dtb.img partition [0],
prior to booting the Android image by calling bootm.

Similar to [1], we find it useful to just call 'bootm' and have the
right DTB being passed to OS (assuming its address has been previously
stored in 'fdtaddr' by calling `fdt addr <dtb-addr>`).

Booting Android with DTB from 'fdtaddr' will only occur if:
 - No DTB is embedded in the second area of Android image
 - 'fdtaddr' points to a valid DTB in RAM

[0] https://source.android.com/devices/architecture/dto/partitions
[1] https://patchwork.ozlabs.org/patch/1046652/
    ("Support boot Android image without address on bootm command")
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
      62392675
    • E
      fdt: boot_get_fdt: android: compress handling (non-functional) · 18b8f2c4
      由 Eugeniu Rosca 提交于 
      Prepare for booting Android images which lack any DTB in the second
area by using 'fdtaddr' environment variable as source/address of FDT.
No functional/behavioral change expected in this patch.
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
      18b8f2c4
    • E
      fdt: boot_get_fdt: simplify no_fdt handling (non-functional) · 80281829
      由 Eugeniu Rosca 提交于 
      Increase the readability of boot_get_fdt().
No change in behavior is expected.
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
      80281829
    • E
      fdt: boot_get_fdt: really boot w/o FDT when "goto no_fdt" · 9ee9cf31
      由 Eugeniu Rosca 提交于 
      The 'no_fdt' goto label was introduced by v2015.01 commit [0] and it
had two review stages [1-2]. The *documented* purpose behind commit [0]
is (excerpt from commit description):

> allows both FDT and non-FDT kernels to boot by making the
> third parameter to the bootm/bootz optional

While [1] and [2] share the same goal, they have very different
implementations:
 - [1] was based on a very simple 'argc' check at function error out
   with returning success to the caller if the third parameter was NOT
   passed to bootm/bootz command. This approach had the downside of
   returning success to the caller even in case of legitimate internal
   errors, which should halt booting.
 - [2] added the "no_fdt" label and several "goto no_fdt" statements.
   This allowed to report the legitimate internal errors to the caller.

IOW the major difference between [1] and [2] is:
 - [1] boot w/o FDT if FDT address is not passed to boot{m,z,*}
 - [2] give *freedom* to the developer to boot w/o FDT from any
   (more or less) arbitrary point in the function flow (and here
   comes the peculiar aspect, which looks to be a leftover from [1])
   with the precondition that the 3rd argument (FDT address) is NOT
   provided to boot{m,z,*}. In practice, this means that only a subset
   of "goto no_fdt" end up booting w/o FDT while the other subset is
   returning an error to the caller.

This patch removes the peculiar behavior described above, such that
"goto no_fdt" performs really what it tells to the developer.

The motivation of this patch is to decrease the unneeded complexity
and increase the readability of boot_get_fdt().

[0] 48aead71 ("fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
[1] https://patchwork.ozlabs.org/patch/412923/
    ("[U-Boot,v1] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
[2] https://patchwork.ozlabs.org/patch/415635/
    ("[U-Boot,v2] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
      9ee9cf31
    • E
      fdt: boot_get_fdt: remove redundant zeroing out · d9313efc
      由 Eugeniu Rosca 提交于 
      Paranoid programming [1] lies at the foundation of proper software
development, but the repetitive zeroing-out of output arguments in the
context of the same function rather clutters the code and inhibits
further refactoring/optimization than is doing any good.

In boot_get_fdt(), we already perform zero/NULL-initialization of
*of_flat_tree and *of_size at the beginning of the function, so doing
the same at function error-out is redundant/superfluous.

Moreover, keeping the code unchanged might encourage the developers to
update *of_flat_tree and *of_size during some interim computations,
which is against the current design of boot_get_fdt(). Currently,
writing useful data into these arguments happens just before
successfully returning from boot_get_fdt() and it should better stay so.

[1] https://blog.regehr.org/archives/1106Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
      d9313efc
  3. 22 4月, 2019 2 次提交
  5. 21 4月, 2019 23 次提交
  7. 19 4月, 2019 3 次提交
  9. 18 4月, 2019 2 次提交