Trying to boot custom kernel on Wink Hub (i.MX28)
Hi folks,
I am trying to boot a custom kernel on a Wink Hub v1, which has an i.MX28 CPU, and is running U-Boot (U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)).
I have tried compiling my own modern kernel and putting it in place of the vendor (Linux version 2.6.35.3-flex-dvt) kernel on the flash chip, but when loading, I simply get the expected U-Boot loading messages, but then nothing at all from the serial port after that.
I'm trying to figure out where my problem is most likely to be. As far as I am aware from long-ago poking at U-Boot, the way that U-Boot passes arguments to the kernel has changed recently? Previously it was ATAGS, and now it expects a Device Tree Blob? Might this explain the failure to boot that I am seeing? And yes, I understand that given that
Many thanks!
Rogan P.S. I have also tried to boot the OpenWrt Duckbill kernel (a few years ago), with the same results ( https://forum.openwrt.org/t/porting-openwrt-to-winkhub-v1/56966):
U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)
CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: NAND, 3V3 DRAM: 64 MiB NAND: 128 MiB In: serial Out: serial Err: serial Net: FEC0 [PRIME] Hit any key to stop autoboot: 0 => setenv bootargs 'noinitrd console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi'; mtdparts default && ubi part database && ubifsmount ubi0:database && ubifsload ${loadaddr} openwrt-19.07.1-mxs-uImage 1799536 && bootm ${loadaddr} UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=3" UBI: MTD device size: 8 MiB UBI: number of good PEBs: 64 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 6 UBI: total number of reserved PEBs: 58 UBI: number of PEBs reserved for bad PEB handling: 2 UBI: max/mean erase counter: 63/45 UBIFS: mounted UBI device 0, volume 0, name "database" UBIFS: mounted read-only UBIFS: file system size: 5459968 bytes (5332 KiB, 5 MiB, 43 LEBs) UBIFS: journal size: 1015809 bytes (992 KiB, 0 MiB, 6 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 269835 bytes (263 KiB) Loading file 'openwrt-19.07.1-mxs-uImage' to addr 0x42000000 with size 1799536 (0x001b7570)... Done ## Booting kernel from Legacy Image at 42000000 ... Image Name: ARM OpenWrt Linux-4.14.167 Created: 2020-01-29 16:05:35 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1799472 Bytes = 1.7 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
Hi Rogan,
On Thu, Jun 15, 2023 at 9:00 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi folks,
I am trying to boot a custom kernel on a Wink Hub v1, which has an i.MX28 CPU, and is running U-Boot (U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)).
I have tried compiling my own modern kernel and putting it in place of the vendor (Linux version 2.6.35.3-flex-dvt) kernel on the flash chip, but when loading, I simply get the expected U-Boot loading messages, but then nothing at all from the serial port after that.
I'm trying to figure out where my problem is most likely to be. As far as I am aware from long-ago poking at U-Boot, the way that U-Boot passes arguments to the kernel has changed recently? Previously it was ATAGS, and now it expects a Device Tree Blob? Might this explain the failure to boot that I am seeing? And yes, I understand that given that
Yes, to boot a modern kernel, you need to generate a devicetree for the Wink Hubv1 board.
Then you build it and generate a .dtb file.
To boot zImage + dtb using an old bootloader that does not support booting dtb, you would need to select the following options in the kernel:
CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y
And then:
cat arch/arm/boot/zImage arch/arm/boot/dts/imx28-wink-hub-v1.dtb > zImage_with_dtb
And then boot zImage_with_dtb as you do with 2.6.35.
Ideally, you should also port a modern U-Boot version, which supports dtb by default and then you don't need the steps above.
Take a look at board/freescale/mx28eevk support for a reference.
Regards,
Fabio Estevam
Thank you so much for the response! It is much appreciated!
I do hope to get JTAG working on the Hub v1, and then will be able to try to build a modern U-Boot which I can flash.
Regards,
Rogan
On Thu, 15 Jun 2023 at 22:01, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Thu, Jun 15, 2023 at 9:00 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi folks,
I am trying to boot a custom kernel on a Wink Hub v1, which has an i.MX28 CPU, and is running U-Boot (U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)).
I have tried compiling my own modern kernel and putting it in place of
the
vendor (Linux version 2.6.35.3-flex-dvt) kernel on the flash chip, but
when
loading, I simply get the expected U-Boot loading messages, but then nothing at all from the serial port after that.
I'm trying to figure out where my problem is most likely to be. As far
as I
am aware from long-ago poking at U-Boot, the way that U-Boot passes arguments to the kernel has changed recently? Previously it was ATAGS,
and
now it expects a Device Tree Blob? Might this explain the failure to boot that I am seeing? And yes, I understand that given that
Yes, to boot a modern kernel, you need to generate a devicetree for the Wink Hubv1 board.
Then you build it and generate a .dtb file.
To boot zImage + dtb using an old bootloader that does not support booting dtb, you would need to select the following options in the kernel:
CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y
And then:
cat arch/arm/boot/zImage arch/arm/boot/dts/imx28-wink-hub-v1.dtb > zImage_with_dtb
And then boot zImage_with_dtb as you do with 2.6.35.
Ideally, you should also port a modern U-Boot version, which supports dtb by default and then you don't need the steps above.
Take a look at board/freescale/mx28eevk support for a reference.
Regards,
Fabio Estevam
I tried to follow your suggestion, but so far I have been unsuccessful.
I cloned Linus' latest source code, and then did:
make ARCH=arm mxs_defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- cat arch/arm/boot/zImage ./arch/arm/boot/dts/imx28-evk.dtb > arch/arm/boot/zImage_with_dtb cd arch/arm/boot mkimage -T kernel -A arm -O linux -a 0x40008000 -e 0x40008000 -C none -d ./zImage_with_dtb uImage_with_dtb
then copied onto the Wink hub and did:
flash_erase /dev/mtd4 0 0 nandwrite -p -m /dev/mtd4 uImage_with_dtb reboot
I then interrupted u-boot, and had to update the number of bytes read from the mtd4 partition (was 0x00400000, now 0x00600000), as the new kernel was about 4 times larger than the vendor kernel, and I was getting checksum errors due to only partial read of the image.
setenv app_boot 'run appboot_args && nand read ${loadaddr} app-kernel 0x00600000 && bootm ${loadaddr}' run app_boot
NAND read: device 0 offset 0x2b00000, size 0x600000 6291456 bytes read: OK ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-22 21:37:11 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6279041 Bytes = 6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
And it stopped there after dumping some garbage to the screen.
I did note that the mxs_defconfig did not define the appended DTB config, so I updated my .config as follows:
$ grep DTB .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
And rebuilt as above, with no change.
Am I doing something obviously wrong?
Thanks
Rogan
On Sat, 17 Jun 2023 at 16:28, Rogan Dawes rogan@dawes.za.net wrote:
Thank you so much for the response! It is much appreciated!
I do hope to get JTAG working on the Hub v1, and then will be able to try to build a modern U-Boot which I can flash.
Regards,
Rogan
On Thu, 15 Jun 2023 at 22:01, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Thu, Jun 15, 2023 at 9:00 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi folks,
I am trying to boot a custom kernel on a Wink Hub v1, which has an
i.MX28
CPU, and is running U-Boot (U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)).
I have tried compiling my own modern kernel and putting it in place of
the
vendor (Linux version 2.6.35.3-flex-dvt) kernel on the flash chip, but
when
loading, I simply get the expected U-Boot loading messages, but then nothing at all from the serial port after that.
I'm trying to figure out where my problem is most likely to be. As far
as I
am aware from long-ago poking at U-Boot, the way that U-Boot passes arguments to the kernel has changed recently? Previously it was ATAGS,
and
now it expects a Device Tree Blob? Might this explain the failure to
boot
that I am seeing? And yes, I understand that given that
Yes, to boot a modern kernel, you need to generate a devicetree for the Wink Hubv1 board.
Then you build it and generate a .dtb file.
To boot zImage + dtb using an old bootloader that does not support booting dtb, you would need to select the following options in the kernel:
CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y
And then:
cat arch/arm/boot/zImage arch/arm/boot/dts/imx28-wink-hub-v1.dtb > zImage_with_dtb
And then boot zImage_with_dtb as you do with 2.6.35.
Ideally, you should also port a modern U-Boot version, which supports dtb by default and then you don't need the steps above.
Take a look at board/freescale/mx28eevk support for a reference.
Regards,
Fabio Estevam
Hi Rogan,
On Thu, Jun 22, 2023 at 7:09 PM Rogan Dawes rogan@dawes.za.net wrote:
I tried to follow your suggestion, but so far I have been unsuccessful.
I cloned Linus' latest source code, and then did:
make ARCH=arm mxs_defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- cat arch/arm/boot/zImage ./arch/arm/boot/dts/imx28-evk.dtb > arch/arm/boot/zImage_with_dtb
Do you have access to the Wink Hub v1 board schematics? What about the original U-Boot and kernel source?
You are using imx28-evk.dtb here, but not sure if the console pins are the same for the two boards.
It is better to create a minimal devicetree specific for Wink Hub v1. To start with, you can only describe the duart node there.
cd arch/arm/boot mkimage -T kernel -A arm -O linux -a 0x40008000 -e 0x40008000 -C none -d ./zImage_with_dtb uImage_with_dtb
then copied onto the Wink hub and did:
flash_erase /dev/mtd4 0 0 nandwrite -p -m /dev/mtd4 uImage_with_dtb reboot
I then interrupted u-boot, and had to update the number of bytes read from the mtd4 partition (was 0x00400000, now 0x00600000), as the new kernel was about 4 times larger than the vendor kernel, and I was getting checksum errors due to only partial read of the image.
setenv app_boot 'run appboot_args && nand read ${loadaddr} app-kernel 0x00600000 && bootm ${loadaddr}' run app_boot
NAND read: device 0 offset 0x2b00000, size 0x600000 6291456 bytes read: OK ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-22 21:37:11 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6279041 Bytes = 6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
And it stopped there after dumping some garbage to the screen.
You should also pass the kernel command line: console=ttyAMA0,115200n8
As far as I recall, the 2.6.35 kernel used a different console device.
Can you share the U-Boot log of the board booting the 2.6.35 kernel?
I did note that the mxs_defconfig did not define the appended DTB config, so I updated my .config as follows:
$ grep DTB .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
One thing you could also try is to load U-Boot via USB using this tool: https://source.denx.de/denx/mxsldr
To build U-Boot for mx28, please check:
https://source.denx.de/u-boot/u-boot/-/blob/master/doc/imx/common/mxs.txt
Hi Rogan,
On Thu, Jun 22, 2023 at 7:43 PM Fabio Estevam festevam@gmail.com wrote:
You should also pass the kernel command line: console=ttyAMA0,115200n8
As far as I recall, the 2.6.35 kernel used a different console device.
Yes, 2.6.35 uses ttyAM0. Mainline uses ttyAMA0 (note the extra A).
Please adjust it accordingly.
Hi Rogan,
On Thu, Jun 22, 2023 at 10:03 PM Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Thu, Jun 22, 2023 at 7:43 PM Fabio Estevam festevam@gmail.com wrote:
You should also pass the kernel command line: console=ttyAMA0,115200n8
As far as I recall, the 2.6.35 kernel used a different console device.
Yes, 2.6.35 uses ttyAM0. Mainline uses ttyAMA0 (note the extra A).
Please adjust it accordingly.
Also, I validated booting a uImage on a imx28-evk using the same procedure.
I used kernel 6.1.34.
$ grep DTB .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
=> setenv bootargs 'console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait' => print loadaddr loadaddr=0x42000000 => load mmc 0:2 $loadaddr uImage_with_dtb 5916489 bytes read in 1778 ms (3.2 MiB/s) => bootm ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-23 1:17:21 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5916425 Bytes = 5.6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.1.34-00030-ga03745a375fa-dirty (fabio@fabio-Precision-3551) (arm-linux-gnueabihf-gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #31 Thu Jun 22 22:12:44 -03 2023 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit ...
Most likely the ttyAMA0 change should allow you to boot.
Cheers
Kernel source is available here: https://github.com/winkapp/wink-hub-kernel-public
(and to close the loop, since I accidentally emailed Fabio without including the list, the console change to /dev/ttyAMA0 was absolutely the problem!)
Thanks again for your help.
Rogan
On Fri, 23 Jun 2023 at 03:25, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Thu, Jun 22, 2023 at 10:03 PM Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Thu, Jun 22, 2023 at 7:43 PM Fabio Estevam festevam@gmail.com
wrote:
You should also pass the kernel command line: console=ttyAMA0,115200n8
As far as I recall, the 2.6.35 kernel used a different console device.
Yes, 2.6.35 uses ttyAM0. Mainline uses ttyAMA0 (note the extra A).
Please adjust it accordingly.
Also, I validated booting a uImage on a imx28-evk using the same procedure.
I used kernel 6.1.34.
$ grep DTB .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
=> setenv bootargs 'console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait' => print loadaddr loadaddr=0x42000000 => load mmc 0:2 $loadaddr uImage_with_dtb 5916489 bytes read in 1778 ms (3.2 MiB/s) => bootm ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-23 1:17:21 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5916425 Bytes = 5.6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.1.34-00030-ga03745a375fa-dirty (fabio@fabio-Precision-3551) (arm-linux-gnueabihf-gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #31 Thu Jun 22 22:12:44 -03 2023 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit ...
Most likely the ttyAMA0 change should allow you to boot.
Cheers
Hi Rogan,
On Fri, Jun 23, 2023 at 3:46 AM Rogan Dawes rogan@dawes.za.net wrote:
Kernel source is available here: https://github.com/winkapp/wink-hub-kernel-public
Ok, I assume that arch/arm/mach-mx28/mx28evk_pins.orig.c is the original imx28-evk pinmux and arch/arm/mach-mx28/mx28evk_pins.c contains the specific pinmux for the imx28-wink-hub-v1 board.
The first thing I noticed is that the duart pins are different between the two boards.
imx28-wink-hub-v1 uses the I2C0 pads for duart.
Can you try the attached two patches that I generated against 6.1.34?
It is a super minimal device tree for imx28-wink-hub-v1 and should allow you to boot until it searches for the rootfs.
I am glad you managed to start seeing kernel console using a mainline kernel :-)
Hi Fabio,
Thanks so much for the effort put in. I just wanted to confirm that I am able to get console output when using the imx28-evk.dts file, although it crashes after a few lines of output. That seems to suggest that the additional pins that you have added in your patch are not necessary, and possibly even incorrect?
NAND read: device 0 offset 0x2b00000, size 0x600000 6291456 bytes read: OK ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-23 6:36:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6279441 Bytes = 6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.4.0-rc6-00242-g1639fae5132b (rogan@vermin) (arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #5 Fri Jun 23 08:35:38 SAST 2023 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit [ 0.000000] Memory policy: Data cache writeback [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000040000000-0x0000000043ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges
etc
Thanks
Rogan
On Fri, 23 Jun 2023 at 14:51, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Fri, Jun 23, 2023 at 3:46 AM Rogan Dawes rogan@dawes.za.net wrote:
Kernel source is available here:
https://github.com/winkapp/wink-hub-kernel-public
Ok, I assume that arch/arm/mach-mx28/mx28evk_pins.orig.c is the original imx28-evk pinmux and arch/arm/mach-mx28/mx28evk_pins.c contains the specific pinmux for the imx28-wink-hub-v1 board.
The first thing I noticed is that the duart pins are different between the two boards.
imx28-wink-hub-v1 uses the I2C0 pads for duart.
Can you try the attached two patches that I generated against 6.1.34?
It is a super minimal device tree for imx28-wink-hub-v1 and should allow you to boot until it searches for the rootfs.
I am glad you managed to start seeing kernel console using a mainline kernel :-)
Hi Rogan,
On Fri, Jun 23, 2023 at 10:53 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
Thanks so much for the effort put in. I just wanted to confirm that I am able to get console output when using the imx28-evk.dts file, although it crashes after a few lines of output. That seems to suggest that the additional pins that you have added in your patch are not necessary, and possibly even incorrect?
It could be that the kernel console log is appearing only because U-Boot did the correct pinmux of the duart pins.
If the arch/arm/mach-mx28/mx28evk_pins.c corresponds to the correct pinmux for the wink hub board, then the duart pins need to be as:
MX28_PAD_I2C0_SCL__DUART_RX MX28_PAD_I2C0_SDA__DUART_TX
like it is done on my patch.
Just so you know, I have no knowledge about the wink hub board.
My comment on the duart pin was merely due to code inspection.
NAND read: device 0 offset 0x2b00000, size 0x600000 6291456 bytes read: OK ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-23 6:36:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6279441 Bytes = 6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.4.0-rc6-00242-g1639fae5132b (rogan@vermin) (arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #5 Fri Jun 23 08:35:38 SAST 2023 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit [ 0.000000] Memory policy: Data cache writeback [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000040000000-0x0000000043ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges
Here is an updated dts with the GPMI node added.
Hopefully, with this one, the NAND flash device can be detected.
Does this dts boot for you without hanging in the USB part?
I understand the importance now. No, I got to the same result with your dts as with the evk one, crash after the usbcore modules were registered, and then binary garbage on the console.
I do understand that you are not familiar with the Wink Hub, and am especially appreciative of the time you are offering.
Is this still relevant to u-boot, or should this conversation move elsewhere, since this is more about the kernel now it seems? Although I guess modern u-boot also cares about device trees?
Regards,
Rogan
On Fri, 23 Jun 2023 at 16:05, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Fri, Jun 23, 2023 at 10:53 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
Thanks so much for the effort put in. I just wanted to confirm that I am
able to get console output when using the imx28-evk.dts file, although it crashes after a few lines of output. That seems to suggest that the additional pins that you have added in your patch are not necessary, and possibly even incorrect?
It could be that the kernel console log is appearing only because U-Boot did the correct pinmux of the duart pins.
If the arch/arm/mach-mx28/mx28evk_pins.c corresponds to the correct pinmux for the wink hub board, then the duart pins need to be as:
MX28_PAD_I2C0_SCL__DUART_RX MX28_PAD_I2C0_SDA__DUART_TX
like it is done on my patch.
Just so you know, I have no knowledge about the wink hub board.
My comment on the duart pin was merely due to code inspection.
NAND read: device 0 offset 0x2b00000, size 0x600000 6291456 bytes read: OK ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-23 6:36:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6279441 Bytes = 6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.4.0-rc6-00242-g1639fae5132b (rogan@vermin)
(arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #5 Fri Jun 23 08:35:38 SAST 2023
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ),
cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit [ 0.000000] Memory policy: Data cache writeback [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000040000000-0x0000000043ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges
Here is an updated dts with the GPMI node added.
Hopefully, with this one, the NAND flash device can be detected.
Does this dts boot for you without hanging in the USB part?
Kernel output up until the crash:
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.4.0-rc6-00242-g1639fae5132b (rogan@vermin) (arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #5 Fri Jun 23 08:35:38 SAST 2023 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit [ 0.000000] Memory policy: Data cache writeback [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000040000000-0x0000000043ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040000000-0x0000000043ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x0000000043ffffff] [ 0.000000] Kernel command line: noinitrd console=ttyAMA0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi [ 0.000000] Unknown kernel command line parameters "gpmi", will be passed to user space. [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear) [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256 [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 45044K/65536K available (8784K kernel code, 1205K rwdata, 2828K rodata, 252K init, 6469K bss, 20492K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] trace event string verifier disabled [ 0.000000] Running RCU self tests [ 0.000000] Running RCU synchronous self tests [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] clocksource: mxs_timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns [ 0.000007] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [ 0.003518] Console: colour dummy device 80x30 [ 0.003899] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.003958] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.004006] ... MAX_LOCK_DEPTH: 48 [ 0.004042] ... MAX_LOCKDEP_KEYS: 8192 [ 0.004075] ... CLASSHASH_SIZE: 4096 [ 0.004109] ... MAX_LOCKDEP_ENTRIES: 32768 [ 0.004141] ... MAX_LOCKDEP_CHAINS: 65536 [ 0.004173] ... CHAINHASH_SIZE: 32768 [ 0.004205] memory used by lock dependency info: 4061 kB [ 0.004239] memory used for stack traces: 2112 kB [ 0.004272] per task-struct memory footprint: 1536 bytes [ 0.004575] Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496) [ 0.081603] pid_max: default: 32768 minimum: 301 [ 0.083730] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.083869] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.097343] CPU: Testing write buffer coherency: ok [ 0.111000] Setting up static identity map for 0x40008400 - 0x40008458 [ 0.122358] devtmpfs: initialized [ 0.210895] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.211175] futex hash table entries: 256 (order: 1, 12288 bytes, linear) [ 0.212810] pinctrl core: initialized pinctrl subsystem [ 0.231662] NET: Registered PF_NETLINK/PF_ROUTE protocol family [ 0.245591] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.313115] platform 80018000.pinctrl: Fixed dependency cycle(s) with /apb@80000000/apbh@80000000/pinctrl@80018000/hog@0 [ 0.367352] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 0.393672] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 0.418068] gpio gpiochip2: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 0.442386] gpio gpiochip3: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 0.466456] gpio gpiochip4: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 0.574021] platform panel: Fixed dependency cycle(s) with /apb@80000000 /apbh@80000000/lcdif@80030000/port/endpoint [ 0.586898] Serial: AMBA PL011 UART driver [ 0.593614] 80074000.serial: ttyAMA0 at MMIO 0x80074000 (irq = 182, base_baud = 0) is a PL011 rev2 [ 0.594577] printk: console [ttyAMA0] enabled [ 3.352978] regulator-vddio-sd0 enforce active low on GPIO handle [ 3.362829] regulator-fec-3v3 enforce active low on GPIO handle [ 3.397532] SCSI subsystem initialized [ 3.419552] usbcore: registered new interface driver usbfs [ 3.426400] usbcore: registered new interface driver hub [ 3.432422] usbcore: registered new device driver usb
On Fri, 23 Jun 2023 at 16:25, Rogan Dawes rogan@dawes.za.net wrote:
I understand the importance now. No, I got to the same result with your dts as with the evk one, crash after the usbcore modules were registered, and then binary garbage on the console.
I do understand that you are not familiar with the Wink Hub, and am especially appreciative of the time you are offering.
Is this still relevant to u-boot, or should this conversation move elsewhere, since this is more about the kernel now it seems? Although I guess modern u-boot also cares about device trees?
Regards,
Rogan
On Fri, 23 Jun 2023 at 16:05, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Fri, Jun 23, 2023 at 10:53 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
Thanks so much for the effort put in. I just wanted to confirm that I
am able to get console output when using the imx28-evk.dts file, although it crashes after a few lines of output. That seems to suggest that the additional pins that you have added in your patch are not necessary, and possibly even incorrect?
It could be that the kernel console log is appearing only because U-Boot did the correct pinmux of the duart pins.
If the arch/arm/mach-mx28/mx28evk_pins.c corresponds to the correct pinmux for the wink hub board, then the duart pins need to be as:
MX28_PAD_I2C0_SCL__DUART_RX MX28_PAD_I2C0_SDA__DUART_TX
like it is done on my patch.
Just so you know, I have no knowledge about the wink hub board.
My comment on the duart pin was merely due to code inspection.
NAND read: device 0 offset 0x2b00000, size 0x600000 6291456 bytes read: OK ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-23 6:36:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6279441 Bytes = 6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.4.0-rc6-00242-g1639fae5132b (rogan@vermin)
(arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #5 Fri Jun 23 08:35:38 SAST 2023
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ),
cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit [ 0.000000] Memory policy: Data cache writeback [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000040000000-0x0000000043ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges
Here is an updated dts with the GPMI node added.
Hopefully, with this one, the NAND flash device can be detected.
Does this dts boot for you without hanging in the USB part?
On Fri, Jun 23, 2023 at 11:35 AM Rogan Dawes rogan@dawes.za.net wrote:
Kernel output up until the crash:
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.4.0-rc6-00242-g1639fae5132b (rogan@vermin) (arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #5 Fri Jun 23 08:35:38 SAST 2023 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit
Please also share the full log when using the simpler dts (which has USB disabled) plus the binary garbage on the console.
Cheers
On Fri, Jun 23, 2023 at 11:41 AM Fabio Estevam festevam@gmail.com wrote:
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.4.0-rc6-00242-g1639fae5132b (rogan@vermin) (arm-linux-gnueabi-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for
Also, please give it a try with kernel 6.1.35.
I suspect you may be facing a problem fixed in linux-next that has not landed in 6.4-rc yet.
Hi Rogan,
On Fri, Jun 23, 2023 at 11:25 AM Rogan Dawes rogan@dawes.za.net wrote:
I understand the importance now. No, I got to the same result with your dts as with the evk one, crash after the usbcore modules were registered, and then binary garbage on the console.
On the dts I shared, the USB nodes are disabled, so I am not sure why it crashes. Please share the full log of the crash.
I do understand that you are not familiar with the Wink Hub, and am especially appreciative of the time you are offering.
It is always a pleasure to see boards running a recent 6.4-rc kernel instead of the vendor 2.6.35 kernel :-)
Is this still relevant to u-boot, or should this conversation move elsewhere, since this is more about the kernel now it seems? Although I guess modern u-boot also cares about device trees?
Yes, I think we are getting off-topic on this list now :-)
Please move the discussion to linux-arm-kernel@lists.infradead.org and Cc me.
Circling back to this, I wanted to get a modern u-boot running on the Wink Hub v1 as well. Since it is possible to invoke SDP over USB (having soldered on a suitable microUSB connector), I have no concern about bricking it now. It's also a LOT easier than JTAG!
I tried to build and flash the mx28evk_defconfig, but failed to get any output on the serial console. This is likely to be unsurprising, due to the already established alternative configuration of the UART identified by Fabio.
I then patched imx28.dtsi to add duart_pins_c as per Fabio's previous patch for the Linux kernel:
+ duart_pins_c: duart@2 { + reg = <2>; + fsl,pinmux-ids = < + MX28_PAD_I2C0_SCL__DUART_RX + MX28_PAD_I2C0_SDA__DUART_TX + >; + fsl,drive-strength = <MXS_DRIVE_8mA>; + fsl,voltage = <MXS_VOLTAGE_HIGH>; + fsl,pull-up = <MXS_PULL_DISABLE>; + }; +
And updated mx28evk_defconfig to use duart_pins_c instead of duart_pins_a. However, I still got no output after using:
sudo $(which snagrecover) --soc imx28 -f src/snagrecover/templates/imx28-evk.yaml
with u-boot.sb in the current directory.
I also tried using the complete imx28-wink-hub-v1.dts as created by Fabio, and updated the .config to reference that instead of the imx28-evk, but I suspect that I may not have made the updates sufficiently well, if the name of the board needs to correspond with any details of the device tree? Neither of these resulted in any output.
Any other suggestions?
Regards,
Rogan Dawes
On Fri, 23 Jun 2023 at 03:25, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Thu, Jun 22, 2023 at 10:03 PM Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Thu, Jun 22, 2023 at 7:43 PM Fabio Estevam festevam@gmail.com wrote:
You should also pass the kernel command line: console=ttyAMA0,115200n8
As far as I recall, the 2.6.35 kernel used a different console device.
Yes, 2.6.35 uses ttyAM0. Mainline uses ttyAMA0 (note the extra A).
Please adjust it accordingly.
Also, I validated booting a uImage on a imx28-evk using the same procedure.
I used kernel 6.1.34.
$ grep DTB .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
=> setenv bootargs 'console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait' => print loadaddr loadaddr=0x42000000 => load mmc 0:2 $loadaddr uImage_with_dtb 5916489 bytes read in 1778 ms (3.2 MiB/s) => bootm ## Booting kernel from Legacy Image at 42000000 ... Image Name: Created: 2023-06-23 1:17:21 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5916425 Bytes = 5.6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.1.34-00030-ga03745a375fa-dirty (fabio@fabio-Precision-3551) (arm-linux-gnueabihf-gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #31 Thu Jun 22 22:12:44 -03 2023 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit ...
Most likely the ttyAMA0 change should allow you to boot.
Cheers
Hi Rogan,
On Fri, Aug 18, 2023 at 10:45 AM Rogan Dawes rogan@dawes.za.net wrote:
Circling back to this, I wanted to get a modern u-boot running on the Wink Hub v1 as well. Since it is possible to invoke SDP over USB (having soldered on a suitable microUSB connector), I have no concern about bricking it now. It's also a LOT easier than JTAG!
I tried to build and flash the mx28evk_defconfig, but failed to get any output on the serial console. This is likely to be unsurprising, due to the already established alternative configuration of the UART identified by Fabio.
I then patched imx28.dtsi to add duart_pins_c as per Fabio's previous patch for the Linux kernel:
- duart_pins_c: duart@2 {
- reg = <2>;
- fsl,pinmux-ids = <
- MX28_PAD_I2C0_SCL__DUART_RX
- MX28_PAD_I2C0_SDA__DUART_TX
- fsl,drive-strength = <MXS_DRIVE_8mA>;
- fsl,voltage = <MXS_VOLTAGE_HIGH>;
- fsl,pull-up = <MXS_PULL_DISABLE>;
- };
And updated mx28evk_defconfig to use duart_pins_c instead of duart_pins_a. However, I still got no output after using:
sudo $(which snagrecover) --soc imx28 -f src/snagrecover/templates/imx28-evk.yaml
I am not familiar with this tool. I was only aware of the one below:
https://source.denx.de/denx/mxsldr
Are you able to load the original vendor U-Boot with it?
Also, is the original vendor U-Boot source code available?
It is important to re-use the same DDR initialization from the original U-Boot.
with u-boot.sb in the current directory.
I also tried using the complete imx28-wink-hub-v1.dts as created by Fabio, and updated the .config to reference that instead of the imx28-evk, but I suspect that I may not have made the updates sufficiently well, if the name of the board needs to correspond with any details of the device tree? Neither of these resulted in any output.
Any other suggestions?
Please check board/freescale/mx28evk/iomux.c:
const iomux_cfg_t iomux_setup[] = { /* DUART */ MX28_PAD_PWM0__DUART_RX, MX28_PAD_PWM1__DUART_TX,
The DUART pins need to be changed here as well.
Hi Fabio,
As far as I am aware, the U-boot source for the Wink hub has not been made available anywhere. That said, the RAM chip in use on the board is marked D9LPX, which apparently corresponds to the following item: https://media-www.micron.com/-/media/client/global/documents/products/data-s...
I did try to change the iomux_cfg_t as suggested above, built using make mx28evk_defconfig && make u-boot.sb, and used mxsldr to try load it, to no avail. There was no output on the serial port at all, or any other suggestion that anything was running.
Any other suggestions?
Regards,
Rogan
On Tue, 22 Aug 2023 at 04:33, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Fri, Aug 18, 2023 at 10:45 AM Rogan Dawes rogan@dawes.za.net wrote:
Circling back to this, I wanted to get a modern u-boot running on the Wink Hub v1 as well. Since it is possible to invoke SDP over USB (having soldered on a suitable microUSB connector), I have no concern about bricking it now. It's also a LOT easier than JTAG!
I tried to build and flash the mx28evk_defconfig, but failed to get any output on the serial console. This is likely to be unsurprising, due to the already established alternative configuration of the UART identified by Fabio.
I then patched imx28.dtsi to add duart_pins_c as per Fabio's previous patch for the Linux kernel:
- duart_pins_c: duart@2 {
- reg = <2>;
- fsl,pinmux-ids = <
- MX28_PAD_I2C0_SCL__DUART_RX
- MX28_PAD_I2C0_SDA__DUART_TX
- fsl,drive-strength = <MXS_DRIVE_8mA>;
- fsl,voltage = <MXS_VOLTAGE_HIGH>;
- fsl,pull-up = <MXS_PULL_DISABLE>;
- };
And updated mx28evk_defconfig to use duart_pins_c instead of duart_pins_a. However, I still got no output after using:
sudo $(which snagrecover) --soc imx28 -f src/snagrecover/templates/imx28-evk.yaml
I am not familiar with this tool. I was only aware of the one below:
https://source.denx.de/denx/mxsldr
Are you able to load the original vendor U-Boot with it?
Also, is the original vendor U-Boot source code available?
It is important to re-use the same DDR initialization from the original U-Boot.
with u-boot.sb in the current directory.
I also tried using the complete imx28-wink-hub-v1.dts as created by Fabio, and updated the .config to reference that instead of the imx28-evk, but I suspect that I may not have made the updates sufficiently well, if the name of the board needs to correspond with any details of the device tree? Neither of these resulted in any output.
Any other suggestions?
Please check board/freescale/mx28evk/iomux.c:
const iomux_cfg_t iomux_setup[] = { /* DUART */ MX28_PAD_PWM0__DUART_RX, MX28_PAD_PWM1__DUART_TX,
The DUART pins need to be changed here as well.
Hi Rogan,
On Tue, Aug 22, 2023 at 6:42 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
As far as I am aware, the U-boot source for the Wink hub has not been made available anywhere. That said, the RAM chip in use on the board
Was there a formal request for the U-Boot source code to Wink?
As per the GPL license, they have to share the U-Boot source code.
is marked D9LPX, which apparently corresponds to the following item: https://media-www.micron.com/-/media/client/global/documents/products/data-s...
There is a tool from NXP that helps with the i.MX28 DDR2 controller initialization for a specific DDR model:
https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/9...
The DDR initialization values obtained from this tool are then used in U-Boot inside the 'mxs_dram_vals' array.
There is a common DDR configuration at arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c.
Most likely, in your case, it will require a custom mxs_dram_vals initialization, like it is done at board/liebherr/xea/spl_xea.c.
I did try to change the iomux_cfg_t as suggested above, built using make mx28evk_defconfig && make u-boot.sb, and used mxsldr to try load it, to no avail. There was no output on the serial port at all, or any other suggestion that anything was running.
It has been a long time since I used the mxsldr tool.
When time permits, I can try to load a recent U-Boot over USB using this tool on a imx28-evk.
Cheers
Hi Fabio,
On Tue, 22 Aug 2023 at 13:44, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Tue, Aug 22, 2023 at 6:42 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
As far as I am aware, the U-boot source for the Wink hub has not been made available anywhere. That said, the RAM chip in use on the board
Was there a formal request for the U-Boot source code to Wink?
As per the GPL license, they have to share the U-Boot source code.
I have just asked them for it, so let's see what happens. I'm not optimistic, though, given their financial troubles. I am not aware of anyone else asking them. However, I do believe that there have been requests for the kernel sources for the Wink Hub 2, which were ignored, suggesting that they are not the best GPL citizen.
is marked D9LPX, which apparently corresponds to the following item: https://media-www.micron.com/-/media/client/global/documents/products/data-s...
There is a tool from NXP that helps with the i.MX28 DDR2 controller initialization for a specific DDR model:
https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/9...
The DDR initialization values obtained from this tool are then used in U-Boot inside the 'mxs_dram_vals' array.
There is a common DDR configuration at arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c.
Most likely, in your case, it will require a custom mxs_dram_vals initialization, like it is done at board/liebherr/xea/spl_xea.c.
I did try to change the iomux_cfg_t as suggested above, built using make mx28evk_defconfig && make u-boot.sb, and used mxsldr to try load it, to no avail. There was no output on the serial port at all, or any other suggestion that anything was running.
It has been a long time since I used the mxsldr tool.
When time permits, I can try to load a recent U-Boot over USB using this tool on a imx28-evk.
Cheers
I think fiddling with RAM timings is a little more in the weeds than I am ready to go at this point. I did see this post (http://web.archive.org/web/20151005053615/http://jalderman.org/?p=348), suggesting that it was not too difficult to get it working using mainline u-boot. That said, I also note that some teardowns mention that the RAM is a Nanya part, while I have Micron, so perhaps I should not place too much reliance on that.
Rogan
Hi folks,
I eventually decided that I did need to figure out the DRAM timings for the Micron chip on my board, but I found an easier way than actually "understanding what I'm doing"! :-)
I pulled the vendor U-Boot image off the flash, skipped the appropriate number of bytes until I was actually dealing with a u-boot.sb formatted image (looking for the STMP signature I found in the compiled mainline u-boot), then used the Rockbox project's sbtoelf tool to convert the SB back to two ELF files, the SPL.elf and the u-boot.elf. From there I loaded the SPL.elf into ghidra, then went looking for byte sequences found in arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c to see if I could locate them in the vendor blob. I did, right at the end of the binary, then converted bytes into uint32 sequences so that I could compare with the mxs_dram_vals for CONFIG_MX28.
Did the compare and found a single bit that is different between the two sequences of initialisation values. Literally a 1 to a 0, and that is all. So I built mainline with that change, and an updated iomux_setup because the Wink Hub v1 uses MX28_PAD_I2C0_SCL__DUART_RX and MX28_PAD_I2C0_SDA__DUART_TX for its console pins. i was hoping to see it boot via mxsldr, but unfortunately, I got nothing.
How can I get the SPL to emit something on the console to confirm it is running? i.e. before the DRAM initialisation?
Regards,
Rogan
On Wed, 23 Aug 2023 at 17:56, Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
On Tue, 22 Aug 2023 at 13:44, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Tue, Aug 22, 2023 at 6:42 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
As far as I am aware, the U-boot source for the Wink hub has not been made available anywhere. That said, the RAM chip in use on the board
Was there a formal request for the U-Boot source code to Wink?
As per the GPL license, they have to share the U-Boot source code.
I have just asked them for it, so let's see what happens. I'm not optimistic, though, given their financial troubles. I am not aware of anyone else asking them. However, I do believe that there have been requests for the kernel sources for the Wink Hub 2, which were ignored, suggesting that they are not the best GPL citizen.
is marked D9LPX, which apparently corresponds to the following item:
https://media-www.micron.com/-/media/client/global/documents/products/data-s...
There is a tool from NXP that helps with the i.MX28 DDR2 controller initialization for a specific DDR model:
https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/9...
The DDR initialization values obtained from this tool are then used in U-Boot inside the 'mxs_dram_vals' array.
There is a common DDR configuration at arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c.
Most likely, in your case, it will require a custom mxs_dram_vals initialization, like it is done at board/liebherr/xea/spl_xea.c.
I did try to change the iomux_cfg_t as suggested above, built using make mx28evk_defconfig && make u-boot.sb, and used mxsldr to try load it, to no avail. There was no output on the serial port at all, or any other suggestion that anything was running.
It has been a long time since I used the mxsldr tool.
When time permits, I can try to load a recent U-Boot over USB using this tool on a imx28-evk.
Cheers
I think fiddling with RAM timings is a little more in the weeds than I am ready to go at this point. I did see this post (http://web.archive.org/web/20151005053615/http://jalderman.org/?p=348), suggesting that it was not too difficult to get it working using mainline u-boot. That said, I also note that some teardowns mention that the RAM is a Nanya part, while I have Micron, so perhaps I should not place too much reliance on that.
Rogan
Hi Rogan,
On Sun, Sep 24, 2023 at 5:16 PM Rogan Dawes rogan@dawes.za.net wrote:
Hi folks,
I eventually decided that I did need to figure out the DRAM timings for the Micron chip on my board, but I found an easier way than actually "understanding what I'm doing"! :-)
I pulled the vendor U-Boot image off the flash, skipped the appropriate number of bytes until I was actually dealing with a u-boot.sb formatted image (looking for the STMP signature I found in the compiled mainline u-boot), then used the Rockbox project's sbtoelf tool to convert the SB back to two ELF files, the SPL.elf and the u-boot.elf. From there I loaded the SPL.elf into ghidra, then went looking for byte sequences found in arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c to see if I could locate them in the vendor blob. I did, right at the end of the binary, then converted bytes into uint32 sequences so that I could compare with the mxs_dram_vals for CONFIG_MX28.
Did the compare and found a single bit that is different between the two sequences of initialisation values. Literally a 1 to a 0, and that is all. So I built mainline with that change, and an updated iomux_setup because the Wink Hub v1 uses MX28_PAD_I2C0_SCL__DUART_RX and MX28_PAD_I2C0_SDA__DUART_TX for its console pins. i was hoping to see it boot via mxsldr, but unfortunately, I got nothing.
Ideally, you should create a new imx28-wink_defconfig.
For a quick test, besides changing iomux_setup, please make sure that arch/arm/dts/imx28-evk.dts also has the duart pins changed.
How can I get the SPL to emit something on the console to confirm it is running? i.e. before the DRAM initialisation?
SPL runs from the internal RAM, and should print something to the console prior to the DRAM init.
Hi Fabio,
I used the following diff with "make mx28evk_defconfig", but unfortunately still get absolutely nothing on the DUART when running "mxsloader u-boot.sb". In fact, mxsloader returns immediately on trying to load my own u-boot.sb, whereas it hangs when running the vendor u-boot.sb, I assume because the CALL never returns. Additionally, there is no need to reset the board between attempting a custom u-boot and the vendor u-boot, indicating that the ROM-based SDP protocol handler is still running. This suggests that there is something wrong with the format of the u-boot.sb file which the ROM-based SDP protocol handler is rejecting, I would think?
I did confirm that the correct DTB file is being used, as the dts/dt.dtb file is identical to arch/arm/dts/imx28-wink-hub-v1.dtb. $ diff dts/dt.dtb arch/arm/dts/imx28-wink-hub-v1.dtb $ grep -i wink .config CONFIG_DEFAULT_DEVICE_TREE="imx28-wink-hub-v1" CONFIG_OF_LIST="imx28-wink-hub-v1"
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index a94803ee93..f4d6cac878 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -29,7 +29,7 @@ __weak uint32_t mxs_dram_vals[] = { 0x00000000, 0x00000100, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00010101, 0x01010101, - 0x000f0f01, 0x0f02020a, 0x00000000, 0x00010101, + 0x000f0f01, 0x0f02020a, 0x00000000, 0x00000101, 0x00000100, 0x00000100, 0x00000000, 0x00000002, 0x01010000, 0x07080403, 0x06005003, 0x0a0000c8, 0x02009c40, 0x0002030c, 0x0036a609, 0x031a0612, diff --git a/arch/arm/dts/imx28-wink-hub-v1.dts b/arch/arm/dts/imx28-wink-hub-v1.dts new file mode 100644 index 0000000000..b0bddebce8 --- /dev/null +++ b/arch/arm/dts/imx28-wink-hub-v1.dts @@ -0,0 +1,206 @@ +// SPDX-License-Identifier: GPL-2.0+ +// Copyright (C) 2023 Fabio Estevam festevam@gmail.com + +/dts-v1/; +#include <dt-bindings/gpio/gpio.h> +#include "imx28.dtsi" +/ { + model = "i.MX28 Wink Hub v1"; + compatible = "wink,imx28-wink-hub-v1", "fsl,imx28"; + + memory@40000000 { + device_type = "memory"; + reg = <0x40000000 0>; /* will be filled in by U-Boot */ + }; + + reg_wifi: regulator-wifi { + compatible = "regulator-fixed"; + pinctrl-names = "default"; + pinctrl-0 = <&wifi_enable>; + regulator-name = "wifi"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + gpio = <&gpio1 13 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + pwmleds { + compatible = "pwm-leds"; + + led-red { + label = "red"; + max-brightness = <255>; + pwms = <&pwm 0 500000>; + }; + + led-green { + label = "green"; + max-brightness = <255>; + pwms = <&pwm 1 500000>; + }; + + led-blue { + label = "blue"; + max-brightness = <255>; + pwms = <&pwm 3 500000>; + }; + }; +}; + +&auart0 { + pinctrl-names = "default"; + pinctrl-0 = <&auart0_pins_a>; + uart-has-rtscts; + status = "okay"; +}; + +&auart1 { + pinctrl-names = "default"; + pinctrl-0 = <&auart1_2pins_a>; + status = "okay"; +}; + +&auart2 { + pinctrl-names = "default"; + pinctrl-0 = <&auart2_2pins_a>; + status = "okay"; +}; + +&auart3 { + pinctrl-names = "default"; + pinctrl-0 = <&auart3_2pins_a>; + status = "okay"; +}; + +&auart4 { + pinctrl-names = "default"; + pinctrl-0 = <&auart4_pins_a>; + uart-has-rtscts; + status = "okay"; +}; + +&duart { + pinctrl-names = "default"; + pinctrl-0 = <&duart_pins_c>; + status = "okay"; +}; + +&gpmi { + pinctrl-names = "default"; + pinctrl-0 = <&gpmi_pins_a &gpmi_pins_extra>; + status = "okay"; + + partition@0 { + label = "gpmi-nfc-0-boot"; + reg = <0x0000000 0x300000>; + read-only; + }; + + partition@300000 { + label = "updater-kernel"; + reg = <0x0300000 0x400000>; + }; + + partition@700000 { + label = "updater-rootfs"; + reg = <0x0700000 0x1c00000>; + }; + + partition@2300000 { + label = "database"; + reg = <0x2300000 0x0800000>; + }; + + partition@2b00000 { + label = "app-kernel"; + reg = <0x2b00000 0x0800000>; + }; + + partition@3300000 { + label = "gpmi-nfc-general-use"; + reg = <0x3300000 0x4d00000>; + }; +}; + +&pwm { + pinctrl-names = "default"; + pinctrl-0 = <&pwm0_pins_a &pwm1_pins_a &pwm3_pins_a>; + status = "okay"; +}; + +&ssp0 { + compatible = "fsl,imx28-mmc"; + pinctrl-names = "default"; + pinctrl-0 = <&mmc0_4bit_pins_a &mmc0_sck_cfg>; + vmmc-supply = <®_wifi>; + bus-width = <4>; + status = "okay"; +}; + +&ssp3 { + compatible = "fsl,imx28-spi"; + pinctrl-names = "default"; + pinctrl-0 = <&spi3_pins_b>; + status = "okay"; + + spidev@0 { + /* Generic compatible to make spidev happy */ + compatible = "rohm,dh2228fv"; + reg = <0>; + spi-max-frequency = <24000000>; + }; +}; + +&usb0 { + dr_mode = "peripheral"; + status = "okay"; +}; + +&usbphy0 { + status = "okay"; +}; + +&pinctrl { + pinctrl-names = "default"; + pinctrl-0 = <&hog_pins_a>; + + hog_pins_a: hog@0 { + reg = <0>; + fsl,pinmux-ids = < + MX28_PAD_LCD_D07__GPIO_1_7 /* Z-Wave reset connection high output */ + MX28_PAD_LCD_D08__GPIO_1_8 /* Lutron Clear-Connect button */ + MX28_PAD_LCD_D09__GPIO_1_9 /* Zigbee reset */ + MX28_PAD_LCD_D10__GPIO_1_10 /* Lutron reset */ + MX28_PAD_LCD_D12__GPIO_1_12 /* Input Zigbee interrupt */ + MX28_PAD_LCD_D14__GPIO_1_14 /* BT power down */ + MX28_PAD_LCD_D15__GPIO_1_15 /* Kidde Reset */ + MX28_PAD_LCD_D16__GPIO_1_16 /* Kidde Data */ + MX28_PAD_LCD_D19__GPIO_1_19 /* Kidde RF Clock */ + MX28_PAD_LCD_D20__GPIO_1_20 /* Kidde GPIO */ + >; + fsl,drive-strength = <MXS_DRIVE_4mA>; + fsl,voltage = <MXS_VOLTAGE_HIGH>; + fsl,pull-up = <MXS_PULL_DISABLE>; + }; + + gpmi_pins_extra: gpmi-pins-extra@0 { + reg = <0>; + fsl,pinmux-ids = < + MX28_PAD_GPMI_CE1N__GPMI_CE1N + MX28_PAD_GPMI_RDY1__GPMI_READY1 + >; + fsl,drive-strength = <MXS_DRIVE_4mA>; + fsl,voltage = <MXS_VOLTAGE_HIGH>; + fsl,pull-up = <MXS_PULL_DISABLE>; + }; + + wifi_enable: wifi-enable@1 { + reg = <1>; + fsl,pinmux-ids = < + MX28_PAD_LCD_D13__GPIO_1_13 + >; + fsl,drive-strength = <MXS_DRIVE_4mA>; + fsl,voltage = <MXS_VOLTAGE_HIGH>; + fsl,pull-up = <MXS_PULL_DISABLE>; + }; +}; diff --git a/arch/arm/dts/imx28.dtsi b/arch/arm/dts/imx28.dtsi index 130b4145af..b4e2c8ec05 100644 --- a/arch/arm/dts/imx28.dtsi +++ b/arch/arm/dts/imx28.dtsi @@ -239,6 +239,17 @@ fsl,pull-up = <MXS_PULL_DISABLE>; };
+ duart_pins_c: duart@2 { + reg = <2>; + fsl,pinmux-ids = < + MX28_PAD_I2C0_SCL__DUART_RX + MX28_PAD_I2C0_SDA__DUART_TX + >; + fsl,drive-strength = <MXS_DRIVE_8mA>; + fsl,voltage = <MXS_VOLTAGE_HIGH>; + fsl,pull-up = <MXS_PULL_DISABLE>; + }; + duart_4pins_a: duart-4pins@0 { reg = <0>; fsl,pinmux-ids = < @@ -404,6 +415,20 @@ fsl,pull-up = <MXS_PULL_DISABLE>; };
+ auart4_pins_a: auart4-4pins@0 { + reg = <0>; + fsl,pinmux-ids = < + MX28_PAD_SAIF0_BITCLK__AUART4_RX + MX28_PAD_SAIF0_SDATA0__AUART4_TX + MX28_PAD_SAIF0_MCLK__AUART4_CTS + MX28_PAD_SAIF0_LRCLK__AUART4_RTS + >; + fsl,drive-strength = <MXS_DRIVE_4mA>; + fsl,voltage = <MXS_VOLTAGE_HIGH>; + fsl,pull-up = <MXS_PULL_DISABLE>; + }; + + auart4_2pins_a: auart4@0 { reg = <0>; fsl,pinmux-ids = < @@ -719,6 +744,16 @@ fsl,pull-up = <MXS_PULL_DISABLE>; };
+ pwm1_pins_a: pwm1@0 { + reg = <0>; + fsl,pinmux-ids = < + MX28_PAD_PWM1__PWM_1 + >; + fsl,drive-strength = <MXS_DRIVE_4mA>; + fsl,voltage = <MXS_VOLTAGE_HIGH>; + fsl,pull-up = <MXS_PULL_DISABLE>; + }; + pwm2_pins_a: pwm2@0 { reg = <0>; fsl,pinmux-ids = < diff --git a/board/freescale/mx28evk/iomux.c b/board/freescale/mx28evk/iomux.c index cc0c858854..1e9ba07f8f 100644 --- a/board/freescale/mx28evk/iomux.c +++ b/board/freescale/mx28evk/iomux.c @@ -22,8 +22,8 @@
const iomux_cfg_t iomux_setup[] = { /* DUART */ - MX28_PAD_PWM0__DUART_RX, - MX28_PAD_PWM1__DUART_TX, + MX28_PAD_I2C0_SCL__DUART_RX, + MX28_PAD_I2C0_SDA__DUART_TX,
/* MMC0 */ MX28_PAD_SSP0_DATA0__SSP0_D0 | MUX_CONFIG_SSP0,
On Mon, 25 Sept 2023 at 01:38, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Sun, Sep 24, 2023 at 5:16 PM Rogan Dawes rogan@dawes.za.net wrote:
Hi folks,
I eventually decided that I did need to figure out the DRAM timings for
the Micron chip on my board, but I found an easier way than actually "understanding what I'm doing"! :-)
I pulled the vendor U-Boot image off the flash, skipped the appropriate
number of bytes until I was actually dealing with a u-boot.sb formatted image (looking for the STMP signature I found in the compiled mainline u-boot), then used the Rockbox project's sbtoelf tool to convert the SB back to two ELF files, the SPL.elf and the u-boot.elf. From there I loaded the SPL.elf into ghidra, then went looking for byte sequences found in arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c to see if I could locate them in the vendor blob. I did, right at the end of the binary, then converted bytes into uint32 sequences so that I could compare with the mxs_dram_vals for CONFIG_MX28.
Did the compare and found a single bit that is different between the two
sequences of initialisation values. Literally a 1 to a 0, and that is all. So I built mainline with that change, and an updated iomux_setup because the Wink Hub v1 uses MX28_PAD_I2C0_SCL__DUART_RX and MX28_PAD_I2C0_SDA__DUART_TX for its console pins. i was hoping to see it boot via mxsldr, but unfortunately, I got nothing.
Ideally, you should create a new imx28-wink_defconfig.
For a quick test, besides changing iomux_setup, please make sure that arch/arm/dts/imx28-evk.dts also has the duart pins changed.
How can I get the SPL to emit something on the console to confirm it is
running? i.e. before the DRAM initialisation?
SPL runs from the internal RAM, and should print something to the console prior to the DRAM init.
Hi Rogan,
On Mon, Sep 25, 2023 at 6:52 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
I used the following diff with "make mx28evk_defconfig", but unfortunately still get absolutely nothing on the DUART when running "mxsloader u-boot.sb". In fact, mxsloader returns immediately on trying to load my own u-boot.sb, whereas it hangs when running the vendor u-boot.sb, I assume because the CALL never returns. Additionally, there is no need to reset the board between attempting a custom u-boot and the vendor u-boot, indicating that the ROM-based SDP protocol handler is still running. This suggests that there is something wrong with the format of the u-boot.sb file which the ROM-based SDP protocol handler is rejecting, I would think?
I just tested loading u-boot.sb via mxsldr on my imx28-evk.
I configured the boot jumpers to USB boot, turned on the board and then saw that it gets recognized by the host PC:
$ dmesg .... [1710347.828895] usb 1-1: new high-speed USB device number 96 using xhci_hcd [1710347.977657] usb 1-1: New USB device found, idVendor=15a2, idProduct=004f, bcdDevice= 0.01 [1710347.977672] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1710347.977678] usb 1-1: Product: ROM Recovery [1710347.977682] usb 1-1: Manufacturer: Freescale,Inc. [1710347.979708] hid-generic 0003:15A2:004F.0014: hiddev0,hidraw1: USB HID v1.10 Device [Freescale,Inc. ROM Recovery] on usb-0000:00:14.0-1/input0
After that, I loaded the u-boot.sb via mxsldr:
$ sudo ./mxsldr u-boot.sb Detected: i.MX28 Chip ID: 0x2800 Chip Revision: 0x0001 ROM Version: 0x0101 Protocol Version: 0x0100
Do you get these messages above (both the dmesg as well the messages after running mxsldr)?
And in the console, I do see the U-Boot messages coming up:
HTLLCLLC
U-Boot 2023.10-rc4-00057-g4cb31a9f3560 (Sep 25 2023 - 09:49:04 -0300)
CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: USB #0 DRAM: 128 MiB Core: 89 devices, 12 uclasses, devicetree: separate NAND: 0 MiB MMC: MXS MMC: 0 Loading Environment from MMC... *** Warning - No block device, using default environment
In: serial Out: serial Err: serial Hit any key to stop autoboot: 0
Hi Fabio,
On Mon, 25 Sep 2023 at 15:04, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Mon, Sep 25, 2023 at 6:52 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
I used the following diff with "make mx28evk_defconfig", but
unfortunately still get absolutely nothing on the DUART when running "mxsloader u-boot.sb". In fact, mxsloader returns immediately on trying to load my own u-boot.sb, whereas it hangs when running the vendor u-boot.sb, I assume because the CALL never returns. Additionally, there is no need to reset the board between attempting a custom u-boot and the vendor u-boot, indicating that the ROM-based SDP protocol handler is still running. This suggests that there is something wrong with the format of the u-boot.sb file which the ROM-based SDP protocol handler is rejecting, I would think?
I just tested loading u-boot.sb via mxsldr on my imx28-evk.
I configured the boot jumpers to USB boot, turned on the board and then saw that it gets recognized by the host PC:
$ dmesg .... [1710347.828895] usb 1-1: new high-speed USB device number 96 using xhci_hcd [1710347.977657] usb 1-1: New USB device found, idVendor=15a2, idProduct=004f, bcdDevice= 0.01 [1710347.977672] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1710347.977678] usb 1-1: Product: ROM Recovery [1710347.977682] usb 1-1: Manufacturer: Freescale,Inc. [1710347.979708] hid-generic 0003:15A2:004F.0014: hiddev0,hidraw1: USB HID v1.10 Device [Freescale,Inc. ROM Recovery] on usb-0000:00:14.0-1/input0
After that, I loaded the u-boot.sb via mxsldr:
$ sudo ./mxsldr u-boot.sb Detected: i.MX28 Chip ID: 0x2800 Chip Revision: 0x0001 ROM Version: 0x0101 Protocol Version: 0x0100
Do you get these messages above (both the dmesg as well the messages after running mxsldr)?
Yes, I get both the dmesg output showing the usb device, and the output from mxsldr.
And in the console, I do see the U-Boot messages coming up:
I see absolutely nothing in the console.
I’m wondering whether I can possibly execute the vendor SPL with a modern u-boot?
And if that works, try and narrow down the differences.
Rogan
On Mon, Sep 25, 2023 at 11:00 AM Rogan Dawes rogan@dawes.za.net wrote:
I see absolutely nothing in the console.
I’m wondering whether I can possibly execute the vendor SPL with a modern u-boot?
The old U-Boot vendor does not use SPL. It uses an old mechanism called bootlets.
I suggest that we start from scratch with this imx28-wink-hub support that I have just added: https://github.com/fabioestevam/u-boot/commits/wink
To build it:
make imx28-wink-hub_defconfig make u-boot.sb
Then try to load u-boot.sb via mxsldr.
If it still fails, then I suspect that the power management unit (PMU) may be incorrectly configured causing the board to not power up.
Try playing with the CONFIG_SPL_MXS_PMU_ options.
From configs/imx28_xea_defconfig, for example:
CONFIG_SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT=y CONFIG_SPL_MXS_PMU_DISABLE_BATT_CHARGE=y # CONFIG_SPL_MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR is not set
That outputs LLC about a second after the mxsldr terminates (kinda slowly, the individual characters can be seen being emitted one at a time), and then about 5 seconds later, "Pref". But nothing after that point.
At least it looks like there is something happening, which is excellent!
Thank you!
Without CONFIG_SPL_MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR=y, (i.e. all 3 PMU options not set) I still get the LLC\nPref as previously.
With only CONFIG_SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT=y, I get LLC\nPref With only CONFIG_SPL_MXS_PMU_DISABLE_BATT_CHARGE=y, I get LLC\nPref With only CONFIG_SPL_MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR=y, I get LLC\nPref
With CONFIG_SPL_MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR=y, AND: - CONFIG_SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT=y, I just get a single L. - CONFIG_SPL_MXS_PMU_DISABLE_BATT_CHARGE=y, I get the LLC\nPref as previously.
With CONFIG_SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT=y AND CONFIG_SPL_MXS_PMU_DISABLE_BATT_CHARGE=y, I get LLC\nPref
With all three =y, I just get L
Rogan
On Mon, 25 Sept 2023 at 17:50, Fabio Estevam festevam@gmail.com wrote:
On Mon, Sep 25, 2023 at 11:00 AM Rogan Dawes rogan@dawes.za.net wrote:
I see absolutely nothing in the console.
I’m wondering whether I can possibly execute the vendor SPL with a
modern u-boot?
The old U-Boot vendor does not use SPL. It uses an old mechanism called bootlets.
I suggest that we start from scratch with this imx28-wink-hub support that I have just added: https://github.com/fabioestevam/u-boot/commits/wink
To build it:
make imx28-wink-hub_defconfig make u-boot.sb
Then try to load u-boot.sb via mxsldr.
If it still fails, then I suspect that the power management unit (PMU) may be incorrectly configured causing the board to not power up.
Try playing with the CONFIG_SPL_MXS_PMU_ options.
From configs/imx28_xea_defconfig, for example:
CONFIG_SPL_MXS_PMU_MINIMAL_VDD5V_CURRENT=y CONFIG_SPL_MXS_PMU_DISABLE_BATT_CHARGE=y # CONFIG_SPL_MXS_PMU_ENABLE_4P2_LINEAR_REGULATOR is not set
Hi Rogan,
On Mon, Sep 25, 2023 at 4:27 PM Rogan Dawes rogan@dawes.za.net wrote:
That outputs LLC about a second after the mxsldr terminates (kinda slowly, the individual characters can be seen being emitted one at a time), and then about 5 seconds later, "Pref". But nothing after that point.
At least it looks like there is something happening, which is excellent!
I pushed a change in my branch. Please give it a try.
Hi Fabio,
That prints "LLC", but does not print "Pref".
Rogan
On Tue, 26 Sept 2023 at 02:15, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Mon, Sep 25, 2023 at 4:27 PM Rogan Dawes rogan@dawes.za.net wrote:
That outputs LLC about a second after the mxsldr terminates (kinda
slowly, the individual characters can be seen being emitted one at a time), and then about 5 seconds later, "Pref". But nothing after that point.
At least it looks like there is something happening, which is excellent!
I pushed a change in my branch. Please give it a try.
Hi Rogan,
On Tue, Sep 26, 2023 at 1:01 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
That prints "LLC", but does not print "Pref".
What happens if you unselect DM_SERIAL like this:
--- a/configs/imx28-wink-hub_defconfig +++ b/configs/imx28-wink-hub_defconfig @@ -58,4 +58,3 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_RTC_MXS=y -CONFIG_DM_SERIAL=y
WARNING: unmet direct dependencies detected for PL01X_SERIAL Depends on [n]: SERIAL [=y] && DM_SERIAL [=n] Selected by [y]: - TARGET_IMX28WINKHUB [=y] && <choice>
WARNING: unmet direct dependencies detected for PL01X_SERIAL Depends on [n]: SERIAL [=y] && DM_SERIAL [=n] Selected by [y]: - TARGET_IMX28WINKHUB [=y] && <choice>
I also tried building and booting your latest version, but just got "LLC".
I'll try putting a logic analyser on the UART pins to see if anything else shows up, but I didn't see anything else on the USB-UART at 115200.
Where are the LLC characters coming from? It's a little tricky to grep the source for a single character :-(
Rogan
On Tue, 26 Sept 2023 at 18:47, Fabio Estevam festevam@gmail.com wrote:
Hi Rogan,
On Tue, Sep 26, 2023 at 1:01 AM Rogan Dawes rogan@dawes.za.net wrote:
Hi Fabio,
That prints "LLC", but does not print "Pref".
What happens if you unselect DM_SERIAL like this:
--- a/configs/imx28-wink-hub_defconfig +++ b/configs/imx28-wink-hub_defconfig @@ -58,4 +58,3 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_RTC_MXS=y -CONFIG_DM_SERIAL=y
participants (2)
-
Fabio Estevam -
Rogan Dawes