›

Flashing Behavior

cybincybin
in LOGI-Bone Discussion
So it was a bit of time since receiving my Kickstarter boards, seeing that everything was working - cool, very cool .... then getting interrupted by other projects and now finally getting back to the back yard and digging up my bones, only to discover that they had changed, not at all the same bones I had buried earlier in the year: Dang and double dang. So "digging" through the forum  I discovered that I needed to run ./install_logibone.sh to update the eeprom. Only to discover that the latest distribution that is running apparently does not have apt-get --Hmm. Better go back and get the latest recommended distribution. ...

So holding down the boot button while applying power, Blue lights, must be loading ... ssh back into the board with Eclipse, boot with ubuntu,temppwd - yep, apt-get OK, run ./install_logibone.sh, OK running, check the log output ERROR -- no eeprom OK on that had removed the logi_bone. So then I pull the SD, attach the logi_bone, and restart expecting to login again as ubuntu -- No joy, I'm back to my previous distribution...

So if I don't hold the boot button I load what's in the on board flash, and with the boot button pressed I load what's on the SD.

Is it possible to update the distribution via the SD card without altering other files within the file system - say stuff I might have put in opt?

Finally my question:

What is the controlling factor that determines when the BBB flash is updated to what is on the SD vs. just booting off the SD and leaving the BBB flash as it was?


Comments

  • jpiatjpiat
    Hi,

    this behavior appeared quite recently as older distribution would just boot from sd card if sd card has a bootloader and fall-back to emmc in case the sd card is not a bootable image. The behavior is now to try to boot from emmc then fallback to sd card ... So the best option right now is to boot the beaglebone-black with no logi-bone on it, then erase the first partition of the emmc (where the bootloader is located) so that the boot process won't try to boot from emmc. There is two options to do so :

    1) brutal option : Boot the beaglebone without logi-bone attached, locate boot parition of emmc (should be mmcblk1boot0, it should contain uboot stuff) and zero it using dd. This is to apply if you don't have a crashed OS on eMMC.
    2) better option :Apply what is advised on http://elinux.org/Beagleboard:Updating_The_Software and just delete the MLO file from the boot parition of the eMMC (boot without sd card, delete MLO, reboot with sd card)

    The first option can be restored by using a flasher image but your are likely to lose your eMMC content. Second option will only require to copy the MLO file back on the filesystem.


  • mjonesmjones
    @cybin

    "and now finally getting back to the back yard and digging up my bones, only to discover that they had changed,"

    I hate when my bones change on me.  Pesky neighbor dogs I'm sure.  
  • cybincybin
    I'm still trying to come to some resolution, opinion, or well considered judgement about how one can best go about the development process in general. In the case of FPGAs its clear that we're going to do the development on a host machine running Webkit for instance. Then, when we have a file to test, transfer it into the BBB. ... and so on. But what about developing a node application. In this case, at least for myself, I edit the BBB files using Eclipse running on my host. Not much of a problem except that for one reason or another I find myself swapping BBB all the time. What would work best would be some way to mirror a set of files that need to reside on both the host and the BBB.

    From what I can read between the lines, it looks like it would be best to have multiple partitions for boot, the soup" distribution" of the day, and work files. Would anyone care to offer an opinion on what might work best as far as managing files spread over multiple systems? I suppose git would be the answer although I confess, it seems a bit odd, to use the cloud to hold everything of interest for a processor that is no bigger than a dime.
  • mjonesmjones
    Hi Cybin,

    Maybe some combination depending on your needs might be cloud(dropbox or other), samba to run your remote BBB files on your PC  and git?

    Most projects that I have worked on have been pretty simplistic, so GCC command line and git and or SCP/FTP GUI (to transfer files) is what I have used.  But, if you are building large projects and need debugging, samba is a nice solution.  If you are not familiar with it, it mounts the BBB drive onto your remote PC.  You can then develop using eclipse (on your PC) using and running your BBB files remotely on teh bone.

    I personally use dropbox alot, though I have not tried to, or know if you can run it on the bone.  Maybe there are some other variants that would be more friendly for this.  Otherwise git a nice solution to manually sync things up.  

    I am sure Jonathan will have some more feedback for you as well. 
  • jpiatjpiat
    Your best take on this is to use a NFS mount on a PC. This way your PC (linux based is best case) can dedicate a directory to host files that can be visible from NFS clients. You then just have to setup NFS on each of your beaglebone-black  so that its configure this directory on your host PC to be part of the BBB filesystem. This way you can access the files from your PC and each time you plug a different BBB you still have access to the same files. The USB on the BBB doubles as an usb ethernet so if the PC you use to connect your BBB also host the NFS you will alway have access to the files. To setup NFS you can follow the direction on :
    https://help.ubuntu.com/community/SettingUpNFSHowTo

    for your PC (if it runs Ubuntu) and for the BBB
Sign In or Register to comment.