FreeBSD, Electronics and more
Hello everybody,
I received today my RT5350F evaluation board from Olimex and decided to give FreeBSD a try.
The main board have a RT5350 with 32MB of RAM, 8MB of SPI Flash and a wifi antenna.
The evaluation board have two ethernet ports, one USB, two relays, a button, uart pins and some expansions ports.
The first step was to find out what was the default speed of the console, after trial and errors I found that it was 57600 baud.
Running tip -57500 ucom1 got me a "nice" u-boot menu.
U-Boot 1.1.3 (Apr 20 2015 - 13:25:55) Board: RT5350F-OLinuXino DRAM: 32 MB relocate_code Pointer at: 81fb4000 spi_wait_nsec: 42 spi device id: 1c 30 17 1c 30 (30171c30) find flash: EN25Q64 raspi_read: from:30000 len:1000 .raspi_read: from:30000 len:1000 .============================================================= RT5350F-OLinuXino UBoot Version: 4.0.0.0 -------------------------------------------------------------- ASIC 5350_MP (Port5<->None) DRAM_CONF_FROM: Boot-Strapping DRAM_TYPE: SDRAM DRAM_SIZE: 256 Mbits DRAM_WIDTH: 16 bits DRAM_TOTAL_WIDTH: 16 bits TOTAL_MEMORY_SIZE: 32 MBytes Flash component: SPI Flash Date:Apr 20 2015 Time:13:25:55 ============================================ icache: sets:256, ways:4, linesz:32 ,total:32768 dcache: sets:128, ways:4, linesz:32 ,total:16384 ##### The CPU freq = 360 MHZ #### estimate memory size =32 Mbytes Please choose the operation: 1: Load system code to SDRAM via TFTP. 2: Load system code then write to Flash via TFTP. 3: Boot system code via Flash (default). 4: Entr boot command line interface. 7: Load Boot Loader code then write to Flash via Serial. 9: Load Boot Loader code then write to Flash via TFTP.
The FreeBSD source tree have support for RT305X which is very simlilar, so I just build a kernel for this CPU and give it a try.
When I tried to tftpboot it u-boot loads it a 0x80800000 but the kernel config file sets the KERNLOADADDR to 0x80001000. So I copied the file, set the KERNLOADADDR to 0x80800000 and :
... Bytes transferred = 8291343 (7e840f hex) NetBootFileXferSize= 007e840f Automatic boot of image at addr 0x80800000 ... ## Booting image at 80800000 ... Bad Magic Number,7F454C46
After looking at the images provided by olimex, the all start by the same 4 bytes 0x27 0x05 0x19 0x56.
I'll leave that for later and just tried to directly boot the kernel from u-boot :
U-Boot 1.1.3 (Apr 20 2015 - 13:25:55)
RT5350 # tftpboot 0x80800000 /mips/rt/kernel
...
done
Bytes transferred = 8291343 (7e840f hex)
NetBootFileXferSize= 007e840f
RT5350 # go 0x80800100
U-Boot args (from 0 args):
None
Environment:
entry: mips_init()
Cache info:
picache_stride = 4096
picache_loopcount = 8
pdcache_stride = 4096
pdcache_loopcount = 4
cpu0: MIPS Technologies processor v76.150
MMU: Standard TLB, 32 entries
L1 i-cache: 4 ways of 256 sets, 32 bytes per line
L1 d-cache: 4 ways of 128 sets, 32 bytes per line
Config1=0xbea3319e<PerfCount,WatchRegs,MIPS16,EJTAG>
Config3=0x420
Physical memory chunk(s):
0xb13000 - 0x1ffffff, 21942272 bytes (5357 pages)
Maxmem is 0x2000000
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #28 f137e07(master): Wed Jul 22 19:49:53 CEST 2015
elbarto@harlock.staff.bocal.org:/usr/home/elbarto/embuild/build/rt5350/mips.mipsel/usr/home/elbarto/embuild/freebsd.git/sys/RT5350 mips
gcc version 4.2.1 20070831 patched [FreeBSD]
Preloaded elf kernel "kernel" at 0x80b0ce10.
real memory = 33554432 (32768K bytes)
Physical memory chunk(s):
0x00b9f000 - 0x01f62fff, 20725760 bytes (5060 pages)
avail memory = 20328448 (19MB)
ULE: setup cpu 0
random: entropy device external interface
mem: <memory>
null: <full device, null device, zero device>
nexus0: <MIPS32 root nexus>
nvram2env0: base=0xbf030000 sig=0xe5e60a74 maxsize=0x00002000 flags=0x00000003
nvram2env1: base=0xbf032000 sig=0x5a045e94 maxsize=0x00004000 flags=0x00000003
clock0: <Generic MIPS32 ticker> on nexus0
Timecounter "MIPS32" frequency 192000000 Hz quality 800
Event timer "MIPS32" frequency 192000000 Hz quality 800
random: harvesting attach, 8 bytes (4 bits) from clock0
obio0 at mem 0x10000000-0x1fffffff on nexus0
rt305x_sysctl0: <RT305X System Control driver> at mem 0x10000000-0x100000ff irq 0 on obio0
Chip ID: "RT5350 "
SYSCTL_SYSCFG=0x003000
GE0 mode 0
Boot from 0
Bootstrap test code 48
SRAM_CS mode 0
8mA SDRAM_CLK driving
SYSCTL_CLKCFG0=0x40200000
SDRAM_CLK_SKEW 1ns
SYSCTL_CLKCFG1=0x80fb283c
I2S clock is internal 15.625MHz
I2S clock divider 40
PCM clock is internal 15.625MHz
PCM clock divider 60
SYSCTL_GPIOMODE=0x400080
random: harvesting attach, 8 bytes (4 bits) from rt305x_sysctl0
rt305x_ic0: <RT305X Interrupt Controller driver> at mem 0x10000200-0x100002ff on obio0
random: harvesting attach, 8 bytes (4 bits) from rt305x_ic0
gpio0: <RT305X GPIO driver> at mem 0x10000600-0x100006ff irq 6 on obio0
gpio0: Use reset_gpio 10
gpiobus0: <GPIO bus> on gpio0
gpiobus0: <unknown device> at pin(s) 0
gpiobus0: <unknown device> at pin(s) 7
gpioled0: <GPIO led> at pin(s) 8 on gpiobus0
random: harvesting attach, 8 bytes (4 bits) from gpioled0
gpioled1: <GPIO led> at pin(s) 9 on gpiobus0
random: harvesting attach, 8 bytes (4 bits) from gpioled1
gpiobus0: <unknown device> at pin(s) 10
gpiobus0: <unknown device> at pin(s) 11
gpioled2: <GPIO led> at pin(s) 14 on gpiobus0
random: harvesting attach, 8 bytes (4 bits) from gpioled2
random: harvesting attach, 8 bytes (4 bits) from gpiobus0
gpioc0: <GPIO controller> on gpio0
random: harvesting attach, 8 bytes (4 bits) from gpioc0
random: harvesting attach, 8 bytes (4 bits) from gpio0
uart1: <rt305x_uart> at mem 0x10000c00-0x10000cff irq 12 on obio0
uart1: console (115200,n,8,1)
uart1: fast interrupt
random: harvesting attach, 8 bytes (4 bits) from uart1
random: harvesting attach, 8 bytes (4 bits) from obio0
rt0: <Ralink RT305XF onChip Ethernet MAC> at mem 0x10100000-0x1010ffff irq 3 on nexus0
rt0: RT305XF Ethernet MAC (rev 0x00000000)
rt0: use hardcoded 00:18:e7:d5:83:90 macaddr
rt0: bpf attached
rt0: Ethernet address: 00:18:e7:d5:83:90
random: harvesting attach, 8 bytes (4 bits) from rt0
random: harvesting attach, 8 bytes (4 bits) from nexus0
Device configuration finished.
Timecounters tick every 10.000 msec
vlan: initialized, using hash tables with chaining
tcp_init: net.inet.tcp.tcbhashsize auto tuned to 512
lo0: bpf attached
Loader variables:
Manual root filesystem specification:
<fstype>:<device> [options]
Mount <device> using filesystem <fstype>
and with the specified (optional) option list.
eg. ufs:/dev/da0s1a
zfs:tank
cd9660:/dev/acd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /)
? List valid disk boot devices
. Yield 1 second (for background tasks)
<empty line> Abort manual input
mountroot>
Yeah !!!
Then I needed userland, I made a small mfsroot (init, getty, sh, the needed libs and a small /etc/rc) using makefs.
I added the following to my kernel config :
options FFS options MD_ROOT options MD_ROOT_SIZE=4096 options ROOTDEVNAME=\"ufs:md0.uzip\" makeoptions MFS_IMAGE=/path/to/mfsroot.uzip options GEOM_UZIP
Even if for now I don't really need to uzip my mfsroot, it will be needed when using the 8MB flash.
md0.uzip: 252 x 16384 blocks Trying to mount root from ufs:/dev/md0 []... Mounting from ufs:/dev/md0 failed with error 22. Trying to mount root from ufs:md0.uzip []... warning: no time-of-day clock registered, system time will not be set accurately start_init: trying /sbin/init Cannot read termcap database; using dumb terminal settings. # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #29 f137e07(master): Wed Jul 22 20:09:16 CEST 2015 elbarto@harlock.staff.bocal.org:/usr/home/elbarto/embuild/build/rt5350/mips.mipsel/usr/home/elbarto/embuild/freebsd.git/sys/RT5350 mips
The kernel still try to use /dev/md0 first even if I specify md0.uzip, I don't know why.
Now I need to check if every drivers for the RT305X is really compatible with the RT5350.
Also, adrian@ redirect me to the freebsd-wifi-build github page, and ask me to add support for this chip, which I will do later this week.
See you in part 2.