Date: Mon, 22 Nov 2010 13:57:03 +0200 From: Alexandr Rybalko <ray@dlink.ua> To: Adrian Chadd <adrian@freebsd.org> Cc: Aleksandr Rybalko <ray@ddteam.net>, freebsd-mips@freebsd.org Subject: Re: First RSPRO deployed ! Message-ID: <20101122135703.1487660c.ray@dlink.ua> In-Reply-To: <AANLkTikVm7d=MzqSK=hsqgjFjahdwUFp0j_K6nB9gJCf@mail.gmail.com> References: <D74327E9-0A8A-4B46-B4DD-16D0FAF8E3BB@gmail.com> <CBBB7D88-210F-4706-A8FD-83FDA7EBA914@gmail.com> <AANLkTimAWM2UszxUsbnPkt0hra2pj0RqmbqhYMm7eCPv@mail.gmail.com> <201011191201.47230.freebsd-mips@dino.sk> <AANLkTi=58UpFdeGybZqeA0eTugq-B6ebPQ7McPET1QMc@mail.gmail.com> <AANLkTim3s5oW=w3%2ByWFn6BwKq=UoCROnyfS4kgBm8-aD@mail.gmail.com> <20101121155810.e615d4ad.ray@ddteam.net> <AANLkTikVm7d=MzqSK=hsqgjFjahdwUFp0j_K6nB9gJCf@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Nov 2010 15:54:25 +0800 Adrian Chadd <adrian@freebsd.org> wrote: >> On 21 November 2010 21:58, Aleksandr Rybalko <ray@ddteam.net> wrote: >> >> >> * aim to get geom_ulzma into the base :-) >> > No problem to add geom_ulzma into base, problem with lzma. >> > LZMA decoder currently stored in geom_ulzma.c, this one has style(9) >> > problems. >> > Another one decoder live in libarchive, this one inaccessible by >> > kernel. >> > So we need something middle, like zlib in kernel code (why it in net >> > subdir, but uses with many parts) >> >> Well, it may be possible to create a liblzma for the kernel, if >> someone's willing to do the legwork to tidy up the style(9) stuff. Thought ideal one is make copy of libarchive part, that have lzma and xz, last based on lzma but have little more power. >> >> >> * modify it a bit so it exports two GEOM devices - a read-only device >> >> with the lzma'ed FS in it, and a read-write'able "rest"; >> > For what? >> > flash splited by parts by geom_map (old name geom_mtd, loos@ name >> > geom_flash IIRC), that parts rw, parts where stored ulzma compressed >> > data handled by GEOM_ULZMA, that RO. >> >> Can you explain it a bit better? The idea is to not have the RW >> offset/length hardcoded, it instead is based on whatever is left in >> the partition after the RO LZMA section. Ah, now I`m understand you. That possible with geom_map. Example: hint.map.0.at="cfid0" hint.map.0.start=0x00000000 hint.map.0.end=0x00030000 hint.map.0.name="cfe" hint.map.0.readonly=1 hint.map.1.at="cfid0" hint.map.1.start=0x00030000 hint.map.1.end=0x00040000 hint.map.1.name="rgdb" hint.map.2.at="cfid0" hint.map.2.start=0x00040000 hint.map.2.end=0x003e0000 hint.map.2.name="upgrade" hint.map.3.at="cfid0" hint.map.3.start=0x003f8000 hint.map.3.end=0x00400000 hint.map.3.name="nvram" hint.map.4.at="cfid0" hint.map.4.start=0x003f6000 hint.map.4.end=0x003f8000 hint.map.4.name="bdcfg" hint.map.5.at="cfid0" hint.map.5.start=0x00040000 hint.map.5.end=0x00120000 hint.map.5.name="kernel" hint.map.5.offset="96" hint.map.6.at="cfid0" hint.map.6.start=0x00120000 hint.map.6.name="rootfs_ro" hint.map.6.offset="96" # File system start without image header hint.map.6.end="search" hint.map.6.searchkey="--some-delimiter--" hint.map.6.searchstart=0x00130000 hint.map.6.searchstep="65536" hint.map.7.at="cfid0" hint.map.7.end=0x003e0000 hint.map.7.name="rootfs_rw" hint.map.7.offset="32" # Skip delimiter size hint.map.7.start="search" hint.map.7.searchkey="--some-delimiter--" hint.map.7.searchstart=0x00130000 hint.map.7.searchstep="65536" In that example GEOM_MAP setup 8 parts, part called rootfs_ro is where lzma-ed rootfs live, part called rootfs_rw is blank part for rw data. GEOM_MAP search for keyword "--some-delimiter--" in flash from searchstart=0x00130000 with step 64k (searchstep="65536") This require correct alignment of key. TODO: make possible to search different start and end keys for parts with float both start and end. make search behavior easiest to define maybe make possible to parts definition via FDT >> >> > I also use small hack enabled writing for overlapped parts. >> > Biggest part named "upgrade" overlapped with "kernel" part and "rootfs", >> > so we can upgrade box when "kernel" and "rootfs" are opened. >> >> How do you overwrite "rootfs" if you're running from it? >> (Without remounting root into a ramdisk and upgrading, openwrt-style.) Embedded device don`t do many operations on roots (all required soft already in memory), so I only omit checking of overlapped parts and do direct write of new image to part (named "upgrade" in example) >> >> >> * modify GEOM to pass through disk parameters from the provider, so >> >> the flash device can export attributes (read size, write sizes, etc); >> >> * modify the flash driver to have a small default block size (say, 128 >> >> bytes) so small transactions don't require huge amounts of SPI bus >> >> access; >> > I use BS=4, since I know many devices that map their FS not to block >> > boundary. >> >> :( Yup. But I can't help but think BS=4 is going to be very >> inefficient for any FSes which do lots of small IO. I`s not about embedded devices :) >> >> The other thing to consider is what BIO_WRITE means. RIght now it's >> effectively BIO_READ_OVERWRITE_WRITE - ie, the disk devices handle >> this as "read in the underlying sector(s), modify what we need to, and >> write out the results." This is a bit inefficient for flash devices. >> It may be cleaner to add a new BIO for "flash writes" that have >> flash-write semantics - ie, depending upon the flash device behaviour, >> either bits get set 0->1 or they get set 1->0, but an ERASE is needed >> to reset them. That then begs the question - what about >> BIO_FLASH_ERASE? Good idea, but think we still need special FS for NOR like flash. >> >> >> Adrian -- Alexandr Rybalko <ray@dlink.ua> aka Alex RAY <ray@ddteam.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101122135703.1487660c.ray>