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 post if there's a DDR3 test tool which
can be run for an extended test. The guy who's having a similar issue,
implied that his firmware engineers
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/62e31de2-328f-44a5-9ca9-fee4e2260c1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
