Activity
From 06/27/2014 to 07/26/2014
07/14/2014
- JC 09:43 AM Software Development: RE: SPI clock issues with using newest u-boot
- Yeah by using the ti_ 335x include files I was hoping to greatly simplify our config file. Hopefully it hasn't caused more confusion then it needed to.
-
09:31 AM
Software Development: RE: SPI clock issues with using newest u-boot
- Ok,
I knew it had to be in there somewhere, was just a bit confused
as the original mityarm335x.h had a nice section in the file for all
that.
Thanks,
John C. - JC 09:26 AM Software Development: RE: SPI clock issues with using newest u-boot
- Pretty sure I found "#define CONFIG_SPI" in one of the ti_ config files that get included.
-
09:25 AM
Software Development: RE: SPI clock issues with using newest u-boot
- Yes the Micron N25Q00AA does support the 48Mhz clock. The sf erase still seems longer
but I'll need to time it get get more specific. I did notice that the mityarm335x.h
file was missing "#define CONFIG_SPI" as I though it was needed ...
07/11/2014
- JC 05:26 PM Software Development: RE: SPI clock issues with using newest u-boot
- Also make sure your Nor chip supports 48Mhz on the spi bus.
- JC 05:25 PM Software Development: RE: SPI clock issues with using newest u-boot
- Did you notice any time difference with the slower speed?
-
03:30 PM
Software Development: RE: SPI clock issues with using newest u-boot
- I took out the CONFIG_SPI_FLASH_BAR define and it now seem to pass the long erase command.
-----------------------------------
U-Boot# sf probe 0:0
SF: Detected N25Q1024 with page size 256 Bytes, erase size 4 KiB, total 128 MiB
SF:... - JC 02:23 PM Software Development: RE: SPI clock issues with using newest u-boot
- It may be perfectly fine with the generic name then.
Try changing the spi clock speed and see if you get different results. I found with the nor on our SoM the erase seemed faster when run at 1Mhz but the write was much faster at 48M... -
02:19 PM
Software Development: RE: SPI clock issues with using newest u-boot
- I added the CONFIG_SPI_FLASH_BAR define to mityarm335x.h and the warning is goes away on the "sf probe" command.
I added the #UNDEF and then "#define CONFIG_BOOTDELAY 3" to mityarm335x.h, and this now works.
The "sf erase" command seem... - JC 01:38 PM Software Development: RE: SPI clock issues with using newest u-boot
- 1) I'm not sure why its detecting it differently. Maybe the newer u-boot has a more specific driver for this chip?
Also from the README -
12:44 PM
Software Development: RE: SPI clock issues with using newest u-boot
- Hey Johnathan,
Testing out the new spi bus changes seem fine. I do have two quick questions:
1) The original code I wrote spit out the device ID as:
-------------------------
U-Boot# sf probe 0:0;
SF: Detected N25Q00AA with p...
07/10/2014
- JC 05:10 PM PCB Development: RE: Time drift
- The skipping bad block is not an error but more of an info. Blocks can be marked bad from factory and during use. This is just telling you one was found and skipped over.
- BJ 04:19 PM PCB Development: RE: Time drift
- The clock is working now. Thank you.
But when we flash the nand, there is an error:
root@mityarm-335x:~# flash_erase /dev/mtd7 0 0
Erasing 256 Kibyte @ 400000 -- 80 % complete flash_erase: Skipping bad block at 00440000
Erasing 2... - JC 03:29 PM PCB Development: RE: Time drift
- So if this is the problem I'm thinking of. It was discovered that when we changed to the 3.2 kernel we weren't setting up the RTC and by default the RTC was using its internal clock. This clock has a much higher error than the external...
- BJ 03:26 PM PCB Development: RE: Time drift
- Hey Jonathan,
Thanks again, we will definitely try this solution and let you know if it works. I would like to know what you think was the problem; it is still unclear to me if the clock on the processor chip is bad, or the kernel was... - JC 03:00 PM PCB Development: RE: Time drift
- I've attached the lastest uImage but yes you can build it if you would like. Instructions are here [[Linux_Kernel]]
This should be built from git commit: e53da3cda4dba6464b5b612e865c29e93144957f - BJ 02:57 PM PCB Development: RE: Time drift
- NAND read: device 0 offset 0x340000, size 0x500000
Skipping bad block 0x00780000
5242880 bytes read: OK
## Booting kernel from Legacy Image at 80007fc0 ...
Image Name: Linux-3.2.0+
Image Type: ARM Linux Kernel Image (unco... - BJ 02:56 PM PCB Development: RE: Time drift
- We used the pre-build kernel image that came with the board. The kernel that in the Virtual Machine/home/mitydsp/project/linux-mityarm-335x is already updated through git. I will post the boot log below. Is this fix need us to rebuild th...
- JC 08:12 AM PCB Development: RE: Time drift
- What version of the kernel came with your devkit? Could you post a boot log?
Particularly I want to know if your kernel is new enough to have this fix. http://support.criticallink.com/gitweb/?p=linux-mityarm-335x.git;a=commit;h=7fae5...
07/09/2014
- JC 05:12 PM Software Development: RE: SPI clock issues with using newest u-boot
- Just pushed a fix for this.
http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=commit;h=82762ccda7286bcc7a72b51b087b3ad6742d8a5f - BJ 04:33 PM PCB Development: RE: Time drift
- Here is our clock tree (in /sys/kernel/debug/clock/summary):
clock-name parent-name rate use-count
ehrpwm2_tbclk none 0 1
ehrpwm1_tbclk... - BJ 04:14 PM PCB Development: RE: Time drift
- When we boot into Linux and use the "date" (system clock) and "hwclock" (RTC I assume) commands to set/ask for time, we notice that the time changes by an hour / day (from what the actual time should be). So, for example, if we set both ...
- MW 08:02 AM PCB Development: RE: Time drift
- Hi,
What do you mean by "hardware and software" clocks. Are you using the RTC or just the system clock? Can you dump your clock tree?
Are you running a heavy processor load or kernel module that may be blocking interrupts?
Nor...
07/08/2014
- Hello,
We bought a MityARM335x dev kit months ago. We have noticed that the time on the board (both software and hardware clocks) drifts by about 1 hour per day. Is this a common problem? Did we get a defective board? Are there any kn...
07/01/2014
-
09:49 AM
Software Development: RE: SPI clock issues with using newest u-boot
- U-Boot# sf probe 0:0
SF: Unsupported flash IDs: manuf ff, jedec ffff, ext_jedec ffff
Failed to initialize SPI flash at 0:0
U-Boot# sf probe 1:0
SF: Unsupported flash IDs: manuf ff, jedec ffff, ext_jedec ffff
Failed to initialize SPI... -
09:49 AM
Software Development: RE: SPI clock issues with using newest u-boot
- Jonathan,
I checked with manufacturing and they do use the command in verification
of basic communication with the SPI flash. So would it be possible to get the
sf command into the main line again? My testing shows that with th...
06/30/2014
-
05:06 PM
Software Development: RE: SPI clock issues with using newest u-boot
- Following your lead and my hardware engineers suggestion we did a temporary check and set 0x44E00050
(CM_PER_SPI1_CLKCTRL Register)to a 0x2 (it was a zero) to enable the SPI1 clock. Our system came up
and is running. I'll try and fix ... - JC 05:03 PM Software Development: RE: SPI clock issues with using newest u-boot
- Committed change.
http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=commit;h=bc7833792442421a60e74ef2dc871429b34448fe
Tested in u-boot. - JC 04:54 PM Software Development: RE: SPI clock issues with using newest u-boot
- I'm testing this change right now and am going to push a commit if it works.
-
04:48 PM
Software Development: RE: SPI clock issues with using newest u-boot
- Thanks. Let me take a look and if it works.
- JC 04:45 PM Software Development: RE: SPI clock issues with using newest u-boot
- I think I found the problem. The memory address 0x481A0000 refers to McSPI1 and only spi0 is enabled in the u-boot.
In the following file in the enable_basic_clocks function:
arch/arm/cpu/armv7/am33xx/clock_am33xx.c
You should be... -
04:40 PM
Software Development: RE: SPI clock issues with using newest u-boot
- We had originally set up to boot out of SPI NOR and on occasion do use that ability for
manufacturing testing. The biggest thing at this point is trying to resolve why we have
a SPI bus dependency on the old u-boot. - JC 04:16 PM Software Development: RE: SPI clock issues with using newest u-boot
- No since booting from the spi nor on our SoMs doesn't work and I wasn't aware of anyone using the nor, I didn't look into getting it functioning in u-boot. Do you use the spi nor?
Looking at board/ti/am335x/board.c it looks like TI a... -
03:40 PM
Software Development: RE: SPI clock issues with using newest u-boot
- Hey Jonathan,
Looking at your release without any of my mods, serial NOR was removed (no sf commands.) Was there
anything specific as to why it was removed? When I enable the SPI, I do get the sf commands back but they
are unstab...
06/27/2014
- JC 08:26 PM Software Development: RE: SPI clock issues with using newest u-boot
- It's possible or even probable that name of the pound defines changed in this version. You can check the Readme to see if they are listed otherwise might need to grep for them.
Also take notice that at the end of the config there is ... -
04:41 PM
Software Development: RE: SPI clock issues with using newest u-boot
- Hey Jonathan,
Do I only need the "#define CONFIG_SPI"? I've tried that along with (from the original mityarm35x.h)
the following no luck:
/* SPI support */
#ifdef CONFIG_SPI
#define BOARD_LATE_INIT
#define CONFIG_OMAP3_SPI
... - JC 04:29 PM Software Development: RE: SPI clock issues with using newest u-boot
- It does look like SPI was not enabled in the new u-boot config. Checkout the differences in include/configs/mityarm35x.h between the new and old. This was done since u-boot doesn't need access to any spi devices so we left it up to lin...
-
02:36 PM
Software Development: SPI clock issues with using newest u-boot
- After moving to the newest u-boot we are having issues running SPI bus. Accessing the McSPI registers (0x481A0000) causes a data
abort. This suggests that the clocking is no longer set up correctly and that we have a dependency on u-boo...