warning...

[Jarielle Catbagan]

On Sat, Jul 18, 2015 at 8:49 AM, Ed Sutter <edsutterjr at gmail.com> wrote:
> Jarielle,
> Ok, looks good.  I was able to do a full-range RAM test!

Great to hear!

> I pushed everything, including the cpuio.c change and also I
> removed INCLUDE_DM and INCLUDE_PM from config.h because INCLUDE_MEMCMDS
> pulls them all in.
> Good work (again) !  :-)

Thanks!

> Meanwhile, I'm just going to let my board soak with the memory test
> running..
> "mt -vc 0x80100000 0x1fefffff"
> Hopefully I'll come back in few hours and it will still be running!
>
> Next is MMC right?

Yes, I am currently looking into MMC right now.  It's a whole
different world with MMC compared to DDR3.  I hope to get it up and
running within the week or so which also depends on how fast I am able
to comprehend the MMC interface specifications.

For my reference, I am using the following:

1. Physical Layer Simplified Specification:
https://www.sdcard.org/downloads/pls/part1_410.pdf

2. SD Host Controller Simplified Specification:
https://www.sdcard.org/downloads/pls/partA2_300.pdf

and...

3. AM335x TRM, Section 18 "Multimedia Card (MMC)"

I'll first target accessing an SD card and then the onboard eMMC next.
>From what I have looked into so far, the interface to both is
practically similar with some differences on how the AM335x
initializes the interface and how communications take place between
them.

> Two nice features come as a result of the MMC-write capability...
>   1. You can boot from eMMC instead of uSD (so no need to hold down the
> button).
>   2. You'll be able to do upgrades without manually needing to remove th uSD
> card.
> That'll be sweet.
> Ed

Definitely! That would be something to look forward to once MMC is up
and running.

Thanks!

>
> Ed,
>
> Your assumption is right, it should have been cm_clksel_dpll_mpu.  Feel free
> to make the change as part of the push, otherwise let me know if I should
> resubmit the patches.
>
> Thanks.
>
> On Jul 18, 2015 6:24 AM, "Ed Sutter" <edsutterjr at gmail.com> wrote:
>>
>> Jarielle,
>> Just pulled in the patches and built, but there's a warning generated
>> when cpuio.c is compiled...
>>
>> > cpuio.c: In function 'mpu_pll_init':
>> > cpuio.c:286:21: warning: 'cm_clksel_dpll_mpu' is used uninitialized in
>> > this function [-Wuninitialized]
>> >   cm_clksel_dpll_mpu &= ~0x0007FF7F;
>>
>> Without digging in too deep, it looks like a typo.
>> Line 285 should be initializing cm_clksel_dpll_mpu instead of
>> cmclkmode_dpll_mpu...
>>
>>     // Set the ARM core frequency to 1 GHz
>>     cm_clkmode_dpll_mpu = CM_WKUP_REG(CM_CLKSEL_DPLL_MPU);
>>     cm_clksel_dpll_mpu &= ~0x0007FF7F; <<<<<This is line 286
>>     cm_clksel_dpll_mpu |= 1000 << 8;
>>     cm_clksel_dpll_mpu |= 23;
>>     CM_WKUP_REG(CM_CLKSEL_DPLL_MPU) = cm_clksel_dpll_mpu;
>>     cm_div_m2_dpll_mpu = CM_WKUP_REG(CM_DIV_M2_DPLL_MPU);
>>     cm_div_m2_dpll_mpu &= ~0x0000001F;
>>     cm_div_m2_dpll_mpu |= 0x00000001;
>>     CM_WKUP_REG(CM_DIV_M2_DPLL_MPU) = cm_div_m2_dpll_mpu;
>>
>>
>> Assuming you have the same set of tools I have (from RTEMS), then you
>> probably missed
>> the warning because it streamed off your screen quickly (it was at the top
>> of the build
>> output).  To avoid that problem, just pipe all make output to a file...
>>
>> make rebuild 2>&1 | tee make.out
>>
>> Then grep for "arning" in the make.out file or just open the file and
>> check it visually.
>>
>> Lemme know if my above assumption is true.  If yes, I'll just make the
>> change as
>> part of this push.
>> 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