Am 12.10.2019 um 00:11 schrieb Simon Glass:
Hi Simon,
On Fri, 11 Oct 2019 at 12:31, Simon Goldschmidt
<simon.k.r.goldschm...@gmail.com> wrote:
Simon Glass <s...@chromium.org> schrieb am Fr., 11. Okt. 2019, 20:27:
Hi Simon,
On Tue, 8 Oct 2019 at 14:34, Simon Goldschmidt
<simon.k.r.goldschm...@gmail.com> wrote:
In a series I'm currently preparing, I've stumbled accross the fact that
IS_ERR_VALUE() doesn't reliably work on socfpga SPL as the onchip SRAM
begins at 0xffff0000 and the heap is at the end of the 32 bit range.
Which function is returning that address?
Sorry, I don't know right now and it was kind of hard to debug. But it was somewhere in
the DM initialization of new drivers I was adding. One of those functions returned a heap
pointer that was interpreted as an error due to the address being in the range regarded
as "error pointer"...
I don't know a good solution to this. But we should consider changing
whatever API it was to use an int return value instead of an address.
The address can be passed back in another parameter. That is how most
uclass methods work.
Digging into this again, it was 'syscon_node_to_regmap', which seems to
be copied from Linux, so I don't think it's feasible to change this
function. Also, IS_ERR() is used in ~120 files, I wouldn't want to
change all these for socfpga.
One idea that came to mind was to change the ERR_PTR/PTR_ERR macros in
linux/err.h to convert errors to an architecture-specified pointer range
instead of just converting the data type. However, that would mean
another change to Linux imports, and Tom just seemed a little opposed to
that...?
Tom?
Regards,
Simon
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
