2010-02-22 02:25:37 Remote Update
Louis Ruch (SOUTH AFRICA)
Message: 86288
Hey all,
We are working on a board we developed based on the BF537 Stamp Board. I have successfully built and tested uClinux for the device and it is working great. I was curious if there is some way to be able to perform a remote upgrade of the system. Ideally we will be installing some of these device's in locations far away and would prefer not to have to travel to update the system.
I was thinking of perhaps using the FTP server on the device to send the new uImage to the board and then mounting the flash, and then performing a flash erase and write with the new uImage. I am not really sure exactly how to do this on this board. Any suggestions will be very appreciated. On a Freescale board that I have previously used I would have tried something like mounting the nand flash and perform a nand erase and nand write at a specific section in the flash.
Obviously I will want to script this procedure that a user will be able to copy a new uImage to the FTP server and then send a command (SSH) and it will then automatically erase, write, and restart the board.
Thanks,
Paladin
QuoteReplyEditDelete
2010-02-22 04:14:24 Re: Remote Update
Yi Li (CHINA)
Message: 86309
I think the update precedure is exactly the same for Linux, regardless of what platform (Freescale or Blackfin) you are using.
You may setup ftp server (or tftp), connect with board using ssh ( docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:dropbear) or telnet, or rsh, then update flash.
I would suggest to read the related topics on upgrade software in field in the book "Building Embedded Linux Systems", which covers many details.
-Yi
QuoteReplyEditDelete
2010-02-22 04:16:51 Re: Remote Update
Yi Li (CHINA)
Message: 86310
Link for the book mentioned above: books.google.com/books?id=I-hVqkX6A9cC&printsec=frontcover&dq=Building+Embedded+Linux+Systems&source=bl&ots=auPnk5Ch2n&sig=iXJLVAmBxsrb1RruyURytNrXjiQ&hl=en&ei=BUuCS7_aBI6TkAXpucnTCA&sa=X&oi=book_result&ct=result&resnum=3&ved=0CBEQ6AEwAg#v=onepage&q=&f=false
-Yi
QuoteReplyEditDelete
2010-02-22 15:22:14 Re: Remote Update
Mike Frysinger (UNITED STATES)
Message: 86344
cat new-uImage > /dev/mtdblock1
this has come up a few times in this forum ... you can search to see what other people are doing
QuoteReplyEditDelete
2010-02-26 01:50:05 Re: Remote Update
Louis Ruch (SOUTH AFRICA)
Message: 86567
Hey,
So I have been playing around for a bit with the:
cat new-uImage > /dev/mtdblock1
However it doesn't seem to work, gave a cannot create error I looked a little bit more and found that I only have mtd0 mounted:
root:~> cat /proc/mtd
dev: size erasesize name
mtd0: 01400000 00001000 "ROMfs"
Obviously I would like to see 2 other mtdblocks there, one to store user changes to data. I would also like to get access to the uImage block in the flash from here. I am not sure if this is something I must setup in u-boot: mtdparts? Or if it is something I must do when I build the uImage.
I read one of the documents on blackfin.uclinux website:
docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:upgrading#Linux
at the bottom it speaks about my problem and says:
On a default BF537-STAMP configuration, the drivers and maps are compiled as modules which can be included into the kernel at run time.
I can see a number of *.ko files in the mtd/maps and mtd/nand, etc folders - I have mounted a couple but keep getting the following error:
insmod bf5xx-flash.ko
BF5xx flash: probing 16-bit flash bus
insmod: cannot insert 'bf5xx-flash.ko': No such device or address (-1): No such device or address
What is the procedure I must follow to get this working. Same thing happens with all the modules.
Thanks
QuoteReplyEditDelete
2010-02-26 06:39:21 Re: Remote Update
Mike Frysinger (UNITED STATES)
Message: 86603
the assumption is that you've properly enabled all the relevant MTD device drivers as well as properly configured partitions. that output indicates you havent done either, so review:
https://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:mtd
dont use `insmod` unless you know exactly which order things need to be loaded. use `modprobe` instead.