[U-Boot] Regression in 2019.01-rc2 for eMMC boot on mxs board?
Hi,
I'm currently testing latest git tree U-Boot on an I2SE Duckbill 2 device and it seems that I've found a regression compared to v2018.11:
Such a Duckbill device is equipped with a NXP i.MX28 CPU and boots from eMMC. The eMMC has a typical DOS MBR with a special boot loader partition where U-Boot is stored in. Then U-Boot loads kernel and device tree from an ext partition. When I run latest git U-Boot (see following trace for commit hash), then the normal boot procedure fails (fallbacks to netboot, fails again) and gives me a prompt on Debug UART, see following trace. The funny part is, that when typing "mmc part" command to list partitions on eMMC and then calling "boot" again, all works and Linux boot succceeds.
Any quick ideas? Or should I start bi-secting tomorrow...
--snip-- HTLLCLLC
U-Boot 2019.01-rc2-00199-g1cd7b8f120 (Jan 04 2019 - 23:28:55 +0100)
CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SD/MMC #0, 3V3 DRAM: 128 MiB MMC: MXS MMC: 0 Loading Environment from MMC... MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) OK In: serial Out: serial Err: serial Board: I2SE Duckbill 2 Net: FEC0 [PRIME] Autobooting in 1 seconds, press <c> to stop MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) switch to partitions #0, OK mmc0(part 0) is current device MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) ** No partition table - mmc 0 ** Booting from net ... BOOTP broadcast 1 DHCP client bound to address 192.168.8.127 (6 ms) Using FEC0 device TFTP from server 192.168.8.253; our IP address is 192.168.8.127 Filename 'zImage'. Load address: 0x42000000 Loading: * TFTP error: 'File not found' (1) Not retrying... BOOTP broadcast 1 DHCP client bound to address 192.168.8.127 (6 ms) Using FEC0 device TFTP from server 192.168.8.253; our IP address is 192.168.8.127 Filename 'imx28-duckbill-2.dtb'. Load address: 0x41000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Bad Linux ARM zImage magic! => mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 2048 16384 5452574f-01 53 Boot 2 20480 3731456 5452574f-02 83 => boot MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) switch to partitions #0, OK mmc0(part 0) is current device MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) 3437936 bytes read in 1019 ms (3.2 MiB/s) Booting from mmc ... 19479 bytes read in 111 ms (170.9 KiB/s) Kernel image @ 0x42000000 [ 0x000000 - 0x347570 ] ## Flattened Device Tree blob at 41000000 Booting using the fdt blob at 0x41000000 Loading Device Tree to 47b80000, end 47b87c16 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 --snap--
Regards, Michael
Hi,
this morning I bisected the issue and found the following commit is causing it:
d0851c8937067ad396f2bdafc46d0326bf3317db is the first bad commit commit d0851c8937067ad396f2bdafc46d0326bf3317db Author: Bin Meng bmeng.cn@gmail.com Date: Mon Oct 15 02:21:07 2018 -0700
blk: Call part_init() in the post_probe() method
part_init() is currently called in every DM BLK driver, either in its bind() or probe() method. However we can use the BLK uclass driver's post_probe() method to do it automatically.
Update all DM BLK drivers to adopt this change.
Signed-off-by: Bin Meng bmeng.cn@gmail.com Reviewed-by: Simon Glass sjg@chromium.org
Just reverting the commit does not apply cleanly, so I tried to manually revert the following change:
--- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2444,9 +2444,6 @@ static int mmc_startup(struct mmc *mmc) bdesc->product[0] = 0; bdesc->revision[0] = 0; #endif -#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT) - part_init(bdesc); -#endif . return 0; }
After re-adding these lines, all works as expected again and my boot issue is gone.
Regards, mhei
Am Freitag, 4. Januar 2019, 23:48:15 CET schrieb Michael Heimpold:
Hi,
I'm currently testing latest git tree U-Boot on an I2SE Duckbill 2 device and it seems that I've found a regression compared to v2018.11:
Such a Duckbill device is equipped with a NXP i.MX28 CPU and boots from eMMC. The eMMC has a typical DOS MBR with a special boot loader partition where U-Boot is stored in. Then U-Boot loads kernel and device tree from an ext partition. When I run latest git U-Boot (see following trace for commit hash), then the normal boot procedure fails (fallbacks to netboot, fails again) and gives me a prompt on Debug UART, see following trace. The funny part is, that when typing "mmc part" command to list partitions on eMMC and then calling "boot" again, all works and Linux boot succceeds.
Any quick ideas? Or should I start bi-secting tomorrow...
--snip-- HTLLCLLC
U-Boot 2019.01-rc2-00199-g1cd7b8f120 (Jan 04 2019 - 23:28:55 +0100)
CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SD/MMC #0, 3V3 DRAM: 128 MiB MMC: MXS MMC: 0 Loading Environment from MMC... MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) OK In: serial Out: serial Err: serial Board: I2SE Duckbill 2 Net: FEC0 [PRIME] Autobooting in 1 seconds, press <c> to stop MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) switch to partitions #0, OK mmc0(part 0) is current device MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) ** No partition table - mmc 0 ** Booting from net ... BOOTP broadcast 1 DHCP client bound to address 192.168.8.127 (6 ms) Using FEC0 device TFTP from server 192.168.8.253; our IP address is 192.168.8.127 Filename 'zImage'. Load address: 0x42000000 Loading: * TFTP error: 'File not found' (1) Not retrying... BOOTP broadcast 1 DHCP client bound to address 192.168.8.127 (6 ms) Using FEC0 device TFTP from server 192.168.8.253; our IP address is 192.168.8.127 Filename 'imx28-duckbill-2.dtb'. Load address: 0x41000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Bad Linux ARM zImage magic! => mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type 1 2048 16384 5452574f-01 53 Boot 2 20480 3731456 5452574f-02 83 => boot MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) switch to partitions #0, OK mmc0(part 0) is current device MMC0: Command 8 timeout (status 0xe0384020) MMC0: Command 55 timeout (status 0xe0284020) 3437936 bytes read in 1019 ms (3.2 MiB/s) Booting from mmc ... 19479 bytes read in 111 ms (170.9 KiB/s) Kernel image @ 0x42000000 [ 0x000000 - 0x347570 ] ## Flattened Device Tree blob at 41000000 Booting using the fdt blob at 0x41000000 Loading Device Tree to 47b80000, end 47b87c16 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 --snap--
Regards, Michael
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Sat, 5 Jan 2019 at 01:39, Michael Heimpold mhei@heimpold.de wrote:
Hi,
this morning I bisected the issue and found the following commit is causing it:
d0851c8937067ad396f2bdafc46d0326bf3317db is the first bad commit commit d0851c8937067ad396f2bdafc46d0326bf3317db Author: Bin Meng bmeng.cn@gmail.com Date: Mon Oct 15 02:21:07 2018 -0700
blk: Call part_init() in the post_probe() method
Yes, I believe these is a patch to fix this.
Regards, Simon
Simon Glass sjg@chromium.org [2019-01-07 17:38:31]:
Yes, I believe these is a patch to fix this.
https://patchwork.ozlabs.org/patch/1014381/
-- ynezz
participants (3)
-
Michael Heimpold -
Petr Štetiar -
Simon Glass