Dear Linus,
In message CACRpkdZ2XCBU9QvFUg=c_2E=QQP=fmRaup-EnEWx3hWzqvtqcA@mail.gmail.com you wrote:
-#define CONFIG_SYS_LOAD_ADDR 0x7fc0 /* default load address */ +#define CONFIG_SYS_LOAD_ADDR 0x800 /* default load address */
This appears to be an unrelated change. It should be clearly documented, especially as users who just update U-Boot on their board may have to make this change manually.
OK moved this out to a separate patch. Not very important anyway, I just never understood the very weird offset 0x7fc0, because when I tested it any address sort of works...
Any hints on why it is (historically) set to 0x7fc0?
I can only speculate - 0x40 = 64 bytes is the size of the old legacy uImage header; with this load address the payload would be aligned at 0x8000. Eventually this was used to avoid a memcpy in case of uncompressed kernel images?
#define CONFIG_SERVERIP 192.168.1.100 #define CONFIG_IPADDR 192.168.1.104
Please get rid of these. We don't allow this in board config files.
I'll try to convert this to using DHCP.
Thanks.
- "setenv fdtaddr 0x00800000 ; " \
- "bootp $loadaddr $serverip:uImage ; " \
- "bootp $fdtaddr $serverip:integratorcp.dtb ; " \
- "bootm $loadaddr - $fdtaddr"
Is it intentional that integratorap.h and integratorcp.h are now configured so differently?
Yes, the Integrator/CP has an ethernet adapter (SMSC91x) that we know will always be available and preferred boot path.
The Integrator/AP has an optional Ethernet PCI card, but we cannot rely on that always being present.
Hm... that's a change of behaviour to all users, which is not really nice. But OK, you're the board maintainer...
Best regards,
Wolfgang Denk