some progress

[Ed Sutter]

That's perfect, cause something in that code isn't complete.
My guess is that it has to do with initialization more fundamental
than the UART itself, like clock management or power control.
When I get this stuff cleaned up I'll send it over.
> Ed,
>
> This is great progress!  Since the time you gave me the diff that
> updates the files up until now, I was mostly walking through what you
> had updated and was working on mostly UART-specific stuff in cpuio.c.
>
> On Tue, Jun 30, 2015 at 8:55 PM, Ed Sutter <edsutterjr at gmail.com> wrote:
>> Jarielle,
>> I made some progress regarding boot from sd...
>> I took a step back and decided to get the LEDs initialized.
>> Doing that allows me to work with a simpler device to verify startup.
>>
>> Anyway, I managed to get the GPIO pins initialized correctly so
>> that I could control the LEDs.  Then I built a SD card with the
>> proper prefixes etc.. in there and was able to boot up the led
>> pattern as expected.
>>
>> That tells me that it boots correctly, but is not initializing the UART
>> as it should. On the other hand, since our UART-boot does work, we can
>> at least say that the code in cpuio.c currently is NOT breaking the
>> uart initialization that the rom-bootloader does for us.  So, my hunch
> I would say so as well.
>
>> is that some clock that drives the UART is not being turned on in our
>> code (but it is turned on when the bootloader is forced to boot through
>> the UART).
>>
>> Anyway, that's my state at the moment.  Done for the night.
>> The one tricky part that I'm glad to have out of the way is the prefix
>> needed at the base of the image.  That wasn't obvious to me.
>>
>> Ed
> Now I am going to try to replicate your approach when trying to get
> UART to work.
>
> I am the one who needs to catch up to you now. :-)
>
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel