-
Notifications
You must be signed in to change notification settings - Fork 0
On iMX23
Recently, whilst tidying up my stuff after moving into a new house, I found this Olinuxino Mini and that iMX233 EVK board. Both are built with iMX233 SoC which comes originally from Freescale what had later become NXP. (I should have said 'came' since iMX233 SoC is officially obsolete and discontinued since 2019.)
[!TIP] For less patient readers: here is my Buildroot for imx23 branch which includes all patches I made to provide better support for iMX23 platform. I hope it might be interesting for someone who is counting out options to upgrade an old devices fleet.
Initial search on the internet brought me to OpenWRT iMX233 Olinuxino page. The first impression was less than great. I would have expected mature SoC platform, but looking at what is under 'Working' turns out that only USB and LAN (attached to USB, BTW) work. Everything else - might or might not work, hmm... To jump ahead: I've just wanted to play a bit with a very cool DirectFB2 project and LCD attached to iMX233 EVK to see what DirectFB2 could be useful for, but... Well, it's open source, so save help yourselves!
Next stop to check for board support was Buildroot. Buildroot includes configuration files for both boards. Having enough experience with Buildroot I forked it into https://github.com/xaelsouth/buildroot/tree/feature/imx23, cloned and then kicked off the build process:
make O=output/imx233_olinuxino olimex_imx233_olinuxino_defconfig && cd output/imx233_olinuxino && make -j$(nproc)
make O=output/imx233_evk imx23evk_defconfig && cd output/imx233_evk && make -j$(nproc)Few coffee cups later I was presented with sdcard.img - one for each board - ready to write to SD card. iMX233 readme and Olinuxino readme will explain that better than I would ever be able to do. The only difference is that Olinuxino uses micro SD card vs. iMX233 EVK wants SD card.
According to the schematics Olinuxino Mini does not exactly have a lot hardware, what could have been tested after booting from uSD card:
- works: uSD card/SPI, USB host, RTC with watchdog, GPIO
- does not work: line in, line out, composite video/TV-out
- untested: JTAG, PWM, I2C, DCP (crypto hardware), LRADC (analog to digital converter)
In terms of hardware the iMX233 EVK is way more interesting. According to the schematics (SPF_77066.pdf), the board has 8-bit NAND, UART, ENC28J60 SPI Ethernet, SD card, array of buttons, LCD, I2C devices (ADC, accelerometer, 24LC128 EEPROM), two PWM controlled LEDs. 128MB RAM (yep, MB!) is quite cool too.
After booting from SD card the LCD will immediately light up, which means that LCD and PWM used as LCD backlight work.
Sad, but SPI Ethernet is multiplexed with uSD card and can work only if booted from USB or NAND.
Application UART works, so at least we could SLIP at no less than 115200 bps or approx. 10KB/s 😒.
While trying to test accelerometer and EEPROM sitting on I2C bus, I quickly realised that using SD card for development with plugging/unplugging really sucks. I had considered ordering of USB SD MUX and even its price, approx. 120€, didn't go down the wrong pipe, but I would probably have been waiting several days or maybe weeks until the package arrives! Anyway, since the board supports booting from USB I would rather use it this way. Unfortunately, due to the old hardware and not very well maintained drivers and tools I ran into a whole bunch of issues which I will be describing below.
According to the Linux BSP guide, iMX23 ROM loads so called bootstream from via DIP switch or OTP fuses configured boot media to perform hardware initialisation and to finally boot Linux. Bootstream is usually split into multiple bootlets: one will initialise power supply, next one clocks and RAM, third one optionally creates ATAGS for the Linux kernel command line. Even the Linux kernel will be considered as bootlet. Bootlets can be found in the Buildroot tree boot/mxs-bootlets. When using mxs-bootles the boot sequence is as follows:
- power_prep for power supply initialisation
- boot_prep for clock and RAM initialisation
- optionally: U-Boot (proper). Can be used to load device tree, initial ramdisk - if applicable, and Linux kernel from any media and finally boot into
- alternatively: directly boot Linux kernel with included initial ramdisk and attached device tree. Linux kernel command line should preferably be written out as bootargs in the device tree, but can instead be compiled into the Linux kernel statically.
[!NOTE] Should one want to use mxs-bootstreams, don't forget to tweak CPU clock somewhere after RAM initialisation. Otherwise, the CPU would be clocked at 227MHz instead of 454MHz. I think the old 2.6 kernel changed the clock automagically, but newer ones, and I'm talking about 6.6.x, don't.
[!NOTE] Using mxs-bootlets makes sense if long-term proven old bootlets for power and RAM initialisation have to be preserved.
Although mxs-bootlets work with iMX233 EVK board, using them does not make much sense since U-Boot replaces bootlets with its own implementation. In that case bootstream will include exactly two bootlets as they are, for example, being used to boot from SD card:
- U-Boot SPL for power and RAM initialisation
- U-Boot (proper) to boot Linux
Now enough about bootstreams and their alternatives. How to use them for USB boot?
Windows user might be considering sb_loader. Don't know how or whether it works, sorry.
Linux users can use sb_loader