Hey Robert,
The EEPROM is mostly board ID, serial number, and Ethernet MAC addresses
right? There isn't anything which is DRAM-specific in EEPROM, right?
My understanding is the EEPROM contains the board ID which u-boot-spl and
u-boot use to customize the configurations for each specific board... I
understand that most of the board-specific changes are contained in the
board.c file, but I'm wondering if there are other critical configurations
in the /arch/arm/mach-omap2 directory. I also added some configurations
for our custom board type to the Kconfig in the mach-omap2 directory. This
looks to be menu options for a makemenuconfig GUI like for the kernel??
Have asked the TI folks on the above-referenced E2E post if there's a DDR3
test tool which can be run for an extended test.
The guy on E2E who's having a similar issue, implied that his firmware
engineers already tuned the IO Delays. Maybe it's something else??
I wonder who the people are who actually derive the IO delays (e.g. the
GDELAY equtions) and tune them for boards like the BB-X15.. How does that
process work?? Maybe that's in TI's SPRAC44 ap note.. I still wonder, how
do you know when you've hit the sweet spot in terms of the optimum values??
This doesn't appear to happen very frequently, but it's probably prudent to
get a handle on what makes it crop up..
On Wednesday, March 21, 2018 at 10:55:59 AM UTC-5, Jeff Andich wrote:
>
> Hi Robert,
>
> We've copied the 572x EVM, reva3 schematic as closely as possible, but
> then added some peripherals.
>
> Our custom board is utilizing 4, Micron, MT41K256 512 MiB DDR3 chips for
> DDR3. I believe this is on Gerald's BOM for the BB-X15.
>
> Right now our EEPROM is blank. My strategy, for the time being, has been
> to ignore the blank EEPROM for now and fool/hard-code the test of the board
> type to always return true for our custom board.
>
> Then I added extra conditionals, where board type is tested, to all/most
> of the routines in board.c.
>
> When the routines in board.c test positive for our custom board type, we
> "mostly" follow the same path that was followed for the BB-X15 in an "older
> version" of the 2017.01 u-boot/u-boot-spl. The major difference is we're
> loading our own arrays for pad configuration and iodelay in
> recalibrate_iodelay in board.c. These arrays were obtained from the TI
> pinmux tool and pinmux design for our board.
>
> I have not tuned the IOdelay values from the pinmux tool to account for
> any differences in timing between the address and data lines to the DDR3 on
> the BB-X15 vs. our custom board.
>
> void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
> {
> .
> .
>
> if ( board_is_am572x_custom() )
> *dmm_lisa_regs = &beagle_x15_lisa_regs;
> .
> .
>
> }
>
>
> Thanks!!
>
>
> On Tuesday, March 20, 2018 at 8:03:55 PM UTC-5, RobertCNelson wrote:
>>
>> On Tue, Mar 20, 2018 at 7:23 PM, Jeff Andich <[email protected]> wrote:
>> > I cross posted in the TI E2E thread referenced below, since someone
>> else
>> > encountered this issue.
>> >
>> > One thing which comes to mind is, even though our custom board is based
>> on
>> > the BB-X15/572xEVM, I have not yet "tuned"/re-computed the IO delays
>> for
>> > u-boot-spl for our custom board. Rather, I'm re-using the default IO
>> delays
>> > from the TI pinmux tool (or from the u-boot for the BB-X15).
>> >
>> > The TI support engineer indicated that "weird things could happen, in
>> > certain cases if you don't tune the IO delay values for your custom
>> board."
>> >
>> > Wonder if this is the next, best place to look???
>>
>> Hi Jeff,
>>
>> What eeprom value did you program? and did you mirror the memory from
>> teh x15 design?
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/dfd417ce-e549-4c4e-9fd5-5a35cbf4346f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
