Power - we need a source of 5volt power. I find a 5V, 2A supply with a "fat" coaxial connector that plugs into the BBB.
Serial console - we need a USB to serial dongle with 3.3 volt levels (everything I have uses 3.3 volts, so this is not much of an issue). The pin connections are unique though. We have 6 pins, but only need to connect to 3 of them. If you hold the board so you can read "J1", then pin 1 is to the left and marked with a dot. The pins (L to R) are:
Gnd - - Rx Tx -Somewhere I have a cable all set up for this, but it may as well be on Mars if it isn't in the box marked "BBB". I have a bag with 10 or so SIL2104 USB to serial gizmos, and with short jumper wires proved to boot. Linux detects this as a CP2104 device and sets it up as ttyUSB0, so this ought to work.
On the BBB I connect brown to Gnd, Red to Rx, Green to Tx. We connect this to my dongle (but Red to Tx and Green to Rx).
I connect a network cable also, apply power, and it boots Xinu!
U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53)I cycle power and hit a key and I am at the U-Boot prompt. There is nothing here about booting Xinu. But I remember how this was done back in the day.
This board is now booting from eMMC (though it could boot from an SD card). The way I handled this in the past was that I hacked on the file /uEnv.txt inside the filesystem. In nicer systems, I can modify the U-Boot environment variables and then use "saveenv", but on the BBB, this gives me:
Saving Environment to NAND... Erasing Nand... Attempt to erase non block-aligned dataHappily this has not bricked my board or even violated the setup to boot Xinu.
/dev/mmcblk0p1 on /media/BEAGLE_BONE type vfat ... /dev/mmcblk1p2 on /media/Angstrom type ext4 (rw ... /dev/mmcblk1p1 on /media/BEAGLEBONE type vfat (rw,nosuid ...I do this:
cd /media/BEAGLEBONE
cat uEnv.txt
optargs=quiet
uenvcmdx=echo Booting via tftp (Xinu); setenv saloadaddr 0x81000000; setenv ipad
dr 192.168.0.54; setenv serverip 192.168.0.5; tftpboot ${saloadaddr} xinu.bin; g
o ${saloadaddr}
uenvcmd=run uenvcmdx
So, this is the file I would like to overhaul.
One problem is that host "54" is now one of my routers here at the house,
so I would like to change the IP number. The other is the name of the
executable. And I just had an idea. I could have just put "kyu.bin" into
the file xinu.bin and been able to boot Kyu without fussing with the board,
albeit causing untold confusion in months and years to come. A better idea
is to make this boot a file like "bbb-c.bin" and then make that a link to
whatever I want to boot (kyu or xinu or whatever).
Xinu wants to boot at 0x81000000, but Kyu wants 0x80000000, so that address also needs to be changed.
The file ends up like this.
optargs=quiet
uenvcmdx=echo Booting via tftp (BBBC); setenv saloadaddr 0x80000000; setenv ipaddr 192.168.0.37; setenv serverip 192.168.0.5; tftpboot ${saloadaddr} bbb-c.bin; go ${saloadaddr}
uenvcmd=run uenvcmdx
cd /var/lib/tftpboot ln -s kyu.bin bbb-c.binThis boots and runs (although I never see a console prompt). It displays this line while starting up:
Kyu version 0.8.0 for bbb, Compiled by tom: Sun Nov 4 14:02:15 MST 2018 startingWe clearly need to build a fresh new version of Kyu.
make clean ./config bbb make clean make
It is important to remember that the "config" command installs a Makefile specific to the bbb or orangepi. I get surpisingly few errors, only these missing items at link time:
arm-linux-gnu-ld.bfd: board.o: in function `i2c_error': (.text+0x211c): undefined reference to `i2c_hw_error' arm-linux-gnu-ld.bfd: main.o: in function `sys_init': main.c:(.text+0x210): undefined reference to `console_use_ints' arm-linux-gnu-ld.bfd: thread.o: in function `change_thread': thread.c:(.text+0x20e4): undefined reference to `wang_hook1' arm-linux-gnu-ld.bfd: thread.c:(.text+0x2120): undefined reference to `wang_hook2' arm-linux-gnu-ld.bfd: net.o: in function `kyu_tcp_init': (.text+0x45ac): undefined reference to `tcp_bsd_init' arm-linux-gnu-ld.bfd: tcp_xinu.o: in function `tcp_xinu_init': (.text+0x5c00): undefined reference to `net_timer_hookup'The "wang_hook" things are cruft in thread.c from some of the TCP debugging.
PRI_SHELL is defined in user.c. I have it set to 11 (since the orange pi was using interrupts to receive characters). I think I will set it to 60 and reboot. I also disable "WANT_NET" in kyu.h and rebuild. It tells me "CPU clock 1000 Mhz" (this is from board.c board_init()). I get this disturbing message:
32K timer running at ~ 2420665644 Hz Enabling interruptsThen there is quite a long delay and finally I get the prompt.
Kyu, ready> l Thread: name ( &tp ) state sem pc sp pri Thread: shell (8008e1b0) READY C 8000b59c 80550000 60 Thread: idle (8008e0bc) READY C 800114d4 80552000 1234
Since it boots Debian from eMMC, all I need to do is to create the file /uEnv.txt
(not /boot/uEnv.txt as I explain elsewhere).
I make it look like this:
optargs=quiet
uenvcmdx=echo Booting via tftp (bbb-e.bin); setenv saloadaddr 0x80000000; setenv ipaddr 192.168.0.38; setenv serverip 192.168.0.5; tft
pboot ${saloadaddr} bbb-e.bin; go ${saloadaddr}
uenvcmd=run uenvcmdx
We do this in /var/lib/tftpboot:
ln -s kyu.bin bbb-e.binAnd the reboot now is quite snappy and I am running Kyu in under a second it seems like. So that board C really does need some work.
I reenable WANT_NET in kyu.h, rebuild, reboot and in a flash I am up and looking at:
RAM 505M+ available starting at 806a0000 Kyu version 0.8.0 for bbb, Compiled by tom: Sat Jan 7 09:35:51 PM MST 2023 running Kyu, ready> l Thread: name ( &tp ) state sem pc sp pri Thread: net-in (8008e610) SEM J net-inq 80011824 80558000 20 Thread: net-out (8008e51c) SEM I net-outq 80011cc4 8055a000 21 Thread: net-slow (8008e428) REPEAT C 80017104 8055c000 22 Thread: tcp-input (8008e7f8) SEM J tcp-inq 80011824 80554000 24 * Thread: tcp-timer (8008e704) REPEAT C 800256a8 80556000 25 Thread: shell (8008e9e0) READY I 80006fec 80550000 60 Thread: idle (8008e8ec) READY C 80011d18 80552000 1234 Kyu, ready>Along the way I noticed:
Host info obtained via DHCP My IP = 192.168.0.127, netmask = ffffff00And indeed this is the address I can ping it on. This is in the range of pool DHCP addresses on my network, and entirely OK. The mystery is why the OrangePi build did not do DHCP like this.
I use "t 5" to start up the wangdoodle server on port 114 then I do:
[tom@trona tcp]$ echo 'big' | ncat -v tequila 114 >try.out Ncat: Version 7.93 ( https://nmap.org/ncat ) Ncat: Connected to 192.168.0.127:114. Ncat: 4 bytes sent, 200000 bytes received in 0.07 seconds.The shocker is that the transfer takes 0.07 seconds on the BBB. On the OrangePi it took 1.14 seconds. That is 16 times faster! What is/was wrong with the Orange Pi? My first guess is simply that the OrangePi is running the network at 10 Mbit rather than 100. Either that or there is some drastic problem with the Orange Pi ethernet driver.
Some simple math. We are moving (ignoring all network overhead) 200,000 bytes or 1,600,000 bits in .07 seconds. That is just short of 23 megabits per second. The orange pi was moving the same information at 1.4 megabits per second.
Kyu / tom@mmto.org