Способ работает с pi2 и pi3. Преимущества: на SD-карте нужен только один файл загрузчика, всё остальное будет загружаться с сервера, включая config.txt.
[aka] Если используется WTware TFTP версии 5.4.82 или новее, не надо лазить руками в c:\program files\. Оно должно работать само. Наша инструкция в соседней теме.
Для примера будем грузить WTware 5.4.60. Корень TFTP сервера в папке C:\Program Files (x86)\WTware\TFTPDROOT.
На чистую SD-карту записываем вот этот
bootcode.bin. Вставляем карту в малину. Клиент для загрузки готов.
На DHCP сервере добавляем опцию 66 с адресом TFTP сервера. Надо указать именно IP адрес, не имя. Опция 67 игнорируется загрузчиком малины, в ней надо указать путь к той версии втвари, которую будем грузить. Пишем
5.4.60/wtware.pxe
На TFTP сервере переходим в папку
5.4.60\pi2\netboot. Файл
kernel7.img заменяем на тот, который лежит в
5.4.60\kernel7.img. Далее скачиваем и заменяем следующие файлы:
bootcode.bin,
start.elf,
fixup.dat.
Теперь нам надо узнать серийный номер процессора малины, чтобы создать ссылку на загрузочный каталог. Если у вас есть живой raspbian, запустите
Внизу будет строчка вида:
Нам нужны последние 8 символов, в данном случае наш серийник будет
82a6f315.
Если нет raspbian, можно просто включить малину, она попытается скачать файлы с TFTP и в логах сервера вы увидите имя загрузочного каталога.
Теперь осталось сделать ссылку на загрузочный каталог. Запустите командную строку с правами администратора.
Код: Выделить всё
cd /d "C:\Program Files (x86)\WTware\TFTPDROOT"
mklink /d 82a6f315 5.4.60\pi2\netboot
На этом всё. Можно грузить малину по сети.
Третья малина (rpi3) также умеет грузиться по сети или с USB флешки вообще без SD-карты. Как включить этот режим загрузки описано
здесь. Ну и гугл, конечно, на предмет "raspberry pi network boot". Для этого способа на TFTP сервере делаете всё то же самое плюс в корень TFTPDROOT кладёте копию
bootcode.bin.
Я пробовал также и этот способ, но он мне не понравился:
1) при включении малина соображает около 5 секунд, что у нее нет SD-карты, и только потом начинает загрузку.
2) нет возможности грузиться с TFTP сервера из другой подсети, т.к. бутром не знает про шлюз. Поиск TFTP сервера ведется через ARP. Возможно, в этом случае может помочь arp-прокси, но я не проверял.
3) (главный глюк) срабатывает ненадежно, через раз, иногда загрузка зависает на полпути. Связано с тайм-аутами при инициализации сетевого адаптера. Наблюдается хитрая зависимость от сетевого оборудования, с некоторыми коммутаторами глючит чаще, с другими реже. Иногда вообще не работает. Подробнее см. ниже.
Дополнение. Список багов в реализации PXE у малины. Скомпилировал с буржуйских форумов.
Ошибки общей реализации DHCP/PXE:
* Although the Pi sets the vendor class option 60 to “PXEClient:Arch:00000:UNDI:002001”, this is not PXE compliant.
* The pi does not send a DHCPREQUEST packet before it starts to use the IP addr in the DHCPOFFER packet.
* DHCP option next-server is ignored, use DHCP Option 66 (option tftp-server-name for linux dhcpd)to specify a different TFTP server address.
* ARCH Option 93 is set to an unexpected value in the DHCPDISCOVER packet. It is set to 0 (Standard PC BIOS).
* DHCP option filename is ignored. start.elf (with or without the serial number as a prefix) is used as a filename instead.
Ошибки в бутроме при загрузке без SD карты:
* When the boot ROM enables the Ethernet link, it first waits for the link to come up, then sends its first DHCP request packet. This is sometimes too quick for the switch to which the Raspberry Pi is connected: we believe that the switch may throw away packets it receives very soon after the link first comes up.
* The DHCP packet retransmission loop is not timing out correctly, so the DHCP packet will not be retransmitted.
* DHCP Option 3 (routers) is not requested (so the Pi cannot contact a server that is located in a different subnet). Even if the DHCP server is forced to provide this option, the Pi seems to ignore it.
Способ работает с pi2 и pi3. Преимущества: на SD-карте нужен только один файл загрузчика, всё остальное будет загружаться с сервера, включая config.txt.
[color=#FF0000][aka] Если используется WTware TFTP версии 5.4.82 или новее, не надо лазить руками в c:\program files\. Оно должно работать само. Наша инструкция [url=https://forum.wtware.ru/viewtopic.php?f=32&t=19968]в соседней теме[/url].[/color]
Для примера будем грузить WTware 5.4.60. Корень TFTP сервера в папке C:\Program Files (x86)\WTware\TFTPDROOT.
На чистую SD-карту записываем вот этот [url=https://github.com/raspberrypi/firmware/raw/next/boot/bootcode.bin]bootcode.bin[/url]. Вставляем карту в малину. Клиент для загрузки готов.
На DHCP сервере добавляем опцию 66 с адресом TFTP сервера. Надо указать именно IP адрес, не имя. Опция 67 игнорируется загрузчиком малины, в ней надо указать путь к той версии втвари, которую будем грузить. Пишем [b]5.4.60/wtware.pxe[/b]
На TFTP сервере переходим в папку [b]5.4.60\pi2\netboot[/b]. Файл [b]kernel7.img[/b] заменяем на тот, который лежит в [b]5.4.60\kernel7.img[/b]. Далее скачиваем и заменяем следующие файлы: [url=https://github.com/raspberrypi/firmware/raw/next/boot/bootcode.bin]bootcode.bin[/url], [url=https://github.com/raspberrypi/firmware/raw/next/boot/start.elf]start.elf[/url], [url=https://github.com/raspberrypi/firmware/raw/next/boot/fixup.dat]fixup.dat[/url].
Теперь нам надо узнать серийный номер процессора малины, чтобы создать ссылку на загрузочный каталог. Если у вас есть живой raspbian, запустите
[code]cat /proc/cpuinfo[/code]
Внизу будет строчка вида:
[code]Serial : 0000000082a6f315[/code]
Нам нужны последние 8 символов, в данном случае наш серийник будет [b]82a6f315[/b].
Если нет raspbian, можно просто включить малину, она попытается скачать файлы с TFTP и в логах сервера вы увидите имя загрузочного каталога.
Теперь осталось сделать ссылку на загрузочный каталог. Запустите командную строку с правами администратора.
[code]cd /d "C:\Program Files (x86)\WTware\TFTPDROOT"
mklink /d 82a6f315 5.4.60\pi2\netboot[/code]
На этом всё. Можно грузить малину по сети.
Третья малина (rpi3) также умеет грузиться по сети или с USB флешки вообще без SD-карты. Как включить этот режим загрузки описано [url=https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/]здесь[/url]. Ну и гугл, конечно, на предмет "raspberry pi network boot". Для этого способа на TFTP сервере делаете всё то же самое плюс в корень TFTPDROOT кладёте копию [url=https://github.com/raspberrypi/firmware/raw/next/boot/bootcode.bin]bootcode.bin[/url].
Я пробовал также и этот способ, но он мне не понравился:
1) при включении малина соображает около 5 секунд, что у нее нет SD-карты, и только потом начинает загрузку.
2) нет возможности грузиться с TFTP сервера из другой подсети, т.к. бутром не знает про шлюз. Поиск TFTP сервера ведется через ARP. Возможно, в этом случае может помочь arp-прокси, но я не проверял.
3) (главный глюк) срабатывает ненадежно, через раз, иногда загрузка зависает на полпути. Связано с тайм-аутами при инициализации сетевого адаптера. Наблюдается хитрая зависимость от сетевого оборудования, с некоторыми коммутаторами глючит чаще, с другими реже. Иногда вообще не работает. Подробнее см. ниже.
[color=#BF0000][b]Дополнение[/b]. Список багов в реализации PXE у малины. Скомпилировал с буржуйских форумов.[/color]
[b]Ошибки общей реализации DHCP/PXE[/b]:
* Although the Pi sets the vendor class option 60 to “PXEClient:Arch:00000:UNDI:002001”, this is not PXE compliant.
* The pi does not send a DHCPREQUEST packet before it starts to use the IP addr in the DHCPOFFER packet.
* DHCP option next-server is ignored, use DHCP Option 66 (option tftp-server-name for linux dhcpd)to specify a different TFTP server address.
* ARCH Option 93 is set to an unexpected value in the DHCPDISCOVER packet. It is set to 0 (Standard PC BIOS).
* DHCP option filename is ignored. start.elf (with or without the serial number as a prefix) is used as a filename instead.
[b]Ошибки в бутроме при загрузке без SD карты[/b]:
* When the boot ROM enables the Ethernet link, it first waits for the link to come up, then sends its first DHCP request packet. This is sometimes too quick for the switch to which the Raspberry Pi is connected: we believe that the switch may throw away packets it receives very soon after the link first comes up.
* The DHCP packet retransmission loop is not timing out correctly, so the DHCP packet will not be retransmitted.
* DHCP Option 3 (routers) is not requested (so the Pi cannot contact a server that is located in a different subnet). Even if the DHCP server is forced to provide this option, the Pi seems to ignore it.