very few busybox applets missing
Not sure, but have you had a look at http://busybox.net/downloads/binaries/latest/ already?
@caminati, Sorry but I did not have any success with your kernel & rootfs. But it is likely because I don't have an Allwinner tablet.
Probably a script.bin (evb.bin) or some such. Seems Allwinner just about needs hardware packs of specific boot bin files.
Anyway, I am extending my kit methodology to my Allwinner A10 Mele. I believe I had Core booting. But alas I need to add X to be sure. So I continue with great hope for a mele-kit.
Dear god that font :P
I took a screenshot from /dev/fb0 via rawtoppm (well, no camera or whatsoever here). See attachment (I don't know why the background turned out to be grayish, it is actually white). Boot time is about 10 seconds :)
Ok, tc-config does little of what it is supposed to do, still...
"Created with GIMP" ??
"Created with GIMP" ??Sounds like he may have used netpbm.
Hi tinypoodleQuote"Created with GIMP" ??Sounds like he may have used netpbm.
I packed a much more complete port of Micro Core, not even an alpha, though.Still no text display on my Mele. Is it because I need hdmi output while you use lcd output for table?
I am uploading it right now:
caminati.net.tf (http://caminati.net.tf)
or, equivalently:
https://sites.google.com/site/marcocaminati/ (https://sites.google.com/site/marcocaminati/)
It is a tar.bz2 with the separate components to be installed manually, if anybody wants a whole media image for simplicity, I can provide it.
Anyhow: now Core scripts are all there, even though actually tc-config is not completing yet.
Refer to the included README.
There I also explain the approach I adopted to port, somehow more streamlined than before, after seeing Robert's Rpi kit.
Still no text display on my Mele. Is it because I need hdmi output while you use lcd output for table?
I cp mele-a1000.bin /mnt/sdb1/script.bin.
Boot Mele, keyboard lights flash, mouse stays lighted.
But no signal to hdmi.
Your code is specifically looking for script.bin?
I will try other bin files on the Ubuntu image.
No response that I can detect when I try:Yes, during tests I kept both names with identical contents, to be on the safe side.
Does writing something like /bin/busybox poweroff -fn work?
Sorry to bother you: have you tried Alt+SysRq+e or Alt+SysRq+i (the sooner during booting process the better)?
I also tried renaming evb.bin, that is what Ubuntu and the miniand distros use, to script.bin and still no hdmi output.
No response that I can detect when I try:
Seeing that you posted a new image file: A10MinimalLinux.img.gz
I tried it with mele-a1000.bin renamed to script.bin.
Viola! I see text. Very LARGE text. It boots to login!
But this is not uCore, initramfs as was the first attempt.
This is why I am delaying initramfs on rpi until I get the basics, traditional rootfs working.
Anyway, you have reached a first milestone. Awesome!
uCore now working.
Used the image file. Copied the boot.scr from first attempt together with uCore to first partition. Formatted the 2nd partition and left blank.
Boots and is working fine.
First let me say thanks for your interest, contribution, and progress in getting Core on A10.
Your latest build boots fine too. However I have some concerns about the direction this is going.If you mean that a possible bterm crash could make the machine unreachable, I am a bit concerned about that, too.
Obviously bterm is the trick to get Core on A10 without it, as the other distros have done, is to have full X.
Your approach is to have already packaged up Core (initramfs) which makes it more difficult to be open development.At first stages, I used standard rootfs (no initramfs). Later, with some stability achieved, I stuck with initramfs; the main reason is that I want to stay as close as possible to original core.gz x86 initramfs.
My approach, as I have stated was to have an open rootfs, then later package it up. It eliminates extra steps during development cycles.
I know of the packaging technique, as documented on j1nx's site. But not of unpacking such. If you do please share.Sure: the only constructive difference between uCore and core.gz is the final mkimage pass, which merely prepends a 64-byte header for u-boot purposes (I think this has to do with u-boot having to deal with a filesystem without having an OS running).
tail -c +65 uCore | gunzip | sudo cpio -idshould give the rootfs in pwd.Do you have the source and makefiles for the binaries that you are distributing or are you basing this on say the linaro builds?
I am most interested in the source and makefile for bterm
Also it would be great if our target is the same. So if you have sources then perhaps hosting them here will make for a more open devlopment environment.I would strongly prefer an open and collaborative work, and would gladly provide any source code.
Otherwise I can only test your packaged core while continuing in parallel development.
Today I have setup a headless Arm development machine for compiles. Now that I am able to get to the roofs I can better look around and hopefully start adding some missing pieces.Is your headless running Debian or what? Just curious.
Sorry, If I sounded like I was complaining about bterm. That is a great find!You can be sure you didn't sound like that.
I suppose we can hold off hosting until compile from sources becomes available or unless your resources (serfver) becomes to taxed.That's ok.
Allwinner is a challenging platform and you have done an awesome job!Thanks!
So, anybody hacking on the Allwinner fbcon currently? I haven't seen anything about that recently on the arm-netbook list.
Success! I have now scripted unpacking and repack of uCore and it still boots! ;D
Success! I have now scripted unpacking and repack of uCore and it still boots! ;D
You mean that you repacked it substituting your own-compiled busybox?
Success! I have now scripted unpacking and repack of uCore and it still boots! ;D
You mean that you repacked it substituting your own-compiled busybox?
Yes!
Looking at other issues now. Finding many broken links.
#!/bin/sh.mkswap /dev/zram0 works?In fact, qemu-extra.tcz could use an update!
caminati, what is the code that you used to create the final img file.
find | cpio -H newc -o | gzip > ~/core
mkimage -C none -A arm -T ramdisk -d ~/core ~/uCore
I now have Core's busybox, blikid, and mke2fs working in uCore. I can now do a backup on A10!
Most scripts should be working since it is our busybox. I would like to post the img so that others may begin testing.
caminati, what is the code that you used to create the final img file.
find | cpio -H newc -o | gzip > ~/core
mkimage -C none -A arm -T ramdisk -d ~/core ~/uCore
I now have Core's busybox, blikid, and mke2fs working in uCore. I can now do a backup on A10!
Most scripts should be working since it is our busybox. I would like to post the img so that others may begin testing.
Thanks for your script. I will take a look.
I know of creating the sdcard and uCore. I have been overwriting the original uCore with my updated uCore.
But typically one dd the sdcard to an image file. I presume you are using some count= with dd as you wouldn't want 4GB or 8GB image.
Are you just summing up the four files +1MB for the count. That is my question.
dd if=/dev/sdb bs=1M count=p+1 | gzip > img.gzwhere p is the size of the first partition, which contains everything.OK. I did a du -h on first( only) partition. Results 5.8MB so I rounded 6 +1 = 7MB
It boots OK for me. Note that I changed the font to 12 so you may want to use the larger font if on tablet.
Also it has my mele script.bin. Anyway, have a go it can be found at
OK. I did a du -h on first( only) partition. Results 5.8MB so I rounded 6 +1 = 7MB
I have tested roberts's image on my gemei G2, but it reboots again and again for loop.
If it reboots after loading the kernel (screen on, usb flashing, etc...), and with a wait time of 10 seconds, it could be the panic=10 in boot.scr.
In this case, the kernel panic could be due to something wrong with uCore or uImage.
Since it works for other people, are you sure you had no IO errors when writing Robert's image to mmc?
On the other hand, I still do not have luck to change the font.
Is the font needed to be converted under a arm-system ?
Thanks, it boots fine for me.
I notice that you didn't take my last image as a starting point: there is an error in init.d/rcS coming frome my previous posts, and zram/zcache are missing.OK. I did a du -h on first( only) partition. Results 5.8MB so I rounded 6 +1 = 7MB
You rounded to 6: you mean that you re-created, using fdisk, a 6Mb partition?
Because only after that you can be sure to catch everything.
No, actually I myself converted the provided fonts on a x86.
Please, describe your problem more accurately: "no luck" means no terminal at all or the old font persisting? What happens when you apply your font?
Did you check the font file's permissions?
Sorry for my bad depiction.
The situation is the backlight turns on, but it seems not to open the terminal.
I think the kernel is loaded correctly, but the bterm doesn't.
Does the font file's permission really have any effect on it?
I had used your font file with different permissions for simple quickly tests, and it seems not to have any effect.
Actually I made an 8MB partition to test with. And I used 8MB to dd the download img file.root@dev:/home/tc# df -h /mnt/sdc1/
Filesystem Size Used Available Use% Mounted on
/dev/sdc1 8.0M 5.8M 2.1M 73% /mnt/sdc1
No, I did not see that you posted another cut. I will post another update with the missing zram.
Permissions was just a blind guess.
Maybe bterm doesn't like your particular fonts.
You could try it on another machine, like an X11-running ARM or X86, and see what happens.
I'm afraid nothing else's coming to my mind for the moment.
Permissions was just a blind guess.
Maybe bterm doesn't like your particular fonts.
You could try it on another machine, like an X11-running ARM or X86, and see what happens.
I'm afraid nothing else's coming to my mind for the moment.
I tried to use your fonts on my X86_64 machine with bterm and it got stuck.
(sudo bterm -f ocra-12.bogl )
The permissions of ocra-12.bogl is :
-r--r--r-- 1 root root 12384 8月 27 09:06 ocra-12.bogl
And I used my own fonts it works correctly.
-r--r--r-- 1 root root 285908 8月 27 21:55 FreeMono.bogl
I also change the permissions of my font to:
---------- 1 root root 285908 8月 27 21:55 FreeMono.bogl
It also works.
Due to this test, I think the permissions doesn't have any effect.
Another cut, for testing purposes only, now posted see: http://distro.ibiblio.org/tinycorelinux/4.x/arm/armv7
SHOWAPPS=1and # while [ ! -e /dev/rtc0 ]; do usleep 50000; doneAnd it still worked: this should be the original tc-config file working.echo 33554432 > /sys/block/zram0/disksize.What version of busybox and would need its config file.
Actually I used busybox-1.20.1-config. Which I see Brian has not yet posted.
Curious that you used 1.17 ? Are you suggesting later ones from the same site have the same issue?
Another cut now posted with net applets now resolving names.
http://distro.ibiblio.org/tinycorelinux/4.x/arm/armv7
The issue is that many distributions have enhanced/deviated from standard unix. Many have IMHO bloated up everywhere. So each platform I had tried their resolver infrastructure was preventing the network applets from working. Finally, I decided to setup a cross-compiler so that I could use Tiny Core. Success!
video: sun5i-disp: Initial fbcon support. …
based on Jari Helaakoski's 3ca6f75 for sun4i.
commit 59b89c9e95
amery authored 20 hours ago
Knowing that it is a huge task of compiling and building extensions,
I have purposely made raspbianCore library compatible with Raspbian.
To that end I have been working on and testing dynamically creating
tczs directly from Raspbian repositories. If this is successful then
it will greatly lessen the need to build/compile hundreds of extensions.
So far initial tests look promising, example: Links browser and its dependencies.
Auto created by entering only links.
My goal is to easily and transparently gain access to some of the 40,000 debs
which the user can select. They, of course, become tczs and thus gain
the Core advantage of pristine boot, onboot, and ondemand features.
Our ibibio arm tcz repository might then only need to host custom extensions not
available in the Raspbian repositories.
So I would hold off building extensions until I accomplish a first
milestone of this tool. Then evaluate its performance and capabilities.
Of course, I am not going to abandon the community built extensions.
The support code for such will remain intact.
The new tool will be just another option. Another tool that the user may or may not
elect to use.
Karl, Thanks for sharing. As time permits, I am making progress on the "import" program to easily access Debian Repositories directly from Tiny Core x86, and A10 devices. Then auto generate full tcz extensions with dependencies. I now have another test suite, wireless and wpa, via your blog post.More progress to report.
More progress to report.
I have been able to easily import wireless-tools and wpasupplicant to get wifi working with the auto generated tczs + deps.
This is all done without running any debian distro and without storing any .deb files. I have been able to import running Core x86 as well a10Core and rpiCore. I have also be able to use the wifi.tcz to scan, select, and connect. The concept is proving to be a viable additional tool.
modprobe: can't load module fuse (kernel/fs/fuse/fuse.ko): invalid module format
fuse: no symbol version for module_layout
Karl, I will post my modules directory. If all you want is 8192 its in there!
Wait while I upload if.
....
Done: Look for allwinner-sunxi-v3.0.39-modules.tgz in the armv7 directory.
I have seen LiveSuit. But since it is a Windows program and I do not have, nor desire Windows, I am unable to comment on its function with regard to Core.