Update: uMon is now booting from SD

Ed Sutter edsutterjr at gmail.com
Sat Jul 4 13:50:17 UTC 2015


On 7/3/2015 8:49 PM, Jarielle Catbagan wrote:
> Hi Ed,
>
> On Fri, Jul 3, 2015 at 6:03 AM, Ed Sutter <edsutterjr at gmail.com> wrote:
>> On 7/2/2015 9:27 PM, Jarielle Catbagan wrote:
>>> Hello Ed and all:
>>>
>>> uMon is now booting from SD!
>>>
>>> As Ed has indicated to me, the first reason why uMon did not appear to
>>> boot from SD was that UART initialization was not performed when the
>>> AM335x was booting from memory.  Originally, when uMon was booting
>>> from UART, as Ed has mentioned to me, uMon was working and was able to
>>> use the UART because it appears that the UART was set up already by
>>> the internal ROM code during the UART boot procedure.
>>>
>>> The UART initialization was suppose to be done in cpuio.c.  Ed has
>>> sent me a diff containing the necessary modifications/additions that
>>> has served as the basis for the UART initialization.  After applying
>>> this diff to the current uMon tree, building the uMon image and
>>> transferring the image to an SD card, attempting to boot from SD still
>>> resulted in the BBB to appear to not boot up.
>>>
>>> Ed has mentioned to me that one of the possible reasons why the SD
>>> boot is not coming through could be something that is missing during
>>> the UART initialization like clock management or power control.  This
>>> has prompted me to go back and look through the AM335x TRM,
>>> specifically on the sections regarding the PRCM (Power Reset Clock
>>> Management) and UART modules.
>>>
>>> It turned out that one of the UART0 registers, register MDR1, the
>>> MODESELECT field had the value 0x07 which translates to the UART
>>> module being disabled. Since the UART in uMon is already set up to
>>> work with UART 16x mode, and the value for this mode is 0x00, this was
>>> stored in the MODESELECT field of the MDR1 register.
>>>
>>> After setting this field the uMon image was rebuilt, the GP header was
>>> prepended to the image and was transferred to the SD card as "MLO".
>>> Booting the SD card resulted in uMon being able to boot and to reach
>>> the uMon command line.
>>>
>>> My next steps before proceeding to finish DDR initialization is to
>>> clean up the updated files that perform the necessary UART
>>> initialization and then I will submit the patches that reflect these
>>> changes for review.
>>> _______________________________________________
>>> umon-devel mailing list
>>> umon-devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>
>> Congratulations!  Big step IMHO...
> Thank you!
>
>> This will allow you to experiment a bit more without the need to reboot
>> manually each time.
>> Looking forward to the patches!  I assume you used a FAT formatted SD card
>> to do this?
> Yes, I booted the uMon image from a FAT32 formatted SD card.
>
>> Make sure you put everything in the port directory needed to reproduce this.
>> When you submit the patches I'll push them and then whatever work I did that
>> does not
>> overlap with your patches I'll push up as well.
>> Great stuff!!!  And excellent reporting!!!
>> Ed
> I just finished the patches and I sent them already to umon-devel for
> your review.  Please let me know if there are any inconsistencies with
> the patches and I'll be glad to make the necessary changes in order
> for the patches to meet the specification that you are looking for.
>
> Thanks!
>
> Best Regards,
> Jarielle
>
> P.S. Have a great Independence Day weekend! :-)
>
Jarielle,
I didn't look at the patches yet, but I'm sure there won't be any inconsistencies.  The only
point I was making with reference to me pushing some stuff in as well was to make sure
that we have everything that's been done put into the port for use by folks in the future.
For example, I just happened to take the "raw" mode approach, so I want to make sure
that is in the port, plus I did that LED/GPIO stuff so while its very trivial, its still more to
go into the port for general use.
Thanks for the patches!
Ed


More information about the umon-devel mailing list