jcatbagan93 at gmail.com
Sat Jul 18 16:47:44 UTC 2015
On Sat, Jul 18, 2015 at 8:49 AM, Ed Sutter <edsutterjr at gmail.com> wrote:
> 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) ! :-)
> Meanwhile, I'm just going to let my board soak with the memory test
> "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:
2. SD Host Controller Simplified Specification:
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
> 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
> 2. You'll be able to do upgrades without manually needing to remove th uSD
> That'll be sweet.
Definitely! That would be something to look forward to once MMC is up
> 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.
> On Jul 18, 2015 6:24 AM, "Ed Sutter" <edsutterjr at gmail.com> wrote:
>> 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
>> // 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.
>> umon-devel mailing list
>> umon-devel at rtems.org
> umon-devel mailing list
> umon-devel at rtems.org
More information about the umon-devel