Sitara™ ARM®

Forum Post: RE: AM335x: GPMC Prefetch TRANSFERCOUNT for 16-Bit NAND?

Ruediger Wesche — Fri, 24 May 2013 16:52:00 GMT

Hi Enders Hu,

currently I am not in my office. To avoid the strange behaviour, I implemented some workarounds in my sources.

Best Regards,

Rudi

Forum Post: RE: Bootloader on EVMSK335x

sviss — Fri, 24 May 2013 16:38:00 GMT

The second one is not a MLO. Also, it is difficult to understand what do you want to get?

If newbie, and you want to single step into the boot loader, why not using the CCS and u-boot_spl?

Forum Post: RE: AM3352 custom board port with TMDssk3358 as template

sviss — Fri, 24 May 2013 16:20:00 GMT

[quote user="Peter T-Innova"] ... do I need some more ...[/quote]

Mmm.. The first thing that comes to mind is that nobody but you only know what you need.

Basically, SDK contains all the code needed for the SK to work, and looking at the datasheets it is not too dificult to upgrade it if needed.

I used to use the SK sources to bring my board up. This worked (for me) fine. Nothing more was required.

HTH

Forum Post: Sync Kernel debug. Pre- init_machine() code -- how? (AM335x Linux psp)

sviss — Fri, 24 May 2013 16:02:00 GMT

Hi hardware guys.

How do you debug the kernel code executed before the machine is initialized : before init_machine() is called?

The case:

I see on my board that one of the GPIO's state change. (this is GPIO0_6, to be specific).

To my understanding, this is strange : I expect all the periferal devices' state is preserved from the U-boot set values.

I added a LED blinking code, to the init_machine() /alias of am335x_evm_init() from the SK support code/ , and using oscilloscope found that GPIO state changes some ~40 milliseconds *BEFORE* the init_machine() is entered.

I want to find out why is it happening but no LED blinking (GPIO conrol) code works there, in the code above init_machine() /maybe pinmuxing is destroyed?/, nor a printk() helps because it is asynchronous: printout goes to the memory, not to the UART, and therefore I cannot trace that 40ms interval. Not even a mdelay()/udelay() methods seem to be functional in certain places of the kernel init code.

So, please kindly share your ideas/knowledge on how to get a bit of information, synchronously (anything better than memory printing with the printk), for hardware debug, from the code executed in the main.c at kernel_init() and around, before the board is initialized, and after the decompress_kernel() / kernel start.

Thanks.

Forum Post: RE: discrepancy between Starter Kit schematics and Starter Kit JTAG connector installation guide

Matt Romney — Fri, 24 May 2013 16:01:00 GMT

I too am using the pdf schematic as a reference and the ref. des. do not match either the layout or the BOM. Please update as soon as possible.

Thank you.

Forum Post: RE: AM335x USB

-DK- — Fri, 24 May 2013 15:38:00 GMT

Jonathan,

I do not believe this is possible. These registers only control the PHY pulldowns and would not be able to control the pull-ups required to support device mode. I'll double check with design, but it may take several days to get a response given the US holiday on Monday.

Forum Post: RE: AM3359 ethernet phy strange behavior / not working

-DK- — Fri, 24 May 2013 15:24:00 GMT

Nick,

Did you enable stats collection via STATS_PORT_EN? By default, stats collection is disabled.

Forum Post: RE: am335x - VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0)

daniel formolo — Fri, 24 May 2013 14:20:00 GMT

dears, I really do not know what happened. I writed flash again with the same files and configurations, now every think works well.

mmc rescan nand erase.chip fatload mmc 0 0x81000000 MLO cp.b 0x81000000 0x81020000 20000 cp.b 0x81000000 0x81040000 20000 cp.b 0x81000000 0x81060000 20000 fatload mmc 0   0x81080000 u-boot.img fatload mmc 0   0x81260000 uEnv.txt fatload mmc 0   0x81280000 uImage.bin fatload mmc 0   0x81780000 ubi.img nand write 0x81000000 0x0 0x2000000 saveenv

Forum Post: RE: Touch panel response time using LINUXEZSDK-AM335X

Ralf Bartzke — Fri, 24 May 2013 13:17:00 GMT

The cause of the problem seems to be different. It is an impractical strong force required to move the mouse cursor on the development board exactly by hand.

Forum Post: McASP underflow error handling

Balazs Ancsa — Fri, 24 May 2013 12:48:00 GMT

Hi!

I'm using AM3359 with StarterWare library and managed to use McASP with DMA across Audio FIFO.

My question is what is the correct way to handle data underflow error? The reference manual says reset McASP but does not mention how to do that.

Is it enough to reset the TX side or the RX part must be reset too?
How can this reset be achieved? With the Global Control Register? I have tried that, wrote 0 to that register, re-initialize the McASP periphery but that does not help.
Should I use the Power, Reset and Clock Management (PRCM) module?

My goal is to recognize the underflow error and handle it without bother the receive side.
Is this possible?

Best Regards,
Balazs Ancsa

Forum Post: RE: am335x 24bit LCD configuration

ebin jose — Fri, 24 May 2013 12:25:00 GMT

Hi Sudarshan,

We found a hardware issue on our board related to voltage level on some lcd pins, waiting to clear this.

As mentioned in the previous post, it seems possible to swap the colours in da8xx-fb.c file, but couldn't check this.

Regards,

Ebin

Forum Post: RE: Clock Tree Tool

Simon Gantenbein — Fri, 24 May 2013 12:20:00 GMT

Hi,

I encountered exactly the same problem, too. As all peripherials like I2C, SPI and UARTs are behaving correctly with the "wrong" PER PLL settings I expect the tool to simple be buggy (wouldn't be the first bug in tools provided by TI :-().

Is this issue already address to the people that wrote this program?

Best regards

Simon

Forum Post: CM3 Firmware to substitute SRAM assembly for PowerManagement

Martino Facchin — Fri, 24 May 2013 10:32:00 GMT

Hi everyone,

pulling arago cm3 git repository I discovered the existence of the next2 branch.

It contains a very useful feature like DDR powerdown which was extremely complicated to control via sleep33xx.S

Considering that the board I'm working on uses LPDDR1 as RAM I can't try the feature "out of the box" so I started hacking both kernel and m3 firmware to obtain the same result as before but incredibly more mantainable.

At the moment I removed anything from sleep33xx.S except wfi instruction and handled the extra parameter passage to CM3 in pm33xx.c but the board doesn't wake up.

Reading commits it appears that exist some kernel build with all the new infrastructure working, not yet publicly released.

Is it possible to obtain a preview of such patches to start hacking on?

Thank you so much

Martino

Forum Post: DM8127 can't set DDR3 frequency to 533Mhz

yao zhang71010 — Fri, 24 May 2013 10:00:00 GMT

Hi,

I was lost in setting the frequency up to 533Mhz of DDR3. And the same U-boot.min.bin can run ok in Appro camera. also, the 400Mhz DDR3 can run ok on my camera.the device mechanical package designator of appro camera is CYEx3,but mine is CYEx2. the DDR is the same. is there something different from CYEx2 and CYEx3 except the things in datasheet?

Thx!

Forum Post: RE: AM335x GPMC IRQ status Monitored by Software Polling

Daisuke Maeda — Fri, 24 May 2013 09:32:00 GMT

Hi Miroslav,

Thank you for your reply.
Sorry for my late reply.

Best regards

Daisuke

Forum Post: RE: AM335x Production Programming

Daisuke Maeda — Fri, 24 May 2013 09:24:00 GMT

Hi David,

Thank you for your reply.

I will check it in June!

Best regards,

Daisuke

Forum Post: RE: EtherCAT Watchdog Behavior with ICE board

PratheeshGangadhar — Fri, 24 May 2013 09:23:00 GMT

Hi,

> so apparently the PRU ESC is still running and handling the packets even when the ARM CPU is halted. Question - is this expected behavior?

Yes - ESC still uses the old process data buffer for communication

> which watchdog do I need to enable to allow the EtherCAT master to detect that the EtherCAT AL app has crashed?

You need to use PDI WD. However note that we have fixed an issue with PDI WD in 1.0.0.8 and a new API is added to configure h/w event to trigger PDI WD (unfortunately we can't disable the h/w trigger in PRU-ICSS for PDI WD). So PDI WD is triggered when firmware receives a command from A8 application or programmed h/w event occurs

http://processors.wiki.ti.com/index.php/AM335x_EtherCAT_firmware_API_guide#bsp_set_pdi_wd_trigger_mode has more details

Forum Post: RE: AM335x NAND Flash Tool or nandlib does not support BCH 16-bit ECC

Pekon Gupta — Fri, 24 May 2013 09:16:00 GMT

Thanks Karel..

It would be really helpful, if you can make a formal patch for your changes and post it to Tom Rini (Uboot).

We would try to get this ported to mainline, and push it upstream so that everyone is benefited from your work.

(You can also attach the patch in this forum-post as reference, instead of posting it inline)

with regards, pekon

Forum Post: RE: Second ethernet port does not work (335x cpsw)

Micael Beronius — Fri, 24 May 2013 08:39:00 GMT

Hi,

and to clarify my issue even more, it was my phy that went into a mode (called "back to back" if I remember correctly, or possibly "ISO" mode) since the pins are multi function (sampled when coming out of reset). From this point on, the Sitara could no longer have a meaningful conversation with the phy. The phy looked to be working just fine, by it self though.

Micael

Forum Post: RE: kernel crash when reading ADC registers

Arturs Elksnis — Fri, 24 May 2013 08:39:00 GMT

Ok, a little update. I've solved my problem but the answer was not where I was expecting it. Just in case it helps someone else who's struggling with a similar issue, my advice is: check how you're registering your device (touchscreen device in my case). In an older kernel I used function "platform_device_register" which is defined in "/arch/arm/mach-omap2/devices.c" and it worked fine. With later kernels however you have to use function "omap_device_build" defined in "/arch/arm/plat-omap/omap-device.c". You'll need to do "omap_hwmod_lookup" first. The best example is TI's own one: function "am33xx_register_mfd_tscadc" in "/arch/arm/mach-omap2/devices.c". This way it registers the device to omap bus and enables all required clocks for you so strictly speaking this:

[quote user="Miroslav Kiradzhiyski XID"]The tsc_adc clock isn't enabled on init - the ti_tscadc.c driver should do this in its probe function.[/quote]

is not really true. The tsc_adc clock should already be running if the device is registered properly. Well, that's how I understood it. If someone knows better, feel free to correct me.

Thanks,

Arturs