Hi!
Based on your feedback,
Here's the next version of the BeagleBoard demo image with a lot of
problems fixed:
Including:
- Filesystem size, format entire partition, this resolves the gnome
errors (Thanks Jason for reporting!)
- Switched to ext3
- Use latest MLO and copy it first into the boot partition (Thanks
Mark Barton for reporting)
- Format boot partition with same size as mentioned in the partition
table to keep bootrom happy (Thanks Vladimir!)
This image has been tested on -xM Rev C but should work on all boards.
You can get this image in 2 simple ways:
1. Direct Download [1]
Once downloaded, please read the setup instructions in the README [2]
on how to write the image to your SDCard
2. Rebuild from scratch
Rebuild instructions can be found in the README [2]
Check out the testlab output to see what new packages have been added
since the last revision [3] and CHANGELOG [4]. Right now testlab
output is quite big because I'm generating it for the first time.
I will try to include a complete a compete package list and not just
the diffs from the next revision.
Let me know how it goes, thanks!
-- Joel
[1] http://www.beagleboard.org/~joelf/images/beagleboard-demo/Angstrom-beagleboard-gnome-image-eglibc-ipk-v2011.09-core-beagleboard-r2.img.gz
[2] http://www.beagleboard.org/~joelf/images/beagleboard-demo/README
[3] http://www.beagleboard.org/~joelf/images/beagleboard-demo/testlab/testlab-r2
[4] http://www.beagleboard.org/~joelf/images/beagleboard-demo/CHANGELOG
in the command line below, dd isn't running as root. try replacing sudo with sudo sh -c " and another " at the end.
On Sep 3, 2011 6:11 PM, "Mark Lee" <marcusant...@gmail.com> wrote:
I do sudo zcat Angstrom-beagleboard-gnome-image-eglibc-ipk-v2011.09-core-beagleboard-r2.img.gz | dd of=/dev/mmcblk0 bs=10and get Permission deniedIs this something to do with mmc?
Mark.
On Sat, Sep 3, 2011 at 3:19 PM, Joel A Fernandes <agnel...@gmail.com> wrote:
> > [This email didn't make it to the beagle list for some reason so I'm > resending it, thanks] > >...
--
So many answers to questions never asked.
--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
I verified this. Thanks.
> - Switched to ext3
> - Use latest MLO and copy it first into the boot partition (Thanks
> Mark Barton for reporting)
> - Format boot partition with same size as mentioned in the partition
> table to keep bootrom happy (Thanks Vladimir!)
>
> This image has been tested on -xM Rev C but should work on all boards.
>
> You can get this image in 2 simple ways:
>
> 1. Direct Download [1]
> Once downloaded, please read the setup instructions in the README [2]
> on how to write the image to your SDCard
>
> 2. Rebuild from scratch
> Rebuild instructions can be found in the README [2]
>
> Check out the testlab output to see what new packages have been added
> since the last revision [3] and CHANGELOG [4]. Right now testlab
> output is quite big because I'm generating it for the first time.
>
> I will try to include a complete a compete package list and not just
> the diffs from the next revision.
>
> Let me know how it goes, thanks!
I've noticed that the startup services don't end with carriage returns
(only newlines) in my minicom view, so it results some funny
indentations.
My biggest issue with this image is that the kernel still does not
work with the BeagleBoardToys ULCD-lite. I think we may have
different definitions of working. Mine includes having all of the
pixels showing up on the screen without wrapping around and using the
LCD driver, ie. defaultdisplay=lcd. Currently, using the LCD driver
causes no display to be enabled.
Automounting of /dev/mmcblk0p1 doesn't seem to be working. Do we need
a udev rule for it?
There are many different warnings that show up in the boot process.
The immediate packages I miss the most are synergy and vnc. Next on
my list would be a native C toolchain.
Now that EDID patches have been submitted to linux-omap, it should be
on our backlog to try integrating them.
Hey, Wait a minute? Did you follow the instructions in the README?
Thanks,
Joel
Sounds good!
thanks
Joel
--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
Can you paste your serial console output?
Joel
I've just boot the R2 on my board and I'd like to share a few comments
from the first run:
1. before loading the kernel, u-boot complains a lot about problems
with i2c bus 1. Is this normal? I have Trainerboard attached to my xM:
------- cut here -------
Texas Instruments X-Loader 1.5.1 (Aug 26 2011 - 21:46:42)
Beagle xM
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2011.06-dirty (Aug 29 2011 - 10:38:55)
OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 512 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Beagle xM Rev A
Recognized Tincantools Trainer board (rev 0 0)
Die ID #65f200001bf00000015739ea07019027
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
SD/MMC found on device 0
reading uEnv.txt
606 bytes read
Importing environment from mmc ...
Running uenvcmd ...
Setting bus to 1
I2C read: I/O error
Error writing the chip.
Setting bus to 0
Loading file "/boot/uImage" from mmc device 0:2 (xxa2)
3363388 bytes read
------- cut here -------
2. startup scripts do not set the time from rtc:
------- cut here -------
new-host-6 login: root
Last login: Thu Jan 1 01:00:31 BST 1970 on ttyO2
root@new-host-6:~# date
Thu Jan 1 01:04:01 BST 1970
root@new-host-6:~# hwclock
Sat Sep 17 00:31:03 2011 0.000000 seconds
------- cut here -------
3. second i2c bus is not detected:
------- cut here -------
root@new-host-6:~# ls -l /dev/i2c-*
crw------- 1 root root 89, 1 Jan 1 01:00 /dev/i2c-1
crw------- 1 root root 89, 3 Jan 1 01:00 /dev/i2c-3
------- cut here -------
4. This request probably is for Koen, but would it be possible to add
driver for rt2870 chipset?
------- cut here -------
root@new-host-6:~# opkg search .\*2870.\*
root@new-host-6:~# uname -a
Linux new-host-6 3.0.4+ #1 Thu Sep 1 17:16:44 CEST 2011 armv7l GNU/Linux
------- cut here -------
regards,
j.
> --
> You received this message because you are subscribed to the Google Groups "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
>
>
--
Given a choice between two theories, take the one which is funnier
Interesting. I wonder what is going on with that I2C bus. Those
commands really don't belong in the boot-up script, so that is
something to clean-up, but it is interesting that the bus isn't
responding.
>
> 2. startup scripts do not set the time from rtc:
> ------- cut here -------
> new-host-6 login: root
> Last login: Thu Jan 1 01:00:31 BST 1970 on ttyO2
> root@new-host-6:~# date
> Thu Jan 1 01:04:01 BST 1970
> root@new-host-6:~# hwclock
> Sat Sep 17 00:31:03 2011 0.000000 seconds
> ------- cut here -------
Seems like a good thing to add to me.
>
> 3. second i2c bus is not detected:
> ------- cut here -------
> root@new-host-6:~# ls -l /dev/i2c-*
> crw------- 1 root root 89, 1 Jan 1 01:00 /dev/i2c-1
> crw------- 1 root root 89, 3 Jan 1 01:00 /dev/i2c-3
> ------- cut here -------
I wonder if this is related to #1.
>
> 4. This request probably is for Koen, but would it be possible to add
> driver for rt2870 chipset?
> ------- cut here -------
> root@new-host-6:~# opkg search .\*2870.\*
> root@new-host-6:~# uname -a
> Linux new-host-6 3.0.4+ #1 Thu Sep 1 17:16:44 CEST 2011 armv7l GNU/Linux
> ------- cut here -------
>
I just built the kernel and I'm seeing this module wasn't built,
despite being build for the 2.6.39 version according to
http://www.angstrom-distributions.org/repo. I'll take a look as I'm
trying to do some kernel updates.
Can you start doing regular rebuilds as the repositories are updated?
Perhaps you can somehow use the existing build servers?
Also, can you include all the specific tags for the repositories such
that things can be rebuilt? With your current layers.txt approach,
not only do you fork people from upstream work, you don't let them
know which particular commit id works. If you want to provide a
layers.txt, include the exact commit ids in that file.
Lastly, can you follow-up on the upstream requests? I know this is a
part-time task for you, but a bit of on-going output is required here.
Automation can be your best friend.
Regards,
Jason
Looks like the errors can be generated by the following lines in uEnv.txt:
lcd1=i2c mw 40 00 00; i2c mw 40 04 80; i2c mw 40 0d 05; i2c mw 40 0d
15; i2c mw 40 0c 25; mw 49056090 10000000
lcd2=i2c mw 40 04 30; i2c mw 40 0c 21; i2c mw 40 04 80; i2c mw 40 04
70; i2c mw 40 04 60
lcd3=i2c mw 40 04 50; i2c mw 40 04 40; i2c mw 40 04 30; i2c mw 40 04 20
What are these commands supposed to do?
>> 4. This request probably is for Koen, but would it be possible to add
>> driver for rt2870 chipset?
>> ------- cut here -------
>> root@new-host-6:~# opkg search .\*2870.\*
>> root@new-host-6:~# uname -a
>> Linux new-host-6 3.0.4+ #1 Thu Sep 1 17:16:44 CEST 2011 armv7l GNU/Linux
>> ------- cut here -------
> I just built the kernel and I'm seeing this module wasn't built,
> despite being build for the 2.6.39 version according to
> http://www.angstrom-distributions.org/repo. I'll take a look as I'm
> trying to do some kernel updates.
Thanks.
One more question, about spi: I can see spi devices in /sys, but there
are no device nodes in /dev. Aren't they supposed to be created
automatically? Or is it a matter of pin muxing?
j.
Sorry for the late reply.
These commands are for LCD. Connecting any other device but the ULCD
panel to the expansion causes these errors. Ideally we'd want to check
if defaultdisplay=lcd and then execute the commands if true. Can you
comment out the i2c commands in the the uEnv.txt on your SD Card?
> 2. startup scripts do not set the time from rtc:
> ------- cut here -------
> new-host-6 login: root
> Last login: Thu Jan 1 01:00:31 BST 1970 on ttyO2
> root@new-host-6:~# date
> Thu Jan 1 01:04:01 BST 1970
> root@new-host-6:~# hwclock
> Sat Sep 17 00:31:03 2011 0.000000 seconds
> ------- cut here -------
Sure will look into this
> 3. second i2c bus is not detected:
> ------- cut here -------
> root@new-host-6:~# ls -l /dev/i2c-*
> crw------- 1 root root 89, 1 Jan 1 01:00 /dev/i2c-1
> crw------- 1 root root 89, 3 Jan 1 01:00 /dev/i2c-3
> ------- cut here -------
No idea why! Devices connected to i2c2 on the expansion such as LCD
panel and camera are working fine. I am not sure but aren't these
device nodes created after a device successfully acquires the bus?
Thanks,
Joel
On Sat, Sep 17, 2011 at 7:49 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
> Joel,
>
> Can you start doing regular rebuilds as the repositories are updated?
> Perhaps you can somehow use the existing build servers?
Ideally we'll want to run through testing, and after adding any
features requested. Are you ok with pushing images just build-tested
from updated repositories (regularly)?
> Also, can you include all the specific tags for the repositories such
> that things can be rebuilt? With your current layers.txt approach,
> not only do you fork people from upstream work, you don't let them
> know which particular commit id works. If you want to provide a
> layers.txt, include the exact commit ids in that file.
I'd rather dump this information into /etc/angstrom-version , unless
its already doing so. Much cleaner no?
> Lastly, can you follow-up on the upstream requests? I know this is a
> part-time task for you, but a bit of on-going output is required here.
> Automation can be your best friend.
Sure.
Thanks,
Joel
Ok I take that back, the camera I'm using cannot acquire the bus:
[ 3.497161] isp_register_subdev_group: Unable to get I2C adapter 2
for device mt9v113
and as for the lcd panel, the i2c commands are issued in U-boot. I
suspect this to be a problem possibly with the i2c driver in the 3.0
kernel we're using. Jason, your ULCD patches are based on the same 3.0
kernel right? and touch screen driver is able to communicate over i2c
right?
Thanks,
Joel
It's a headless system, I don't have anything attached to the display/lcd ports.
Errors disappeared after commenting out the lcd* and uenvcmd lines.
> No idea why! Devices connected to i2c2 on the expansion such as LCD
> panel and camera are working fine. I am not sure but aren't these
> device nodes created after a device successfully acquires the bus?
Second bus is routed to the main expansion connector and the camera,
bus 3 controls the displays. With the 2.3.39 kernel from Angstrom
repository all buses have nodes in /dev and are accessible from user
programs, so I don't think this is caused by a conflict with camera
driver in the kernel. Especially that the camera is disabled in uEnv:
camera=none .
Looks that the kernel detects only buses 1 and 3:
------- cut here -------
root@new-host-6:~# dmesg |grep -i i2c
[ 0.067077] omap_i2c omap_i2c.1: bus 1 rev4.0 at 2600 kHz
[ 0.077239] omap_i2c omap_i2c.3: bus 3 rev4.0 at 100 kHz
[ 3.408142] input: twl4030_pwrbutton as
/devices/platform/omap/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input1
[ 3.419891] i2c /dev entries driver
root@new-host-6:~#
------- cut here -------
j.
Koen just wrote a patch for this [1]. This will do what you're asking
From an easy image rebuild-ability standpoint, the cleanest solution
would be to provide a setup-scripts fork with git-tags for the various
image release versions with the appropriate layers.txt modifications.
This fork should go on a beagleboard.org git repository if possible.
Thanks,
Joel
> Hi Jason,
>
> On Sat, Sep 17, 2011 at 7:49 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
>> Joel,
>>
>> Can you start doing regular rebuilds as the repositories are updated?
>> Perhaps you can somehow use the existing build servers?
>
> Ideally we'll want to run through testing, and after adding any
> features requested. Are you ok with pushing images just build-tested
> from updated repositories (regularly)?
Yes, as long as we are clear when something is tested or not and how. We can automate some testing as well.
>
>> Also, can you include all the specific tags for the repositories such
>> that things can be rebuilt? With your current layers.txt approach,
>> not only do you fork people from upstream work, you don't let them
>> know which particular commit id works. If you want to provide a
>> layers.txt, include the exact commit ids in that file.
>
> I'd rather dump this information into /etc/angstrom-version , unless
> its already doing so. Much cleaner no?
Can you propose a patch?
>