Custom IMX28 board, no boot

[dgotfroi]

Hello,

I design my own board with an imx28 CPU. I configured the board (resistors on LCD_D0 to LCD_05) to boot on SSP0 (SD card).

When I try to boot without SD card connected, I have the 0x8020a014 error code on the debug console. So it seems it want to boot on Sd card. So it's good.

But when I connect the SD card, I have absolutely nothing on the debug console.

I measured voltage and everything is good except VDD4P2. It equal to 0.8V !!!!!

This is the schematic :

Can you help me ?

[MarioEBV]

Hi Fabio,

Yes, I did a quick test but got some error but system does not crash.  I don't know if this tool is suitable for this ?

I changed the EMI_FRAC to get a lower DDR2 speed (166Mhz and 133Mhz) but memtester still gives some errors.

Mario

[fabio_estevam]

Hi Mario,

On a properly configured hardware memtester utility can run for days without failure.

[dgotfroi]

Hello,

We found that some board works and some other crash during linux boot.

It seems to be a problem from the component or the mounting.

So, now I can validate my VDD5V_Only patch. It works on all recent U-boot versions (2013, 2014, 2015) but depending the version of your u-boot, you could have some warning like "Hunk #n succeeded at nnn (offset n lines)", but it will work.

Please find attached.

[graemeruss]

Hi Damien,

I tried your patch, but I still cannot get the board I am working on to boot. I added some more debugging to your patch (expanded patch with your changes plus my debug output attached)

With the additional debugging, I get the following console output:

SPL: Serial Console Initialised

SPL: Initialising Power Block

SPL:   Configured for VDD 5v only (no battery)

SPL: Switching CPU clock to 24MHz XTAL

SPL: Setting auto-restart bit

SPL: Setting VDDD 25mV below DC-DC converters

SPL: Setting VDDA 25mV below DC-DC converters

SPL: Setting VDDIO 25mV below DC-DC converters

SPL: Starting 5v input detection comparator

SPL: Starting battery voltage measurement logic

SPL: Initialisating LRADCSPL: Enabling LRADC battery measurement

SPL: LRADC channel 7 is present - configuring

SPL: Finished configuring LRADC channel 7

SPL: Configuring power source

SPL: Pre-Configuring power block

SPL: Disabling automatic battery voltage measurements

SPL: Configuring power block to boot from 5V input

SPL: 5V VDD good

SPL: Booting from 5V supply

SPL: Powering up 4P2 regulator

SPL: Configuring common 4P2 regulator params

SPL: Configuring 4P2 VDD5V only regulator params

SPL: Starting 4P2 regulator

SPL: Charging 4P2 capacitor

SPL: Disabling 4P2 DC-DC Input

SPL: Setting 4P2 brownout level

SPL: Ramping up current limit (VDD5V only)

SPL: Switching DC-DC converters to 4P2

SPL: Enabling 4P2 DC-DC Input

SPL: 4P2 regulator powered-up

SPL: Switching CPU core clock source to PLL

SPL: Clearing CLKCTRL_CLKSEQ_BYPASS_CPU bit

<< at this point, the board hangs >>

The last line of output is in mxs_power_clock2pll() which is called if MXS_VBUS_CURRENT_DRAW is not defined - should I be defining this (I hav no idea what the purpose of it is). This is the only point in the code that MXS_VBUS_CURRENT_DRAW is used.

The next line of console output should be:

SPL: Switching VDDD to DC-DC converters

[dgotfroi]

Hi,

What's your U-boot version ?

What's the flash of your board (for u-boot) ? SD card or NAND flash ?

In my case (SD card and U-boot 2013, 2014 or 2015), the following line was needed in mxs_power_clock2pll():

clrbits_le32(&clkctrl_regs->hw_clkctrl_clkseq, CLKCTRL_CLKSEQ_BYPASS_CPU);

But try, to remove theses lines, your mxs_power_clock2pll must be like this :

static void mxs_power_clock2pll(void)

{

  struct mxs_clkctrl_regs *clkctrl_regs =

  (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;

  setbits_le32(&clkctrl_regs->hw_clkctrl_pll0ctrl0,

  CLKCTRL_PLL0CTRL0_POWER);

  early_delay(100);

  setbits_le32(&clkctrl_regs->hw_clkctrl_clkseq,

  CLKCTRL_CLKSEQ_BYPASS_CPU);

}

Finally, be sure that your power supply can delivrer enought current. Look your 5V with a scope.

[graemeruss]

Hi Damien,

I'm using the latest HEAD from the denx u-boot repo.

I am doing a JTAG boot

Here is the mxs_power_clock2pll() post patch:

/**

* mxs_power_clock2pll() - Switch CPU core clock source to PLL

*

* This function switches the CPU core clock from 24MHz XTAL oscilator

* to PLL. This can only be called once the PLL has re-locked and once

* the PLL is stable after reconfiguration.

*/

static void mxs_power_clock2pll(void)

{

  struct mxs_clkctrl_regs *clkctrl_regs =

  (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;

  debug("SPL: Switching CPU core clock source to PLL\n");

  setbits_le32(&clkctrl_regs->hw_clkctrl_pll0ctrl0,

  CLKCTRL_PLL0CTRL0_POWER);

  early_delay(100);

#ifdef CONFIG_MX28_VDD5V_ONLY

  debug("SPL: Clearing CLKCTRL_CLKSEQ_BYPASS_CPU bit\n");

  clrbits_le32(&clkctrl_regs->hw_clkctrl_clkseq,

  CLKCTRL_CLKSEQ_BYPASS_CPU);

#else

  debug("SPL: Setting CLKCTRL_CLKSEQ_BYPASS_CPU bit\n");

  setbits_le32(&clkctrl_regs->hw_clkctrl_clkseq,

  CLKCTRL_CLKSEQ_BYPASS_CPU);

#endif

}

So are you suggesting I should revert the changes to mxs_power_clock2pll() so CLKCTRL_CLKSEQ_BYPASS_CPU is SET rather than CLEARED?

[dgotfroi]

Yes. Before my patch, in any case CLKCTRL_CLKSEQ_BYPASS_CPU was set. But I saw in LTIB code that CLKCTRL_CLKSEQ_BYPASS_CPU was cleared and not set (and it worked with LTIB), so I added this line and after that my board booted. But I never tested with JTAG (I only tested with SD Card and USB OTG). So maybe it cause a failure during a JTAG boot.

[graemeruss]

Hi Damien,

I hacked in your changes so CLKCTRL_CLKSEQ_BYPASS_CPU is SET rather than CLEARED and now I can boot to the U-Boot prompt

Three questions:

1) Shall I just drop the changes to mxs_power_clock2pll() included in your patch? (i.e. is there a use-case for clearing CLKCTRL_CLKSEQ_BYPASS_CPU)

2) What exactly does defining MXS_VBUS_CURRENT_DRAW do? It results in mxs_power_clock2pll() being called (which is always called if booting from battery). Maybe there is a better name for this define

3) I'm working on a set of patches for a board at the moment - would you like me to clean up your patch and submit it to the U-Boot mailing list on your behalf (assigning you as the author)?

[dgotfroi]

Perfect, it's great to hear. 1). It's not so easy. In my case, with SD card, I need to clear this bit rather than set. It depend on the way the board is used. 2). I don't know what is this define, I think this flag is define in an other file. It was already there in the original source code. 3). Yes of course you can, I'm not familiar with that. So please, you can submit it. I will try to edit my code and set CLKCTRL_CLKSEQ_BYPASS_CPU rather than clear. Maybe I miss something in my previsous tests.

[graemeruss]

The addition was in your original patch. I've tracked it into the Freescale bootlets - it is defined in the root level Makefile

POWERFLAG = ?

ifeq ($(POWERFLAG),MXS_VBUS_CURRENT_DRAW)

CFLAGS += -DMXS_VBUS_CURRENT_DRAW

endif

Perhaps somebody in Freescale might be able to shed some light on it. It looks like it is intended to keep the CPU clock running from the xtal rather than the PLL (i.e. run the CPU at a lower clock frequency in order to reduce current draw). In the meantime, I will define it as a seperate U-Boot CONFIG_MXS flag which can be set in the board specific configuration header.

I'f you find that you need to clear CLKCTRL_CLKSEQ_BYPASS_CPU (I definitely need it set), I could easily make a separate define for that.

In order to properly attribute the patch to you, I will need your email address - can you please PM it to me.

[dgotfroi]

Hi,

Thanks for your comment, you were totally right.

I removed my change in mxs_power_clock2pll(), so this is what I have now :

static void mxs_power_clock2pll(void)

{

                struct mxs_clkctrl_regs *clkctrl_regs =

                               (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;

                setbits_le32(&clkctrl_regs->hw_clkctrl_pll0ctrl0,

                                               CLKCTRL_PLL0CTRL0_POWER);

                early_delay(100);

                setbits_le32(&clkctrl_regs->hw_clkctrl_clkseq,

                                               CLKCTRL_CLKSEQ_BYPASS_CPU);

}

And everythings works fine.

So you can delete this section of the patch.

Many thanks

[fabio_estevam]

Hi Damien,

Could you please send it to the U-boot list for review?

It would nice to have this included in mainline. It would also be good to add your board support into U-boot as well, so that we could have a user for the VDD5V_Only configuration.

Thanks

[dgotfroi]

Yes of course I can. But I nerver do that, so how can I send it to the U-boot list ?

[fabio_estevam]

You can refer to Patches < U-Boot < DENX for details.

Basically you need to use git send-email command to send it to the U-boot list <u-boot@lists.denx.de> and also Cc Marek Vasut <marex@denx.de> on it.

Make sure you have a nice commit log explaining in details why the patch is needed. You also need to provide your Signed-off-by tag.

Run ./scripts/checkpatch.pl on it to make sure style issues are not present.

About the patch: you should not force '+#define VDD5V_Only' inside arch/arm/cpu/arm926ejs/mxs/spl_power_init.c. You can add a CONFIG_VDD5V_ONLY instead and add such definition in the board config file (this should be a separate patch though).

Let me know if you have issues with the patch submission.

Regards,

Fabio Estevam

[dgotfroi]

With LTIB I was not able to start the kernel because I always had the following message :

## Booting kernel from Legacy Image at 42000000 ...

   Image Name:   Linux-2.6.35.3-670-g914558e

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    2566168 Bytes =  2.4 MB

   Load Address: 40008000

   Entry Point:  40008000

   Verifying Checksum ... Bad Data CRC

ERROR: can't get kernel image!

MX28 U-Boot >

Power supply are perfectly stable

[dgotfroi]

It's my mistake, I'm really confused.

So, as I use a 512 Mbits and as U-boot detect 64 MiB (so = 512 Mbits), everything is good.

But there is a bad error in the i.MX28 EVK Hardware guide. In chapter 2.4 it says : "There is a single 64MB×16 (128 Mbit) DDR2 SDRAM on the EVK board."

But it's not 128Mbits but 128MBytes !

So everything is clear for me now, u-boot detects 128MiB (so 128 Mega Bytes ?) on the IMX28EVK because it's a 1Gbits DDR2 (and not a 128Mbits). Is it correct ?

[fabio_estevam]

mx28evk has a 1Gbits DDR2, which is the same as 128MB :-)

So it seems the U-boot port is running correctly on your board.

Now I would be glad to see the changes you did in U-boot to allow the booting on your board (5V input only patch).

Regards,

Fabio Estevam

[dgotfroi]

Of course I will send you the patch.

I will clean my code (because I made a lot of changes and I commented a lot of my additions).

Maybe It could be good to put my changes into some ifdef to give the choice between VDD5V only and Battery.

Finally, I certainly made some modifications that were not required, but I followed the LTIB bootlets Code and "translated" it to U-boot.

I will do that as soon as possible and upload my patch here.

Many thanks for your help.

[fabio_estevam]

Ok, thanks.

Take your time, no need to hush. The LTIB patch does seem a bit convoluted, so I understand it would require some time to achieve a 'clean' version that would be acceptable in U-boot mainline code. It probably needs to be split in several smaller patches.

[dgotfroi]

Hello,

I'm now really near the solution. My patch works fine with yocto dizzy, but now I have an error during boot procedure when starting udev :

INIT: version 2.88 booting

Starting udev

[    6.856500] udevd[67]: starting version 182

[    7.529324] Unable to handle kernel paging request at virtual address 8333f280

[    7.536598] pgd = c0004000

[    7.539327] [8333f280] *pgd=00000000

[    7.542949] Internal error: Oops: 5 [#1] ARM

[    7.547240] Modules linked in:

[    7.550341] CPU: 0 PID: 74 Comm: modprobe Not tainted 3.17.4-fslc+g783addb #2

[    7.557497] task: c377ef00 ti: c2e5a000 task.ti: c2e5a000

[    7.562956] PC is at trace_hardirqs_off_caller+0x4c/0xcc

[    7.568296] LR is at debug_check_no_locks_freed+0x48/0x160

[    7.573805] pc : [<c003fa34>]    lr : [<c004207c>]    psr: 20000093

[    7.573805] sp : c2e5bde8  ip : 00080208  fp : c05b710c

[    7.585300] r10: c05b70f8  r9 : c377ef00  r8 : 20000013

[    7.590540] r7 : 00001000  r6 : c009f4c4  r5 : c3802000  r4 : c3fec060

[    7.597081] r3 : 8333ef00  r2 : 60000093  r1 : 00001000  r0 : c009f4c4

[    7.603625] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user

[    7.610862] Control: 0005317f  Table: 42e4c000  DAC: 00000015

[    7.616623] Process modprobe (pid: 74, stack limit = 0xc2e5a1c0)

[    7.622646] Stack: (0xc2e5bde8 to 0xc2e5c000)

[    7.627034] bde0:                   c3fec060 c004207c c06e21bc c00a01e8 00000001 c3fec060

[    7.635240] be00: 00000001 c3fec040 00000000 00000001 00000000 c009f4c4 00000000 c3fec040

[    7.643446] be20: c3f7c000 00000000 00080208 00040000 c06e5408 c06e5408 c06e21bc c00a11c8

[    7.651651] be40: 00000000 c3fd8b00 c3fec040 00000000 c2e5be74 c2e5be88 c06e5408 c00a132c

[    7.659856] be60: c3fd8b00 000000a1 00000000 00000007 c2e6f520 c06e21bc 00000007 c00a56e8

[    7.668062] be80: c2e5bf00 00000000 c3fd8b14 c3fec054 c2e82268 c2e6f524 c3fd8b00 c2e6f524

[    7.676268] bea0: 00000007 00000007 0000001c c2e6f508 c2e22654 c00cd270 c2e82630 c2e5bf00

[    7.684473] bec0: c2e22600 00000001 00000001 c2e5a008 c2e22600 c00c440c c2e22600 00000001

[    7.692678] bee0: 00000000 00000000 ffffffff 00000000 00000000 00000149 00000400 c2e6f000

[    7.700884] bf00: c2e5a018 00000001 60000013 c0e94d1c c2e22654 c2e22600 00000000 c37dd420

[    7.709088] bf20: 000000f8 c2e22600 00000000 c37dd420 000000f8 c0014588 00000001 c377f21c

[    7.717295] bf40: c377ef00 c00178e8 00000002 00000000 c3707ad8 c2e575a8 b6f70000 c00dafc4

[    7.725500] bf60: 00000000 00000100 c2e5a000 c37dd420 000000f8 c0009724 c2e5a000 00000000

[    7.733704] bf80: 00000000 c0018f98 ffffffff 00000001 00000001 452d5b50 000000f8 c001901c

[    7.741910] bfa0: ffffffff c0009560 00000001 00000001 00000001 452d84c8 00000001 ffffffff

[    7.750114] bfc0: 00000001 00000001 452d5b50 000000f8 452d84c8 00000000 00000000 00000000

[    7.758319] bfe0: 00000000 beab5a30 451d2b20 4523f370 60000010 00000001 fbffffff efdffdf3

[    7.766557] [<c003fa34>] (trace_hardirqs_off_caller) from [<c004207c>] (debug_check_no_locks_freed+0x48/0x160)

[    7.776608] [<c004207c>] (debug_check_no_locks_freed) from [<c009f4c4>] (free_pages_prepare+0x144/0x19c)

[    7.786134] [<c009f4c4>] (free_pages_prepare) from [<c00a11c8>] (free_hot_cold_page+0x28/0x150)

[    7.794875] [<c00a11c8>] (free_hot_cold_page) from [<c00a132c>] (free_hot_cold_page_list+0x3c/0x9c)

[    7.803966] [<c00a132c>] (free_hot_cold_page_list) from [<c00a56e8>] (release_pages+0x220/0x238)

[    7.812796] [<c00a56e8>] (release_pages) from [<c00cd270>] (free_pages_and_swap_cache+0xac/0xc4)

[    7.821630] [<c00cd270>] (free_pages_and_swap_cache) from [<c00c440c>] (exit_mmap+0x128/0x20c)

[    7.830295] [<c00c440c>] (exit_mmap) from [<c0014588>] (mmput+0x40/0xdc)

[    7.837046] [<c0014588>] (mmput) from [<c00178e8>] (do_exit+0x24c/0x8f0)

[    7.843795] [<c00178e8>] (do_exit) from [<c0018f98>] (do_group_exit+0x3c/0xb0)

[    7.851062] [<c0018f98>] (do_group_exit) from [<c001901c>] (__wake_up_parent+0x0/0x18)

[    7.859013] Code: 1a000002 e10f2000 e3120080 0a00000b (e5932380)

[    7.865142] ---[ end trace f0433865ddbd6572 ]---

[    7.869778] Fixing recursive fault but reboot is needed!

bootlogd: cannot allocate pseudo tty: No such file or directory

[   10.869348] random: nonblocking pool is initialized

Do you have any idea ?

[fabio_estevam]

Looks like your DDR settings are not stable yet. If you boot the board several times: does the crash look always the same or does it change every time?