Update: uMon is now booting from SD
Ed Sutter
ed.sutter at alcatel-lucent.com
Thu Jul 9 17:05:29 UTC 2015
Jarielle,
Great! Meanwhile, I may push a few changes just to clean up a few
non-obvious things
that are still hanging around in the port/beagleboneblack directory from
the CSB740 port;
so you may see a few patches over the next few days.
Ed
> Ed,
>
> You're absolutely right. Will do! I will continue focusing on the DDR init.
>
> Thanks.
>
> On Thu, Jul 9, 2015 at 5:07 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
>> 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
>>
>> _______________________________________________
>> 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