Skip to content
Snippets Groups Projects
Select Git revision
  • rk3576-sige5-kwiboo-mainline
  • sige5-dev default
2 results
Search by author
  • Any Author
  • Nicolas Frattaroli Nicolas Frattaroli fratti
1 author
  1. Apr 03, 2009
  3. Apr 02, 2009
  5. Apr 01, 2009
    • Laurent Gregoire's avatar
      libfdt: Fix C++ compile-time cast error on gnu 4.2.1 · 67b89c79
      Laurent Gregoire authored 
      
Allow the inclusion of libfdt.h in C++ source.

Signed-off-by: default avatarLaurent Gregoire <laurent.gregoire@tomtom.com>
Acked-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      67b89c79
    • Emil Medve's avatar
      Fix a possible overflow case detected by gcc 4.3.2 · 13d93f38
      Emil Medve authored 
      
.../dtc/libfdt/fdt_sw.c: In function 'fdt_end_node':
.../dtc/libfdt/fdt_sw.c:81: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false

Signed-off-by: default avatarEmil Medve <Emilian.Medve@Freescale.com>
      13d93f38
    • David Gibson's avatar
      libfdt: Rework/cleanup fdt_next_tag() · a22d9cfb
      David Gibson authored 
      
Currently, callers of fdt_next_tag() must usually follow the call with
some sort of call to fdt_offset_ptr() to verify that the blob isn't
truncated in the middle of the tag data they're going to process.
This is a bit silly, since fdt_next_tag() generally has to call
fdt_offset_ptr() on at least some of the data following the tag for
its own operation.

This patch alters fdt_next_tag() to always use fdt_offset_ptr() to
verify the data between its starting offset and the offset it returns
in nextoffset.  This simplifies fdt_get_property() which no longer has
to verify itself that the property data is all present.

At the same time, I neaten and clarify the error handling for
fdt_next_tag().  Previously, fdt_next_tag() could return -1 instead of
a tag value in some circumstances - which almost none of the callers
checked for.  Also, fdt_next_tag() could return FDT_END either because
it encountered an FDT_END tag, or because it reached the end of the
structure block - no way was provided to tell between these cases.

With this patch, fdt_next_tag() always returns FDT_END with a negative
value in nextoffset for an error.  This means the several places which
loop looking for FDT_END will still work correctly - they only need to
check for errors at the end.  The errors which fdt_next_tag() can
report are:
	- -FDT_ERR_TRUNCATED if it reached the end of the structure
	   block instead of finding a tag.

	- -FDT_BADSTRUCTURE if a bad tag was encountered, or if the
           tag data couldn't be verified with fdt_offset_ptr().

This patch also updates the callers of fdt_next_tag(), where
appropriate, to make use of the new error reporting.

Finally, the prototype for the long gone _fdt_next_tag() is removed
from libfdt_internal.h.

Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      a22d9cfb
    • David Gibson's avatar
      libfdt: Rework fdt_next_node() · 2c0b843e
      David Gibson authored 
      
Currently fdt_next_node() will find the next node in the blob
regardless of whether it is above, below or at the same level in the
tree as the starting node - the depth parameter is updated to indicate
which is the case.  When a depth parameter is supplied, this patch
makes it instead terminate immediately when it finds the END_NODE tag
for a node at depth 0.  In this case it returns the offset immediately
past the END_NODE tag.

This has a couple of advantages.  First, this slightly simplifies
fdt_subnode_offset(), which no longer needs to explicitly check that
fdt_next_node()'s iteration hasn't left the starting node.  Second,
this allows fdt_next_node() to be used to implement
_fdt_node_end_offset() considerably simplifying the latter function.

The other users of fdt_next_node() either don't need to iterate out of
the starting node, or don't pass a depth parameter at all.  Any
callers that really need to iterate out of the starting node, but keep
tracking depth can do so by biasing the initial depth value.

This is a semantic change, but I think it's very unlikely to break any
existing library users.

Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      2c0b843e
    • Wolfgang Denk's avatar
      Merge branch 'master' of git://git.denx.de/u-boot-arm · dfc91c33
      Wolfgang Denk authored
      dfc91c33
    • Scott Wood's avatar
      mpc83xx: Set guarded bit on BAT that covers the end of the address space · c1230980
      Scott Wood authored 
      
The mpc8313erdb board currently sets DBAT6 to cover all of the final 256MiB of
address space; however, not all of this space is covered by a device.  In
particular, flash sits at 0xfe000000-0xfe7fffff, and nothing is mapped
at the far end of the address space.

In zlib, there is a loop that references p[-1] if p is non-NULL.  Under
some circumstances, this leads to the CPU speculatively loading from
0xfffffff8 if p is NULL.  This leads to a machine check.

Signed-off-by: default avatarScott Wood <scottwood@freescale.com>

continuation to the remaining mpc83xx boards that suffer from the same problem.

Signed-off-by: default avatarKim Phillips <kim.phillips@freescale.com>
      c1230980
    • Wolfgang Denk's avatar
      Merge branch 'master' of git://git.denx.de/u-boot-i2c · ed9953d6
      Wolfgang Denk authored
      ed9953d6
    • Wolfgang Denk's avatar
      Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx · da72af8d
      Wolfgang Denk authored
      da72af8d