a1ien

Попробую пованговать. У вас windows и стоит плагин Eclipse Embedded Systems Register View?

Переход тоже гдето в 2 така выливается. Тоесть цикл записи в порт самый оптимизированный(а не тот что приведен выше) занимает около 6 тактов,соответственно 12 тактов запись патерна. Тоесть теоретически 6-7 мгц это максимум что можно получить при генерации меандра.

Trial это как и у j-link EDU наверно. Тоесть при каждом запуске будет выскакивать сообщение что вы пользуетесь EDU верснией которая только для некомерческого использования.

Ммм несовсем понял я просто взял драйвер нанд от s3c2410 он есть в убуте. Думаю поидее проблем недолжно быть. Плюс еще есть сорци совсем старого убута года этак 2008 в котором полностью работает моя плата. Нет это спортивный интерес. Просто как практика в изучении убута.

Да спасибо вы полностью подтвердили то что я подозревал. Угу именно при делении на 0 и ловлю сигнал #8. Спс. щас буду править код.

get_PCLK() смотрел там все выглядит правильно. вот код static ulong get_PLLCLK(int pllreg) { struct s3c24x0_clock_power *clk_power = s3c24x0_get_base_clock_power(); ulong r, m, p, s; if (pllreg == MPLL) r = readl(&clk_power->mpllcon); else if (pllreg == UPLL) r = readl(&clk_power->upllcon); else hang(); m = ((r & 0xFF000) >> 12) + 8; p = ((r & 0x003F0) >> 4) + 2; s = r & 0x3; #if defined(CONFIG_S3C2440) if (pllreg == MPLL) return 2 * m * (CONFIG_SYS_CLK_FREQ / (p << s)); #endif return (CONFIG_SYS_CLK_FREQ * m) / (p << s); } /* return FCLK frequency */ ulong get_FCLK(void) { return get_PLLCLK(MPLL); } ulong get_HCLK(void) { struct s3c24x0_clock_power *clk_power = s3c24x0_get_base_clock_power(); #ifdef CONFIG_S3C2440 switch (readl(&clk_power->clkdivn) & 0x6) { default: case 0: return get_FCLK(); case 2: return get_FCLK() / 2; case 4: return (readl(&clk_power->camdivn) & (1 << 9)) ? get_FCLK() / 8 : get_FCLK() / 4; case 6: return (readl(&clk_power->camdivn) & (1 << 8)) ? get_FCLK() / 6 : get_FCLK() / 3; } #else return (readl(&clk_power->clkdivn) & 2) ? get_FCLK() / 2 : get_FCLK(); #endif } ulong get_PCLK(void) { struct s3c24x0_clock_power *clk_power = s3c24x0_get_base_clock_power(); return (readl(&clk_power->clkdivn) & 1) ? get_HCLK() / 2 : get_HCLK(); } Тоесть делает что и должна. Щас вчитываюсь внимательно в код. Смотрю что и как может тут реально косяк. Если кто хочет код посмотреть то можно в исходники убута залезть вот ссыочка сразу на файл https://github.com/a1ien/u-boot/blob/master...s3c24x0/timer.c

Так вот что я накопал. Может мне теперь смогут помочь. Вся проблемма начинается аж самой инициализации. Первой сишной функцией которая вызывается является board_init_f она выполняется еше во флеше в ней происходит вся основная инициализация, и таймеров в том числе. Тоесть вызывается вот такая функция. Тут надо обратить внимание на timer_load_val и на timer_clk. Эти переменные оказываются почемуто во флеше. Тоесть напрмер адресс переменной timer_load_val = 0x52600(флеш мапиться по нулевому адресу) И вовремя работы программы они естественно не меняются. А если еще и посмотреть бинарник которые прошиваю(и который создается во время сборки убута) то по адресу 0x52600 мы увидим нашу будующую переменную и притом отличную от 0. Внимание вопрос что я не так делаю. Ведь этот код относиться не к конкретно моей плате и даже не конкретно моему процессору, и код верный. Собственно дальше из-за этого кода все у меня и не работает. Так-как значения переменной равняется в моем случае 0x17 что по логике вобще не врно и естественно дальше все работает соверенно не так. ЗЫ. Переменные обявленны как , int timer_load_val = 0; static ulong timer_clk; Моежт это всетаки косяк. Потому как очень странно выглядит такое обявление глобальных переменных.

Собственно добавляю потдержку в новый u-boot платы mini2440(процессор s3c2440). Неполучается подружить nand flash. Вот что имеем в качестве вывода. NAND: board_nand_init() end of nand_init hwcontrol(): 0xff 0x83 hwcontrol(): 0xffffffff 0x81 raise: Signal # 8 caught raise: Signal # 8 caught dev_ready hwcontrol(): 0x90 0x83 hwcontrol(): 0x00 0x85 hwcontrol(): 0xffffffff 0x81 raise: Signal # 8 caught raise: Signal # 8 caught dev_ready hwcontrol(): 0x90 0x83 hwcontrol(): 0x00 0x85 hwcontrol(): 0xffffffff 0x81 raise: Signal # 8 caught raise: Signal # 8 caught dev_ready hwcontrol(): 0x90 0x83 hwcontrol(): 0x00 0x85 hwcontrol(): 0xffffffff 0x81 raise: Signal # 8 caught raise: Signal # 8 caught dev_ready No NAND device found!!! Как я понимаю проследил в отладке raise: Signal # 8 caught возникет где-то в таймере. Но из-за чего это может быть я незнаю. Может кто наставит на путь истины? Может можно как-то узнать что не так в настройках таймера?

Спасибо большое. Последний нубский вопрос. Допустим стоит задача отлаживать u-boot который я гружу в рам. Я правильно понимаю что моя последовательность дествия такая(допустим использую OpenOCD хотя не принципиально что). То мои действия такие. Я Инициализирую SDRAM и иницализирую MMU и ремаплю таблицу прерываний. Потом заливаю в оперативку u-boot и передаю ему управление. И все должно быть ок. С ядром линукса тоже все будет ок? Он же MMU сам настраивает, как тогда с ним быть?

Но вы же писали что спомощью MMU можно только замапить либо в 0x00000000 либо в 0xffff0000

Ну и куда копать чтобы ядро считало адрес 0x30000000 логическим 0?

Чтобы не плодить тем, так-как вопрос похожий, собственно а как отлаживать приложение в RAM, ведь в рам заливаем по адресу 0x30000000 И по тому же адресу лежит таблица прерываний и соответственно как только у нас будет прерывание произойдет прыжок по 0 адресу а там например режит старая прошивка(или вобще другая прошивка) и получится фиг знает что. Или я чегото не понимаю?

Ясно. Я тоже впринципе спрашиваю ради интереса и чтобы лучше понять. Но видомо тоже запить придется так-как "Жить мешает не сильно".

Собственно пытаюсь разобраться почему? Так-как все происходит очень странно. Плата mini2440 от friendlyarm schematic. Дак вот проблемма в том что если процессор грузиться из NAND то появляется такая бяка(когда грузимся из NOR то проблеммы нету), при этом если вручную в jlink командаре прописать halt то он остановиться сразу(и после ресета из командера по команде "r" он тоже встанет отлично). Собественно непонятно вот что. 1) Подаем питание. Пробуем законектитьться jlink'ом получем Unable to halt ARM core. И проц начинает выполнять то что прошито в нанд 2) проц работает выполняет прошивку из нанда имы выполняем halt и проц нормально стопается. 3) делаем ресет "r" после ресеа проц тоже стопается сразу. Тоесть я просто хочу для себя выяснить почему jlink неможет остановить проц когда он стартует код из нанд

J-link EDU это тотже j-link. Разница только в лицензии. + еще минимум 300р за доставку. и получается по стоимости почти тоже самое, только не офицальное. Какая еще утилита?