makc

Можно, конечно, но может быть опасно. Лучше всё-таки, чтобы это делал внешний независимый узел по отдельной команде. Реализуете внутри ПЛИС контроллер SPI Master и будет вам механизм доступа. Собственно приблизительно так родной говиновский программер и шьет внешнюю память: загружает в ПЛИС (на время) прошивку с контроллером SPI, которая по сути является транслятором JTAG<=>SPI, и через неё шьёт всё, что нужно. Вы тоже так можете сделать.

Микроконтроллером через JTAG. Если без МК, то всё сложнее. Остаётся только копать в сторону Multiboot в режиме конфигурирования MSPI из внешней флешки.

Плюс/минус тоже можно повторить, никто не запрещает прогрузить в SRAM Gowin технологическую прошивку, реализующую JTAG TAP и далее использующуюся для прошивки всего, что заблагорассудится. Я пока не вижу никакой принципиальной разницы между Gowin и Xilinx в этом плане. В Xilinx чуточку проще, т.к. есть аппаратный примитив, позволяющий работать с JTAG в довольно удобной виде, но при наличии JTAGSEL_N и реализации TAP можно получить всё то же самое.

Не понимаю проблемы: если есть JTAG, то у вас есть полный контроль и вы можете сделать приблизительно всё, что угодно. Зачем ещё какой-то SPI? Через JTAG вы можете зашить внутреннюю флешку Gowin, можете общаться с технологическим ядром и шить данные во внешнюю флешку, например, через SPI и т.п. Кстати, у Gowin можно переключать функцию пинов JTAG, а SPI на пинах JTAG реализуется легко и просто:

Ставите МК в роли моста UART<=[Микроконтроллер]=>JTAG<=>Gowin и вуаля, получаете выполнение требования ТЗ. Как шить Gowin из МК здесь уже обсуждалось.

Думать != знать. Поэтому вопрос к ТС: опишите задачу детальнее, чтобы можно было обсуждать что-то более определённо.

Потому что непонятно, как это применимо к обстоятельствам у ТС. А то может так случиться, что мы сейчас напридумываем проблем на ровном месте, а у ТС вообще частная сеть (изолированный комплекс) и там будут только его девайсы...

Фантазировать можно до бесконечности, но какой в этом смысл в контексте вопроса темы? Поэтому предлагаю не уходя от темы либо предлагать другие варианты, либо не усугублять оффтопик.

Я видел параноиков, которым было делать нечего и они делали полные привязки по MAC на портах кисок. Но обычно это продолжается недолго, т.к. MAC никак не аутентифицирует подключенную станцию, а значит на безопасность повлиять не может. Хотя, конечно, не все это понимают... Случаи бывают разные... Я на практике с таким подходом СИБ ни разу не сталкивался и таких требований в ТЗ ни разу не видел. Мы не знаем, что за изделие разрабатывается у ТС и как оно будет применяться, поэтому говорить что подход с LAA априори некорректен по-моему довольно опрометчиво. 😉

Вы пишете, что "у кого-то из купивших пользователей может оказаться в сети другой девайс, где случайно окажется такой-же MAC. ". Т.е. в сети оказался ещё девайс c LAA, а значит, по вашей же логике, в нём обязана быть реализована возможность смены адреса на другой LAA. Разве не так получается исходя из ваших же постов выше? Поскольку для решения конфликта адрес достаточно сменить на одном из устройств, а в устройстве ТС такой возможности не реализовано (предположительно), то пользователь изменит адрес на другом устройстве (которое было в сети ранее) и проблема решится. Нет никакого противоречия, т.к. тиражи наших устройств (полагаю) о-малое на фоне тиражей сетевых карт, роутеров и другого широкораспространённого брендового сетевого оборудования. Хотя манию величия никто не отменял... 😉 У меня пока проблем не было. Возможно это ошибка выжившего. Про этих вообще лучше не говорить.

В этом случае у пользователя должна быть возможность сменить адрес на одно из девайсов. И, скорее всего, у него такая возможность будет, даже если ТС её у себя не реализует. Нет, не на столько же спокойно, т.к. мне думается, что UAA куда более распространены в сравнении с LAA. Поэтому мой выбор для таких случаев - LAA.

Формально такое требование есть, а по факту можно выбрать себе условный OUI в этом диапазоне, который не похож на распространённых вендоров и софт виртуализации, а дальше спокойно использовать и на 99,99% проблем не будет. Да можно и свой OUI зарегистрировать (в теории), были бы деньги. Только вот из России нынче это сделать проблематично, да и финансы обычно поют романсы... PS: https://superuser.com/questions/1120178/how-to-register-for-a-vendor-oui-mac-address-prefix

Смотря что за устройства вы хотите разработать. Мы для таких целей всегда используем locally administered addresses (LAA) и никаких проблем не было. И на крайний случай можно дать пользователям возможность его изменить.

Подход более чем переносим, т.к. его гарантирует правильно выравнивания начала структуры в С. И посмотрите список поддерживаемых архитектур в том же Debian, к вопросу о переносимости. Здесь такого нет. Поэтому GObject везде себя прекрасно чувствует. Ok, если примера Glib/GTK недостаточно, то есть ещё http://libcello.org/ 😎 Погуглите еще "Object-Oriented Programming with ANSI C". К вопросу об UB - https://stackoverflow.com/questions/68162979/is-casting-glib-gtk-pointers-undefined-behavior

Почитайте, как сделано объектно-ориентированное программирование на C и наследование в частности в Glib/GTK. Т.е. как устроен GObject и как он используется. Например, немного понять суть можно по этому вопросу https://stackoverflow.com/questions/48306127/gobject-and-inheritance Мне кажется вы пытаетесь изобрести нечто подобное, только намного более простое. Но подход должен быть тот же.