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.

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

FS#975 - ARV752DPW u-boot partition to small for recent u-boot #5930

Open
openwrt-bot opened this issue Aug 23, 2017 · 7 comments
Open

FS#975 - ARV752DPW u-boot partition to small for recent u-boot #5930

openwrt-bot opened this issue Aug 23, 2017 · 7 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Aug 23, 2017

Oliver:

Applies to 17.01.2 and trunk.

/target/linux/lantiq/dts/ARV752DPW.dts defines a uboot partition of 64k and places the firmware partition at 0x00020000.
There is no recent u-boot that would fit into 64k. The u-boot images in the LEDE repo are 192k.
The kernel_address should be 0x00040000 instead.

Sorry, I do not have the resources right now to download the source and create a proper patch. But the attached diff should give you an idea:

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 24, 2017

mkresin:

I'm well aware of the issue but we can not simply change the partition layout. The OpenWrt wiki article for the board links to a [[https://wiki.openwrt.org/toh/arcadyan/arv752dpw#downloads|precompiled bootloader]] which fits into the 64Kybte u-boot partition.

If we change the partition layout, boards using the linked bootloader + the current partition layout will be bricked, since the kernel isn't any longer at the position the precompiled u-boot expects.

A proper solution would be to shrink the u-boot provided by LEDE to 64Kbyte. It should be possible using a two staged u-boot, where the 2nd stage is lzma compressed and decompressed by the first stage. Support for NOR SPL is already present in the [[https://github.com/danielschwierzeck/u-boot-lantiq/tree/openwrt/v2014.01-next|v2014.01-next branch of Daniels u-boot lantiq]].

Unfortunately I wasn't able to get it running on danube boards. The bootloader just hangs and I can not find the issue. If you are interested, everything I have so far is in my [[https://github.com/mkresin/u-boot-lantiq/tree/openwrt/v2014.01-openwrt5|u-boot-lantiq repo]].

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 24, 2017

Oliver:

Yes, backward compatibility is important.
Let me give you my reasoning why it should be broken in this case:

  1. The bootloader linked to is broken. It has tftpboot, bootp, rarpboot - but networking is broken. It does not have loadx, so the only way to upload an image is via a python script that uses MM to byte-wise upload the binary. It takes ages. And each time you have to open the box and make a serial connection.
    Giving up on something that is broken does not seem a bad idea to me.

  2. Uploading a LEDE image starting at 0×00040000 on the 64k u-boot will not brick the router. The bootloader will still be there (as useless as it is). All the user needs to do is to set kernel_address in the uboot environment. If he knew ahead of time, he could have already done so from within OpenWRT/LEDE.
    But for those who use a real™ 192k u-boot, uploading a LEDE image to 0×00020000 will overwrite the bootloader and brick the router.

  3. Someone has broken backward compatibility already for the Easybox 803. Even a long time ago. The Easybox 802 seems to have been forgotten back then. Why not correct this now?

And on a personal note: The patch that fixed the rtl8306 switch is from Oct. 21, 2013. It is sad to see that people still use broken versions of u-boot.

P.S.: SPL is a very good idea. I looked at your repo. Are you testing on a VGV7510KW22?
Is there a thread in the forum on this? (I don't want to pullute the bug tracker.)

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 28, 2017

mkresin:

The bootloader will still be there (as useless as it is). All the user needs to do is to set kernel_address in the uboot environment.

Exactly that is the problem I'm talking about. There is no userspace support for altering the u-boot env partition for this board. Furthermore the u-boot env partition is write protected. You need at least an intermediate release with that changed.

It is all about backwards compatibility. The casual user most likely does not expect that such a change is required. Apart from this, I'm in doubt that there is a way to make people aware of such necessary changes.

I've change the partitioning of the BT HomeHub5 as it was in development (no release image). To my surprise it caused a lot of bugreports/forum threads. Even people using development snapshots are not reading the commit history/wiki pages/changelogs.

Are you testing on a VGV7510KW22? Is there a thread in the forum on this? (I don't want to pullute the bug tracker.)

Yes I do testing on the VGV7510KW22 as well. Not sure why it needs a forum thread. I've prepared the update and tested stuff on my own. Works fine for xrx200 but breaks on danube. Therefore it can not be used/released as it is.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 29, 2017

Oliver:

I've change the partitioning of the BT HomeHub5 as it was in development (no release image). To my surprise it caused a lot of bugreports/forum threads.

Yes, the issue is that you have no way pf knowing the size of your user base. In case of the ARV752DPW the user base may already have been "successfully" disencouraged to use it - with a broken bootloader, broken USB in LEDE 17.01.2, uninitialized switch...

Yes I do testing on the VGV7510KW22 as well. Not sure why it needs a forum thread.
I just wanted to avoid discussing development issues in the bug tracker.

The reason why I was asking is, that I thought you might want to use a VGV7519. It is easy/cheap to get and has JTAG exposed, which would make it easier to find out why it hangs in u-boot.
But if it works on xrx200 you will probably not learn much new with the VGV7519.
Hm... maybe the ARV7518PW or the Gigaset SX762 / SX763. But I don't know them and I don't have a datasheet.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 29, 2017

mkresin:

Yeah, JTAG would be the next step. But so far I never debugged using JTAG...

But if it works on xrx200 you will probably not learn much new with the VGV7519.

Yes, xrx200 won't help in that case.

Hm... maybe the ARV7518PW or the Gigaset SX762 / SX763. But I don't know them and I don't have a datasheet.

I wasn't able to find a danube board which exposes the JTAG pins. Searching for them is quite hard, since people are not aware that JTAG != UART. And to be honest, danube is somewhat legacy and I don't have a use case for ADSL only boards. Hence, I'm not really willing to invest more time/money than the bare minimum.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 29, 2017

Oliver:

Searching for them is quite hard, since people are not aware that JTAG != UART.

Without a danube datasheet it would be like poking around in the dark.

I don't have a use case for ADSL only boards. Hence, I'm not really willing to invest more time/money than the bare minimum.

They are still good as APs, range extenders or UMTS gateways.
But I get your point.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jan 16, 2020

gho:

Why is u-boot-arv8539pw22_nor built when the resulting binary is not usable (of wrong size)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant