On 13/02/18 09:16, John Paul Adrian Glaubitz wrote:

On Feb 13, 2018, at 7:39 AM, Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> 
wrote:

On 12/02/18 10:55, John Paul Adrian Glaubitz wrote:

On 02/12/2018 11:52 AM, Mathieu Malaterre wrote:
  From the look at the error message, I thought this was the hack
milan@d.o used with:

https://packages.debian.org/sid/e2fslibs1.41-dev
Again, we're talking about booting the CD, not the installed system.
There is no ext2/3/4 involved here. The bug you mentioned exists
because Yaboot doesn't handle ext4.

The above package provided the key: the link error I was seeing was because the 
default e2fslibs package only provides .so libraries. Extracting the static 
library from the above package was enough to get my compile to succeed.

Ok, I wasn’t paying too much attention to the linker errors. We have to verify 
then that Yaboot actually still builds on unstable.

I did have a look at the sid yaboot debian packages, and from memory they did list the dependency on e2fslibs1.41-dev so I would expect this to work.

Anyhow I can confirm that the bug I see is present in 1.3.17 and not 1.3.16, 
and with the magic of git bisect I managed to isolate it down to this commit:

I can upload a version of Yaboot today with this patch reverted provided that 
Yaboot still builds fine on unstable without the hack you used.

Well let me dig a bit deeper first. The net result of the change is that the malloc() heap base is changed from 0x300000 to just under PROM_CLAIM_MAX_ADDR (0x10000000), and the claim itself returns success from the firmware.

The strange behaviour I was seeing in the debugger was that writes to the higher address ranges (i.e. in strdup()) were succeeding but reading back the just written values was returning all zeros which is why the configuration data comes back empty.


ATB,

Mark.

Reply via email to