WhyCan Forum(哇酷开发者社区)

下面的连接脚本，有很多段不是很明白，有大佬能解释一下吗？比如.fini_array ，.ctors，  .dtors

ENTRY( jump_reset )

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 16K
  RAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 2K
}

SECTIONS
{
  .init :
  { 
    _sinit = .;
    . = ALIGN(4);
    KEEP(*(SORT_NONE(.init.jump)))
    KEEP(*(SORT_NONE(.init.vectors)))
    . = ALIGN(4);
    _einit = .;
  } >FLASH AT>FLASH

  .text :
  {
    . = ALIGN(4);
    *(.text)
    *(.text.*)
    *(.rodata)
    *(.rodata*)
    *(.gnu.linkonce.t.*)
    . = ALIGN(4);
  } >FLASH AT>FLASH 

  .fini :
  {
    KEEP(*(SORT_NONE(.fini)))
    . = ALIGN(4);
  } >FLASH AT>FLASH

  PROVIDE( _etext = . );
  PROVIDE( _eitcm = . );  

  .preinit_array :
  {
    PROVIDE_HIDDEN(__preinit_array_start = .);
    KEEP(*(.preinit_array))
    PROVIDE_HIDDEN(__preinit_array_end = .);
  } >FLASH AT>FLASH 
  
  .init_array :
  {
    PROVIDE_HIDDEN(__init_array_start = .);
    KEEP(*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
    KEEP(*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
    PROVIDE_HIDDEN(__init_array_end = .);
  } >FLASH AT>FLASH 
  
  .fini_array :
  {
    PROVIDE_HIDDEN(__fini_array_start = .);
    KEEP(*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))
    KEEP(*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))
    PROVIDE_HIDDEN(__fini_array_end = .);
  } >FLASH AT>FLASH 
  
  .ctors :
  {
    KEEP(*crtbegin.o(.ctors))
    KEEP(*crtbegin?.o(.ctors))
    KEEP(*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
    KEEP(*(SORT(.ctors.*)))
    KEEP(*(.ctors))
  } >FLASH AT>FLASH 
  
  .dtors :
  {
    KEEP(*crtbegin.o(.dtors))
    KEEP(*crtbegin?.o(.dtors))
    KEEP(*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
    KEEP(*(SORT(.dtors.*)))
    KEEP(*(.dtors))
  } >FLASH AT>FLASH 

  .dalign :
  {
    . = ALIGN(4);
    PROVIDE(_data_vma = .);
  } >RAM AT>FLASH  

  .dlalign :
  {
    . = ALIGN(4); 
    PROVIDE(_data_lma = .);
  } >FLASH AT>FLASH

  .data :
  {
    . = ALIGN(4);
    *(.gnu.linkonce.r.*)
    *(.data .data.*)
    *(.gnu.linkonce.d.*)
    . = ALIGN(8);
    PROVIDE( __global_pointer$ = . + 0x800 );
    *(.sdata .sdata.*)
    *(.sdata2*)
    *(.gnu.linkonce.s.*)
    . = ALIGN(8);
    *(.srodata.cst16)
    *(.srodata.cst8)
    *(.srodata.cst4)
    *(.srodata.cst2)
    *(.srodata .srodata.*)
    . = ALIGN(4);
    PROVIDE( _edata = .);
  } >RAM AT>FLASH

  .bss :
  {
    . = ALIGN(4);
    PROVIDE( _sbss = .);
    *(.sbss*)
    *(.gnu.linkonce.sb.*)
    *(.bss*)
    *(.gnu.linkonce.b.*)    
    *(COMMON*)
    . = ALIGN(4);
    PROVIDE( _ebss = .);
  } >RAM AT>FLASH

  PROVIDE( _end = _ebss);
  PROVIDE( end = . );
  PROVIDE( _eusrstack = ORIGIN(RAM) + LENGTH(RAM));	
}

首先介绍一下背景：以下是plan9的故事

例一、替换 CPU

假想一下我们有一台日常使用但性能不佳的笔记本，和一台不在本地但性能强劲的服务器。 我们当然能够使用远程计算机的强劲的 CPU 运行一些计算量特大的程序。这不是什么难事，因为几乎所有操作系统都支持登陆到远程的机器。然而，麻烦的是，如果在远程运行程序需要读写本地的文件，或者访问挂载在本地笔记本上的打印机，扬声器麦克风之类设备，我们除了在本地和远程之间把文件传来传去之外，并没有什么好方法。特别的，如果我们想借用另一台计算机上强劲的 CPU 做音频和视频解码，来播放一个放在本机光盘驱动器里的电影文件的话，我们是不可能指望远程计算机既能读本地的光驱，又能把音频投递到本机的扬声器上的。

Plan 9 中，有一个简单的 cpu 命令，能够让用户自然地使用一个其他机器上的 CPU 运行程序，且仍然能够访问本地的所有文件和设备。也就是说，我们可以用远程计算机上强劲的 CPU 做图像处理，媒体解码等任务，并且可以直接把声音播放到本地的扬声器。cpu 命令给人的感觉，是除了给机器换个了 cpu 外，其他一切都和原来一样。这个看似 “神奇” 的功能，其实在 Plan 9 里实现起来一点都不复杂： cpu 指令首先连接服务器上，然后将本地的所有资源和文件系统，包括窗口管理器，光盘驱动器，扬声器等设备（别忘了他们都是文件），一股脑儿挂载到服务器上，成为服务器上的资源。这样，在服务器上运行的程序，就可以“自然地”使用本地的键盘鼠标和显示器完成交互，还可以访问你本地的显示器扬声器等设备。

cpu 命令真的就是名副其实的换掉了本地计算机的 cpu （其实还有内存）而保留其他一切设备。Plan 9 的这个 cpu 命令，带有强烈的分布式操作系统的特征，而我们平时接触的操作系统都不是分布式操作系统，因此 cpu 这个命令至今在现代主流操作系统上没有完全等价物。

现在这个牛逼的cpu命令移植到了linux系统，它是完全用go实现的。

请看以下简介：
The u-root cpu command
Do you want to have all the tools on your linuxboot system that you have on your desktop, but you can’t get them to fit in your tiny flash part? Do you want all your desktop files visible on your linuxboot system, but just remembered there’s no disk on your linuxboot system? Are you tired of using scp or wget to move files around? Do you want to run emacs or vim on the linuxboot machine, but know they can’t ever fit? What about zsh? How about being able to run commands on your linuxboot machine and have the output appear on your home file system? You say you’d like to make this all work without having to fill out web forms in triplicate to get your organization to Do Magic to your desktop?

Your search is over: cpu is here to answer all your usability needs.
The problem: running your program on some other system
People often need to run a command on a remote system. That is easy when the remote system is the same as the system you are on, e.g., both systems are Ubuntu 16.04; and all the libraries, packages, and files are roughly the same. But what if the systems are different, say, Ubuntu 16.04 and Ubuntu 18.10? What if one is Centos, the other Debian? What if a required package is missing on the remote system, even though in all other ways they are the same?

While these systems are both Linux, and hence can provide Application Binary Interface (ABI) stability at the system call boundary, above that boundary stability vanishes. Even small variations between Ubuntu versions matter: symbol versions in C libraries differ, files are moved, and so on.

What is a user to do if they want to build a binary on one system, and run it on another system?

The simplest approach is to copy the source to that other system and compile it. That works sometimes. But there are limits: copying the source might not be allowed; the code might not even compile on the remote system; some support code might not be available, as for a library; and for embedded systems, there might not be a compiler on the remote system. Copy and compile is not always an option. In fact it rarely works nowadays, when even different Linux distributions are incompatible.

The next option is to use static linking. Static linking is the oldest form of binary on Linux systems. While it has the downside of creating larger binaries, in an age of efficient compilers that remove dead code, 100 gigabit networks, and giant disks and memory, that penalty is not the problem it once was. The growth in size of static binaries is nothing like the growth in efficiency and scale of our resources. Nevertheless, static linking is frowned upon nowadays and many libraries are only made available for dynamic linking.

Our user might use one of the many tools that package a binary and all its libraries into a single file, to be executed elsewhere. The u-root project even offers one such tool, called pox, for portable executables. Pox uses the dynamic loader to figure out all the shared libraries a program uses, and place them into the archive as well. Further, the user can specify additional files to carry along in case they are needed.

The problem here is that, if our user cares about binary size, this option is even worse. Deadcode removal won’t work; the whole shared library has to be carried along. Nevertheless, this can work, in some cases.

So our user packages up their executable using pox or a similar tool, uses scp to get it to the remote machine, logs in via ssh, and all seems to be well, until at some point there is another message about a missing shared library! How can this be? The program that packaged it up checked for all possible shared libraries.

Unfortunately, shared libraries are now in the habit of loading other shared libraries, as determined by reading text files. It’s no longer possible to know what shared libraries are used; they can even change from one run of the program to the next. One can not find them all just by reading the shared library itself. A good example is the name service switch library, which uses /etc/nsswitch.conf to find other shared libraries. If nsswitch.conf is missing, or a library is missing, some versions of the name service switch library will core dump.

Not only must our user remember to bring along /etc/nsswitch.conf, they must also remember to bring along all the libraries it might use. This is also true of other services such as Pluggable Authentication Modules (PAM). And, further, the program they bring along might run other programs, with their own dependencies. At some point, as the set of files grows, frustrated users might decide to gather up all of /etc/, /bin, and other directories, in the hope that a wide enough net might bring along all that’s needed. The remote system will need lots of spare disk or memory! We’re right back where we started, with too many files for too little space.

In the worst case, to properly run a binary from one system, on another system, one must copy everything in the local file system to the remote system. That is obviously difficult, and might be impossible if the remote system has no disk, only memory.

One might propose having the remote system mount the local system via NFS or Samba. While this was a common approach years ago, it comes with its own set of problems: all the remote systems are now hostage to the reliability of the NFS or Samba server. But there’s a bigger problem: there is still no guarantee that the remote system is using the same library versions and files that the user’s desktop is using. The NFS server might provide, e.g., Suse, to the remote system; the user’s desktop might be running Ubuntu. If the user compiles on their desktop, the binary might still not run on the remote system, as the Suse libraries might be different. This is a common problem.

Still worse, with an NFS root, everyone can see everyone’s files. It’s like living in an apartment building with glass walls. Glass houses only look good in architecture magazines. People want privacy.
https://github.com/u-root/cpu
https://book.linuxboot.org/cpu/

看到一份官网开发文档https://doc.zh-jieli.com/AC79/zh-cn/master/index.html，然后在淘宝和b站都有看到官方在普及芯片。芯片性价比真是无敌呀

go和c现在是我工作中的主力语言。go在很多领域发挥了强大作用，那go适合嵌入式吗？当前并不适合，但go具有控制硬件的能力，虽然有些繁琐。
本帖最终目的是在全志f1c100s/200s或者说是arm9系列芯片直接运行go程序，主要是把go runtime移植到arm9上。本帖主要是受github的开源项目https://github.com/icexin/eggos的启发，此项目已成功将go runtime移植到x86上。开篇先建立环境:
虚拟环境是qemu-system-arm
先在上面跑个gnu汇编热热身。
arm.zip

主控stm32G030F6P，6个cd4051用作io选通，6个ad通道轮询读取光敏电阻压降。识别准确率很高，加上遮光片几乎可以100%准确。

当前应用的开发模式逐渐都在web化，无论是从桌面端到移动端，都从本地app转向web开发。具体地说，之前桌面端开发模式主要有delphi、qt、vs等，现在正在向electron、nodejs、渐进式Web 应用（PWA）转移。移动端从android和ios本地应用，逐渐被小程序和轻应用替代。这种种迹象已经表明web正在吞噬一切。而最近几年有一个关键技术备受关注，那就是WebAssembly。web应用的一个最大问题是运行速度，WebAssembly的引入使得web应用速度得到很大提升。而且可以支持多种语言编程编译成WebAssembly。
      从sipeed买了d1的哪咤计算条，看到介绍waft。深入了解发现waft非常有前途，可能是未来iot设备应用的开发形态。ui开发的一个痛点就是定制化，想要灵活多变很耗时间。而web模式的开发就是多变，可以轻松实现定制化需求。最近今年各种小程序层出不穷，但都是基于android或ios的大厂app之上构建。但这种情况正在逐渐发生变化，微信有了小程序硬件框架，阿里有了waft。把小程序的依赖环境从app分离，直接把依赖安装到其他系统或硬件之上，使得小程序可以适用的范围不断扩大。相信不久小程序如果哪一天跑在了串口屏上也不要太过惊讶，这只是未来iot应用开发模式的初级阶段。我们经历了功能机走向智能机，同样在5G技术和万物互联的影响下，又一次技术革命拉开了序幕。

riscv架构发展迅速，riscv芯片日益增多。
汇总一下以备以后选型用。有知道小伙伴请跟贴接龙。

1.esp32-c3，160mhz，乐鑫
2.bl702，144mhz，博流智能
3.ch573/571，南京沁恒
4.w806，240mhz，北京联盛德
5.gd32vf系列，兆亿创新
6.d1/f133-A，全志阿里
7.AB32VG1，中科蓝讯
8.k210，嘉楠科技

mcu型号不限，能够采集3路就行

这参数太猛了，adda都是24位的，dsp核心400mhz。可惜不提供sdk，需要签协议。

32位144MHZ的带浮点riscv架构cpu
蓝牙ble5.0
内嵌512K SPI FLASH，内置rom 192k
132k RAM
自带USB烧录模式
700ma 3.3V LDO
锂电池管理
低功耗可电池供电，pds最低仅15ua左右电流，hbn最低1.5ua
15个GPIO接口
可插面包板
大小仅32mm X 18mm

板子回来了，就等器件。大家猜第一次焊接BGA能不能成功呢?  顺便吐槽一下最近芯片涨价，常用的电源ldo芯片都翻了几倍，什么时候价格才能恢复呀！！！

avr单片机是很经典的8位mcu，因为arduino的火爆，直到现在依然很流行。在8位单片机开创性的引入了32个寄存器，两级流水线，risc结构直接降维打击了同时代的8051。以avr为例，探究一下计算机的本质。研究计算机原理可以看书，也可以做试验。我选择从试验开始，这样更有趣一些。现在做实验简单多了，各种虚拟环境和ide非常丰富。我选择用真机做实验，这样更实用和真实一些。

首先介绍一下用到的工具：
1.atmel studio,主要用它编译和仿真汇编代码
2.硬件，一个avr最小系统，我选择attiny13，研究汇编够用了
3.烧写器usb isp，以及烧写工具智峰下载器
4.avr汇编指令集手册，以及attiny13的手册

开篇上点灯程序：

.cseg 
.org $0
        rjmp start
.org $000A
start:
	sbi DDRB,DDB0
	sbi PORTB,PB0
Loop:
	rjmp loop

机器码对照：

                                 .cseg 
                                 .org $0
000000 c009                              rjmp start
                                 .org $000A
                                 start:
00000a 9ab8                      	sbi DDRB,DDB0
00000b 9ac0                      	sbi PORTB,PB0
                                 Loop:
00000c cfff                      	rjmp loop

hex格式

:020000020000FC
:0200000009C035
:06001400B89AC09AFFCF6C
:00000001FF

flash memery快照：

prog 0x0000  09 c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff b8 9a c0 9a 
prog 0x0018  ff cf ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

hex格式解释：
  数据个数   地址      类型    数据          crc校验
: 00           0000     00     000000...    00

下载器使用hex文件烧录数据到avr，中间经过了解析hex文件的过程。主要是取出机器码并烧录到flash。
avr的汇编格式是：
操作码---操作数/地址/空---操作数/地址/空
整条指令是16位或是32位（32位很少）

avr整个工作过程是，从mcu上电开始，pc指向flash的0地址，开始取指-执行重复下去，直至结束。我们每天使用的电脑办公、手机刷视频，在cpu看来都是一堆01010101。

我们可以用汇编开发mcu，也可以直接用机器码开发。上古计算机就是机器码编程，那时候是没有falsh，直接把01代码用纸带打孔的方式来表示，也就是说纸带相当于falsh。即使现在用机器码开发，比那时候也简单多了，直接在电脑上查询寄存器的地址并转为相应的机器码，然后烧进falsh即可。

首先在线仿真地址：http://tice.sea.eseo.fr/riscv/，选择这个主要是因为比较好玩直观。

这个模拟器是支持gnu的编译器的，所以先安装编译器：

sudo apt install gcc-riscv64-unknown-elf

模拟器gpio寄存器：

点灯程序：

/*
 * Configure the GPIO with:
 * - Byte 0: 8 LEDs
 * - Byte 1: 8 toggle switches
 */

    .text

    .global __reset

__reset:
    j start

start:
    li x1, 0xd0000000
    /* Set first GPIO byte as outputs */
    sb x0, (x1)

    li x3, 0xff
    sb x3, 0x10(x1)
    j .

    .section gpio_config, "a"

leds: .byte 3, 3, 3, 3, 3, 3, 3, 3
sws:  .byte 2, 2, 2, 2, 2, 2, 2, 2

编译文件：

riscv64-unknown-elf-gcc -march=rv32i -mabi=ilp32 -c -o led.o led.s

连接成elf文件：

riscv64-unknown-elf-gcc -march=rv32i -mabi=ilp32 -nostdlib -T rv32e.ld -o led.elf led.o

连接文件rv32e.ld

ENTRY(__reset)

MEM_SIZE    = 4K;
STACK_SIZE  = 512;
BITMAP_SIZE = 1K;

SECTIONS {
    . = 0x0;

    .text : {
        *(vectors)
        *(.text)
        __text_end = .;
    }

    .data   : { *(.data) }
    .rodata : { *(.rodata) }

    __global_pointer = ALIGN(4);

    .bss ALIGN(4) : {
        __bss_start = .;
        *(.bss COMMON)
        __bss_end = ALIGN(4);
    }

    . = MEM_SIZE - STACK_SIZE - BITMAP_SIZE;

    .stack ALIGN(4) : {
        __stack_start = .;
        . += STACK_SIZE;
        __stack_pointer = .;
    }

    .bitmap ALIGN(4) : {
        __bitmap_start = .;
        *(bitmap)
    }

    __bitmap_end = __bitmap_start + BITMAP_SIZE;
}

生成intel格式hex：

riscv64-unknown-elf-objcopy -O ihex led.elf led.hex

最后附上在线仿真器的文档说明：http://tice.sea.eseo.fr/riscv/doc/

现在正在开发阶段，核心功能已完成。主要功能网口和多串口透传数据。
架构组成：
1.vined模块（运行在开发板），可任意扩展
2.vinelookup模块（可运行在开发板或pc），模块注册和发现
3.vineadmin模块（运行在pc），可视化管理，数据展示

硬件构成：任意可运行linux并且带串口和网口的板子
软件：go语言开发，跨平台

路线图和支持特性如下：
1.分布式，可任意平行扩展，模块化管理
2.数据监控，过滤，持久化
3.支持以http，tcp，udp等协议向指定串口透传数据
4.。。。。

测试效果如下，在win10虚拟4个串口，打开两个串口工具分别打开com2和com4，分别向vined模块发送数据，vined建立通串口和网络的透传通道，就可以获取串口数据：

仓库：https://github.com/vineio/vine

在wsl建立了esp32开发环境，顺利编译。