Однако. У нас как на 2008 была самописная так и осталась. Можно наверно, начинать использовать, но не везде можем, т. к. в основном все работает со старым уровнем совместимости. Потому что план запроса меняется и тяжелый код (а у нас он такой в целом везде, обрабатываем данные большими пачками) с кривым планом выжирает очень много и работает долго.
jcmvbkbc, и пчелы и мед, не меняется конфиг, ядра по крайней мере.
То что на sd я знал, там ничего нет больше.
Я ошибочно думал, что offset и size неправильно указаны. А они правильно, на гитхабе u-boot а была указана разметка sd карты, загрузчик это первый килобайт (или мегабайт), и там в блоках по килобайту указано, где начинается какой сектор (сам загрузчик, env) и какой размер. То что у меня в fw_config - правильно, если менять на что-то другое, уже даже ничего не выдает fw_printenv.
Освоил serial (тяжко быть нубом: tx, ..мае, надо к rx подключать), в загрузчике сделал setenv bootargs bla-bla-bla , saveenv- ядро загружено без этих параметров. fw_printenv их не показывает. Потом ребутнусь опять в загрузчик, посмотрю что даст printenv bootargs. Подозреваю, скажет нету переменной такой.
jcmvbkbc, понятно, но блин, как это сделать?
Сейчас рылся час в интернете, единственное, что толковое нашел:
залезть в исходники u-boot в папку include/configs и искать там заголовочный для своего девайса и в нем CONFIG_ENV_OFFSET и CONFIG_ENV_SIZE. Нашел там для alwinner a20 (на котором моя bananapi m1) файл, там ничего нет, идет инклюдом общий sunxi конфиг, там.. что-то есть.. упоминается CONFIG_ENV_OFFSET, но в комментах, ничего похожего, что можно было бы взять не нашел.
Спасибо! Походу то, но не работает: fw_printenv вначале выдает Bad CRC, using default environment.
Как понял, это значит, что сектор, куда писать параметры указан неправильно в файле fw_env.config.
После fw_setenv fw_printenv выдает конфиг уже с моим параметром, но ядро все равно грузится без него.
Это не поможет, пробовал и так тоже. Проблема вообще в том, что SQL Server не понимает, что таблица дропнута, если написать без go будет ругаться что таблица олреди экзистс. Я go включил так как если выполнять код вне хранимой процедуры, то работает, так как это заставляет сервер каким-то образом понимать что таблица дропнута
Не помогает. Вообще ошибка-то наверное в самих обертках (pyodbc/pymssql) кроется, они, небось, получая поток байтов от драйвера ODBC (в определенной кодировке), например просто как-есть выводят в командную строку.
