Thanks for the replies guys. I don't seem to have the board-am335xevm.c
file in my kernel sources (grabbing them this
way<http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Availability:>or
this
way <http://beagleboard.org/linux>) so I can't really make the appropriate
modifications. I've found the board file online, but is there a specific
kernel source I should use that already includes that file? And if I
download the file and make the appropriate modifications, will the kernel
build process even do anything? I'm guessing I would need to specify
am335xevm as the target or something to that effect? I've never built the
Linux kernel before so this is all pretty new to me.
Thanks,
On Wednesday, February 19, 2014 2:06:15 AM UTC-7, lisarden wrote:
>
> hacking the kernel to pretend EEPROM contains my board id
>
> diff --git a/arch/arm/mach-omap2/board-am335xevm.c
> b/arch/arm/mach-omap2/board-am335xevm.c
> index 3f17cf8..aad2738 100644
> --- a/arch/arm/mach-omap2/board-am335xevm.c
> +++ b/arch/arm/mach-omap2/board-am335xevm.c
> @@ -4287,13 +4287,21 @@ static void am335x_evm_setup(struct
> memory_accessor *mem_acc, void *context)
> if (ret != sizeof(config)) {
> pr_err("AM335X EVM config read fail, read %d bytes\n",
> ret);
> pr_err("This likely means that there either is no/or a
> failed EEPROM\n");
> - goto out;
> + //goto out;
> + {
> + char ar[] = {0xaa, 0x55, 0x33, 0xee, 'A', '3',
> '3', '5', 'U', 'S', 'O', 'M', 0};
> + memcpy((char *)&config, (char *)&ar, sizeof(ar));
> + }
> }
>
> if ((config.header != AM335X_EEPROM_HEADER) && (config.header !=
> BONEA2_EEPROM_HEADER)) {
> pr_err("AM335X: wrong header 0x%x, expected 0x%x\n",
> config.header, AM335X_EEPROM_HEADER);
> - goto out;
> + //goto out;
> + {
> + char ar[] = {0xaa, 0x55, 0x33, 0xee, 'A', '3',
> '3', '5', 'U', 'S', 'O', 'M', 0};
> + memcpy((char *)&config, (char *)&ar, sizeof(ar));
> + }
> }
>
> /*
>
>
>
> 2014-02-19 8:27 GMT+04:00 Jason Kridner <[email protected]<javascript:>
> >:
>
>>
>>
>>
>> On Tue, Feb 18, 2014 at 7:07 PM, <[email protected]
>> <javascript:>>wrote:
>>
>>> Hey guys,
>>>
>>> I'm working on a project which is using a clone of the BBB hardware and
>>> I'm running into some issues with Device Trees. I wasn't involved with the
>>> hardware design, but as far as I know, the BBB hardware has been duplicated
>>> exactly. Specifically, the clone board will be directly connected to an LCD
>>> using the LCD data pins on the AM335x. I've never worked with Device Trees
>>> before, but after some initial research (mostly based on this
>>> summary<http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview>)
>>>
>>> I'm thinking that they are the best way to accomplish what I'm looking for
>>> (enabling the LCD pins and configuring the driver to use them). I'm not
>>> concerned about the details of implementing this right now, since I'm
>>> having issues with Device Trees in general that I need to address first.
>>>
>>> The board is booting from an SD card with two partitions: one for U-boot
>>> and one for the Angstrom (v2012.12 with 3.8.13 kernel) image, both of which
>>> are the standard images which ship with the Beaglebone. I'm not having
>>> problems getting the board to boot. It has no problem running U-boot and it
>>> can start Linux without any catastrophic failures using the default images.
>>> Once Linux boots, if I go to /sys/devices/bone_capemgr.8, there are all the
>>> files you'd find on a regular BBB *except *slots and the slots-* files.
>>> As far as I know, without these files I can't add or modify device trees
>>> for the board. I still could by rebuilding the kernel I suppose, but as far
>>> as I know this is a deprecated approach.
>>>
>>> Here's a pastebin showing the serial output of the clone while it
>>> boots<http://pastebin.com/ZBmatVgk>
>>>
>>> I only have a basic understanding of U-Boot, so the output during the
>>> boot sequence doesn't help me to much, but here are the main things I've
>>> noticed while skimming through it:
>>>
>>> 1. Right at the start of the SPL process, the magic number check in
>>> EEPROM fails. This makes sense since the cloned board has a blank EEPROM.
>>> I'm not sure if this is a problem, but the assumption in the next lines
>>> (Beaglebone LT/Black.musb-hdrc) seem to work. The board is able to get past
>>> the SPL stage so I'd figure that this assumption is accurate enough.
>>>
>>
>> There are some rather basic configuration components that require board
>> detection to work. I suggest you hard-code it in the SPL/u-boot or program
>> the EEPROM.
>>
>>
>>>
>>> 2. The main U-Boot process also checks the EEPROM and fails the ID
>>> check. There is no reassuring message this time ("Assuming Beaglebone" or
>>> something to that effect) so I'm not sure if this is a larger problem.
>>>
>>> 3. The PHY initialization fails. The only hardware difference I know of
>>> between the clone and the BBB is the PHY, so this isn't very surprising.
>>> I'm pretty sure the PHY uses a different address so I'll deal with this
>>> when it becomes an issue.
>>>
>>> 4. The uEnv.txt is being read. I originally thought this might have been
>>> a problem, but if I modify uEnv.txt U-boot reports the correct file size.
>>> In this example I'm just using the default one though.
>>>
>>> 5. U-boot mentions the device tree addresses, but I don't know if there
>>> is any significance to this.
>>>
>>> 6. While booting the kernel, U-boot throws some bone-capemgr errors
>>> relating to the EEPROM. This makes me think that the EEPROM failure might
>>> be messing up the device tree configuration through bone-capemgr but I'm
>>> not sure. There are also some GPIO mux errors but I'm not sure that they
>>> really matter for my problems right now.
>>>
>>> That's all I've got right now. As I said, this is my first time working
>>> with anything related to the BBB and I don't really have any experience
>>> with U-Boot, so unfortunately I'm mostly relying on support from you guys
>>> at this point. If you need any more information just let me know.
>>>
>>
>>> Thanks,
>>>
>>> --
>>> 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] <javascript:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>> --
>> 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] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
> Company - http://www.linkedin.com/company/mentorel
> Facebook - https://www.facebook.com/mentorel.company
>
--
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].
For more options, visit https://groups.google.com/groups/opt_out.
