**** BEGIN LOGGING AT Tue May 02 03:00:02 2017
May 02 07:42:47 <VartiWork> hi ant_work
May 02 08:01:45 <ant_work> hi
May 02 08:11:14 <ant_work> VartiWork, the bug is http://cgit.openembedded.org/meta-handheld/tree/recipes-bsp/zaurus-utils/zaurus-updater/updater.sh#n85
May 02 08:11:29 <ant_work>  -HOMEFS_SIZE=`echo $RO_MTD_LINE | cut -d" " -f2`
May 02 08:11:41 <ant_work>  +HOMEFS_SIZE=`echo $RW_MTD_LINE | cut -d" " -f2`
May 02 09:45:33 <VartiWork> from what I understand, the home partition was being mounted as read-only by mistake
May 02 09:50:00 <VartiWork> btw I noticed yesterday that the Sharp ROM reports 32MB of total RAM on the 5500 instead of 64. Could it be that it is actually a 5000D? In the back side "SL-5500" is engraved... could it be that 5000D's were always labelled as 5500's in the back, or maybe is this a 5000D's board that has been enclosed in a 5500's shell?
May 02 10:00:25 <ant_work> what happened is, you put home.bin to flash on mtd3 but the sizecheck was wrong
May 02 10:00:41 <ant_work> it was checking mtd2 size instead
May 02 10:01:12 <ant_work> typical copy&paste error
May 02 10:01:56 <ant_work> about the memory, the Sharp rom uses one part of the ram as mtd
May 02 10:02:09 <ant_work> that was possible on collie, static dram iirc
May 02 10:03:14 <ant_work> mtdram
May 02 11:51:45 <VartiWork> I see, strange that it wasn't found earlier, I guess most people, if not everyone prefered to have /home on SD/CF, so they never have to flash mtd3
May 02 11:52:01 <VartiWork> and thanks for the explanation, now I understand the "get back the full 64M on your collie" part of Crow's Cacko ROM
May 02 11:53:23 <ant_work> VartiWork, I have modified updater.sh to read on efile containing the size in MB of mtd2/root
May 02 11:53:49 <ant_work> I am finishing the sizechecks , that's why I discovered the bug
May 02 11:54:00 <ant_work> I have reserved 1MB for home
May 02 11:54:14 <ant_work> so you can have root = 128-7-1 = 120
May 02 11:54:44 <ant_work> smf=7 root=120 home=1
May 02 11:54:58 <ant_work> mtd1    mtd2     mtd3
May 02 11:55:20 <ant_work> as max
May 02 11:56:00 <ant_work> we could ask for user input but ...
May 02 11:56:32 <ant_work> you have to put a file on SD/CF together with updater.sh to repartition, so it makes little sense to put an empty file there
May 02 11:56:56 <ant_work> for users it is better to write in the file th enew root size (I think)
May 02 11:57:47 <ant_work> if you have suggestions for the name of the file, tell me
May 02 11:58:19 <ant_work> fsro_size
May 02 11:58:21 <ant_work> atm
May 02 11:59:16 <ant_work> could also be "root_resize" "rootsize" "rootfs_size"
May 02 11:59:20 <ant_work> ...
May 02 11:59:55 <ant_work> btw if erases both partitions after
May 02 12:00:04 <ant_work> so you can wipe your mtd easily
May 02 12:19:25 <VartiWork> nice work. I wonder if mtd3 does have to be present at all, even if you don't need it?
May 02 12:22:53 <VartiWork> if I understood correctly, you'd have the zImage and initrd.bin file to flash, and at the same time you'd indicate in their filename the size of the partitions you'd like to have, is this correct?
May 02 12:37:05 <ant_work> it is hardcoded in the bootloader afaik
May 02 12:37:42 <ant_work> pdax guys did disassemble and overwrite it to get one partition iirc
May 02 12:37:52 <ant_work> it is not for normal users
May 02 12:39:36 <ant_work> kernel expects 3 partitions as well
May 02 12:40:23 <ant_work> to resize root partition you have to put a file on the SD, like you do with zImage
May 02 12:40:28 <ant_work> it is a separate file
May 02 12:41:54 <ant_work> I guess you need a reboot after repartitioning because the kernel still has the old parts in memory
May 02 12:42:23 <ant_work> so it is not possible to flash rootfs or home
May 02 12:42:44 <ant_work> you could flash zImage (kexecboot) and repartition in one pass I think
May 02 12:42:54 <ant_work> because mtd1 doesn't change
May 02 12:43:09 <ant_work> err. repartition and flash ofc
May 02 12:54:47 <VartiWork> ok, it makes sense now. So the procedure for repartitioning would be to put one or two empty files, each indicating in their filename the desired partition size?
May 02 12:55:37 <ant_work> ehm, not exactly
May 02 12:56:05 <ant_work> the file contains the size
May 02 12:58:13 <ant_work> $ cat fsro_size
May 02 12:58:19 <ant_work> 53
May 02 12:58:39 <ant_work> the home size is calculated automatically, minimum 1 mb
May 02 12:59:07 <ant_work> if you think it is more3 clear we cqn do:
May 02 12:59:10 <ant_work> fsro 7
May 02 12:59:22 <ant_work> err..
May 02 12:59:25 <ant_work> smf 7
May 02 12:59:29 <ant_work> fsro 53
May 02 12:59:34 <ant_work> fsrw 68
May 02 12:59:41 <ant_work> but you have to know the size..
May 02 12:59:53 <ant_work> my scripts does work with 16/64/128 mb
May 02 13:01:26 <ant_work> actually we only change the root/home split, one (root) is enbough
May 02 13:06:42 <ant_work> VartiWork, I have added a new case before kernel here:
May 02 13:06:43 <ant_work> http://cgit.openembedded.org/meta-handheld/tree/recipes-bsp/zaurus-utils/zaurus-updater/updater.sh#n420
May 02 13:07:07 <ant_work> so it expects (atm) fsro_size
May 02 13:07:52 <ant_work> or FSRO_SIZE
May 02 13:32:33 <VartiWork> ok, now I get it, I'm sorry for being dense today, I'm quite tired today, been a stressful weekend. IMHO, better to use the terms "kernel", "root" and "home" instead of introducing new (for the user) terms. What about kernel_size, root_size and home_size then? Also, I find it more convenient to make the home size parameter optional as you suggested, and if it is not present the updater script should automatically fill the remaini
May 02 13:36:39 <VartiWork> Just an idea: what about adding an optional parameter for the start position of each partition? this way you could avoid to put the partitions in damaged areas in the NAND, e.g. "7 1", indicating a partition of 7MB starting after 1MB from the beginning. Using MB won't give much of a granularity, but would make easier to set it up since both the size and position use the same measurement unit
May 02 13:43:41 <ant_work> I fear it would be too complicated for the user
May 02 13:43:48 <ant_work> you mean like http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm
May 02 13:43:53 <ant_work> updater.pro
May 02 13:44:26 <ant_work> remember we only change one value, the split between root and home
May 02 13:45:06 <ant_work> cacko and pdaxrom called it 'root resize', home size is a subproduct :)
May 02 13:46:06 <ant_work> + * PARTITIONINFO1
May 02 13:46:07 <ant_work> + * 0x00060000: 00 00 00 00 00 00 70 00 42 4f 4f 54 00 00 00 00  ......p.BOOT....
May 02 13:46:07 <ant_work> + * 0x00060010: 00 00 70 00 00 00 c0 03 46 53 52 4f 00 00 00 00  ..p.....FSRO....
May 02 13:46:07 <ant_work> + * 0x00060020: 00 00 c0 03 00 00 00 04 46 53 52 57 00 00 00 00  ........FSRW....
May 02 13:46:07 <ant_work> + * 0x00060030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
May 02 13:46:07 <ant_work> + *
May 02 13:46:21 <ant_work> they give start - end for each
May 02 13:47:02 <ant_work> 00700000 smf end
May 02 13:47:13 <ant_work> 03c00000 root end
May 02 13:47:51 <ant_work> 04000000 home end (but is valid only for 64M models)
May 02 13:47:59 <ant_work> they = Sharp
May 02 13:49:03 <ant_work> what we do is to overwrite the '00 00 c0 03' with the right endianness
May 02 14:19:21 <VartiWork> my idea was to make those position values to be optional. If you think that it would confuse users, we might not document them at all, and consider them as a hidden feature, to be mentioned only if anyone explicitely ask for it. I think it would be a pity that anyone would not have any way to use his Zaurus in case of one or more bad blocks. On the other side, it would probably help only for a while, since once bad blocks start t
May 02 14:27:34 <ant_work> the blocks in mtd1 are 'safe'
May 02 14:28:21 <ant_work> I have one bad block in mtd1 and it gets remapped
May 02 14:28:44 <ant_work> the first block is guaranteed error-free
May 02 14:30:01 <VartiWork> probably then the same applies to mtd2 and 3...
May 02 14:30:24 <ant_work> no, Toshiba specs only guarantee first block
May 02 14:31:07 <ant_work> and MTD1 is managed by that FTL taking care of wear leveling
May 02 14:31:24 <ant_work> (that is the code in the 2.4 sources but I am not sure it is ever used...)
May 02 14:33:31 <ant_work> the Sharp 2nd kernel should reinit the list of block usage (like when you use updater.sh), at least in the sources
May 02 14:41:43 <VartiWork> I see
May 02 14:44:27 <VartiWork> what about jffs2? do you know if it has any similar block relocation mechanism?
May 02 14:44:40 <ant_work> no, ubi has it
May 02 14:45:01 <ant_work> the badblock are managed by the lower MTD level
May 02 14:49:12 <ant_work> VartiWork, actually with the orribly limited shell available it would be easier to write that in C, modifying nandlogical
May 02 14:49:40 <ant_work> I plan to release a binary for the advanced users, like nandlogical
May 02 14:52:23 <VartiWork> ok, I like the idea
May 02 14:53:19 <ant_work> I'll send you the updater soon
May 02 15:08:44 <VartiWork> ty
May 02 21:16:08 <ant_home> Varti, another bug found in updater.sh..sigh
May 02 21:16:22 <ant_home> bluelightning, I really don't understand...
May 02 21:16:45 <bluelightning> nor me, why didn't we notice before?
May 02 21:17:18 <ant_home> that code path is not used happily
May 02 21:17:23 <ant_home> or..it happens to work
May 02 21:17:39 <ant_home> there is a funny shell in that busybox 2002...
May 02 21:17:51 <ant_home> I am printing out the vars
May 02 21:18:36 <ant_home> even the sizecheck seems a bit bogus...but it works somehow
May 02 21:38:23 <ant_home> ah, code works now
May 02 21:38:27 <ant_home> finally
May 02 21:38:54 <ant_home> now I need to patch the kexecboot kernels to enjoy repartitioning
**** ENDING LOGGING AT Wed May 03 03:00:00 2017