Update: uMon is now booting from SD

Ed Sutter ed.sutter at alcatel-lucent.com
Thu Jul 9 12:07:06 UTC 2015


Jarielle,
At this point, I'd suggest that you deal with DDR and the other BBB stuff.
I'd really rather you tackle the board-specific stuff.  I'll leave it up 
to you,
but I really think your time is better spent on the port itself.
If you agree, then I'll look into this fdisk issue.
Ed
> Jarielle,
> Sorry I didn't get back to you immediately after the push last night.
> I had to leave and didn't get back till after midnight.
> Anyway, yea, I guess there are different versions of fdisk because I
> figured you had a typo in the script.  For me, the '1' is the response
> to the 'a' command.  After issuing the 'a', it asks me what partition
> to apply it to.  Here's part of my fdisk interaction...
>
>     ...
>     Command (m for help): t
>     Selected partition 1
>     Hex code (type L to list codes): 6
>     Changed system type of partition 1 to 6 (FAT16)
>
>     Command (m for help): a
>     Partition number (1-4):  1 <<<<<<
>     ...
>
>
> I'm running with ubuntu 14.04.
> I also found that the path to bash at the top of the script was different.
> The final adjustment I made was to add a few 'sync' commands between
> the mount/umount lines  because for me, the "rm -rf mnt" would fail 
> because
> the device was busy (apparently not quite unumounted yet).  The sync takes
> care of that.
>
> So, not quite sure what to say about this.  The sync is not an issue; 
> harmless if not
> needed; useful if needed so it will work for all cases.  The fdisk 
> issue may just mean we
> need to document the possibility that there are different versions.
> Thoughts?
> Ed
>
>> Hi Ed,
>>
>> Thanks for merging the patches.
>>
>> I just have one question about the latest commit.  The addition of the
>> '1' in the fdisk command is actually resulting in "unknown command"
>> being outputted when fdisk is executing from the script.  I took a
>> screenshot of the script output and I have attached it to this email.
>>
>> Could I be missing something?
>>
>> On Wed, Jul 8, 2015 at 3:59 AM, Ed Sutter<edsutterjr at gmail.com>  wrote:
>>> Jarielle,
>>> Ok, great, just thought I'd save you some typing, but you beat me to it!
>>> The files look excellent!
>>> Ed
>>>
>>>> Ed,
>>>>
>>>> Thank you.
>>>>
>>>> I actually already finished the next set of drafts of the files and
>>>> modified the Makefile to build a uMon image for "raw" mode booting, as
>>>> well as updated the script to provide the ability to setup the SD for
>>>> either "raw" or FAT mode.
>>>>
>>>> By coincidence I also created a configuration header source file when
>>>> I was updating the Makefile in order to build the "raw" mode image.  I
>>>> was able to boot from an SD card using both modes that was set up
>>>> using the script.
>>>>
>>>> The files I updated/created are as follows:
>>>>
>>>> README:
>>>> https://github.com/jrcatbagan/umon/blob/dev/ports/beagleboneblack/README
>>>>
>>>> config_header.S:
>>>>
>>>> https://github.com/jrcatbagan/umon/blob/dev/ports/beagleboneblack/config_header.S
>>>>
>>>> sd-setup.sh:
>>>> https://github.com/jrcatbagan/umon/blob/dev/ports/beagleboneblack/sd-setup.sh
>>>>
>>>> And these are the changes I made to the Makefile to build the image
>>>> for "raw" mode:
>>>>
>>>> https://github.com/jrcatbagan/umon/commit/8246293254e3ce9e37cb8ed314077f35888af58c
>>>>
>>>> Let me know what you think so far about the changes/additions.  If
>>>> they are ready, I'll be happy to send them to you as patches for
>>>> further testing/review.
>>>>
>>>> Thanks.
>>>>
>>>> On Tue, Jul 7, 2015 at 5:40 PM, Ed Sutter<edsutterjr at gmail.com>  wrote:
>>>>> Jarielle,
>>>>> Since I already did it, attached is the cfg_header.S file I used for raw
>>>>> mode.
>>>>>
>>>>> Ed
>>>>>
>>>>>
>>>>> On Jul 7, 2015 4:49 AM, "Ed Sutter"<ed.sutter at alcatel-lucent.com>  wrote:
>>>>>> Jarielle,
>>>>>> Great!
>>>>>> Two (last) minor suggestions...
>>>>>> 1. Mention the script in the documentation file.
>>>>>> 2. In the script you may as well include the final step that you have in
>>>>>> the documentation
>>>>>> for copying the MLO file to the card...
>>>>>>
>>>>>>      cd ~
>>>>>>      mkdir mnt
>>>>>>      ...
>>>>>>      rmdir mnt
>>>>>>
>>>>>> Other than that, it looks good to me.
>>>>>> Good hunting regarding the cluster error issue!
>>>>>> Ed
>>>>> Thanks.  Doc and script are now updated to reflect the minor suggestions.
>>>>> I
>>>>> added a part in the "FAT Mode" section to refer to the script and I added
>>>>> the last remaining steps in the doc to the script.  The links to the
>>>>> files
>>>>> are the same as before.
>>>>>
>>>>> How are the doc and script so far?
>>>>>
>>>>> Just for completeness, I'm going to get the raw mode image built as well
>>>>> with the Configuration Header and GP Header prepended.  I'm thinking of
>>>>> also
>>>>> updating the script even further to allow the user to select whether they
>>>>> would want to format the SD card for "raw" or FAT mode.
>>>>>
>>>>> I'll then send another draft of the files for your review.
>>>>>
>>>>>>> Ed,
>>>>>>>
>>>>>>> Thank you for your suggestions.  I have taken them into account when
>>>>>>> improving the document.
>>>>>>>
>>>>>>> Here is the second draft of the doc:
>>>>>>>
>>>>>>> https://github.com/jrcatbagan/umon/blob/dev/ports/beagleboneblack/README
>>>>>>> .
>>>>>>>
>>>>>>> I have also created a script that automates the process of setting up
>>>>>>> the SD card.  It can be found here:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/jrcatbagan/umon/blob/dev/ports/beagleboneblack/sd-setup.sh
>>>>>>> .
>>>>>>>
>>>>>>> I also looked into the error regarding the situation where there is
>>>>>>> not enough clusters and it turns out that the minimum size for the
>>>>>>> FAT32 primary partition is around 32MB.  FAT16 on the other hand has a
>>>>>>> minimum size of around 3MB.  I was using this document as reference:
>>>>>>> https://staff.washington.edu/dittrich/misc/fatgen103.pdf  .   So I went
>>>>>>> ahead and had the script create the primary partition as FAT16.  I was
>>>>>>> able to boot uMon from an SD card that was setup with this script.
>>>>>>>
>>>>>>> Please let me know what you think about the doc and script so far.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On Mon, Jul 6, 2015 at 5:10 PM, Ed Sutter<edsutterjr at gmail.com>  wrote:
>>>>>>>> Jarielle,
>>>>>>>> Excellent!
>>>>>>>> Couple of  comments...
>>>>>>>> 1. Since you've got so much detail in there, you may want to include
>>>>>>>> the
>>>>>>>> names of
>>>>>>>> the TRM chapter and sections that you reference.  I say this because a
>>>>>>>> later
>>>>>>>> revision may insert
>>>>>>>> a chapter or a section and that will make the chapter/section numbers
>>>>>>>> you
>>>>>>>> have confusing.
>>>>>>>> 2. For raw mode description, in the 'dd' line, change "of=/dev/sdc" to
>>>>>>>> "of=<device>" (where <device> is the sd card).
>>>>>>>> 3. For fat mode description, you may want to add a "dd if=/dev/zero
>>>>>>>> of=<device> bs=1M count=1" as the first step just to
>>>>>>>>         make sure there is no partition table at the base of the SD
>>>>>>>> card.
>>>>>>>> If
>>>>>>>> there is, then the first 'n' in your instructions
>>>>>>>>         may not do what you want.  I know you mention that the card is
>>>>>>>> assumed
>>>>>>>> to not be formatted.  This just
>>>>>>>>         makes sure of that.  So, I walked through your steps, using
>>>>>>>> this
>>>>>>>> to
>>>>>>>> automate:
>>>>>>>>
>>>>>>>> export SDDEV=/dev/sdc  # User should verify this device.
>>>>>>>> sudo dd if=/dev/zero of=${SDDEV} bs=128K count=1
>>>>>>>> echo "n\np\n1\n\n+1M\nt\nc\na\n1\np\nw\n" | fdisk ${SDDEV}
>>>>>>>>
>>>>>>>>         But when I did the mkfs line in your text, it returned an
>>>>>>>> error:
>>>>>>>> Not
>>>>>>>> enough clusters for a 32bit FAT.
>>>>>>>>         So, I just did "mkfs.vfat /dev/sdc1" and that worked fine.
>>>>>>>> Honestly, I
>>>>>>>> don't know the details here,
>>>>>>>>         so if you can investigate this, that would be great.  Suggest
>>>>>>>> adding
>>>>>>>> something like the script above as
>>>>>>>>         a shortcut.
>>>>>>>>
>>>>>>>> 4. For UART boot mode, mention that the uMon image that is transferred
>>>>>>>> is
>>>>>>>> boot.bin, not the MLO.
>>>>>>>>
>>>>>>>> Some other stuff you could add:
>>>>>>>> - To know for sure what device is your uSD card in your linux box, run
>>>>>>>> "cat
>>>>>>>> /proc/partitions" before and after
>>>>>>>> inserting the card and note the difference.
>>>>>>>>
>>>>>>>> Good stuff,
>>>>>>>> Ed
>>>>>>>>
>>>>>>>> Ed,
>>>>>>>>
>>>>>>>> I finished the first draft of the document.  It can be found here:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/jrcatbagan/umon/commit/7f751486d5ca3ba5f6449adf5561df527a5cfde1
>>>>>>>> . Please feel free to give me any suggestions on how I can improve it
>>>>>>>> or if I am missing something.  Once you give the green light, I'll
>>>>>>>> send it to umon-devel as a patch.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On Mon, Jul 6, 2015 at 5:21 AM, Ed Sutter
>>>>>>>> <ed.sutter at alcatel-lucent.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 7/5/2015 6:46 PM, Chris Johns wrote:
>>>>>>>>
>>>>>>>> On 5/07/2015 4:19 am, Ed Sutter wrote:
>>>>>>>>
>>>>>>>> Ok, I managed to get it to boot using only Linux for formatting the
>>>>>>>> card.
>>>>>>>> It wasn't working for me until I just read your email and realized I
>>>>>>>> did
>>>>>>>> not mark
>>>>>>>> the partition active.  After doing that it booted!
>>>>>>>> So here are the steps I walked through
>>>>>>>> (extracted from:
>>>>>>>> http://forum.xda-developers.com/showthread.php?t=502095)
>>>>>>>> :
>>>>>>>>
>>>>>>>> 1. Verify the partition that the SD card installs as:
>>>>>>>>          - cat /proc/paritions (without the uSD)
>>>>>>>>          - Insert uSD card
>>>>>>>>          - cat /proc/paritions (note the difference)
>>>>>>>> Using /dev/sdc as our partition:
>>>>>>>> 2. sudo fdisk /dev/sdc
>>>>>>>>         - delete all paritions with 'd' command (d1/d2/d3/d4) as needed
>>>>>>>>         - use 'n' command to create partition 1
>>>>>>>>         - use 't' command to relabel partition 1 to 'c'
>>>>>>>>         - use 'a' command to make the parition active
>>>>>>>>         - use 'p' to show something like:
>>>>>>>>
>>>>>>>>        Device Boot      Start         End      Blocks   Id  System
>>>>>>>> /dev/sdc1   *        2048     3932159     1965056    c  W95 FAT32
>>>>>>>> (LBA)
>>>>>>>>
>>>>>>>>          - use 'w' to write to the card
>>>>>>>>
>>>>>>>> 3. Run sudo mkfs.vfat /dev/sdc1
>>>>>>>> 4. Mount /dev/sdc1 as /media/boot (or whatever)
>>>>>>>> 5. Copy MLO to /media/boot
>>>>>>>> 6. Run sync; unmount /media/boot
>>>>>>>> 7. Put card in BBB, reset with boot button depressed.
>>>>>>>>
>>>>>>>> A simple request to place in the doco early is to create a root
>>>>>>>> partition only as large as you need and not use whole disk size in the
>>>>>>>> root partition. Users should be encouraged to add other partitions
>>>>>>>> they
>>>>>>>> can mount as read/write to store a kernel and/or user data.
>>>>>>>>
>>>>>>>> Chris
>>>>>>>> _______________________________________________
>>>>>>>>
>>>>>>>> Yep, for sure... my example above was lame...
>>>>>>>> Functionally ok, but not considering the fact that the SD card will
>>>>>>>> have
>>>>>>>> other "stuff".  Also, Chris, IIRC, you mentioned that FAT-booting may
>>>>>>>> not be
>>>>>>>> the right way to go ultimately.  So, for now at least, it will be good
>>>>>>>> to
>>>>>>>> cover
>>>>>>>> both modes of booting until we get a better grip on which approach to
>>>>>>>> take.
>>>>>>>> Jarielle, I can add detail on raw mode to whatever you initially write
>>>>>>>> up
>>>>>>>> if you want me to...
>>>>>>>> Ed
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> umon-devel mailing list
>>>>>>>> umon-devel at rtems.org
>>>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> umon-devel mailing list
>>>>>>>> umon-devel at rtems.org
>>>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> umon-devel mailing list
>>>>>>>> umon-devel at rtems.org
>>>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>>> _______________________________________________
>>>>>>> umon-devel mailing list
>>>>>>> umon-devel at rtems.org
>>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>> _______________________________________________
>>>>>> umon-devel mailing list
>>>>>> umon-devel at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>
>>>>> _______________________________________________
>>>>> umon-devel mailing list
>>>>> umon-devel at rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> umon-devel mailing list
>>>>> umon-devel at rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>> _______________________________________________
>>> umon-devel mailing list
>>> umon-devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>
>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel



More information about the umon-devel mailing list