Eugene Solo

Request for Official STM32 uCLinux port

Discussion created by Eugene Solo on Mar 18, 2017
Latest reply on Nov 8, 2017 by Clive One

Yes, I know, there is a lots of ready and available OSes for STM32 Cortex-M3, -M4 and sometimes -M7. Yes, I know, there is a support of STM32 chips in mainline kernel. Yes, I heard about Emcraft.


Yes, I got my own design of STM32F746 board, loosely based on STM32F7-Discovery: 64 megabytes of 32 bit wide memory (running on maximum available speed); LVDS serializer for TFT LCD port (LCD display will be connected via relatively long cabling and I don't like an idea of 40+conductors in high-speed ribbon cable running thru my box - so I decided to add some extra hardware and reduce wiring to 5 differential pairs plus some little extra); two UARTs (one with RS232 levels, another is pure 3.3V logic) and one "combo" UART (TxD pin was borrowed from one port and RxD from another - sorry, hardware resources are vast but still limited! - routed to RS232 translator too); two SPI ports (one will be used as FPGA uplink, another is spare, it also shares pins with CAN); 16 megabytes of fast QSPI flash (I'm planning to put 32 or maybe 64 megabytes chip.. sometime later); SD/MMC port with external socket; I2C with on-board buffer; 10/100 Ethernet and ruggedized FS USB OTG (since no HS PHY in chip and i don't want to waste precious pins for ugly ULPI bus.. its really ugly!). There is also some special hardware pins available (inputs for timers for two rotary encoders; PWM outputs for LCD backlight and tiny beeper), few spare GPIOs. I'm not counting improvised "reset tree" with external supervisor, I2C FRAM, STLM75 and tiny EEPROM with factory programmed MAC address (yes, I know about 96 bit ID, but still).


This board is not designed to be universal mainboard or perfect evaluation kit, its specialized hardware with special purpose - so there is no standard connectors or sockets, almost every available IOs are routed to pinheaders.


And yes, I got kernel 4.2 up and running. I got Ethernet, I got all ttyS, i got I2C (but stock driver seems to be broken - something with DMA by unclear reasons - so I'm using i2c-gpio driver, it's enough for system checks) and SPI (yet again, experiencing problems with stock drivers - but bit-banging IO works well enough for checks, so I'll leave it be while problem is under investigation).


So here is a real, huge, smelly problem: kernel.


Mainline support is very limited. Even Emcraft (embedded specialists!) kernel is not so good as it could be. Even in latest releases there is no support for STM32' SD/MMC peripheral -- and thats just ridiculous: embedded system with high performance, but without flash storage?.. Seems that USB is not working or "nearly not working" (all I want is to use system in gadget mode.. or plug USB keyboard and USB-SATA converter into system - no luck so far), I2C drivers are not really functional (as mentioned above), there is no QSPI driver, I'm not sure if on-chip RTC is really working (I have external RTC chip with battery backup, it consumes significantly less power from battery -- sorry ST, but your RTC design is bit far from perfect!). I'm struggling to get LTDC working (lack of good documentation for drivers is problem #2: I see kernel report about successfull framebuffer registration, but there is absolutely no signs of life on LTDC pins, no clocks, nothing) - I know that its hardware functional, I've tested it with bare-metal software,... Seems that there is no support for hardware CRC accelerator (could be nice help in networking applications) and crypto core (I'm not using it now but i can imagine situation when it will be really required).. etc, etc. You name it. Struggle and conflict is path of evolution, thus you can achieve something really interesting.. but it takes too long.


In short form: main problem is drivers. Lack of drivers, to be exact. Proven, stable, provided or approved by vendor, with documentation and examples. Something like STM32CubeMx, but built with kernel menuconfig in mind (oh, that will be just perfect! Lots of people will think - "Oh sh.. Wow! OMG!!! Look at that! just look at that! They did it!! They really did it! So be it, we dropping our ****** hardware from N*P, Micr**ip, Ing**enic and even Allw***ner and moving all prods to STM32!").


All we need is official linux port by ST. With fresh kernel and drivers for each and every piece of hardware packed in those beautiful, feature-rich and sometimes pricey, but really nice chips.




P.S. oh, and toolchains too, please. I've succesfully built arm-none-eabihf-gcc-6.3.0 and compiled u-boot and kernel with it, but I failed to build uclibc-ng (so no custom rootfs for me, only the vampirized one). Buildroot still have *NO* support for Cortex-M7 and - look above, got same problems with hardware drivers.


P.P.S just an exact step-by-step instructions "How to build toolchain for uclinux on cortex-m7 and get really working environment" would be very nice too - ready-made toolchain can be good thing for fast deploy, but if you need specific tuning, you need to know what and how can be tuned in your blackbox. Don't forget about caches and FPU enabling routines!


On photo below: my board, early stage of hardware assembly (yes, i did it by my own hands).


P.P.P.S by the way, why EMAC needs external 50 MHz clock when its in RMII mode? We have plenty of PLLs inside chip, including that one dedicated PLL for I2S... so why not add another one circuit to get 50MHz from our main crystal? I dont get it.