Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

unrecognized JEDEC id bytes: 0b, 40, 18 #11

Closed
AndersBNielsen opened this issue Jan 10, 2020 · 23 comments
Closed

unrecognized JEDEC id bytes: 0b, 40, 18 #11

AndersBNielsen opened this issue Jan 10, 2020 · 23 comments

Comments

@AndersBNielsen
Copy link

AndersBNielsen commented Jan 10, 2020 •
edited by thirtythreeforty

Hi! Amazing writeup, George! I got myself a Lichee Nano to try this out for myself.

It compiled ok (except for fortune due to a cmake error - so I disabled it).
It flashed ok (even though I know my SPI Flash is 16Mb)

When booting, Uboot doesn't seem to know what to do with the 16mb flash. Any hints on how to make it work with my Lichee Nano?

This is my boot output:

U-Boot SPL 2019.04 (Jan 09 2020 - 18:03:40 +0100)
DRAM: 32 MiB
SPL: Unsupported Boot Device!
Trying to boot from sunxi SPI


U-Boot 2019.04 (Jan 09 2020 - 18:03:40 +0100) Allwinner Technology

CPU:   Allwinner F Series (SUNIV)
Model: George Hilliard's business card
DRAM:  32 MiB
In:    serial@1c25000
Out:   serial@1c25000
Err:   serial@1c25000
Hit any key to stop autoboot:  0
unrecognized JEDEC id bytes: 0b, 40, 18
Failed to initialize SPI flash at 0:0 (error -2)
Could not find a valid device for spi-flash
Partition rootubi not found!
Error, no UBI device selected!
Error, no UBI device selected!
=> sf probe
unrecognized JEDEC id bytes: 0b, 40, 18
Failed to initialize SPI flash at 0:0 (error -2)
=>
@thirtythreeforty
Copy link
Owner

thirtythreeforty commented Jan 10, 2020 •
edited

Hey! I think you did everything right.

unrecognized JEDEC id bytes: 0b, 40, 18

This means that U-Boot found the flash but couldn't find its JEDEC ID in its table. Typically this means support is not compiled in, and you need to add support in the U-Boot configuration.

To do this, get a magnifying glass and note the brand of the SPI flash chip on your Nano. On your workstation, run:

make uboot-menuconfig

and a screen with lots of menu items should appear. Navigate to the SPI flash support under Device Drivers > MTD Support > SPI Flash Support and you should see a list of flash vendors.

Just scroll to the one that's on your board and hit Space to check it. Then Right will highlight Save. Save to .config (should be pre-filled). Now keep hitting Exit until you're back at the command line.

(Sounds like you know how to work menuconfig already; these instructions are just detailed for future Googlers :)

Now you can run

make

to generate a new image.

One problem is that you might not be able to flash the new image because the processor no longer goes in FEL mode (it finds the U-Boot image just fine, U-Boot gets stuck though). You can short the CS and GND pins of the flash during boot to force the processor into FEL mode.

If you get it working, you can tell me which flash comes on the Lichee Nano, or send me a patch (make uboot-update-defconfig), so I can update this repository!

Good luck. Lemme know if you have problems.

@AndersBNielsen
Copy link
Author

AndersBNielsen commented Jan 11, 2020 •
edited by thirtythreeforty

Thanks for getting back to this so fast! The JEDEC ID is for xt25f128b.
It doesn't seem to be available in uboot-menuconfig. According to this blog (and Google translate) it's a Winbond clone and needs to be added to uboot's spi id's.

https://zhuanlan.zhihu.com/p/76221655

I think I can figure out adding it but I'm not sure it's the right way.

@kg9316
Copy link

kg9316 commented Jan 11, 2020 •
edited

I have done this with lichee pi, your original code. No issues at all.

Kato

@AndersBNielsen
Copy link
Author

AndersBNielsen commented Jan 11, 2020 •
edited

I forked uboot and linux, and added the xt25f128b. I can't seem to figure out how to configure buildroot to use my forks for testing before I make a pull request.

Edit: Found them. Guess the easiest is to do a make clean&make

@thirtythreeforty
Copy link
Owner

thirtythreeforty commented Jan 11, 2020 •
edited

@AndersBNielsen nice find. You can do this three ways:

a) clone Linux, make your change, then generate a patch with Git (even git diff > 0001-flash.patch works). Put this patch in the Buildroot tree and configure Buildroot to find that patch under menuconfig > Kernel. (Similar procedure with U-Boot.) I would probably go this route, using option (c) while I was testing.

b) push your new kernel somewhere and change the kernel version setting to "Custom git repository." Give it your repo address and commit hash. It'll clone and build based on that. I usually use this option for longer-running forks.

c) use local.mk to temporarily override the source directory to your working directory. Refer to the Buildroot user manual for how this works - it's pretty easy. Good option while you're actively hacking on the code.

@thirtythreeforty
Copy link
Owner

Also, you can simply do make uboot-dirclean to clean that single package without a build from scratch.

@thirtythreeforty
Copy link
Owner

@kg9316 worked for you because your particular Nano had a flash chip it already supports. In general I understand why the JEDEC ID is used but it's kind of a dumb system because you end up with parts that are drop-in replacements for the Winbond parts, but the code can't tell that because the ID is different.

@AndersBNielsen
Copy link
Author

Success! Submitted pull requests for linux & uboot.

Thank you so much! - learned a lot about buildroot in the process.

@hashexclude
Copy link

@AndersBNielsen I have the same chip set, I have setup the spi registers the same way, but the device is not booting up well. Sadly, I do not have my soldering set for another few days to hook into serial console and check the tty. Will you be kind to share your flash.bin ?

@AndersBNielsen
Copy link
Author

@AndersBNielsen I have the same chip set, I have setup the spi registers the same way, but the device is not booting up well. Sadly, I do not have my soldering set for another few days to hook into serial console and check the tty. Will you be kind to share your flash.bin ?

I'm afraid my compiled version is a bit off from this at the moment, but I forked linux and u-boot and added the changes I made. You can use those straight from buildroot or make a patch from the diff.
https://github.com/AndersBNielsen/linux
https://github.com/AndersBNielsen/u-boot

Also - I had no trouble with jumper wires resting on the holes for getting serial.

@hashexclude
Copy link

@AndersBNielsen Thanks man. I checked your fork, It needs some extra adjustments apart from those two files. I got lucky, I had to double numpebs in genimage.cfg, and it started working. I believe we need a different branch for xt25f128b or may be a toggle script to change the flash type. I am unlucky at the moment, I can not solder my gpio pins to the board.

@derekmulcahy
Copy link

I also have the xt25f128b flash chip and I tried using @AndersBNielsen repositories. I did the uboot one first and it looked good.

U-Boot 2019.04 (Feb 02 2020 - 12:09:14 -0500) Allwinner Technology

CPU:   Allwinner F Series (SUNIV)
Model: George Hilliard's business card
DRAM:  32 MiB
In:    serial@1c25000
Out:   serial@1c25000
Err:   serial@1c25000
Hit any key to stop autoboot:  0 
SF: Detected xt25f128b with page size 256 Bytes, erase size 64 KiB, total 16 MiB
ubi0: attaching mtd2
ubi0: scanning is finished
ubi0: attached mtd2 (name "rootubi", size 15 MiB)
ubi0: PEB size: 65536 bytes (64 KiB), LEB size: 65408 bytes
ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
ubi0: VID header offset: 64 (aligned 64), data offset: 128
ubi0: good PEBs: 252, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 5, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 1255305838
ubi0: available PEBs: 135, total reserved PEBs: 117, PEBs reserved for bad PEB handling: 0
No size specified -> Using max size (1598040)
Read 1598040 bytes from volume kernel to 80500000
No size specified -> Using max size (7778)
Read 7778 bytes from volume dtb to 80c00000
## Flattened Device Tree blob at 80c00000
   Booting using the fdt blob at 0x80c00000
   Loading Device Tree to 816fb000, end 816ffe61 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.2.4 (derek@oxford) (gcc version 8.3.0 (Buildroot 2019.05.1)) #1 Sat Feb 1 16:53:48 EST 2020

but later it panics in the kernel, this is not surprising as the linux kernel wasn't updated yet.

[    1.390042] g_acm_ms gadget: g_acm_ms ready
[    1.398901] UBI error: cannot open mtd 1, error -19
[    1.403805] UBI: block: can't open volume on ubi0_-1, err=-19
[    1.409651] UBI: block: can't open volume on ubi0_-1, err=-19
[    1.415889] vcc3v3: disabling
[    1.420589] VFS: Cannot open root device "ubiblock0_2" or unknown-block(0,0): error -6
[    1.428624] Please append a correct "root=" boot option; here are the available partitions:
[    1.436971] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.445224] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

I then updated to the @AndersBNielsen linux repo and now it doesn't appear to be happy in uboot. I am not sure what is happening!

U-Boot SPL 2019.04 (Feb 02 2020 - 12:09:14 -0500)
DRAM: 32 MiB
SPL: Unsupported Boot Device!
Trying to boot from sunxi SPI


U-Boot 2019.04 (Feb 02 2020 - 12:09:14 -0500) Allwinner Technology

CPU:   Allwinner F Series (SUNIV)
Model: George Hilliard's business card
DRAM:  32 MiB
In:    serial@1c25000
Out:   serial@1c25000
Err:   serial@1c25000
Hit any key to stop autoboot:  0 
SF: Detected xt25f128b with page size 256 Bytes, erase size 64 KiB, total 16 MiB
ubi0: attaching mtd2
ubi0 error: scan_peb: bad image sequence number 1255305838 in PEB 124, expected 1459793244
Erase counter header dump:
	magic          0x55424923
	version        1
	ec             1
	vid_hdr_offset 64
	data_offset    128
	image_seq      1255305838
	hdr_crc        0x49985cca
erase counter header hexdump:
00000000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01 00 00 00 40 00 00 00 80 4a d2 72 6e 00 00 00 00  UBI#...............@....J.rn....
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49 98 5c ca  ............................I.\.
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd2, error -22
UBI error: cannot attach mtd2
UBI error: cannot initialize UBI, error -22
UBI init error 22
Please check, if the correct MTD partition is used (size big enough?)
Error, no UBI device selected!
Error, no UBI device selected!
=>

@AndersBNielsen
Copy link
Author

AndersBNielsen commented Feb 2, 2020 via email

@derekmulcahy
Copy link

I didn't feel qualified to mess with anything else! I simply ran make menuconfig and changed the uboot and kernel repos to be your links and the latest version. What/where is the genimage.cfg that you changed? It does seem odd that tweaking the JEDEC IDs should have such a knock on effect. Maybe a completely clean build will sort it out or stealing the entry for the working chip and just changing the ID.

The only changed lines in my buildroot/.config were

BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/AndersBNielsen/linux"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="fe39d1d28fb4130b0dc030913b18e66d6fd069cb"
BR2_LINUX_KERNEL_VERSION="fe39d1d28fb4130b0dc030913b18e66d6fd069cb"
...
BR2_TARGET_UBOOT_CUSTOM_REPO_URL="https://github.com/AndersBNielsen/u-boot"
BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="d7eb3a4f7ff3dd5b91dbea2159edda04dbd944a9"
BR2_TARGET_UBOOT_VERSION="d7eb3a4f7ff3dd5b91dbea2159edda04dbd944a9"

@hashexclude
Copy link

This my genimage.cfg, with numpebs doubled and it works.

flash xt25f128b {
    pebsize = 65536
    lebsize = 65408
    numpebs = 256
    minimum-io-unit-size = 1
    sub-page-size = 1
    vid-header-offset = 64
}

image flash.bin {
	flash {}
	flashtype = xt25f128b
	partition uboot {
		image = "u-boot-sunxi-with-spl.bin"
		size = 256K
	}
	partition rootubi {
		image = root.ubi
		size = 0
	}
}

image persist.ubifs {
	ubifs {
		extraargs = "--compr=zlib --jrn-size=192KiB --log-lebs=2"
	}
	size=1280K
	flashtype = xt25f128b
	mountpoint = /root
}

image root.ubi {
	ubi {}
	partition kernel {
		image = "zImage"
		read-only = true
	}
	partition dtb {
		image = "businesscard.dtb"
		read-only = true
	}
	partition root {
		image = "rootfs.squashfs"
		read-only = true
	}
	partition flashdrive {
		image = flashdrive.img
		read-only = true
	}
	partition persist {
		image = persist.ubifs
	}
}

@derekmulcahy
Copy link

Well that fixed it! Thanks! I replaced buildroot/boards/licheepi/genimage.cfg with your file and ran make.

I can now boot businesscard-linux on my Lichee Pi Nano. It uses the USB connection to provide a nice selection of pictures as a 1.7MB "drive" mounted on my OS X system. It also provides a USB serial connection to a Linux login. Good stuff.

I don't really understand why the genimage.cfg is so different from the original one. It seems like much more than the numpebs were changed.

Anyway, thanks for the help and I have a really good base for my investigations.

@alanwli

This comment has been minimized.

Sign in to view
@thirtythreeforty

This comment has been minimized.

Sign in to view
@AndersBNielsen
Copy link
Author

@thirtythreeforty
Can you elaborate on the bare minimum to resize partitions and take advantage of the 16Mb flash on our chips?
To me it looks like doubling uboot size to 512k broke boot?

It seems to me I have to modify both genimage.cfg and flash.layout but I'm stuck in a very tough trial and error and error and error loop. The documentation helps but not enough for me to understand exactly what you made it do and how to change the sizes.

@AndersBNielsen
Copy link
Author

Strange - after doubling to 512k(might not be related - will test again) it actually boots the first after flashing but after that I just get this in a loop:

U-Boot SPL 2019.04 (Mar 29 2020 - 21:44:32 +0200) DRAM: 32 MiB SPL: Unsupported Boot Device! Trying to boot from sunxi SPI

@thirtythreeforty
Copy link
Owner

thirtythreeforty commented Mar 30, 2020 •
edited

@AndersBNielsen there's a couple things to do. In general genimage.cfg is a declarative configuration that specifies how the flash image is to be built. Mine specifies two "bare" partitions - the first for U-Boot, the second an UBI partition. Within UBI, there are several other volumes (think ZFS datasets - the exact location of each volume is managed by UBI). In addition this layout info is duplicated in several places because everything uses different formats and nobody likes to share and there's not a tool to manage it.

So:

  • define the new flash for genimage by modifying the flash definition:

    businesscard-linux/board/businesscard/v1/genimage.cfg

    Lines 1 to 8 in 837c56f

    flash w25q64 {
    pebsize = 65536
    lebsize = 65408
    numpebs = 128
    minimum-io-unit-size = 1
    sub-page-size = 1
    vid-header-offset = 64
    }

    Since your flash is very similar to mine, doubling numpebs should probably be sufficient. You shouldn't need to change the partition size for U-Boot unless you're turning on more features.

  • Ignore flash.layout; it's only used for flashrom.

  • Tell U-Boot about your new flash by adding an entry to its flash table as mentioned

  • Change the size of the UBI partition in genimage.cfg.

  • Change the size of the flash and partitions in the device tree.

    businesscard-linux/board/businesscard/v1/dts/businesscard.dts

    Lines 57 to 80 in 837c56f

    flash: w25q64@0 {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "winbond,w25q64", "jedec,spi-nor";
    reg = <0>;
    spi-max-frequency = <50000000>;
    partitions {
    compatible = "fixed-partitions";
    #address-cells = <1>;
    #size-cells = <1>;
    partition@0 {
    label = "u-boot";
    reg = <0x000000 0x40000>;
    //read-only;
    };
    partition@110000 {
    label = "rootubi";
    reg = <0x40000 0x7C0000>;
    //read-only;
    };
    };
    };

    This tells the Linux kernel about the flash layout; it must match the one that is actually on flash. If you increased the U-Boot genimage partition without telling LInux, it would corrupt U-Boot and that's probably what you're seeing. Not sure if you need to patch Linux to know about your flash; it may Just Work. Try and see.

  • Decide what you want to do with the extra space. If you want a bigger persist UBI volume, modify the declarative configuration in genimage.cfg - don't make it 8MB bigger (UBI needs some free space) but 7MB bigger should be fine. If instead you want more software, the UBI volume for the squashfs rootfs will be made bigger automatically when the squashfs image is rebuilt.

If you hit specific errors, post the whole log. Good luck!

@JarrettR JarrettR mentioned this issue May 19, 2020
Merged
@thirtythreeforty
Copy link
Owner

Fixed in #18.

@masoudr
Copy link

masoudr commented Jan 11, 2021

Hi,
I'm having the exact same problem but I just want to compile U-Boot with support for xt25f128b but none of the repos mentioned here have configured this chip in their uboot configuration file (licheepi_nano_spiflash_defconfig), I also can't find the chip support in uboot's menuconfig. Maybe I'm missing something in here. Can you give me the proper repo and the right configuration file for this?
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@derekmulcahy @alanwli @thirtythreeforty @masoudr @kg9316 @AndersBNielsen @hashexclude