BIOS upgrade 'utility'

140 views
Skip to first unread message

biff...@yahoo.co.uk

unread,
Jan 27, 2013, 5:33:47 PM1/27/13
to Bifferboard
You can now upgrade your BIOS relatively easily (without JTAG).

I suppose I don't need to say this, but I will anyhow: USE ENTIRELY
AT YOUR OWN RISK! This is a convenience utility for people who can't
be bothered to get their JTAG cable out the drawer to try out a new
version of Biffboot. Noobs, please get your friend to do it, and then
blame them when it goes wrong :).

1) Download the image 'upgrade-kernel-rootfs.img' from
sites.google.com/site/bifferboard/biffboot-community-editions
2) flash it to your Bifferboard. It should work on 1, 4 or 8MB
boards.
3) Set kernel command-line to just 'console=uart,io,0x3f8'
4) Boot the image
5) At the console setup a an IP address for the board with e.g.
'ipconfig eth0 192.168.0.66'
6) Now you can ftp your new bootloader to the board (use username
'root', no password to login)
7) Check that you have a device /dev/biffupgrade. It should just
appear after boot.
8) Flash your new BIOS like this:

cat biffboot-000102030405-8M-v3_9rc4_community.bin > /dev/biffupgrade

There are some basic sanity checks on the image before writing it to
flash, in particular you will need to recompile the image if you want
to flash some alternative BIOS, this check looks for the Biffboot
signature. At least it should catch problems such as trying to write
a zipped BIOS image to the flash.

Some kernel messages will tell you how things are going. The flash
should complete in just seconds. If it takes more than about ten
you've probably got a brick. Sorry.

Here is what it just printed for me:
/ # cat biffboot-000102030405-v3_10_community.bin > /dev/biffupgrade
BIFFUPGRADE: Write buffer is full, writing to flash now
BIFFUPGRADE: Sanity check passed, erasing BIOS area
Sector erased in 214673 ticks
BIFFUPGRADE: Writing data, do not switch off until complete
BIFFUPGRADE: BIOS area written. Please reboot.
/ # reboot
/ # umount: can't remount rootfs read-only
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
Restarting system.
machine restart

BIFFBOOT v3.10 000102030405 32-bit Loader by bifferos (c) 2012
Redistribution prohibited, all rights reserved.
Press <ESC>
'help' or '?' for a list of commands
BIFFBOOT> go
Booting...
000F0000 loaded from flash.
Booting Linux with: console=uart,io,0x3f8

Decompressing Linux... Parsing ELF... done.

regards,
Biff.

Razvan Dragomirescu

unread,
Jan 28, 2013, 8:03:48 PM1/28/13
to biffe...@googlegroups.com
Wow! That's very very cool (I'm one of the lazy devs that doesn't have a JTAG and/or a computer with a parallel port). I'll give this a try, it makes interaction with MRT in Taiwan a lot easier :).
 
Good work!
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL



--
--
To unsubscribe send email to bifferboard...@googlegroups.com




biff...@yahoo.co.uk

unread,
Jan 29, 2013, 12:48:47 PM1/29/13
to biffe...@googlegroups.com

I realised a rather trivial change would allow one to also set the MAC address.  Basically, it could take the Bootloader, read it into RAM, change the MAC address, then write it back to flash.  The MAC address would be sent to the board via another device file e.g., /dev/biffmac:

cat mac.bin > /dev/biffmac

So long as I don't have to accept the MAC in the dotted form, it makes it pretty simple.  mac.bin would be exactly 6 bytes long, a binary file.

Would that also help?

regards,
Biff.

Razvan Dragomirescu

unread,
Jan 29, 2013, 12:55:16 PM1/29/13
to biffe...@googlegroups.com
Yes! That would definitely help!
 
(at least it would help us, not sure about everyone else :) )
 
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL


--
--
To unsubscribe send email to bifferboard...@googlegroups.com
 
---
You received this message because you are subscribed to the Google Groups "Bifferboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bifferboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Andrew Scheller

unread,
Jan 29, 2013, 2:04:12 PM1/29/13
to biffe...@googlegroups.com
I was thinking it might be quite nifty (and I might have a go at it
over the weekend if I find the time) to have an integrated all-in-one
python script which would run on a 'normal' PC, and then have this PC
connected to the BB via both ethernet and a USB console cable. And
then you simply tell this python script what MAC you want the target
BB set to, and it would then:
* use bb_eth_upload (or bb_upload as a fallback) to write Biff's new
'upgrade' firmware to the BB
* prompt the user to power-cycle the BB if necessary
* use the serial connection to set an appropriate IP address on the BB
(after it's finished booting)
* set the requested MAC address into a local copy of the 3.10 bootloader
* use the ethernet connection ftp the bootloader to the IP address it
just set the BB to
* use the serial connection to instruct the BB to flash the new bootloader
* use the serial connection to send a reboot command

Should be pretty funky, if I can get it all working together :)
(been a while since I played with BiffBoot-flashing)


Would /dev/biffmac be able to check that the current on-device
firmware is one of the versions that allows the MAC to be changed
simply by writing the new bytes into the bootloader? Or would it
simply need to "assume" that it always is?

Lurch
> --
> --
> To unsubscribe send email to bifferboard...@googlegroups.com
>

biff...@yahoo.co.uk

unread,
Jan 30, 2013, 5:19:16 AM1/30/13
to biffe...@googlegroups.com, ya...@loowis.durge.org

On Tuesday, January 29, 2013 7:04:12 PM UTC, Andrew Scheller wrote:
* use the serial connection to set an appropriate IP address on the BB
(after it's finished booting)

I didn't mention that you can also set the IP address via the command-line, i.e. biffip=192.168.1.45 then you don't need to manually configure the board after boot.  You could set this via the .py script which we already have for setting config block (can't remember its name off-hand).  This way you don't need the serial connection.

The firmware supports telnet, I *think*.  If it doesn't already then I can trivially add that.  The whole thing is based on my buildroot firmware in git which is a kind of swiss-army-knife for 1MB (or greater) devices.  It is based on kernel 2.6.37.6 and buildroot 2011.11, and since the kernel supports module loading you can easily turn the board into a webcam (or anything else), with the important stuff loaded from some server on the network.

See here for more details:
https://github.com/bifferos/bb/tree/master/buildroot

The really cool thing about that (IMHO) is that you can trivially add OpenWrt pre-compiled packages to the firmware in the form of 'applications'.  An application is just a tarball that you put on the network somewhere, and reference via the kernel command-line.  It has a runscript inside it.  So long as you have a webserver to host the 'application' you can get pretty much *any* OpenWrt package running on a 1MB device, just by dropping the package files into a directory at build time.

If you want to build all that with my kernel module added you will need to copy the module source from the Biffboot page, put it under the drivers directory then modify the appropriate kconfig and Makefile to include it in the kernel.  I've deliberately not provided Kconfig and Makefile because I don't want people compiling their own versions unless they know what they're doing.  It's a trivial change though.
 
* set the requested MAC address into a local copy of the 3.10 bootloader
* use the ethernet connection ftp the bootloader to the IP address it
just set the BB to
* use the serial connection to instruct the BB to flash the new bootloader
* use the serial connection to send a reboot command

 
You can run those same commands over a telnet session instigated by the pexpect Python extension, alternatively you can use the python telnet module itself.
 
Should be pretty funky, if I can get it all working together :)
(been a  while since I played with BiffBoot-flashing)


Would /dev/biffmac be able to check that the current on-device
firmware is one of the versions that allows the MAC to be changed
simply by writing the new bytes into the bootloader? Or would it
simply need to "assume" that it always is?

I was going to make it dumb.  However I don't think changing the MAC for Biffboot versions that don't support it will cause any problems.  They'll just keep their old MAC address.

 
Lurch

regards,

Biff.

Reply all
Reply to author
Forward
0 new messages