WhyCan Forum(哇酷开发者社区)

这帖子可以呀，求大神QQ号

我调了两个月裸机串口 一直直接用论坛的串口驱动代码 后来想了一下不对啊 忐忑了一下 会不会引脚不一样啊 结果一看...

https://whycan.cn/files/members/3/QQ20180819181552.png

太优秀了，只有70个文件.

https://whycan.cn/files/members/3/QQ20180819194823.png

刚刚烧录进去， 串口接上 PE0, PE1, 满屏都是 AAA, 还以为我的串口坏了。

重烧了几次还是一样，

打开 main.c 源码一看，原来是这样:

#include <stdint.h>
#include <stdio.h>
#include <string.h>

extern void sys_uart_putc(char c);

int boot_main(int argc, char **argv) {

    while(1)
    {
        sys_uart_putc('A');
    }
    return 0;
}

可以在 main.c  点亮屏幕吗?

大哥，你的mksunxi.c怎么编译呀？编译后是不是exe文件呀

gui401 说：

@三哥 这个exe文件用来干嘛的？

给编译出来的 spl 加魔术头用的，

brom 会先检查魔术头， 合规才会继续加载 spl 到 ram

主要改动：
1. 从XBOOT剥离出来基本ARCH和Machine的boot代码以及Makefile
2. 修改了mksunx tool，解决了文件小于0x3C00时的BROM checksum错误。
3. 修改link文件增加bootloader section，修改start.S自动计算启动代码长度，这样只加载bootloader到RAM，加快启动
3. 把UART0 TX/RX改为GPIOE1 and GPIOE0， 方便调试

Todo：
1. 增加GPIO，PWM和中断支持，已经有网友实现了，准备加进来
2. 从XBOOT主线同步最新启动代码，主线已经增加了MMU支持（打开I、DCache），并且对启动代码优化了速度

用法：
1. 首先编译mksunxi：make mktool 或者 cd tools/mksunxi && make
2. 编译firmware.bin: make
3. 烧到SPI flash：make write

我遇到的最大的坑是，原来BROM里填的固定加载0x3C00长度，而我的minimal代码总共才1xxx bytes，导致checksum错误。后来用官方的mksunxiboot工具，虽然可以识别BROM但是，一跳到DRAM执行main就reset。一看代码，有个DRAM检查0x5C位置的信息，不知道为什么要检查这个，但估计是mksunxiboot没处理这个导致DRAM没有初始化好。最后还是用xboot的mksunxi改了下终于好了。

另外发现SRAM代码跑得很慢，加载几k代码到RAM用了1xxms，虽然是3M的clock但是发现有很多间隔；后来copy SPI全部代码到DRAM，50M时钟也用了几MS，也有很多等待，平均只有1/3的有效速度。XBOOT似乎发现这个问题，有了更新，我准备试一试。

minmal_f1c100s

@kingmooth 这个用jink调试的方法可以分享一下吗？

主要改动：
1. 从XBOOT剥离出来基本ARCH和Machine的boot代码以及Makefile
2. 修改了mksunx tool，解决了文件小于0x3C00时的BROM checksum错误。
3. 修改link文件增加bootloader section，修改start.S自动计算启动代码长度，这样只加载bootloader到RAM，加快启动
3. 把UART0 TX/RX改为GPIOE1 and GPIOE0， 方便调试

Todo：
1. 增加GPIO，PWM和中断支持，已经有网友实现了，准备加进来
2. 从XBOOT主线同步最新启动代码，主线已经增加了MMU支持（打开I、DCache），并且对启动代码优化了速度

用法：
1. 首先编译mksunxi：make mktool 或者 cd tools/mksunxi && make
2. 编译firmware.bin: make
3. 烧到SPI flash：make write

我遇到的最大的坑是，原来BROM里填的固定加载0x3C00长度，而我的minimal代码总共才1xxx bytes，导致checksum错误。后来用官方的mksunxiboot工具，虽然可以识别BROM但是，一跳到DRAM执行main就reset。一看代码，有个DRAM检查0x5C位置的信息，不知道为什么要检查这个，但估计是mksunxiboot没处理这个导致DRAM没有初始化好。最后还是用xboot的mksunxi改了下终于好了。

另外发现SRAM代码跑得很慢，加载几k代码到RAM用了1xxms，虽然是3M的clock但是发现有很多间隔；后来copy SPI全部代码到DRAM，50M时钟也用了几MS，也有很多等待，平均只有1/3的有效速度。XBOOT似乎发现这个问题，有了更新，我准备试一试。

minmal_f1c100s