mcf54415 eSDHC

[angelo_d]

Dear all,

i was trying to see some signal out of the eSDHC controller, but i can't see any sign of activity.

Pinmux pads on the gpio controller has been set to eSHDC (alll as 0x03). Card is always

inserted.

Testing some commands, using an existing u-boot driver, or also with separate init test commands, i can't see any signal on sd_clk or sd_cmd.

Is it possible there is weird thing ? Also, i have seen that at least one coldfire model as mcf53xx has the eSDHC module not enabled. Hope is not the case of this mcf54415 chip.

Every help is appreciated.

Angelo

[angelo_d]

Hi Tom,

really many thanks for the precious study, and sorry if my questions cause you to spend much time.

Very good to know, i can look inside the above patches, even if of course they would not apply to 4.X kernels it is something very useful already, at least to see the if registers maps are as in the hardware, or the dma channels are as in the hardware, (this of course due to the recent reply from NXP that won't fix any datasheet, and that datasheet errors are now "history", as seems the cpu). Since rev.4 manual errors are many and not trivial, to require the use of the rev.3 manual (that's not even available in the documents section), having this drivers seems really god. 

Regards,

angelo

[TomE]

> sorry if my questions cause you to spend much time

It is my favorite way of learning.

Regarding your next post (which isn't here, but I received as email), your system isn't set up right if it is getting "CPU Resets". Linux should always catch exceptions. If you're talking about running the SD driver under U-Boot, then that's a different problem (but it should be able to catch these too). After the "Reset", check the RSR to see what happened. The usual cause of resets like this is unhandled or badly handled interrupts. Make sure EVERY interrupt vector in the entire table is initialised to an "unhandled interrupt handler" that tells you that it got called. If "mishandled", then either the request wasn't cleared and it got stuck in interrupts forever, or worse, it context-switched somehow and the interrupt was still pending and triggered again. You're probably blowing the stack up or overwriting something, sending the CPU off into a bus error or double-bus error.

Also, the M68k isn't like an I86 where all interrupts are masked and acked via the interrupt controller. In many peripherals you have to write to the interrupt status register (CAN, Ethernet) or empty the receiver (UART) to make the interrupt go away properly. The "interrupt controller" is mainly a smart interrupt multiplexer rather than being the "master controller" like is needed on other CPUs that only have one usable core interrupt level (ARM, I86, PPC).

Is this interrupt controller like the MCF52 ones (that cause all the priority problems) or the MCF53 ones that fixed that? They look like the latter, in that the interrupt priority within a level is in a fixed order depending on the request number in the controller. Check "Table 17-15. Interrupt Source Assignment For INTC0" and the other two to make sure you're doing what it says in the last column.

Tom

[angelo_d]

Hi Tom,

thanks again

did another step forward, my last issue was hardware, inserting the card 3,3v was moving to 2,5 causing the cpu to reset. So, i added a 100uF in parallel on the 3,3V and the issue is now fixed.

Next problem is that the card is never detected anyway by the controller. Tracing prsstat i get:

stmark2 $ mmc rescan
esdhc_getcd_common() prsstat = ff880008
esdhc_getcd_common() timeout 0
MMC: no card present
mmc_init: -123, time 1009‍‍‍‍‍

So the bit CINS is never set wherever i insert or remove the sd card.

[angelo_d]

I found that the CINS bit (card insertion detection bit) comes set only if i set PROCTL[D3CD], so i set it.

At this point i get

prsstat = ff890008

so card detected, but always, also if the card is not inserted.

I had the idea to test all those pins as GPIO, sending out a square wave.

So i set all SDHC pins as PF0, 1 2 and PG 5, 6 and 7 as outputs and fire a square wave on all. Nothing comes out.

This seems to match with the fact that nothings comes out from the same pins also in sdhc mode.

Mmmm is it possible that i have issues with soldering on pcb/bga, while all other balls around there seems well soldered ? Testing those pins, they all gives some resistance, so they are not open electrically.

Looking the manual rev3 (and rev4), esdhc seem supported and existing in my mcf54415.

[TomE]

Things are always easier if you have a working Reference Board to run tests on. Or two, in case one gets damaged.

GPIOs not working? That's a worry. The only think I can think of is the clocking (but there's only one GPIO clock enable and nothing would work if it was set), Power (these pins run from EVDD as does everything else). There's nothing to say if all 10 EVDD pins are joined inside the chip, so one of them might power those pins and mightn't be connected. Check your layout to make sure no power pins got missed.

Otherwise it might be a software problem. See what other pins you can change to GPIO and get working. Get something simple working first (read and write one pin, any pin) and then use that test on other ones.

> I had the idea to test all those pins as GPIO, sending out a square wave.

At what frequency? The GPIO pins are VERY SLOW (hundred CPU clocks), so you want to toggle them slowly. 1MHz at most, but easier to test at 1Hz or so. You can also see if you can get the RGPIO pins reading and writing as a test if they're available.

Do you have a debug pod? It is usually easier to directly read and write the I/O ports from a debugger. Watch out though, some debuggers perform reads and writes as BYTES where some registers can only be written as 32-bit writes or vice versa. Make sure you read back ports you've written to to make sure the writes work.

All the Port Control registers are BYTES and should be accessed with byte writes. Watch out, this is a big-endian chip, so if you're reading or writing 32-bits, the UPPER byte is byte zero and the LOWER one is byte three.

Check the pin definition header files you're using. Some of these can have bugs in them, the wrong addresses, the wrong access modes (16-bit definitions when they should be 8-bit definitions), or you might have a header for the wrong chip. That's why using a debug pod with hex addresses can be safer for testing.

> Testing those pins, they all gives some resistance

Play with the PCR (Pull Control) registers. Change from pull-up to pull-down to none and see if you get voltage and current changes on those and other GPIO pins. Test GPIO pins as inputs. See if you can see changes in the PPDSDR input registers. Don't confuse these with the PODR ones which set the outputs, but if you read them return the register values and not the pin values.

Tom

[angelo_d]

Got some probably end-of-the-run bad news.

I used BDM, a brief start.S on internal SRAM and this main:

#define PDDR_A     0xEC09400C
#define PDDR_F     0xEC094011
#define PDDR_G     0xEC094012

#define PODR_A     0xEC094000
#define PODR_F     0xEC094005
#define PODR_G     0xEC094006

#define write_reg_8(x, y)  *(volatile unsigned char *)x = y;

int __main(void)
{
     int ch, i;

     /*
      * testing a square wave on PORTA, UART0_TX, UART1_TX, and all SDCH pins
      *
      * PF0   SDHC_DAT1
      * PF1   SDHC_DAT2
      * PF2   SDHC_DAT3
      * PF3   UART0_TX
      * PF7   URAT1_TX
      *
      * PG5   SDHC_CLK
      * PG6   SDHC_CMD
      * PG7   SDHC_DAT0
      *
      */
     write_reg_8(PDDR_A, 0xff);
     write_reg_8(PDDR_F, 0x8f);
     write_reg_8(PDDR_G, 0xe0);

     for(;;) {
          write_reg_8(PODR_A, 0x00);
          write_reg_8(PODR_F, 0x00);
          write_reg_8(PODR_G, 0x00);
          for (ch = 0; ch < 1000; ++ch);
          write_reg_8(PODR_A, 0xff);
          write_reg_8(PODR_F, 0xff);
          write_reg_8(PODR_G, 0xff);
          for (ch = 0; ch < 1000; ++ch);
     }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I see a nice square wave on PORTA (with exception to FB pins) PA0, 2 3 4 5 6 7 (PA1 is used by FB), then on PF3.

Nothing on PF7 (UART1_TX) and nothing on all SD pins.

So a brief analysis:

Fact 1: no signal has ever been seen over sdch pins after proper controller init and sending commands

Fact 2: controller sees a card always inserted (PRSSTAT[CINS]) even if there is no card

Fact 3: there is no way to have any GPIO signal out of sdhc pins PF0 PF1 PF2 PG5 PG6 PG7 (above code).
Fact 4: tower board (where esdhc should work) uses exactly same pins for esdhc
Fact 5: gpio PM is active by default

Fact 6: sdhc pins, are measuring some resistance in the Kohm range so i expect they are soldered to the bga (nothing else connected).

Fact 7: on UART0_TX as GPIO in PF3 i properly a square wave (to confirm above code).

Fact 8: can't measure any shortcut on sdio pins.

So, at this point, if i don't miss something, my theory is that i believe i damaged the cpu, in a way to interrupt output pins inside the package, since it has been soldered by a cheap BGA soldering station. I am still surprised that the ddr2 part works perfect, so my soldering was not that bad at the end.

[TomE]

I would add to the above code explicitly setting PPMHR[0, 1] and PPMLR[1, 0] to all zeroes to make sure all your clocks are running.

I would also explicitly set the PAR registers of interest (there are 22 in total).

There are 11 ports. I'd suggest trying all the ones you can that don't cause problems on your board. Testing more of them might show a pattern that can be recognised.

Can you get a TOWER system, or some other development board to compare it with? Do you have another built-up board to compare with? Do you have a blank board you can check all the power supply connections on with a meter?

> I used BDM, a brief start.S on internal SRAM and this main:

Is the "start.S" setting up all the clocking and so on, or does the BDM have a configuration file that sets up some registers before loading the code? It must have some setup as RAMBAR defaults to UNDEFINED on Reset. So there has to be a list or a default file that the BDM uses to set that up at least, and it may be setting up other registers in there that you may not be expecting.

Tom

[angelo_d]

Hi Tom,

many thanks still for your support,

i changed BDM test code as you suggested:

#define PDDR_A     0xEC09400C
#define PDDR_F     0xEC094011
#define PDDR_G     0xEC094012

#define PODR_A     0xEC094000
#define PODR_F     0xEC094005
#define PODR_G     0xEC094006

#define PPMHR0     0xFC040030
#define PPMLR0     0xFC040034
#define PPMHR1     0xFC040038
#define PPMLR1     0xFC04003C

#define PAR_FBCTL     0xEC094048
#define PAR_BE          0xEC094049
#define PAR_CS          0xEC09404A
#define PAR_IRQ0H     0xEC09404C
#define PAR_IRQ0L     0xEC09404D
#define PAR_DSPIOWH     0xEC09404E
#define PAR_DSPIOWL     0xEC09404F
#define PAR_TIMER     0xEC094050
#define PAR_UART2     0xEC094051
#define PAR_UART1     0xEC094052
#define PAR_UART0     0xEC094053
#define PAR_SDHCH     0xEC094054
#define PAR_SDHCL     0xEC094055
#define     PAR_SIMP0H     0xEC094056
#define     PAR_SIMP0L     0xEC094057
#define     PAR_SSI0H     0xEC094058
#define     PAR_SSI0L     0xEC094059
#define     PAR_DEBUGH1     0xEC09405A
#define     PAR_DEBUGH0     0xEC09405B
#define     PAR_DEBUGL     0xEC09405C
#define PAR_FEC          0xEC09405E

#define write_reg_8(x, y)  *(volatile unsigned char *)x = y;
#define write_reg_32(x, y)  *(volatile unsigned long *)x = y;

int __main(void)
{
     int ch, i;

     /* pll init */
     system_init();

     write_reg_32(PPMHR0, 0);
     write_reg_32(PPMLR0, 0);
     write_reg_32(PPMHR1, 0);
     write_reg_32(PPMLR1, 0);

     write_reg_8(PAR_FBCTL, 0);
     write_reg_8(PAR_BE, 0);
     write_reg_8(PAR_CS, 0);
     write_reg_8(PAR_IRQ0H, 0);
     write_reg_8(PAR_IRQ0L, 0);
     write_reg_8(PAR_DSPIOWH, 0);
     write_reg_8(PAR_DSPIOWL, 0);
     write_reg_8(PAR_TIMER, 0);
     write_reg_8(PAR_UART2, 0);
     write_reg_8(PAR_UART1, 0);
     write_reg_8(PAR_UART0, 0);
     write_reg_8(PAR_SDHCL, 0);
     write_reg_8(PAR_SDHCH, 0);
     write_reg_8(PAR_SSI0H, 0);
     write_reg_8(PAR_SIMP0H, 0);
     write_reg_8(PAR_SIMP0L, 0);
     write_reg_8(PAR_SSI0H, 0);
     write_reg_8(PAR_SSI0L, 0);
     write_reg_8(PAR_DEBUGH1, 0);
     write_reg_8(PAR_DEBUGH0, 0);
     write_reg_8(PAR_DEBUGL, 0);
     write_reg_8(PAR_FEC, 0);

     /*
      * testing a square wave on PORTA, UART0_TX, UART1_TX, and all SDCH pins
      *
      * PF0   SDHC_DAT1
      * PF1   SDHC_DAT2
      * PF2   SDHC_DAT3
      * PF3   UART0_TX
      * PF7   URAT1_TX
      *
      * PG5   SDHC_CLK
      * PG6   SDHC_CMD
      * PG7   SDHC_DAT0
      *
      */
     write_reg_8(PDDR_A, 0xff);
     write_reg_8(PDDR_F, 0x8f);
     write_reg_8(PDDR_G, 0xe0);

     for(;;) {
          write_reg_8(PODR_A, 0x00);
          write_reg_8(PODR_F, 0x00);
          write_reg_8(PODR_G, 0x00);
          for (ch = 0; ch < 1000; ++ch);
          write_reg_8(PODR_A, 0xff);
          write_reg_8(PODR_F, 0xff);
          write_reg_8(PODR_G, 0xff);
          for (ch = 0; ch < 1000; ++ch);
     }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

No changes, i still miss all the signals output on all the eSDHC pins and UART_TX1, while the test square wave in PORTA and UART_TX0 is perfect.

I will soon manage to have additional boards to compare, but very likely, i damaged some parts of the chip, as said, i tested by tester, SD wires are connected to something so likely soldered, but they are not in short between themselves and not in short to ground or evdd.

regards,

angelo

[angelo_d]

Hi Tom,

just to close this thread. The above issues was due to a wrong soldering process, likely, some bga solderings was not done properly, or i damaged something in the cpu.

Now i am organized with a new bga soldering station, more professional, and could have a board well soldered with usdhc and uart 1 working as expected.

Thanks again !

[miduo]

Hi,

Please let me know if you are using the  linux BSP we provided for TWR-MCF5441x. Actually the linux BSP support the eSDHC module of MCF5441x. So how you config the eSDHC controller? Please provide as much information as possible that will help to address the issue. Thanks.

[TomE]

Fang Li wrote:

> Please let me know if you are using the  linux BSP we provided for TWR-MCF5441x.

Can you please let me know where that is? I would have thought it would be available on the "TWR-MCF5441x" page, but there's very little there, and certainly no link to the BSP. There's no mention of software at all.

https://www.nxp.com/products/processors-and-microcontrollers/additional-processors-and-mcus/coldfire...

Searching found this page, but it doesn't mention MCF5441x. It says it is for "M5475EVB, M5485EVB, M5474LITE, M54451EVB, and M54455EVB".

https://www.nxp.com/support/developer-resources/run-time-software/linux-software-and-development-too...

Google finds me this post, that says the update listed above actually contains a Linux Release for the MCF5441x, even through the title of it doesn't say that:

https://community.nxp.com/thread/317579

That details the Linux Version is 2.6.38. It is an LTIB ISO. The "packages" directory contains the 2.6.38 Linux Release, together with about about 184 patches to apply to the packages. There is also a "kernel-2.6.38-CF-maintenance2011-release.tar.gz" package that contains 52 patches to be applied to the Kernel to then constitute the "fixes" required to the mainline to make it work on that board/CPU. Some of these "patches" are over 300 kbytes long! They're not "patches" so much as complete drivers or driver trees. There are over 92.000 lines of them!

Angelo wrote:

> do you know if there is/was any plan to move those BSP drivers into mainline

They did. In 2011. Against the "2.6.38 mainline". When you don't have a "mainstream architecture" (which means i86 or ARM), then the only way to get working software to customers quickly is to "freeze" on the current version of Linux, add 92,000 LINES of "patches", and then release that. Linux changes so fast that those 92.000 lines won't apply to the next version (without a huge amount of expensive work and testing), and as well, those 92,000 lines won't ever make it into the "mainstream" moving forwards (into linux 3.x and 4.x) because (a) that would take a long time to get them all "approved", and (b) there would be continuing effort needed to keep all that code alive, tested and running.

Freescale did the same with the more "mainstream" i.MX53 chip. The latest release for that is Linux 2.6.35. You can see the git tree here:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain

That consists of 2.6.35 with about 1243 patches applied. Many of these are complete drivers to support things like the video hardware. There haven't been any fixes from Freescale since November 2013. But in that release, the Ethernet driver doesn't work with IPV6, the CAN driver can't receive or send messages in order, locks up and doesn't recover from errors, the SPI driver can only handle 8-bit peripherals, the PWM driver glitches, the GPIO pin setups are all wrong...

https://community.nxp.com/message/593611

If you want those fixes you have to read my posts and try to apply my patches.

Tom

[angelo_d]

Hi Fang,

many thanks,

i am actually in u-boot eSDHC so bare metal. But good to know there are Linux drivers available, i'll check them.

About the Linux drivers, i am actually running only from the mainline linux.git, do you know if there is/was any plan to move those BSP drivers into mainline ?

Regards,

angelo

[TomE]

eSDHC? Wasn't the eDMA hard enough already? Let me guess, you've got the USB controller on your list as well. :-)

You've previously written:

> I am working actually on mcf54415 and linux, with Greg

Aren't there existing Linux or uCLinux source and drivers already available for these modules in other chips that Freescale have released Linux development kits for?

Another thing that might be causing you problems. There is no clear "assignment of responsibilities" for setting up a chip between the Bootstrap and the Linux kernel that then runs. Some kernels depend on the Boot having set up all the GPIOs and peripheral pin assignments, pin setup, power enables and clock enables, while others have some "Platform Setup" code in the Kernel to do some/most of that, and then some more in specific device drivers. I'm working on a system at the moment where the Boot (optionally) sets up the Ethernet Controller and the Ethernet PHY, and then the Linux Drivers repeat the setup. But not the same way. They do it differently. Linux has changed over time as they've tried to add "low power modes". That requires Linux to start messing with clocks that used to be the responsibility of the Boot.

What is the clock source for the eSDHC? The eSDHC Chapter shows an "eSDHC Controller Clock" on the Block Diagram, This is probably the "base clock" referred to in the SYSCTL register description.

The Clock Chapter has two clocks feeding the eSDHC module. One is from OUTDIV2 and the other can be switched between OUTDIV3 and Fref. The switch for this says it is the "source of the SDHC card clock" as does the documentation for OUTDIV3. That's the "baud rate clock" called the "base clock" and used by the SYSCTL fields. The OUTDIV2 one is the "Peripheral Clock" that runs the logic apart from the peripheral-clocking. Do you have all the clocks set up properly?

What about "Power Control"? Have you got CD51 in PPMHR0 set properly? These bits control the peripheral clocks, and CD51 defaults to "1" which is "eSDHC Peripheral Clock OFF".

Except it might not be that bit. They managed to get the clock-control bit assignment documentation wrong as well. Some bits actually control a different peripheral to the one it says they do. This of course doesn't matter if your setup code "turns everything on", but your code might not work if you try to enable specific peripherals.

This is another cut-and-paste-from-the-wrong-model error in the manuals. They copied the MCF53355 Power Control chapter to the MCF54415 manual and didn't fix the fact that the chips have different peripherals in different address slots, and so the "CD" bit assignments changed in the hardware. This affected the Edge Port, ADC and DAC Clocks. I didn't check the whole table, so it might be OK for the eSDHC. Best to check all of them though. Or just turn them ALL on and see if the problem goes away.

https://community.nxp.com/message/568281?commentID=568281#comment-568281

Have you checked the Errata? SECF 210, 211, 212, 213, 314, 215, 216, 217 and 218 apply to the eSDHC controller, are all "No plans to fix", but have workarounds.

Tom

[angelo_d]

Hi Tom,

ok many thanks for all your points, checking them all carefully, even if 90% of them has already been checked.

Yes, in the linux side i am working on eDMA and it is "hard" also for difficulty in testing it.

But to fast up the development i decided to try to have sdcard boot enabled from u-boot first (y-modem is not that friendly). So i am in u-boot eSDHC driver now.

As in Linux, also u-boot already has an eSDHC driver that seems to do the right things also for coldfire.

Yes, as Linux drivers i am contributing mainly to have this custom board (stmark2) fully functional and code into mainline.

Actually, some of the imx drivers can work with minimal changes for Coldfire too. For spi i managed to have the existing spi driver working, i now boot from spi-nor flash into linux.

U-Boot 2018.01-00386-gd3b7151fc4-dirty (Jan 30 2018 - 22:52:23 +0100)

CPU:   Freescale MCF54410 (Mask:9f Version:2)
       CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz
       INP CLK 30 MHz VCO CLK 480 MHz
SPI:   ready
DRAM:  128 MiB
MMC:   FSL_SDHC: 0
SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0 
SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
device 0 offset 0x100000, size 0x1e1040
SF: 1970240 bytes @ 0x100000 Read: OK
## Booting kernel from Legacy Image at 40001000 ...
   Image Name:   mainline kernel
   Created:      2018-01-14  16:40:18 UTC
   Image Type:   M68K Linux Kernel Image (uncompressed)
   Data Size:    1970176 Bytes = 1.9 MiB
   Load Address: 40001000
   Entry Point:  40001000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
[    0.000000] Linux version 4.15.0-rc3stmark2-001-00860-g2dd6486ddf91-dirty (angelo@jerusalem) (gcc version 5.2.0 (crosstools-sysam-2016.04.16)) #159 Sun Jan 14 17:40:17 CET 2018
[    0.000000] uClinux with CPU COLDFIRE(m5441x)
[    0.000000] COLDFIRE port done by Greg Ungerer, gerg@snapgear.com
[    0.000000] Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
[    0.000000] On node 0 totalpages: 16384
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 16384 pages, LIFO batch:0
[    0.000000] random: fast init done
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16320
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/ram0 rw rootfstype=ramfs rdinit=/bin/init devtmpfs.mount=1 ignore_loglevel
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
[    0.000000] Memory: 128416K/131072K available (1189K kernel code, 112K rwdata, 304K rodata, 312K init, 61K bss, 2656K reserved, 0K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0x40000000 - 0x40000400   (   1 KiB)
[    0.000000]     kmap    : 0x00000000 - 0xffffffff   (4095 MiB)
[    0.000000]     vmalloc : 0x00000000 - 0xffffffff   (4095 MiB)
[    0.000000]     lowmem  : 0x40000000 - 0x48000000   ( 128 MiB)
[    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   ( 312 KiB)
[    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (1190 KiB)
[    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   ( 417 KiB)
[    0.000000]       .bss  : 0x(ptrval) - 0x(ptrval)   (  62 KiB)
[    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
[    0.000000] NR_IRQS: 256
[    0.000000] clocksource: pit: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1019338904850 ns
[    0.070000] Calibrating delay loop... 234.70 BogoMIPS (lpj=1173504)
[    0.070000] pid_max: default: 32768 minimum: 301
[    0.080000] Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
[    0.080000] Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
[    0.180000] devtmpfs: initialized
[    0.330000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.340000] futex hash table entries: 256 (order: -2, 3072 bytes)
[    0.350000] gpio gpiochip0: (mcfgpio): added GPIO chardev (254:0)
[    0.350000] gpiochip_setup_dev: registered GPIOs 0 to 86 on device: gpiochip0 (mcfgpio)
[    0.620000] WARNING: workqueue cpumask: online intersect > possible intersect
[    0.640000] mcf_edma_probe() entering
[    0.650000] mcf_edma_probe() init channels
[    0.650000] mcf_edma_probe() init irq
[    0.650000] mcf_edma_irq_init() entering
[    0.650000] mcf_edma_irq_init() int0 res->start 72 res->end 87
[    0.660000] mcf_edma_irq_init() int16 res->start 136 res->end 176
[    0.690000] mcf_edma_irq_init() int56 res->start 192
[    0.690000] mcf_edma_irq_init() 0-63 ok
[    0.690000] mcf_edma_irq_init() all ok
[    1.060000] mcf_edma_probe() exiting, all ok
[    1.080000] clocksource: Switched to clocksource pit
[    1.090000] FS-Cache: Loaded
[    4.050000] workingset: timestamp_bits=27 max_order=14 bucket_order=0
[    4.840000] io scheduler noop registered
[    4.840000] io scheduler deadline registered
[    4.870000] io scheduler cfq registered (default)
[    4.870000] io scheduler mq-deadline registered
[    4.870000] io scheduler kyber registered
[    8.600000] ColdFire internal UART serial driver
[    8.600000] mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90, base_baud = 7500000) is a ColdFire UART
[    8.910000] console [ttyS0] enabled
[    8.930000] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 7500000) is a ColdFire UART
[    8.950000] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 7500000) is a ColdFire UART
[    8.980000] mcfuart.0: ttyS3 at MMIO 0xfc06c000 (irq = 93, base_baud = 7500000) is a ColdFire UART
[    9.050000] fsl-dspi fsl-dspi.0: registered master spi0
[    9.060000] spi spi0.1: setup mode 3, 8 bits/w, 5000000 Hz max --> 0
[    9.100000] m25p80 spi0.1: is25lp128 (16384 Kbytes)
[    9.100000] Creating 3 MTD partitions on "is25lp128":
[    9.110000] 0x000000000000-0x000000100000 : "U-Boot (1024K)"
[    9.180000] 0x000000100000-0x000000800000 : "Kernel+initramfs (7168K)"
[    9.250000] 0x000000800000-0x000001000000 : "Flash Free Space (8192K)"
[    9.310000] fsl-dspi fsl-dspi.0: registered child spi0.1
[   10.590000] Freeing unused kernel memory: 312K
[   10.600000] This architecture does not have kernel memory protection.

Sysam Firmware Solutions - stmark 2

Greetings !

For further information check: http://www.sysam.it

/ # 
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

angelo

[angelo_d]

I proceeded into some further checks,

* PLL clock is 480 MHz, cpu clock is 240Mhz, OUTDIV3 = 9 so sdhc_clock = 48Mhz. MISCCR[SDHCSRC] switch is set to PLL divider. Further sysctl clock dividers get set properly to be 400 Khz on initial commands.

* peripheral clock should be there since proper OUTDIV1 and OUTDIV2 setup, and all other peripheral works too.

* gpio pad pinmux regs are set to primary function esdhc  (all 0xff)

* power mamangent is set, bit cleared, peripheral enabled, tried a range near 51, no changes

* errata are not actually interesting the fact i see no signals at all by scope sending commands.

Then i figured out that, i am actually powering on with the card inserted, but controller PRSSTAT[CINS] bit is 0 (not iserted). Removing and inserting the card, system resets after 1 sec.

Investigating.

angelo

[angelo_d]

Some other progress, the card/slot i selected is microSD but should be compatible with miniSD/SD reported in the RM, card is SD"HC", so don't think there would be any issue. When i boot without initializing the controller, i can insert and remove the card, otherwise, with controller initialized by u-boot driver, the cpu resets on card insertion. I also tried to manage the interrupt INTC2/31 for card insertion, no changes for now.