Am 09.06.2015 um 16:51 schrieb Dr. H. Nikolaus Schaller <h...@goldelico.com>:
> > Am 09.06.2015 um 15:56 schrieb Paul Boddie <p...@boddie.org.uk>: > >> 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. > > It could be possible to load another instance of U-Boot instead of a kernel. > > And then do the final work. > > Or modify the minifs. > >> >>> 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. > > IMHO progress is promising. But it is still not arrived at linux-next so > chances > for 4.2-rc1 are not very high. I have to correct myself. Yesterday, JZ4740 DT support has found its way into linux-next: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=e6382f138edd218dbe7757cf12f0b64e2926400f So we definitvely will see it as part of the 4.2-rc series :) A minor problem will be how to boot a DT kernel… We can’t easily modify U-Boot to load the .dtb and pass its address to the bootm command. But it is usually possible to append the DTB before using mkimage to build an uImage. Then, the kernel startup code will scan the kernel binary for a DTB. I hope this mechanism exists for MIPS as well and not only for ARM. It needs some CONFIG to be enabled. We also use this method for the GTA04 if we boot from NAND. There we also can’t load a separate DTB (because we have no dedicated partition for it). Here is the code that merges an existing uImage and some DTB into a bootable thing: http://git.goldelico.com/?p=gta04-rootfs.git;a=blob;f=config/root/flash-nand;hb=HEAD#l152 > >> >>> 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. > > If you open the L400 it is possible to solder an RS232 adapter for console > access. And it has a flex cable connector for JTAG. > >> >> 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. > > It appears that the jz4730 has two USB1 host mode only ports (DPLS0/DNS0, > DPLS1/DMNS1). > One goes directly to one of the 3 usb sockets while the other goes to a 4 > port-hub AU9254A21. > One of the 4 ports is unused, two are the other two USB sockets and the last > one goes > to an CSC0101A-S16 PS2 converter (touch pad). The JZ4730 also has a PS2 > interface > but that ends in test points… > > None of the USB sockets has an ID pin - so they are not OTG capable. > > In summary: the L400 can only be USB host and not USB peripheral. > >> >> 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. > > Yes, because it is probably a little risky to do so. > > BR, > NIkolaus > > > _______________________________________________ > Mipsbook-devel mailing list > Mipsbook-devel@linuxtogo.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel _______________________________________________ Mipsbook-devel mailing list Mipsbook-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
