Activity
From 06/25/2014 to 07/24/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...
06/25/2014
- JC 05:09 PM Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Dirty gets appended to the version string for both u-boot and the kernel when you compile source code that has changes that aren't committed in git. Its a sort of warning to the developer that this version may not be reproducible from a...
-
05:05 PM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- I pulled the AM335XPSP_04.06.00.08 tag and there were a lot of differences. I don't think it matters
that much as we really only modify six files of yours, and most of that is because of the one very
large SPI NOR chip that we need. I'... - JC 04:58 PM Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Looks like both the 03 and 08 branches have the same 2011.09 date so harder to determine which branch of code you were using.
- JC 04:55 PM Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- You were likely using the code from the AM335XPSP_04.06.00.08 branch before and now should be using the u-boot-2013.10 branch. There may be alot of changes between the two branches.
-
02:05 PM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Hey Jonathan,
Can you tell me if I were to pull a full u-boot "tree" from your "u-boot-mityarm-335x.git/tree", which one of
the head labels should I use? u-boot-2013.10, AM335XPSP_04.06.00.03 or AM335XPSP_04.06.00.08 ?
I'll... -
12:18 PM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Seems like when I used our NAND mlo/u-boot burn in scripts, I blasted over the old u-boot by erasing NAND from 0 to 0x1E0000.
Sorry for the distraction. -
12:11 PM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Not sure what happened, but even placing the original MLO back it will not boot:
U-Boot SPL 21401-101.01.00.02-dirty (Nov 06 2013 - 08:59:11)
Texas Instruments Revision detection unimplemented
MityARM335x profile 1 - Model No: 3352... -
12:02 PM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Booting from the mmc card now does not show that u-boot in NAND has any issues.
U-Boot# nand read 8d000000 80000 1e0000
NAND read: device 0 offset 0x80000, size 0x1e0000
1966080 bytes read: OK
U-Boot# - JC 11:56 AM Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Yes we decided to store everything in nand using the correct ecc so we disabled the nandecc command. So you do not need to change ecc modes anymore in u-boot.
Odd I wasn't aware of any compatibility problems with loading the old u-bo... -
11:43 AM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Looks like we can't reach u-boot with the new MLO. We see the following and then it stops. If we plug in the
mmc, we are back. Any suggestions?
John C.
U-Boot SPL 2013.10-gd35e056 (Jun 03 2014 - 17:00:30)
MitySOM335x profile 1 -... -
11:34 AM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Thanks Jonathan,
It seems the u-boot nandecc command has changed. We used to run the following script for
burning all four MLO locations. When we ran the "nandecc hw 2" command it used to come back
with a "HW ECC BCH8 Selected" r... - JC 11:17 AM Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Okay. I created a FAQ about this issue incase anyone else runs into it.
https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Software_FAQs#U-boot-has-started-hanging-on-startup-while-booting-from-nand-or-is-behaving-... -
11:13 AM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Hey Jonathan,
Yes there is indeed an error. I'll try the newer MLO to see how that works.
Thanks,
John C.
U-Boot# nand read 8d000000 0 80000
NAND read: device 0 offset 0x0, size 0x80000
524288 bytes read: OK
U-Boot#... - JC 10:18 AM Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- If you confirm there are bit flips you can then flash just the UBL into the NAND and see if it boots fine. You'll see something like the following during boot to show that its correcting the bit flips.
- JC 10:13 AM Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Try doing to following. It should print out bitflips if it finds them.
-
09:53 AM
Software Development: RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
- Hey Jonathan,
I don't have access to a booted Linux, only u-boot. I created a text script that runs the u-boot "nand dump <address>" from address 80000h to F0000h in increments of 800h = 2048 (page size.) The output is raw (see inc...