# GCC 3.x is reported to have problems generating the type of relocation
# that U-Boot wants.
-# See http://lists.denx.de/pipermail/u-boot/2012-September/135156.html
+# See https://patch.msgid.link/1348500648.2514.2.camel@petert/
checkgcc4:
@if test "$(call cc-name)" = "gcc" -a \
$(call cc-version) -lt 0400; then \
It does not support 'boot from SD' at offset 0x400
except through the 'bmode' command.
- http://lists.denx.de/pipermail/u-boot/2012-August/131151.html
+ https://patch.msgid.link/1345062683-19134-1-git-send-email-troy.kisky@boundarydevices.com/
2. Boots using 6x_bootscript on SATA or SD card
-----------------------------------------------
Compiled based on information here::
- https://lists.denx.de/pipermail/u-boot/2015-March/209530.html
+ https://patch.msgid.link/1427703262.24522.59.camel@collabora.co.uk/
https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big
- https://lists.denx.de/pipermail/u-boot/2017-May/289491.html
+ https://patch.msgid.link/CALr8Vo1WvO=m1W2zvT=MOQ3k-fNtcCtBjk2+zgKha0j28s8g6A@mail.gmail.com/
https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card
1. Build U-Boot
for a particular architecture. It also makes it easier to adopt Graeme's
initcall proposal when it is ready.
-http://lists.denx.de/pipermail/u-boot/2012-January/114499.html
+https://patch.msgid.link/4F019ABB.9010201@gmail.com/
This series removes the dependency on generic relocation. So relocation
happens as one big chunk and is still completely arch-specific. See the
relocation series for a proposed solution to this for ARM:
-http://lists.denx.de/pipermail/u-boot/2011-December/112928.html
+https://patch.msgid.link/CAPnjgZ0jesqX1Y71S5xoYQDGPuARfOX48RGbU9Mw=P5HGYcOKg@mail.gmail.com/
or Graeme's recent x86 series v2:
-http://lists.denx.de/pipermail/u-boot/2012-January/114467.html
+https://patch.msgid.link/1325477374-6417-1-git-send-email-graeme.russ@gmail.com/
Instead of moving over a whole architecture, this series takes the approach
of simply enabling generic board support for an architecture. It is then up
* implemented we should call
* st_boottime->exit(image_handle, EFI_SUCCESS, 0, NULL);
* here, cf.
- * https://lists.denx.de/pipermail/u-boot/2017-October/308720.html
+ * https://patch.msgid.link/44453b06-5a09-ee3c-0a6a-b54bee9020e4@gmx.de/
*/
return EFI_SUCCESS;
}
/*
* Pad to a 2KB alignment, as required for init/boot size by the ROM
- * (see https://lists.denx.de/pipermail/u-boot/2017-May/293268.html)
+ * (see https://patch.msgid.link/CANbgqAQPw5Dxp7Qm_aZoL1nggg9Mm1SQoKvx=V5a8p-9+DTDNw@mail.gmail.com/)
*/
return ROUND(size, RK_SIZE_ALIGN);
}
* to determine the size of the next-stage bootloader (e.g. U-Boot
* proper), when used with the back-to-bootrom functionality.
*
- * see https://lists.denx.de/pipermail/u-boot/2017-May/293267.html
+ * see https://patch.msgid.link/CANbgqAQ5p-fE4T-Ye9UAMs-nRGU8AP_yxDf+5SbZbP8bxLa0dg@mail.gmail.com/
* for a more detailed explanation by Andy Yan
*/
if (spl_params.boot_file)