India BeagleBoard Workshop - Bangalore

Today is the first day of a 3-day Beagle Workshop in Bangalore India.

The purpose of this posting is to give something for my participants to reply to.

Enjoy…

–Mark

hi all
beagle board xm rev c with linux kernel 3.4.0 running (sd boot)

arm9-mini2440.blogspot.in
http://www.youtube.com/watch?v=zJVJ9gXj3Wk&feature=plcp

working on bsp for lcd on same kernel.

best wishes
Phanirajkiran.
Embedded Software Labs
mprk@embeddedsoftwarelabs.com
India.

Hello, Good time combining the Audio Capture and Play. We would like to hear more from you on Kernel, Cross compiling issues and tips and techniquest for developing Device Drivers and Kernel modules. Thanks

Hello Sir,
I have recently started working with the BB-xm. Can you upload some videos or blogs for those who were not able to attend the workshop?

Thanks!!

We've built our own custom XM3359 board and all is working well EXCEPT the thing powers up as if it is being powered by USB (500MHz processor speed). I guess this question is for those familiar with the initial Linux boot code that checks with the TPS65217b to determine the power source. We basically duplicated the schematics from the Beaglebone. I am running Linux 3.2.18 but have tried 3.2.14 with the same results. If I plug the uSD card into a standard Beaglebone the unit boots up with the proper speed. So, if anyone has any pointers as to where I can start digging around in the kernel to force the unit to boot up at full speed, I would appreciate them.

Thanks,
Ross

Snippet from the reduced speed boot up (our custom board)

On your board do you have both USB and DC power supplied to the TPS65217B?

Gerald

Initially 5V only to pin 10 (AC) but have added pin 12 (USB), so yes, both pins are supplied from the 5V source. If there is no load on Sys1_out and Sys2_out will that cause a problem and confuse the TPS? We didn’t use those outputs, but rather just feed everything from our main 5V and just hung a 10uF cap to gnd on the Sys1/2_out pins.

Thanks,
Ross

I would remove the one for the USB. Just have DC. The PMIC may be defaulting to USB. So if you ar enot using the SYS pins, what are you using to power the switchers and the LDOS in the PMIC?

Gerald

We have our board configured similar to Figure 18, right side in the TPS65217 data sheet (SLVSB64D - November 2011, revised April 2012) but we didn’t tie the two bat inputs and bat sense to the 5V supply nor did we pull the TS line to gnd via 10k AND we did feed 5V into the AC pin. We should probably clean that up to better match the data sheet.

What do you think?

Thanks,
Ross

OK. Batt is not required, but SYS is, that is the output from the AC or USB inputs. So, I am not sure why it isn’t defaulting to 720MHz. All that is done is that it reads the register and acts accordingly.

The next possibility is that there is an I2C issue of some kind. Have you checked to see if there is any data on the I2C from the AM335x and the TPS65217B? Are you able to read the registers from UBoot?

Gerald

Understood, leave the AC line connected to the 5V so there is output on the SYS lines.

Next determine if my I2C is working by reading the TPS registers from uBoot.

Just hooked up everything, AC pin connected to 5V, USB pin disconnected. Ran i2c probe from uBoot and got “valid chip addresses: 24”. Haven’t played with uBoot much so I’ll do some reading to figure out how to read registers unless you have a quick cheat sheet.

Thanks again,
Ross

Okay, can anyone help me figure out the key to using the i2c command in uBoot.

Usage:
i2c crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
i2c dev [dev] - show or set current I2C bus
i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device
i2c md chip address[.0, .1, .2] [# of objects] - read from I2C device
i2c mm chip address[.0, .1, .2] - write to I2C device (auto-incrementing)
i2c mw chip address[.0, .1, .2] value [count] - write to I2C device (fill)
i2c nm chip address[.0, .1, .2] - write to I2C device (constant address)
i2c probe - show devices on the I2C bus
i2c read chip address[.0, .1, .2] length memaddress - read to memory
i2c reset - re-init the I2C Controller
i2c speed [speed] - show or set I2C bus speed

I just want to read register values from the TPS65217. All I seem to be able to generate is this message:
“Error reading the chip.”
And this is on a good working Beaglebone.

Thanks for any help here.
Ross

Never mind, I finally figured it out

i2c md 24 xx (xx being the starting address)

Thanks,
Ross

Gerald,

This is what I know now. I am able to get the proper ID value from the TPS65217b (0xF1), the power path also looks okay (0x3D) and the status byte shows the correct status (0x08). So, at the uBoot stage everything seems correct, but once Linux starts booting, something gets confused. Do you or Jason know what module(s) this initialisation occurs in, or what one would do to try to force the clocks back ?

Thanks,
Ross

Jason would be the best to answer that one. I am the HW team.

Gerald

Gerald/Jason

I put some pr_info statements in the Kernel boot up. GPTIMER1 is being setup as if the unit is being powered by USB. The question now is whether reading the TPS65217b’s status registers or something else is causing the kernel to decide to come up in the reduced power mode. I’ll keep digging, but if anyone has any ideas, I would appreciate them. Somewhere early on in the init code, Linux is making this decision and that is where I need to focus. Yes, I’ve checked my 32Khz crystal connected to the AM3359 and it is being powered and is oscillating properly. Maybe some other signature that Linux is looking for to determine this is a Beaglebone???

Thanks all for your help,

Ross

Uncompressing Linux… done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.2.18 (rmorrison@ubuntu-2) (gcc version 4.5.4 20120305 (prerelease) (GCC) ) #24 Wed Jun 13 16:19:24 PDT 2012
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: am335xevm
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] AM335X ES1.0 (sgx neon )
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
[ 0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait ip=none
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] allocated 1048576 bytes of page_cgroup
[ 0.000000] please try ‘cgroup_disable=memory’ option if you don’t want memory cgroups
[ 0.000000] Memory: 256MB = 256MB total
[ 0.000000] Memory: 253868k/253868k available, 8276k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] modules : 0xbf800000 - 0xc0000000 ( 8 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0414380 (4145 kB)
[ 0.000000] .init : 0xc0415000 - 0xc044c000 ( 220 kB)
[ 0.000000] .data : 0xc044c000 - 0xc0490fc0 ( 276 kB)
[ 0.000000] .bss : 0xc0490fe4 - 0xc04d830c ( 285 kB)
[ 0.000000] NR_IRQS:410 nr_irqs:410 410
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] **** omap2_gp_clockevent_init()
[ 0.000000] **** omap_dm_timer_init_one()
[ 0.000000] **** omap_dm_timer_switch_src()
[ 0.000000] **** _is_timer_idle()
[ 0.000000] **** _is_timer_idle() ret: 0
[ 0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
[ 0.000000] **** omap_dm_timer_init_one()
[ 0.000000] **** omap_dm_timer_switch_src()
[ 0.000000] **** _is_timer_idle()
[ 0.000000] **** _is_timer_idle() ret: -16
[ 0.000000] omap_dm_timer_switch_src: Switching to HW default clocksource(sys_clkin_ck) for timer1, this may impact timekeeping in low power state
[ 0.000000] OMAP clocksource: GPTIMER1 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] Console: colour dummy device 80x30
[ 0.000238] Calibrating delay loop… 498.89 BogoMIPS (lpj=2494464)
[ 0.056266] pid_max: default: 32768 minimum: 301
[ 0.056432] Security Framework initialized
[ 0.056510] Mount-cache hash table entries: 512
[ 0.056935] Initializing cgroup subsys cpuacct
[ 0.056984] Initializing cgroup subsys memory
[ 0.057028] Initializing cgroup subsys devices
[ 0.057044] Initializing cgroup subsys freezer
[ 0.057057] Initializing cgroup subsys blkio

What about magic i2c eeprom IC? Do you have it?

Nope, no on board EEPROM at all. That seems to be checked much further down in the boot sequence and I do plug data into the config structure to emulate the contents of what would be found (based on the example in the code).

I just pulled R22 from an official Beaglebone which removes the 32Khz crystal from the system. With the crystal removed, the GPTIMER1 does default to the 24Mhz value, but the bone still boots up at 718bogomips (full speed).

So the question still exists, at what very early stage of boot is something (possibly the EEPROM) checked to determine the boot up frequency? Apparently GPTIMER1 being set to 24Mhz is only a symptom of some earlier config checking and not a cause.

Thanks again for any and all help, ideas, comments…

Ross

if it helps:
https://groups.google.com/d/topic/beagleboard/Q65z5O4haYc/discussion

Okay, I'll dead bug an EEPROM on our prototype and see if that makes everything work. If uBoot is actually setting some initial values up and after digging through the init code for Linux, the EEPROM option seems like the easiest way to go, or at least try so I can eliminate that as a problem. Hopefully after programming the values found in a standard Bbone into the EEPROM on our board everything will start working because I am unable to find anything else wrong.

Thanks again and I'll post with results.

Ross