<kristianpaul>
wolfspraul: is it okay if i put this document  http://ur1.ca/2dx68 from united state coast guard homeland security?
<kristianpaul>
s/put/link on the wiki
<kristianpaul>
it said UNCLASSIFIED
<kristianpaul>
ah is public anway, just i had the broken link
<kristianpaul>
nv
<wolfspraul>
kyak: you there?
<wolfspraul>
I'm wondering what the lowest memory consuming way is to offer nfs exports from the NanoNote
<wolfspraul>
probably I will try the nfs-kernel-server route first, although it seems some people have problems with that. guess it needs portmap as well...
<kyak>
wolfspraul: i'm here
<kyak>
so you are thinking about easy access to files on Ben?
<wolfspraul>
yes
<wolfspraul>
well I'm thinking in all direction, a nfs client on the ben would be nice too
<wolfspraul>
but I think my #1 is that I can nfs-mount the ben from my linux host
<wolfspraul>
I was just wondering whether you had any knowledge about how to do it in a most resource-efficient way
<wolfspraul>
I will probably go the nfs-kernel-server/portmap route
<wolfspraul>
haven't started yet...
<wolfspraul>
the user space servers seems to be much bigger
<kyak>
have you considered ftp or http access?
<kyak>
or maybe replace dropbear with openssh and gain sshfs?
<wolfspraul>
well for myself I'm used to nfs mounts
<kyak>
though i see messages that dropbear works well with sshfs..
<wolfspraul>
I have never done a ftp-mount or http-mount and my experience with DAV tells me that stretching these protocols beyond what they were initially meant for is not a good idea
<wolfspraul>
sshfs is another thing, that sounds interesting
<wolfspraul>
well first I just want to get nfs export to work
<wolfspraul>
without dragging down the boot time or memory load
<wolfspraul>
I think some people on the list reported using nfs, but I forgot who it was or what they did. I think it was a while ago.
<wolfspraul>
I'll just experiment.
<wolfspraul>
I played a little with xiangfu's latest image (config.full_system). good progress but depressing amount of work needed :-)
<wolfspraul>
well we'll do it one by one I guess...
<kyak>
i think it depends on what you really want to do when you get access to Ben's files.. You don't want to watch movies from Ben, but rather upload and download there, right?
<kyak>
therefore, ftp could be enough
<wolfspraul>
yes
<wolfspraul>
screen and keyboard on my notebook are just much more convenient
<wolfspraul>
so I can quickly copy stuff and get things ready on the ben, then take the ben with me 'on the move'
<wolfspraul>
let's say I want to write some small scripts or so
<kyak>
how are doing it right now? i use "scp" and think it's ok
<wolfspraul>
so I plug in my ben, then in ~/ben it's just there :-)
<wolfspraul>
yes but an auto-mounted nfs is more convenient
<wolfspraul>
no worry I am not trying to convert you
<wolfspraul>
I just want to add nfs export capability, and try to find a way that won't hurt boot time and memory usage
<wolfspraul>
I thought you might have used nfs, even on the ben, but I guess not
<wolfspraul>
so no worries. I'll report how it goes...
<kyak>
not on the ben :)
<kyak>
i'm not concerned about copying files to/from ben: by setting things ~/.ssh/config and /etc/host it is possible to copy files as easy as "scp file ben:/data"
<kyak>
about the latest image - i think it's great already :) though of course there are some buggin things
<wpwrak>
kyak: any proposal that replaces dropbear with openssh is music in my ears ;-)
<wpwrak>
for syncing directories, let's not forget rsync
<wpwrak>
rafa: OMG. your approach for preventing opkg from reading the package database is CRUDE ! :)
<wpwrak>
rafa: have an interrupt/crash/reset at just the wrong moment, and ...
<kyak>
wolfspraul: not sure yet.. right now it has three processes, each one using 5008 RSS
<kyak>
this might be a shared memory between these forks?
<kyak>
then it's using 5 Mb real memory
<kyak>
i guess it's the same memory between them.. because the number is exactly the same
<kyak>
compare: both lynx and w3m using ~2.8Mb
<kyak>
of course netsurf is bigger than them
<wolfspraul>
kyak: can we disabled the telnetd and atd?
<wolfspraul>
I'm wondering whether they are totally necessary...
<kyak>
wolfspraul: telnetd is necessary for the first login (or at least this is it's purpose on routers)
<kyak>
you login, set root password, then telnetd is disabled and dropbear is started
<wolfspraul>
sure but the NanoNote is no router :-)
<kyak>
still someone would like to make first login remotely?
<wolfspraul>
cannot really picture it
<kyak>
me too ;)
<wolfspraul>
ok so no need to auto-launch telnetd
<wolfspraul>
how about atd?
<kyak>
we could disable telnetd, yes.. we could also overwrite /etc/passwd so the root user password would some "root" by default
<kyak>
right now it's empty and dropbear wouldn't allow login
<kyak>
unless use explicitely set password locally
<wolfspraul>
I think that's fine
<wolfspraul>
would need to think about it
<wolfspraul>
we are thinking about a little setup script anyway
<wolfspraul>
the root password can be in there
<wolfspraul>
but by default I wouldn't want the device to be setup in a very insecure way
<kyak>
right
<wolfspraul>
in fact quite the opposite
<wolfspraul>
how about atd?
<wolfspraul>
do you know who uses it or where?
<kyak>
i don't use atd
<wolfspraul>
I can't imagine anything on the Ben using it :-)
<wolfspraul>
if that's the case no need to auto-launch it
<kyak>
i think it's even not there in my miniaml build
<wolfspraul>
hotplug makes sense, for microSD insertion
<kyak>
yep
<wolfspraul>
how about dbus-daemon?
<wolfspraul>
dbus is nice, but is anybody using it right now?
<kyak>
i also don't have it...
<wolfspraul>
ok, so telnetd and atd can 'probably' be removed, dbus needs some more investigation
<kyak>
(hm, isn't this the reason why stardict can't be started in my build?)
<wolfspraul>
hotplug and dropbear are needed
<kyak>
i think you are right
<kyak>
wolfspraul: could you please pastebin your "ps" output?
<wolfspraul>
he
<wolfspraul>
no
<wolfspraul>
:-)
<kyak>
i wonder what full_system has running that i don't have
<wolfspraul>
I have no USB cable here
<kyak>
ah ok
<wolfspraul>
I'll do it later
<wolfspraul>
it's funny, I find htop so much more useful than top, unless I find a good reason of something special top can do, we should remove top and just symlink top to htop :-)
<wolfspraul>
not very high priority, but if someone only knows about top they will not enjoy that very much...
<kyak>
i'd suggest to install procps
<kyak>
it has fully-fledged versions of ps, top etc
<kyak>
the desktop ones :)
<kyak>
not the cut-off versions thatbusybox offers
<wolfspraul>
which package is that?
<wolfspraul>
(OpenWrt package I mean)
<wolfspraul>
another thing I noticed is that since we have gmenu2x as respawn in inittab now, you cannot easily kill the process anymore, it will just be respawn
<wolfspraul>
so what is the right way to get rid of gmenu2x now, short of editing inittab and rebooting (which is what I did)
<wpwrak>
kyak: (first login) dropbear lets me in with an empty password - i just hit [Enter] :)
<wpwrak>
rafa: (crude) hmm .. you should at least be able to recover if things go wrong, with opkg update. still ... gotta see if there's an easier way to make opkg think the files aren't there
<rafa>
wpwrak: yes.. it is not so bad.. jlime-pkg update.. or opkg update
<rafa>
will download again those files
<rafa>
and updated :)
<viric>
wolfspraul: 'init q' reprocesses the inittab
<viric>
wolfspraul: so you don't need to reboot
<viric>
(I don't use sysvinit since years, but that's hardwired in my brain somehow)
<mth>
or you could add a menu item in gmenu2x that starts a shell
<wpwrak>
viric: (gcc naming) right now, we have, on OpenWRT, mipsel-openwrt-linux-gcc and mipsel-openwrt-linux-uclibc-gcc, symlinked to each other. Jlime keeps it short and calls their compiler just mipsel-linux-gcc :)
<viric>
wpwrak: ah ok. I always used  mipsel-unknown-linux-gcc
<wpwrak>
viric: 4th variant ;-)
<viric>
i686-unknown-linux-gcc...  some use i686-pc-linux-gcc
<viric>
it's important to the config.guess scripts in autoconf
<wpwrak>
viric: they shouldn't really have to care. i mean, does a build of "ls" need to know if it will run on a PC or a Ben ?
<viric>
wpwrak: well, 'ls' is not the best example for a program that may have to care on the provider of some hardware :)
<viric>
wpwrak: as autoconf has been more used for userland software (usually kernel agnostic) than building kernels, it is not that important.
<viric>
in cases of not having any OS of the kind that can dynamically load code into execution, it may have more sense. Usually that string determines not only the compiler but also the libc or things like that
<viric>
mipsel-jz4750-linux-gnu-gcc  could be for the Ben Nanonote, the toolchain being glibc based (hence the gnu) and it knowing about the SIMD instructions.
<viric>
a toolchain you should not use if you build not for jz4750
<wpwrak>
viric: i think in most cases, all you care about are CPU architecture and ABI conventions.
<mth>
the Ben does not have a 4750 though
<viric>
I was sure I was recalling that number bad :)
<wpwrak>
viric: hah, but gcc usually allows run-time selection of minor variants :)
<mth>
it's a 4724 iirc, which is similar to the 4740
<wpwrak>
often, even the ABI
<viric>
For example, for the loongson2f I use a toolchain that has a "--with-arch=loongson2f" set at the configure time of gcc, so binaries produced by it would not work in any mips64 around.
<wpwrak>
so it's all quite muddy
<viric>
Yes, it allows quite a lot of variants usually.
<wolfspraul>
mth: the Ben has a 4720, which is the same die as the 4740 (and 4725), only that 4720 comes in a COB package, 4725 TQFP, 4740 BGA
<viric>
wpwrak: but as I tell you, that string includes the full toolchain specification, not only gcc, usually.
<wolfspraul>
all three differ in the pinout
<viric>
glibc based system use "linux-gnu" usually
<mth>
ah, that explains it
<mth>
the prototype I told you about seems to use a 4755 rather than a 4750, by the way
<viric>
I should be taking notes :)
<mth>
the "system triples" seems to be very informally specified
<viric>
mth: yes
<mth>
which makes it a pain to actually use it in an automated build
<viric>
I imagine it has been the way to keep them used! :)
<viric>
big flexibility.
<mth>
for example, some use "ppc" and some use "powerpc"
<viric>
reading a config.guess and config.sub will give you an accurate idea of the state :)
<wpwrak>
mth: it's always fun to sift through those translation tables :)
<mth>
reading config.guess made me wonder why people have put up with this system for so long
<kyak>
wpwrak: (first login without password) interesting, i'll check again
<viric>
at the end all ends up working impressively well :)
<mth>
but that's the same feeling I get from all autotools components
<viric>
mth: 'cmake' is even less specified than autotools
<kyak>
wolfspraul: the package is called "procps", but it conflicts with some busybox files, those busybox features must be disabled
<mth>
I haven't used cmake yet, so I cannot judge about that
<mth>
I just have the feeling that something better must be possible
<kyak>
wolfspraul: for gmenu2x, you should run ash from icon menu, and gmenu2x will exit :)
<mth>
if I figure out exactly what that is, I'll write the best build tool ever ;)
<viric>
mth: it's a lot up to the builder. It's popular on programs that are very hardware-agnostic.
<wpwrak>
mth: at some point, people could just draw a UUID and use that ;-) gcc-0li3h8, and be done with it. all further details are in the great dictionary of gcc ;-)
<wpwrak>
rafa: (no password) annoyingly, jlime doesn't let me set the password to nothing. probably because there's no /etc/shadow, but i haven't tracked that one down yet. (too afraid to lock myself out :)
<viric>
wpwrak: passwd has a parameter to set 'no password'
<viric>
maybe I am wrong!
<mth>
wpwrak: UUIDs are the opposite: very exact, but utterly meaningless by themselves
<wpwrak>
viric: you mean passwd -d ? doesn't work on jlime either
<mth>
but why isn't there a registry of established names?
<viric>
ok
<mth>
there is one for USB IDs, there is one for port numbers, there is one for device major IDs etc
<wpwrak>
mth: aren't UUIDs very honest in that regard ? ;-)
<viric>
wpwrak: maybe jlime has a wrong pam configuration
<wpwrak>
viric: yeah, something's not right there. hmm, let's see if i can change the password at all
<B_Lizzard>
kyak, is keymouse X dependent?
<B_Lizzard>
Or does it work under the tty too?
<wpwrak>
nyet. so, definitely a bug.
<viric>
I'll try to use that block2mtd recommended by lars
<mth>
B_Lizzard: if it's the same keymouse as was used on the Dingoo, it doesn't depend on X, since Dingux doesn't run X
<mth>
it injects events using uevent
<B_Lizzard>
awww yeeeaaah
<viric>
how may I know, the instruction set of mips 24kf?
<viric>
In terms of gcc... maybe the gcc manual
<wpwrak>
viric: google for it ? ;-)
<viric>
the gcc manual told me all :)
<viric>
Is anyone using the nanonote as a smartcard token?
<viric>
I don't know how deep the usb device driver can be hacked for that
<rafa>
wpwrak: can you check to creat an empty shadow?
<rafa>
wpwrak: IIRC somebody said at jlime forum or something that creating shadow file fixes
<wpwrak>
viric: (gcc version) perhaps the system is just a bit too compiler-centric. for most users, the question is really "WHO can tell me authority WHAT works on my platform ?". so it would be more something like, qihw-ben-gcc, jlime-nanonote-gcc, etc. with the current scheme, you have both too much and too little information. well, it's not likely to change ... :)
<wpwrak>
rafa: kewl. that worked. easier than i thought :-) thanks !
<viric>
wpwrak: Well, it's compiler + libc centric because usually a user writes some code, and for it to work, it only needs the "other pieces" (gcc + libc) to make it work on the given platform :)
<viric>
And I imagine it is up to the programmer that wrote the autoconf files whether at building it has to care on the hardware provider or not, from the triplet. I can imagine many cases where it should not care.
<viric>
I don't know if, for example, eyeOS cares on that
<kyak>
viric: unfortunately, yes. fortunately, it is fast to test
<xiangfu>
kyak: yes. I remember. I would suggest add "triggersad", the working one 0.1.3,with your origin patch.
<kyak>
xiangfu_: removing all comment lines from its config files helps :) this is weird, but it looks there is some bug when parsing config files
<xiangfu>
kyak: don't have much time on debug 'triggerhappy' :)
<xiangfu>
kyak: so how about just use the working one (0.1.3 + your patch)
<xiangfu>
kyak: when the upstream fixed. we remove 'triggersad' in openwrt-package.git then use the upstream one
<kyak>
xiangfu: let's do it. i don't want to dig into it either
<xiangfu>
kyak: ok. I will revert that change.
<rafa>
viric: do not you have a nn right?
<rafa>
viric: and you are looking some qemu environment to test things right?
<viric>
I have
<viric>
but I don't want to test things there
<rafa>
on nn ?
<viric>
yes
<viric>
Otherwise I'll stop having a nanonote I can use other than for testing
<viric>
I have hope on qemu working
<rafa>
viric: and i do not remember.. but .. the qemu system around which could be useful.. support normal disks?.. no nand.. some emu disk like ide or sata ? (like the -hda option for qemu x86?)
<viric>
yes, -hda will work I think, and then I have block2mtd as lars said
<rafa>
viric: why do not you do a normal tar.gz of your openwrt system and use hda?.. because kernel does not support?
<viric>
I want to test if I can build an ubifs properly too
<rafa>
viric: why exactly you want to have ubifs
<rafa>
?
<viric>
isn't ubifs nice for the nand?
<rafa>
viric: yes. but i do not understand why you are so long to have your qemu system
<viric>
I'm not a big expert on all this :)
<rafa>
viric: you can use hda on that qemu system and use ext2
<rafa>
then if you want to have an ubifs later
<rafa>
for your nn
<rafa>
you do a tar.gz and then convert that to ubifs
<viric>
is 'convert' that easy?
<rafa>
yes
<rafa>
more easy than eat and drink
<viric>
:)
<viric>
I imagine I'm simply having the fun of emulating a ubifs root on qemu
<rafa>
yes.. i do not understand the advantages to do that
<viric>
:)
<rafa>
and i see your concerns about how to do that  for a long time on this chat
<viric>
rafa: you could buy a programmable pocket computer other than working on jlime, that's also "easier" ;)
<rafa>
viric: yes.. but the advantages??!!!
<rafa>
which are them??!
<rafa>
viric: i did not buy my nn.. jlime bought that
<rafa>
tell them
<viric>
haha :)
<rafa>
I still do not understand sorry
<viric>
well, if you mean I was annoying in the chat for a long time with those questions...  if larsc would have come up with that block2mtd I would not have bothered that long.
<rafa>
no no.. that all is okey
<rafa>
i do not undesrtand which are the advantages to do that
<viric>
I'm trying to make some recipes that build a ubifs for the nanonote
<rafa>
and no simply to use qemu with had and ext2
<viric>
that's my main goal. And I think I can make init scripts and all that - I don't see troubles on those. My main blocker was how to test an ubifs image.
<viric>
I wanted to solve the blocker.
<rafa>
I see.. but you have doubs about how to convert a, for example, rootfs dir with your system on a ubifs image? if so.. i have some notes useful
<rafa>
about how to convert that into a ubi image for nn
<viric>
I have some recipes
<viric>
I have the image
<viric>
I want to test it
<viric>
I'm almost booting it ;)
<rafa>
cool ;)
<viric>
for me this ubifs, with the ubi layer, is quite unusual
<viric>
rafa: I'm not using openwrt or jlime... I'm a bit on my own
<viric>
it's nice for learning about all it.
<kyak>
xiangfu: i see you are playing with reflash_ben.sh now. How do you think, would it be easy to implement a progress bar to indicate flash progress?
<kyak>
viric: so are you using that qemu-jz or stock qemu for that?
<viric>
kyak: stock qemu
<kyak>
nice. have you managed to boot the uboot?
<viric>
I'm using the malta board
<viric>
And I did not plan to build uboot...
<viric>
I boot with -kernle
<kyak>
ah ok
<kyak>
you should have a custom kernel for that, right? not the one you can for Ben
<viric>
exactly
<kyak>
*use for
<viric>
but I mostly wanted to test userland things
<kyak>
i think you might be very close to your goal :)
<viric>
I hope so!
<kyak>
let us know when you succedd
<viric>
sure
<kyak>
i'd love to repeat your steps
<viric>
well, I'm using nix for all that... nix expressions that create all I want. It may look weird to you if you never used nix
<kyak>
viric: i remember we discussed nix once.. have you been able to build a working image with that?
<xiangfu>
kyak: Hi. Please test this 'triggersad' in your host. if works fine. help me update the config.full_system. thanks. I need goto sleep. (about flash progress, talk it later) see you.
<xiangfu>
kyak: thanks for netsurf and keymouse .
<viric>
kyak: all the software I use in the nanonote comes from that. kernel included.
<kyak>
xiangfu: np! and thank you!
<viric>
kyak: I'm making nix also build an ubifs; I'll make some little boot scripts... and let there be only nix-generated things in the nanonote.
<viric>
kyak: (uboot included too)
<kyak>
viric: so you have to patch the kernel, right? since not all ben-related things are upstream
<viric>
I build the jz kernel from the git repositories, not vanilla.
<viric>
(2.6.35). I've not tried to go to 2.6.36 still
<kyak>
ah ok
<kyak>
that's pretty cool i'd say. it's another distro for ben :)
<viric>
something like that, yes :)
<kyak>
do you have something special there? something you think might be useful for others? :)
<viric>
nothing special, other than it has the usual advantatges from nix
<kyak>
do i remeber it correct that Ångström is using nix?
<viric>
no, it is not
<viric>
only nixos uses nix
<viric>
(But nix works in many systems, not only nixos)
<kyak>
okay
<viric>
I hit UBI error: validate_ec_hdr: bad VID header offset 4096, expected 64
<viric>
It may be time for learning ubifs at leats :)
<viric>
least
<viric>
hmmm I'm getting to the point that I cannot prepare a file to be used as block device for a block2mtd for a qemu guest, unless I have 'ubiformat'ed it before, using block2mtd in the host...
<viric>
rafa: do you have a pointer to some recipes of making the ubifs images that people flash into the nanonotE?
<rafa>
viric: i do not know what recipe means in this context. But suppose that you have a rootfs dir on your pc.. and it has the files to build the ubifs rootfs.. For example you have under a rootfs/ : bin etc usr .. etc..
<wpwrak>
kyak: yeah, it's set to something else. but you can set it to empty.
<kyak>
something else huh..
<kyak>
root:!:0:0:root:/root:/bin/ash
<kyak>
this is the default string
<wpwrak>
ah well, that would make it difficult to get in :)
<kyak>
indeed
<wpwrak>
but .. isn't there /etc/shadow ?
<kyak>
thereis no shadow by default
<kyak>
there's a separate pacakge for this, not in base system
<wpwrak>
i see. then it's indeed blocked.
<kyak>
heh.. that keymouse thing is working in Qt also :)
<kyak>
for some reason, this is funy
<kyak>
*funny
<qi-bot>
[commit] Juan64Bits: Adding bases to the code generator. Code text edit, fixing input/output ID control, etc. http://qi-hw.com/p/nn-usb-fpga/2efe106
<viric>
kyak: sorry, I went away...
<viric>
kyak: The kernel has access to /dev/hda, where an image lays. But it's told to create a mtd device from whatever there is in hda. And then use that mtd device for ubi volumes.
<viric>
kyak: There is no mips board in qemu that includes a NAND or NOR. qemu emulates some boards. Some have PCI buses, so they can get the usual IDE controllers, VGA cards, ...
<kyak>
viric: i see.. so this way, you emulate a mtd device on your host?
<viric>
in the guest
<viric>
but it does not work.
<viric>
I think the main problem is that ubinize creates images only of the minimum size
<viric>
and expects people to use 'ubiformat' on the final flash.
<viric>
But in this case the final flash appears from the image at kernel boot time.
<viric>
I don't have a middle point where to 'ubiformat'. It's all up to block2mtd
<viric>
kyak, rafa: I just booted a qemu-system-mipsel from ubifs! :)
<wpwrak>
viric: you did it ! congratulations !
<viric>
Yes! Great thing!
<viric>
sh `nix-build -A emulate sim-packages.nix`Â Â Â Â <= this commands builds whatever I want on the target and runs a qemu booting it from ubifs
<viric>
Now I'd like to reuse the nixos expressions for a super-cross-nixos. It may work. But that's for tomorrow.