I was poking around in the lenovoemc fosskit 4.1.414.34909 which has source and patches for linux 3.2.1.101.
I did a grep for the PHY_ADDR and found this:

22  MV643XX_ETH_PHY_ADDR(8)
13  MV643XX_ETH_PHY_ADDR(0)
4  MV643XX_ETH_PHY_ADDR(1)
3  MV643XX_ETH_PHY_ADDR(11)
2  MV643XX_ETH_PHY_ADDR(9)
1  MV643XX_ETH_PHY_ADDR(10)
1  MV643XX_ETH_PHY_ADDR(24)

Latest linux kernel for my board from lenovo is 2.6.22.7.
I've posted on lenovo forum to see if they will be able to cough up the patches for that.
I'm very interested to update my u-boot in the flash, and to update patches to apply to recent linux kernel.

Thanks again for all the help so far.

In the meanwhile, apt update on the board didn't do much good. I'll need to look into how to add more packages (no toolchain or scm tools, for example).

> I've posted on lenovo forum to see if they will be
> able to cough up the patches for that.
> I'm very interested to update my u-boot in the
> flash, and to update patches to apply to recent
> linux kernel.

There is really no need to worry about incorporate the old patches from 2.6.x into the modern kernel.

You already run a modern kernel built by Jeremy (? aka 100's). The only things needed are information from the patches that can be incorporated into the DTS.

And combine what Jeremy has in the Buffalo NAS, and what you have changed (eg. Ethernet PHY). Recompile the DTB, and run with the current kernel. As you go, you might find info from the patches that answer the question about what should go into a certain nodes in the DTS.

=====

Regarding u-boot, I would not try to roll a new one. IIRC from your previous posts, the current stock u-boot can boot kernel files from the HDD rootfs, and that's really all you need.

Besides, the Orion5x SoC is too old, so kwboot is not likely to work. And that's the first major hurdle. IOW, you cannot test u-boot without an easy way to load from UART and run it. I'm not sure this BootROM even has documented way to do that.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I agree about u-boot and kwboot with this board, I'm doing some experiments to confirm.
kwboot -d worked, but not yet kwboot -b.

There are a few spots for headers on the board, and one is quite likely to be a JTAG,
so that's one possible avenue.

But you've certainly accomplished the initial stated objective, which is to boot modern kernel and rootfs.

I found I needed to fix up /var, install some swap space, and set proper date+time and got apt update to conclude.
Now I could install ntp and at least work around not having hwclock/rtc yet.

And so it proceeds...

I also wouldn’t mess with the uboot, though I rarelly do.

I looked at your stock dmesg at the beginning of the thread, I didnt see a reference to an rtc. You could always poke around with i2c-detect. They are usually pretty easy to spot on the board since they’re usually well labeled and connected to a crystal oscillator.

If you’re using a rootfs from my process you might need to modprobe spi-not, mtdblock, etc for mtd to show up.

> I also wouldn’t mess with the uboot, though I
> rarelly do.

I would roll new u-boot for a board that I think a lot of people will use it, like the Marvell Kirkwood boards u-boot that I released here. But for a much older SoC like Orion5x, not many people will need it, it's not worth the time I would spend on.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Thanks for the hints.
I installed i2c-tools and libgpiod to poke around from user space.

I built my own linux kernel based on your config-6.1.66 (including a few extras like CONFIG_USB_UAS and CONFIG_DEVTMPFS_MOUNT). Now I can to insert some more trace printk to investigate.

I moved rootfs into my internal scsi drive.
The thumb drive gets hot, and the usb-storage task gobbles huge amounts of cpu time.