On Tuesday 9. June 2015 14.55.48 Dr. H. Nikolaus Schaller wrote: > > Am 09.06.2015 um 13:45 schrieb Paul Boddie <p...@boddie.org.uk>: > > > > https://www.mail-archive.com/mipsbook-devel%40linuxtogo.org/msg00181.html > > Indeed! Thanks for looking it up.
[...] > Fortunately, I have found copies of PC701-LX-u-boot-1.1.6.tar.bz2 on my > daily work machine… > > So it is not lost. I have uploaded it to > > http://download.goldelico.com/letux-400/files/ I imagine that it will be mostly the same as the repositories I found... > > Fortunately, I found the following repository containing U-Boot with > > jz4730 support: > > > > https://github.com/shenhaocn/jzcode-x11 > > > > There's also a specific U-Boot repository, but I can't see any notable > > differences between it and the other one: > > > > https://github.com/shenhaocn/jz-uboot > > > > I'm sure I've seen boot code before, but I think it's the code in the 2.6 > > kernel that detects various keys and supposedly performs NAND-flashing > > operations. > > Yes, according to my 5 years old description there are multiple locations > where hot keys are detected to help the boot process. A big hack… No chance > to get it upstream to kernel.org or denx :) I seem to remember a bit more of this now: before the init process is run, the user has the chance to hold down a key, and then the relevant resources are accessed: http://projects.goldelico.com/p/letux-400/source/tree/master/arch/mips/jz4730/board- minipc.c#L126 http://projects.goldelico.com/p/letux-400/source/tree/master/init/do_mounts.c#L425 This seems to allow an alternative root filesystem, at least. > The key point is that U-Boot can only boot from NAND or SD/MMC. And it > can boot the “minifs” which is a stripped down Linux with running a single > shell script in busybox. That script provides some user interface - and of > course USB drivers (and network) to load recovery systems from. It might be interesting to get some low-level bootloader to work from SD/MMC if possible (that is, if possible on the Letux, not if generally possible for U-Boot). I'm naturally wary of using the NAND, anyway, and I do use the NanoNote with a microSD/MMC card instead of booting from NAND if I don't need to use the MMC port for homebrew hardware. > I have found that we had written a simple replacement minifs (which is not > the same as the one that comes shipped with the hardware). But if you > did not touch the original, it should be possible to read out the NAND > partition. > > http://projects.goldelico.com/p/l400-rootfs/source/tree/master/config/root/ > mkminifs > http://projects.goldelico.com/p/l400-rootfs/source/tree/master/config/root > /recover I'll have to take a look at that. > > It becomes difficult to track all the different resources, > > especially when some of them tend to go away and not always come back, > > like all the kwaak.net ones which even the Internet Archive doesn’t have > > any more. > > This is why http://projects.goldelico.com/p/letux-400/ and siblings like > http://projects.goldelico.com/p/l400-rootfs/ exist. My target is that this > resource is never going away (at least as long as the company exists and > can pay for the server operation :). > > Anyways, I also plan to consolidate the GTA04 boot/kernel/rootfs system > with the Letux400 boot/kernel/rootfs as soon as we have MIPS/JZ device > tree support in the kernel. Then, this u-boot will also be unpacked into > git (and mirrored to github). Right. At this point, I'm not actively pursuing the Linux kernel stuff as I don't think I can muddle my way through the necessary work. Moreover, I got the impression that other people need to finish off their own efforts around device tree and the necessary changes around it before we even have a chance of getting the jz4730 stuff to work with it. > If someone needs write access to this project forge to update information, > please register and let me know. I'll think about doing that. > > Ultimately, for the Letux (but also for less awkward NanoNote > > experiments) it may be worthwhile focusing on a payload loaded from > > SD/MMC media, however. > > For the initial work, I think we should indeed focus on SD/MMC. And only if > it becomes more stable, complete boot from USB can be revisited. I did wonder whether it was even possible without opening up the Letux unit itself, and whether it would be possible even then. The NanoNote deliberately exposes a contact in the battery compartment for the hardware USB boot mode, meaning that even if U-Boot is broken or doesn't support the software USB boot mode (which appears to involve some initialisation of the SoC's bootloader, or maybe even a partial reimplementation of it), it's still possible to activate the hardware mode. Another thing that I'm not clear about (without studying the schematic) is how the USB port on the Letux is connected to the SoC and whether it would make sense to use the provided USB ports for booting purposes. The NanoNote is only capable of being a USB peripheral, whereas the Letux is presumably meant to be a USB host, although I guess it can also be a peripheral. Either way, the internal "wiring" would need to be right for any boot mode to be exposed. But yes, employing SD/MMC would be best, and maybe I should investigate that on the NanoNote, booting into my own test payload directly from U-Boot. And it would be interesting to know if a bootloader could be deployed on SD/MMC for the Letux. Currently, I see the limitation being that the 2.6 kernel hacks only support changing the root filesystem to the MMC storage, not invoking a completely new payload from it. Paul _______________________________________________ Mipsbook-devel mailing list Mipsbook-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
