Portable issues with BeagleBone Black
I Hope all is well - my apologies for the long post - i could spend a few more minutes making it shorter but i would rather give as many details as possible
I'm revisiting the HAH again as my Livebox kept failing and was eventually chucked in a box to be fixed on a rainy day
I figured the portable build was the way to go as i have a number of raspberry pi units and a BBB sitting around waiting for a valid project.
Mark Baldwin kindly insisted i should go the BBB route as technically its a more powerful device
Following Bretts and Marks Portable / BBB notes i now have the HAH build Build: 313 (SVN - Revision 650 on Ubuntu 14.04 with a REV C BBB - appreciate others are running 12.04 / 13.10
I have set a static IP using interfaces to 192.168.1.12
The Ubuntu 14.04 install is flashed to the eMMC (no SD card required to boot)
1) How do i upgrade to the advertised current firmware 317 or latest beta
with the livebox build i used either of the below
Stable - /etc/init.d/update
Beta - /etc_ro_fs/update-dev hah-beta.dbzoo.com
2) I appear to have a serial comms issue between the GUI and the HAH PCB - i'll do my best to explain below
By default only the console port ttyO0 is enabled on the BBB, if you want to use UART 1, 2 or 4 you have to manually enable.
Adding a cape to \boot\uboot\uEnv.txt is the recommended solution for REV C boards however this did not work for me.
I have however enabled UART 4 using a cape based on the following commands
cd /sys/devices/platform/bone_capemgr then sudo sh -c 'echo BB-UART4 > slots'
The UART is now listed as \dev\ttyO4 there is also an entry for \dev\ttyS4 which i understand is standard linux tty numbering
Kernal debug - dmesg | grep tty gives me the following
[ 0.000000] Kernel command line: console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5 root=UUID=d59b6515-d514-4a8a-95e8-77e8718bc053 ro rootfstype=ext4 rootwait coherent_pool=1M quiet cape_universal=enable
[ 0.000427] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[ 3.553473] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 155, base_baud = 3000000) is a 8250
[ 3.560948] console [ttyS0] enabled
[ 27.826909] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 192, base_baud = 3000000) is a 8250
A bit confusing - have i enabled ttyS4 or ttyO4 or both prehaps?
I have updated my \etc\xap.d\xap-livebox.ini as follows
I have also enabled serial \etc\xap.d\xap-serial.ini
I have also confirmed ttyO4 works by running two SSH connections and wiring TXD to RXD
Heres the issue - The HAH web GUI will not communicate with the HAH PCB in anyway, i.e no relay toggling, no 1wire data - the LCD remains on Booting V3.4 - no IP is displayed.
With that said it appears somethings are working...
If i cat -v < /dev/ttyO4 - do indeed see my 1Wire devices which means everything should probably work correctly? theres HAH PCB data on ttyO4 as required.
1wire 28726B9C0300009E 19.8^M
1wire 28DB8F5C040000D2 21.0^M
Additionally xFX viewer is showing the device present on the network
The 1wire packet is however missing the 1wire information
displaytext=Sensor 1 ?
I suspect the issue is a simple one relating to configuring the HAH to the correct tty04 or S4
Maybe i have missed a file somewhere or i need to setup a Symbolic link between ttyS4 and ttyO4 or vice-versa - i did try this but same issue.
any help or suggestions would be great.
think the key thing you are missing it the initserial=+++ key.
Or do a site search on initserial and you'll get some background.
Why do you need this?
The external hardware goes into a loop and listen on the serial port consuming all the console text the livebox emitted and simply discards it until it see the +++ token. I do this so that some spurious piece of livebox startup text won't trigger the external hardware to do something it should not. This token on the livebox is normally emitted by the /etc/init.d/controlpcb livebox startup script. HOWEVER that script does not exist in the portable distribution as it makes no sense as the HAH hardware is not attached to the console serial port. So we use this initserial= argument as a workaround I should document that on the "portable" wiki as something you MUST do.
As you can see from the livebox HAH firmware the "Booting vX.X" message will remain on the LCD screen until it see's three consecutive +++ characters. This is where you need to focus. If you can open a terminal emulate to the HAH serial port you can drive this manually.
You might try running the xap-livebox in debug mode and see what is going and coming in from the serial port.
This is your problem at this point the xap-livebox program is terminating itself.
[crt][server.c:227:svr_bind] Could not bind to port 79
You must run this as ROOT because port 79 can't be bound from a normal user.
ubuntu@beaglebone:~$ xap-livebox -d 7
The whole xap subsystem must be debugged and ran as root.
ubuntu@beaglebone:~$ sudo su -
Ubunutu is a little shit like that it wants you to do everything as a normal user.
The code should probably check that is root and throw you out if its not instead of failing with a port 79 bind error.
im not sure your AVR is the issue. You seem to be talking to it ok. It's the fact your not binding to port 79 as Brett says. Although I have no ideas why.
Then you have something else listening on port 79 find out what it. As root do this
# lsof -i:79 -P
For example port 80 has the HAH KLONED web server
root@beaglebone:~# lsof -i:80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
kloned 903 root 3u IPv4 5529 0t0 TCP *:80 (LISTEN)
Andrew, have you tried killing off livebox before you run it as debug from the command line?
I'm not really sure. Maybe try altering the following in the xap file in /etc/init.d
subsystem="hub xively livebox iserver web sms serial currentcost twitter googlecal plugboard urfrx mail"
subsystem="hub xively iserver web sms serial currentcost livebox twitter googlecal plugboard urfrx mail"
this is may give other systems chance to boot before loading livebox?
but I'm only guessing now
just noticed in the same file, there is a delay after hub startup. Try increasing that too
/usr/bin/xap-hub $MYDEV > /var/log/xap-hub.log 2>&1 &
That is strange "you have kill xap-livebox and start it up again for things to work !?"
The only dependency xap-livebox has is xap-hub thus its sleep 1 after starting.
In fact everything depends on xap-hub starting first and being operational before they fire up.
I can't see how the serial port would not be ready when xap-livebox starts.
You can try editting the /etc/init.d/xap script and mess around with how it starts up.
if [ `iniget $INI livebox enable 0` -eq 1 ] ; then
/usr/bin/xap-livebox $MYDEV >/var/log/xap-livebox.log 2>&1 &
Put a sleep before the starting of xap-livebox if you think that might help but I don't see how, maybe it might.
After will do no good as nothing depends on xap-livebox being up before it starts.
You can also try putting the -d 7 option in the start_livebox() func and then power cycle so you get in the logs how it looks at system boot time that might help you figure out what is different.
That little tid bit about your serial port slots nicely into why xap-livebox was having startup problems.
There were two issues at play.
1. You did not include initserial=+++ to get the external hardware online.
2. Once you sorted the above out your serial port was found to not be "onlined" when required by xap-livebox on a power cycle.
Looks like you have a workaround and some knowledge of why things where going pear shaped.
I'm not sure about the uboot thing. I'm using a beaglebone original which does have flash onboard.
An it ain't broke so I'm not touching it....
The code in the portable still has a lot of HAH warts. You can ignore this they are actually in sync. in fact sometimes the portable leads the HAH distribution as my livebox board died after a power flucuation and I run purely on portable.