Re: [9fans] ARM and u-boot
you'll need the uboot sd image that Richard put together (/n/sources/contrib/miller/uboot.img) No, that file is just an executable binary of uboot. An SD image for pxe-type loading is /n/sources/extra/pi.uboot.sd.img.gz as mentioned in booting(8). I just tried this to check it still works, and found that you need a vgasize= definition in the /cfg/pxe/NN file if you're booting with uboot and want an HDMI screen. I'm not sure that was documented anywhere. If you just boot a 9pi kernel from the SD card without using uboot, vgasize= isn't needed because the screen size can be detected automagically.
Re: [9fans] ARM and u-boot
yes, sorry; i was going from memory -- which isn't as reliable as it once was. On Mon, Jun 3, 2013 at 3:35 AM, Richard Miller 9f...@hamnavoe.com wrote: you'll need the uboot sd image that Richard put together (/n/sources/contrib/miller/uboot.img) No, that file is just an executable binary of uboot. An SD image for pxe-type loading is /n/sources/extra/pi.uboot.sd.img.gz as mentioned in booting(8). I just tried this to check it still works, and found that you need a vgasize= definition in the /cfg/pxe/NN file if you're booting with uboot and want an HDMI screen. I'm not sure that was documented anywhere. If you just boot a 9pi kernel from the SD card without using uboot, vgasize= isn't needed because the screen size can be detected automagically.
Re: [9fans] ARM and u-boot
On Mon Jun 3 06:42:31 EDT 2013, 9f...@hamnavoe.com wrote: there's something just a little annoying about having a boot loader that is much larger than the kernel than you're loading. Thanks to /dev/reboot you can alternatively use plan 9 itself as a loader, thus guaranteeing the loader is no bigger than the kernel. I've found this useful when loading requires a bit of extra sophistication (eg booting over wifi). unfortunately, as far as i know plan 9 can't be used as a primary loader most of the environments where uboot is used because we haven't written the (usually small) memory initialization code, etc. i know using uboot has generally worked out, but i recently worked on an arm project. for some reason uboot was used. i thought this wouldn't be a problem, so left it alone. as it turned out we had a few bugs that required messing with uboot, and those were costly. writing our own would have been much cheeper. to a lesser extent i see this problem on the pc. the drivers needed for boot are not necessarly the ones one is interesting in writing. also, interacting with the bios drivers allows one to capture info from bios like which nic was used to boot. in our network this is a massive time saver, since i never have to set ether0=type= any more. this is also how i've set up automatic usb / disk boot. - erik
Re: [9fans] ARM and u-boot
On Jun 3, 2013, at 3:35 AM, Richard Miller 9f...@hamnavoe.com wrote: I just tried this to check it still works, and found that you need a vgasize= definition in the /cfg/pxe/NN file if you're booting with uboot and want an HDMI screen. I'm not sure that was documented anywhere. If you just boot a 9pi kernel from the SD card without using uboot, vgasize= isn't needed because the screen size can be detected automagically. The screen size detection code uses rpi's msgbox interface so should work even with uboot.
Re: [9fans] ARM and u-boot
On Mon, Jun 3, 2013 at 6:19 AM, erik quanstrom quans...@quanstro.netwrote: unfortunately, as far as i know plan 9 can't be used as a primary loader most of the environments where uboot is used because we haven't written the (usually small) memory initialization code, etc. It's more than that. Many board vendors will use a secured stage 1 bootloader that assumes U-Boot. It's probably possible to shove in a different second stage loader, but you'll still need to do board initialization as you mentioned. It's not that onerous and there is source out there, but I think it's really a question of motivation. U-Boot is supported by the same vendors and covers of the behavior you will likely want in a boot loader (and then some). Board configs are easy to customize so that you aren't carrying around a massive binary. The binary I use for the Arndale is measured in kilobytes, not megabytes. Every SoC is going to have a different process - in the end, you'll have something that will probably look quite a bit like U-Boot without any real benefit. I'd rather tilt at other windmills...
Re: [9fans] ARM and u-boot
The screen size detection code uses rpi's msgbox interface so should work even with uboot. It should but it doesn't. I notice uboot is now echoing its console output to hdmi as well as the serial port, which earlier versions didn't do. Maybe this is messing up the screen size.
Re: [9fans] ARM and u-boot
On Jun 3, 2013, at 11:21 AM, Richard Miller wrote: The screen size detection code uses rpi's msgbox interface so should work even with uboot. It should but it doesn't. I notice uboot is now echoing its console output to hdmi as well as the serial port, which earlier versions didn't do. Maybe this is messing up the screen size. Strange... I will take a look at the code. Which uboot are you using? Though we don't have to use the latest uboot.
Re: [9fans] ARM and u-boot
Strange... I will take a look at the code. Which uboot are you using? Though we don't have to use the latest uboot. I grabbed the uboot binary from a freebsd distribution dated 20130201. Earlier versions won't work with a 512MB pi model B.
Re: [9fans] ARM and u-boot
It's more than that. Many board vendors will use a secured stage 1 bootloader that assumes U-Boot. It's probably possible to shove in a good point. what are the secure loaders assuming? Every SoC is going to have a different process - in the end, you'll have something that will probably look quite a bit like U-Boot without any real benefit. I'd rather tilt at other windmills... that was my opinion, and i argued it pretty loudly— until u-boot didn't cover my needs and i had to fix u-boot. i had to eat my words. u-boot is really terrible to work with. there is no danger of writing something that looks like u-boot. :-) but if u-boot works out of the box, i would totally agree, why not use it? but don't fall for the trap of modifying it. that's a terrible waste. instead of learning about the internals of u-boot, you could spend time learning how the hardware in hand is really set up. - erik
Re: [9fans] ARM and u-boot
On Mon, Jun 3, 2013 at 11:43 AM, erik quanstrom quans...@quanstro.netwrote: It's more than that. Many board vendors will use a secured stage 1 bootloader that assumes U-Boot. It's probably possible to shove in a good point. what are the secure loaders assuming? I have no idea - those I've dealt with were always delivered as a binary image with little to no instruction. Presumably there is an assumption that the second stage loader is located at some offset at a minimum. We could work backward from the second stage loader if we had a mind to. Every SoC is going to have a different process - in the end, you'll have something that will probably look quite a bit like U-Boot without any real benefit. I'd rather tilt at other windmills... that was my opinion, and i argued it pretty loudly— until u-boot didn't cover my needs and i had to fix u-boot. i had to eat my words. u-boot is really terrible to work with. there is no danger of writing something that looks like u-boot. :-) but if u-boot works out of the box, i would totally agree, why not use it? but don't fall for the trap of modifying it. that's a terrible waste. instead of learning about the internals of u-boot, you could spend time learning how the hardware in hand is really set up. Really? I've had very little problem with modifying U-Boot - the code base is fairly common for most Linux-like projects. The code was consistent, and well documented. As far as setting up the hardware, it's certainly interesting, but of small utility in the grand scheme of things. I think it's important to remember that U-Boot (and many other projects) all came into being out of necessity. As engineers (and hobbyists to some degree) we all tend to suffer from NIH. Decisions that some see as mistakes usually have a good reason for coming to being. Exitus acta probat, I suppose. Cheers, Steve
Re: [9fans] ARM and u-boot
Really? I've had very little problem with modifying U-Boot - the code base is fairly common for most Linux-like projects. The code was consistent, and well documented. As far as setting up the hardware, it's certainly interesting, but of small utility in the grand scheme of things. perhaps this is vendor (or even part) specific, and i am falsely generalizing. the vendor code i was dealing with was massive, poorly written, undocumented, and #ifdef hell. flashing uboot took special tools (and 15 minutes connected to a windows laptop), so the normal trick of printing to see what code gets run was not easy. I think it's important to remember that U-Boot (and many other projects) all came into being out of necessity. As engineers (and hobbyists to some degree) we all tend to suffer from NIH. Decisions that some see as mistakes usually have a good reason for coming to being. Exitus acta probat, I suppose. existance is not proof of necessity. - erik
Re: [9fans] ARM and u-boot
Really? I've had very little problem with modifying U-Boot - the code base is fairly common for most Linux-like projects. The code was consistent, and well documented. As far as setting up the hardware, it's certainly interesting, but of small utility in the grand scheme of things. perhaps this is vendor (or even part) specific, and i am falsely generalizing. the vendor code i was dealing with was massive, poorly written, undocumented, and #ifdef hell. flashing uboot took special tools (and 15 minutes connected to a windows laptop), so the normal trick of printing to see what code gets run was not easy. i should have mentioned that the vendor required a hacked version of the arm toolchain. this version of u-boot was the gift that just kept giving. - erik
Re: [9fans] ARM and u-boot
On Sat, Jun 01, 2013 at 09:06:55PM -0700, Steven Stallion wrote: It's quite possible. I even have it working. :-) A couple of months ago I submitted a patch to the U-Boot mainline to add formal support for Plan 9 kernels. It has since been accepted. At the same time I also submitted a patch to Geoff which has been gathering dust to add uImage support to 5l (patch/arm-uboot) - a requirement to exist nicely with the loader. The exynos5 port that I am working on (Arndale Board, Samsung Chromebook) relies on this exclusively. Thanks for the tip! I will indeed first test kernels by loading them via TFTP before going any further. Best, -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ARM and u-boot
On Sat, Jun 01, 2013 at 06:10:51PM -0400, erik quanstrom wrote: Marvell Development Board (LSP Version KW_LSP_5.1.3_patch18)-- RD-88F6281A Soc: 88F6281 A0 LE That is openRD (Marvell 88F6281), it is a starting point for playing with it... well, good luck. there's a sata driver in 9atom. As I wrote it will be for me a course since hardware driving is an area where my knowledge is nil. I will learn where the border is between machine dependent and machine independent; and for machine dependent, what portion can be written in C and what has to be done in assembly. I don't know how far I will go, but I'm sure to learn a couple of things in the way... -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ARM and u-boot
uImage support to 5l (patch/arm-uboot) - a requirement to exist nicely with the loader. The exynos5 port that I am working on (Arndale Board, Samsung Chromebook) relies on this exclusively. this is in 9atom. also note, that the kw kernel is bootable without uimage support. - erik
Re: [9fans] ARM and u-boot
also note, that the kw kernel is bootable without uimage support. ... and so is any other Plan 9 arm kernel, as long as you have access to u-boot's console or config variables. See booting(8).
Re: [9fans] ARM and u-boot
you'll need the uboot sd image that Richard put together (/n/sources/contrib/miller/uboot.img) that's what i use to boot the 9Pi cluster from the file server. On Sun, Jun 2, 2013 at 8:53 PM, erik quanstrom quans...@quanstro.netwrote: also note, that the kw kernel is bootable without uimage support. ... and so is any other Plan 9 arm kernel, as long as you have access to u-boot's console or config variables. See booting(8). the rpi doesn't use u-boot by default, though, does it? i certainly don't see any indication on my machines. there's something just a little annoying about having a boot loader that is much larger than the kernel than you're loading. :-) - erik
Re: [9fans] ARM and u-boot
On Sun, Jun 2, 2013 at 6:09 AM, erik quanstrom quans...@quanstro.netwrote: also note, that the kw kernel is bootable without uimage support. Sure, though supporting uImage means you get a few things for free, not to mention it isn't ELF. This deserves a proper write up - I'll probably do something for IWP9 if I can manage to complete the port in time. At the very least, it will be WIP. There are a few subtle bits as to why I ended up going with uImages.
Re: [9fans] ARM and u-boot
Since it has u-boot installed and that the mapping of the flash is given does one know if one could build a Plan9 kernel, write it (via u-boot) to the flash and be able to boot? I'm looking for the answer to this question too. Besides the Sheevaplug, I have a similar ARM gadget that I was planning to enhance by running Plan 9 on it. But before I go there, the Feroceon seems to me to be the same device as the Sheeva's, so you have an advantage there, you may be able to shoehorn the existing plug stuff into it without much effort. The ARM world is considerably more complicated, what with dozens of subspecies in existence and 600-page manuals to describe how they work. Personally, I'd be very interested in setting up a Plan 9/ARM Google group in which to discuss what may turn out to be a busy issue. There are many problems I'd like to discuss with similarly minded people and one may want to include the growing Raspberry PI community in such discussions. If anyone is interested, but does not want to use 9fans for this, feel free to mail me at my gmail address (lucio.d...@gmail.com) with ideas. ++L
Re: [9fans] ARM and u-boot
On Sat, Jun 01, 2013 at 10:04:23AM +0200, lu...@proxima.alt.za wrote: The ARM world is considerably more complicated, what with dozens of subspecies in existence and 600-page manuals to describe how they work. Personally, I'd be very interested in setting up a Plan 9/ARM Google group in which to discuss what may turn out to be a busy issue. I'd be interested too in a Plan9/ARM exchange, since a course is a path in a domain to tell a student a story (a thread; what today text books have totally forgotten), the ARM port would be an interesting Plan9 course (not to mention real world/real need coverage: in DAO/CAO, survey, GIS, mapping etc. there is a need for a versioning of binary files without an explosion of the size of data; the WORM addresses this). -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ARM and u-boot
I have read on the wiki that there is a 5c, for ARM 32bits little-endian, but that there is no flash memory support. i boot my openrd from flash. Unfortunately, it happens that in France, for small enterprises (not to say independant worker like me), we are not a worthy target. And the hardware can not be bought directly but only from VAR. (I was looking for example for Coraid products---I don't what put me this name in the head...). i believe alissio (sp) is a reseller in france. you can contact me off list for more information. But I still want to experiment with WORM (more kenfs I think) and I have this ARMv5 thing at disposal. Since it has u-boot installed and that the mapping of the flash is given does one know if one could build a Plan9 kernel, write it (via u-boot) to the flash and be able to boot? Here are the dmesg from the installed Linux kernel (note: it has GbE, but it was accessed through a network with a 100Mb switch, hence the speed reported on the interface): i have some experience with the marvell ferceron, and they are similar to the plug computers/open rd, but most of the memory mapping will be different. if your want your focus to be on the file server, and not porting to arm, it would be more efficient to use the existing 386 port. - erik
Re: [9fans] ARM and u-boot
On Sat, Jun 01, 2013 at 09:31:29AM -0400, erik quanstrom wrote: i have some experience with the marvell ferceron, and they are similar to the plug computers/open rd, but most of the memory mapping will be different. if your want your focus to be on the file server, and not porting to arm, it would be more efficient to use the existing 386 port. Well, the ARM is now ubiquitous and I don't know if there are x86 (whether 32 or 64 bits) without a FPU (now a GPU is even integrated), so ARM is something definitively to consider along x86_* now for uses that don't involve floating point calculus. Fileservers come first to mind, well terminals too for still a significative number of applications not needing high 3D rendering (leaving CPU for... computing). Plus I have the hardware (it was not planned). And finally, if Plan9 could be used as easily as on the Sheevaplug on this kind of Iomega appliance, when it comes to price, with typically two disks of 1, 2 or 4 terabytes, it is an ARM appliance not more expensive than a sheevaplug, and more widely available... (not the same size, and producing---to my taste---a lot of heat; but I had rough times with Iomega software, but if one can get rid of the software and deal with the hardware...). -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ARM and u-boot
On Sat, Jun 01, 2013 at 09:31:29AM -0400, erik quanstrom wrote: I have read on the wiki that there is a 5c, for ARM 32bits little-endian, but that there is no flash memory support. i boot my openrd from flash. So since it is: Marvell Development Board (LSP Version KW_LSP_5.1.3_patch18)-- RD-88F6281A Soc: 88F6281 A0 LE That is openRD (Marvell 88F6281), it is a starting point for playing with it... -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ARM and u-boot
Marvell Development Board (LSP Version KW_LSP_5.1.3_patch18)-- RD-88F6281A Soc: 88F6281 A0 LE That is openRD (Marvell 88F6281), it is a starting point for playing with it... well, good luck. there's a sata driver in 9atom. - erik
Re: [9fans] ARM and u-boot
On Sat, Jun 1, 2013 at 12:19 AM, tlaro...@polynum.com wrote: Since it has u-boot installed and that the mapping of the flash is given does one know if one could build a Plan9 kernel, write it (via u-boot) to the flash and be able to boot? It's quite possible. I even have it working. :-) A couple of months ago I submitted a patch to the U-Boot mainline to add formal support for Plan 9 kernels. It has since been accepted. At the same time I also submitted a patch to Geoff which has been gathering dust to add uImage support to 5l (patch/arm-uboot) - a requirement to exist nicely with the loader. The exynos5 port that I am working on (Arndale Board, Samsung Chromebook) relies on this exclusively. If you are familiar with setting up a BSP for U-Boot, it's fairly straightforward to boot a Plan 9 kernel from either a filesystem (ie. FAT, ext2, etc.) or via TFTP. I tend to use TFTP while testing new kernels, though longer lived kernels will likely end up sitting in a FAT - I haven't quite decided yet. Since you seem to be keen console spew, this is what a booted Arndale looks like with the above patches: U-Boot 2013.01.-rc1-2-g67fd7e7-dirty (May 10 2013 - 23:58:01) for ARNDALE5250 CPU: Exynos5250@1000MHz Board: for ARNDALE5250 I2C: ready DRAM: 2 GiB WARNING: Caches not enabled Checking Boot Mode ... SDMMC MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1, EXYNOS DWMMC: 2 In:serial Out: serial Err: serial Net: No ethernet found. (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Hit any key to stop autoboot: 0 Waiting for Ethernet connection... done. Using asx0 device TFTP from server 10.0.0.8; our IP address is 10.0.0.10 Filename '/sys/src/9/exynos/9arndale'. Load address: 0x4200 Loading: # ### done Bytes transferred = 1510728 (170d48 hex) ## Booting kernel from Legacy Image at 4200 ... Image Name: 9arndale Image Type: ARM Plan 9 Kernel Image (uncompressed) Data Size:1510664 Bytes = 1.4 MiB Load Address: b100 Entry Point: b100 Verifying Checksum ... OK Loading Kernel Image ... OK OK ## Transferring control to Plan 9 (at address b100) ... Plan 9 from Bell Labs ... Cheers, Steve
