[U-Boot] regression: setting the rpi mac address stopped working
Hi,
u-boot 2016.11 & newer doesn't set the mac address on my raspberry pi any more, so the linux kernel picks a random mac address. Bisected to this commit:
commit b91c6a1209e7da1a7f989d9ac35d0d8be0b7b710 Author: Simon Glass sjg@chromium.org Date: Wed Oct 5 20:42:11 2016 -0600
Fix return value in trailing_strtoln()
This function should return -1 if there is no trailing integer in the string. Instead it returns 0. Fix it by checking for this condition at the start.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com
Appearently this change broke fdt_fixup_ethernet().
cheers, Gerd
Hi,
On 27 March 2017 at 02:24, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
u-boot 2016.11 & newer doesn't set the mac address on my raspberry pi any more, so the linux kernel picks a random mac address. Bisected to this commit:
commit b91c6a1209e7da1a7f989d9ac35d0d8be0b7b710 Author: Simon Glass sjg@chromium.org Date: Wed Oct 5 20:42:11 2016 -0600
Fix return value in trailing_strtoln() This function should return -1 if there is no trailing integer in the string. Instead it returns 0. Fix it by checking for this condition at the start. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>Appearently this change broke fdt_fixup_ethernet().
I'm sorry to hear that. Any change you have a patch? It looks like the latter code was relying on the bad behaviour?
Regards, Simon
Hi Simon, Gerd
On Fri, 31 Mar 2017 22:22:52 -0600 Simon Glass sjg@chromium.org wrote:
Hi,
On 27 March 2017 at 02:24, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
u-boot 2016.11 & newer doesn't set the mac address on my raspberry pi any more, so the linux kernel picks a random mac address. Bisected to this commit:
commit b91c6a1209e7da1a7f989d9ac35d0d8be0b7b710 Author: Simon Glass sjg@chromium.org Date: Wed Oct 5 20:42:11 2016 -0600
Fix return value in trailing_strtoln() This function should return -1 if there is no trailing integer in the string. Instead it returns 0. Fix it by checking for this condition at the start. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>Appearently this change broke fdt_fixup_ethernet().
I'm sorry to hear that. Any change you have a patch? It looks like the latter code was relying on the bad behaviour?
https://www.mail-archive.com/u-boot@lists.denx.de/msg241949.html fixes this problem.
Hi,
https://www.mail-archive.com/u-boot@lists.denx.de/msg241949.html fixes this problem.
Tested things today, only to figure it doesn't work :(
Reverting commit "3f66149 Remove extra fdt_fixup_ethernet() call" brings things into working state. So the fix above actually works, and apparently the fdt_fixup_ethernet() call in image_setup_libfdt() isn't as redundant as it seems ...
cheers, Gerd
PS: I'm not on the list, if you want me test any patches please cc me.
On Mon, Apr 24, 2017 at 02:12:28PM +0200, Gerd Hoffmann wrote:
Hi,
https://www.mail-archive.com/u-boot@lists.denx.de/msg241949.html fixes this problem.
Tested things today, only to figure it doesn't work :(
Reverting commit "3f66149 Remove extra fdt_fixup_ethernet() call" brings things into working state. So the fix above actually works, and apparently the fdt_fixup_ethernet() call in image_setup_libfdt() isn't as redundant as it seems ...
cheers, Gerd
PS: I'm not on the list, if you want me test any patches please cc me.
Ug. Thanks for the report!
participants (4)
-
Gerd Hoffmann -
Simon Glass -
Tom Rini -
Tuomas Tynkkynen