[9fans] ARM and u-boot

[9fans] ARM and u-boot

[tlaronde]

Hello,

I have read on the wiki that there is a 5c, for ARM 32bits
little-endian, but that there is no flash memory support.

Some time ago, I was looking for a NAS (for a client) and was looking
for a device that was doing WORM (block deduplication) since, due to
user changing metadata (file names) and due to the high necessity to
have history for (binary) files, it seemed to me the best.

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...).

So, without answers from VAR contacted, the client went for the simpler
(for testing purpose) and cheaper : a Iomega Ix2.

To say that the experiment was satisfying will be a big lie... The
combination of XFS with RAID1 with the inability to administer
wholly (problems of consistency between the two disks, so what does
it do when there is a problem? Windows oriented and taking time
from whatever Active Directory is telling it something despite its
configuration, etc.).

The result is that I have retired it and built from scratch a fileserver
with a classic incremental backup policy (with NetBSD since I'm
not competent enough with Plan9).

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):

Linux version 2.6.31.8 (soho@bsoho091.lss.emc.com) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #1 Thu Feb 17 18:15:07 EST 2011
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Feroceon-KW
Using UBoot passing parameters structure
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c04be8f4, node_mem_map c04e3000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 65024
Kernel command line: console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0x0(uboot),0x20000@0xa0000(env),0x300000@0x100000(zImage),0x300000@0x540000(initrd),128m@0x0(flash)
PID hash table entries: 1024 (order: 10, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 245760KB available (4512K code, 315K data, 132K init, 0K highmem)
Hierarchical RCU implementation.
NR_IRQS:128
Console: colour dummy device 80x30
Calibrating delay loop... 992.87 BogoMIPS (lpj=4964352)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
xor: measuring software checksum speed
   arm4regs  :   866.800 MB/sec
   8regs     :   684.800 MB/sec
   32regs    :   668.800 MB/sec
xor: using function: arm4regs (866.800 MB/sec)
NET: Registered protocol family 16
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.

CPU Interface
-------------
SDRAM_CS0 ....base 00000000, size 256MB 
SDRAM_CS1 ....disable
SDRAM_CS2 ....disable
SDRAM_CS3 ....disable
PEX0_MEM ....base e0000000, size 128MB 
PEX0_IO ....base f2000000, size   1MB 
PEX1_MEM ....no such
PEX1_IO ....no such
INTER_REGS ....base f1000000, size   1MB 
NFLASH_CS ....base fa000000, size   2MB 
SPI_CS ....base f4000000, size  16MB 
BOOT_ROM_CS ....no such
DEV_BOOTCS ....no such
CRYPT_ENG ....base f0000000, size   2MB 

  Marvell Development Board (LSP Version KW_LSP_5.1.3_patch18)-- RD-88F6281A  Soc: 88F6281 A0 LE

 Detected Tclk 200000000 and SysClk 333333333 
MV Buttons Device Load
Marvell USB EHCI Host controller #0: c8040740
PEX0 interface detected no Link.
PCI: bus0: Fast back to back transfers enabled
mvPexLocalBusNumSet: ERR. Invalid PEX interface 1
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
raid6: int32x1     76 MB/s
raid6: int32x2     91 MB/s
raid6: int32x4     99 MB/s
raid6: int32x8     77 MB/s
raid6: using algorithm int32x4 (99 MB/s)
cfg80211: Calling CRDA to update world regulatory domain
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 2728K
rtc mv_rtc: rtc core: registered kw-rtc as rtc0
RTC registered
mp_lm63: device lm63 found
mp_lm63: Alert/tach pin configured for tachometer input
mp_lm63: PWM clock 1.4 kHz, output frequency 22 Hz
mp_lm63: PWM output active high, auto mode
mp_lm63: Module loaded.
cpufreq: Init kirkwood cpufreq driver
cpufreq: High frequency: 1000000KHz - Low frequency: 333333KHz
cpufreq: Setting CPU Frequency to 1000000 KHz
cpufreq: Setting PowerSaveState to off
cpufreq: Setting CPU Frequency to 1000000 KHz
cpufreq: Setting PowerSaveState to off
XOR registered 4 channels
XOR 2nd invalidate WA enabled
cesadev_init(c000ed48)
mvCesaInit: sessions=640, queue=64, pSram=f0000000
MV Buttons Driver Load
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 485
alg: No test for cipher_null (cipher_null-generic)
alg: No test for ecb(cipher_null) (ecb-cipher_null)
alg: No test for digest_null (digest_null-generic)
alg: No test for compress_null (compress_null-generic)
alg: No test for stdrng (krng)
alg: No test for hmac(digest_null) (hmac(digest_null-generic))
async_tx: api initialized (sync-only)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler anticipatory registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
brd: module loaded
loop: module loaded
Integrated Sata device found
IRQ 21/mvSata: IRQF_DISABLED is not guaranteed on shared IRQs
scsi0 : Marvell SCSI to SATA adapter
scsi1 : Marvell SCSI to SATA adapter
scsi 1:0:0:0: Direct-Access     Seagate  ST32000542AS     CC38 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] Sector size 0 reported, assuming 512.
sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
sd 1:0:0:0: [sda] 0-byte physical blocks
sd 1:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 23 00 10 00
Loading Marvell Ethernet Driver:
  o Cached descriptors in DRAM
  o DRAM SW cache-coherency
  o 2 Giga ports supported
  o Single RX Queue support - ETH_DEF_RXQ=0
  o Single TX Queue support - ETH_DEF_TXQ=0
  o TCP segmentation offload (TSO) supported
  o Receive checksum offload supported
  o Transmit checksum offload supported
  o Network Fast Processing (Routing) supported - (Disabled)
  o Driver ERROR statistics enabled
  o Driver INFO statistics enabled
  o Proc tool API enabled
  o SKB Reuse supported - (Disabled)
  o SKB Recycle supported - (Disabled)
  o Rx descripors: q0=128
  o Tx descripors: q0=532
  o Loading network interface(s):
     o register under mv88fx_eth platform
     o eth0, ifindex = 2, GbE port = 0
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
sd 1:0:0:0: [sda] Sector size 0 reported, assuming 512.
     o eth1, ifindex = 3, GbE port = 1

mvFpRuleDb (c44ec000): 2048 entries, 8192 bytes
Intel(R) PRO/1000 Network Driver - version 7.3.21-k3-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
 sda:
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
NAND device: Manufacturer ID: 0xad, Chip ID: 0x75 (Hynix NAND 32MiB 3,3V 8-bit)
Scanning device for bad blocks
mtd: nand_mtd: partitioning exceeds flash size, truncating
4 cmdlinepart partitions found on MTD device nand_mtd
Using command line partition definition
Creating 4 MTD partitions on "nand_mtd":
0x000000000000-0x0000000c0000 : "uboot"
0x0000000a0000-0x0000000c0000 : "env"
0x000000100000-0x000000400000 : "zImage"
0x000000540000-0x000000840000 : "initrd"
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_marvell ehci_marvell.70059: Marvell Orion EHCI
ehci_marvell ehci_marvell.70059: new USB bus registered, assigned bus number 1
ehci_marvell ehci_marvell.70059: irq 19, io base 0xf1050100
 sda1 sda2
sd 1:0:0:0: [sda] Sector size 0 reported, assuming 512.
ehci_marvell ehci_marvell.70059: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
sd 1:0:0:0: [sda] Attached SCSI disk
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
usbcore: registered new interface driver usblp
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
usbcore: registered new interface driver ums-usbat
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
dm_crypt using the OCF package.
cpufreq: Setting CPU Frequency to 1000000 KHz
cpufreq: Setting PowerSaveState to off
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
rtc mv_rtc: setting system clock to 2011-02-12 18:03:03 UTC (1297533783)
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
RAMDISK: gzip image found at block 0
usb 1-1: new high speed USB device using ehci_marvell and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
VFS: Mounted root (ext2 filesystem) on device 1:0.
md: md0 stopped.
md: bind<sda1>
raid1: raid set md0 active with 1 out of 2 mirrors
md0: detected capacity change from 0 to 21484339200
 md0: unknown partition table
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
NTFS driver 2.1.29 [Flags: R/O MODULE].
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.13
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
ufsd: module license 'Commercial product' taints kernel.
Disabling lock debugging due to kernel taint
ufsd: driver 8.3 (009_A)  LBD=ON with ioctl loaded at bf0ee000
NTFS read/write support included
Hfs+/HfsX read/write support included
SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
Freeing init memory: 132K
eth1: link up, full duplex, speed 100 Mbps
eth1: started
warning: `proftpd' uses 32-bit capabilities (legacy support in use)
md: md1 stopped.
md: bind<sda2>
md1: detected capacity change from 0 to 1978914373632
 md1: unknown partition table
XFS mounting filesystem dm-1
Starting XFS recovery on filesystem: dm-1 (logdev: internal)
Ending XFS recovery on filesystem: dm-1 (logdev: internal)
XFS mounting filesystem dm-2
Starting XFS recovery on filesystem: dm-2 (logdev: internal)
Ending XFS recovery on filesystem: dm-2 (logdev: internal)
Adding 524280k swap on /mnt/system/swapfile.  Priority:-1 extents:4 across:524308k 
iSCSI Enterprise Target Software - version 1.4.20.2
iscsi_trgt: Registered io type fileio
iscsi_trgt: Registered io type blockio
iscsi_trgt: Registered io type nullio
Uncached vma c7f872e0 (addr 405c7000 flags 080000d5 phy 075b7000) from pid 2635
Uncached vma c2dfdf40 (addr 405f3000 flags 080000d5 phy 075b7000) from pid 2635
Uncached vma c533e288 (addr 4bb48000 flags 080000d5 phy 075b7000) from pid 2635
Uncached vma c9782bd0 (addr 40638000 flags 080000d5 phy 075b7000) from pid 2635
Uncached vma c9d681d8 (addr 40b80000 flags 080000d5 phy 075b7000) from pid 2635
Uncached vma c73c0b20 (addr 404ca000 flags 080000d5 phy 075b7000) from pid 2675
Uncached vma c79978b8 (addr 40638000 flags 080000d5 phy 075b7000) from pid 2676
Uncached vma c737e6a8 (addr 40b80000 flags 080000d5 phy 075b7000) from pid 2676
Uncached vma c7f87860 (addr 404ca000 flags 080000d5 phy 075b7000) from pid 2710
Uncached vma c737e758 (addr 40638000 flags 080000d5 phy 075b7000) from pid 2713
Uncached vma c59210d0 (addr 405f3000 flags 080000d5 phy 075b7000) from pid 2720
Uncached vma ced027b0 (addr 405f3000 flags 080000d5 phy 075b7000) from pid 2721
Uncached vma c61b0bd0 (addr 405f3000 flags 080000d5 phy 075b7000) from pid 2722
-- 
        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

[lucio]

> 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.dere@gmail.com) with ideas.

++L

Re: [9fans] ARM and u-boot

[tlaronde]

On Sat, Jun 01, 2013 at 10:04:23AM +0200, lucio@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

[erik quanstrom]

> 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

[tlaronde]

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

[tlaronde]

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

[erik quanstrom]

> 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

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

On Sat, Jun 1, 2013 at 12:19 AM, <tlaronde@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-00002-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: 0x42000000
Loading: #################################################################
 ###############################################
done
Bytes transferred = 1510728 (170d48 hex)
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   9arndale
   Image Type:   ARM Plan 9 Kernel Image (uncompressed)
   Data Size:    1510664 Bytes = 1.4 MiB
   Load Address: b1000000
   Entry Point:  b1000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
## Transferring control to Plan 9 (at address b1000000) ...

Plan 9 from Bell Labs
...

Cheers,

Steve

[-- Attachment #2: Type: text/html, Size: 3675 bytes --]

Re: [9fans] ARM and u-boot

[tlaronde]

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

[tlaronde]

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

[erik quanstrom]

> 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

[Richard Miller]

> 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

[erik quanstrom]

> > 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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

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 <quanstro@quanstro.net>wrote:

> > > 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
>
>

[-- Attachment #2: Type: text/html, Size: 1271 bytes --]

Re: [9fans] ARM and u-boot

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Sun, Jun 2, 2013 at 6:09 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> 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.

[-- Attachment #2: Type: text/html, Size: 799 bytes --]

Re: [9fans] ARM and u-boot

[Richard Miller]

> 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/NNNNNN 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

[Richard Miller]

> 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).

Re: [9fans] ARM and u-boot

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

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 <9fans@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/NNNNNN 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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1200 bytes --]

Re: [9fans] ARM and u-boot

[erik quanstrom]

On Mon Jun  3 06:42:31 EDT 2013, 9fans@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

[Bakul Shah]

On Jun 3, 2013, at 3:35 AM, Richard Miller <9fans@hamnavoe.com> wrote:
> I just tried this to check it still works, and found that you
> need a vgasize= definition in the /cfg/pxe/NNNNNN 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

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

On Mon, Jun 3, 2013 at 6:19 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> 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...

[-- Attachment #2: Type: text/html, Size: 1508 bytes --]

Re: [9fans] ARM and u-boot

[Richard Miller]

> 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

[Bakul Shah]

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

[Richard Miller]

> 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

[erik quanstrom]

> 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

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

On Mon, Jun 3, 2013 at 11:43 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > 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

[-- Attachment #2: Type: text/html, Size: 2977 bytes --]

Re: [9fans] ARM and u-boot

[erik quanstrom]

> 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

[erik quanstrom]

> > 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