WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Towards Microcore on Allwinner A10  (Read 78739 times)

Offline caminati

  • Full Member
  • ***
  • Posts: 184
    • Homepage
Re: Towards Microcore on Allwinner A10
« Reply #30 on: August 20, 2012, 07:57:26 AM »
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.

Nice! That uCore is still not completely functional, mainly due to blkid missing, but this is nice to hear.
I think the presence of 2nd partition is irrelevant, by the way.
From now on, I will use image files :)

As soon as I have time, I will try to get to beta quality (except for zcache, again).
Then on to toolchain: if you have some tcz already done, I would like to try that.
Otherwise, I've my eyes set on aboriginal, which seems to provide binary tarballs with nice toolchains for lazy people :)

Offline caminati

  • Full Member
  • ***
  • Posts: 184
    • Homepage
Re: Towards Microcore on Allwinner A10
« Reply #31 on: August 22, 2012, 10:20:12 AM »
If the upload goes well, you will find first beta image on my homepage.
Check README for usage.

Notes:

Very few kernel modules and binaries, hopefully not needed during boot, missing.
I redirected verbose tc-config output to /var/log/tc-config: it would be useful if Core people checked that to assess about thinks going well.

tce-load et others do not work due to absence of builtin getopts.
Redirecting to busybox getopt does not work, however changing #!/bin/sh to #!/bin/ash should do it, if I included the right busybox.

Sorry, I am not totally sure of statement above, since busybox versioning is a mess, as is u-boot one: indeed I probably included the wrong version in previous releases, so yes, Robert's failure to boot was probably my fault.
This time I checked the upladed version myself, should work.

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: Towards Microcore on Allwinner A10
« Reply #32 on: August 23, 2012, 10:29:04 AM »
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.
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.
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.

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.

Otherwise I can only test your packaged core while continuing in parallel development.
10+ Years Contributing to Linux Open Source Projects.

Offline caminati

  • Full Member
  • ***
  • Posts: 184
    • Homepage
Re: Towards Microcore on Allwinner A10
« Reply #33 on: August 23, 2012, 03:25:33 PM »
First let me say thanks for your interest, contribution, and progress in getting Core on A10.

I'm doing that because I want my hardware to run the software I like.
Sheer utility apart, hence, I'm doing that to celebrate how good what you and Core team created is: thanks for that, folks!

Your latest build boots fine too. However I have some concerns about the direction this is going.
Obviously bterm is the trick to get Core on A10 without it, as the other distros have done, is to have full X.
If you mean that a possible bterm crash could make the machine unreachable, I am a bit concerned about that, too.
We're relying on some obscure piece of code as the only means of video output.
However, it is a tiny piece of code, while any X server is much bigger, and hence much more likely to crash.
The good news is that it never crashed here, and even under some trivial crash tests (e.g. killing it while reading /dev/ptmx) it behaved itself.
By the way, any ideas for meaner tests on bterm are welcome.
Of course, I would prefer fbcon support in mainline kernel, even only to be a bit more confident about stability.

Your approach is to have already packaged up Core (initramfs) which makes it more difficult to be open development.
My approach, as I have stated was to have an open rootfs, then later package it up. It eliminates extra steps during development cycles.
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.
Indeed, I preliminarily repackaged your core.gz in nine separate rootfs: binaries, scripts, symlinks, and so on, which is probably not much scriptable (but may desirable for its own sake).
Then I overlaid selected binaries and patches to some of those split rootfs and repackaged, which is quite quick and scriptable.
A second reason is that there is an annoying difference between working with and without initramfs: in the latter former case /dev must be pre-populated, I don't know why exactly.
So I had to avoid switching between the two modes, and stuck with initramfs.

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).
Bottom line: doing something like
Code: [Select]
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

This is a patchwork. busybox binary is the one distributed on its homepage, with a second version coming from aboriginal for some applets (notably sh).
bterm binary comes from debian.
I managed to build it on x86 (with both manual patches and debian's diff, which I don't like, however), but I have to set up some toolchain before having and TESTING it on ARM.
Alternatively, I could free a mmc and setup some ready-made Allwinner Debian to straight compile it.
The rest is either from debian or compiled on ARM Debian some weeks ago, before I needed the mmc for other uses.

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.

Otherwise I can only test your packaged core while continuing in parallel development.
I would strongly prefer an open and collaborative work, and would gladly provide any source code.
As from above, the sources are all there, the problem is that in many cases I'm using the corresponding binaries compiled by someone else (i.e., Debian maintainers), and that I did that manually, without tidy scripting as you did in your picore.
In the future, I could set up Debian on my tablet, and reproduce the binaries by myself, if you think this would be preferable. In a second moment, I could do the same from ARM Micro Core by using some toolchain.

For the time being, I can supply:
  • kernel config
  • core.gz split into the nine parts as from above
  • a script to get from the split core.gz and other binaries to uCore
or whatever you deem worth it.
« Last Edit: August 24, 2012, 08:31:39 PM by caminati »

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: Towards Microcore on Allwinner A10
« Reply #34 on: August 23, 2012, 03:47:29 PM »
Thanks, I figured out how to get into Ucore by using dd.

I did notice that your busybox is not compiled from our config as some applets are missing and other are configured differently, e.g.,tar.

I usually start with natively comping our busybox, e.g. as on the raspberry pi, as it is the center piece of Core then start from there.

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.

Sorry, If I sounded like I was complaining about bterm. That is a great find!

I suppose we can hold off hosting until compile from sources becomes available or unless your resources (serfver) becomes to taxed.

Allwinner is a challenging platform and you have done an awesome job!



10+ Years Contributing to Linux Open Source Projects.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: Towards Microcore on Allwinner A10
« Reply #35 on: August 23, 2012, 04:04:24 PM »
So, anybody hacking on the Allwinner fbcon currently? I haven't seen anything about that recently on the arm-netbook list.
The only barriers that can stop you are the ones you create yourself.

Offline caminati

  • Full Member
  • ***
  • Posts: 184
    • Homepage
Re: Towards Microcore on Allwinner A10
« Reply #36 on: August 23, 2012, 04:40:49 PM »
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!

Offline caminati

  • Full Member
  • ***
  • Posts: 184
    • Homepage
Re: Towards Microcore on Allwinner A10
« Reply #37 on: August 23, 2012, 04:42:46 PM »
So, anybody hacking on the Allwinner fbcon currently? I haven't seen anything about that recently on the arm-netbook list.

I'm afraid nothing's happening on that front.

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: Towards Microcore on Allwinner A10
« Reply #38 on: August 23, 2012, 08:37:18 PM »
My headless is running a linaro ubuntu precise server via cnxsoft.

Success! I have now scripted unpacking and repack of uCore and it still boots!   ;D
10+ Years Contributing to Linux Open Source Projects.

Offline caminati

  • Full Member
  • ***
  • Posts: 184
    • Homepage
Re: Towards Microcore on Allwinner A10
« Reply #39 on: August 24, 2012, 12:10:23 AM »

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?

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: Towards Microcore on Allwinner A10
« Reply #40 on: August 24, 2012, 10:38:33 AM »

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.
10+ Years Contributing to Linux Open Source Projects.

Offline caminati

  • Full Member
  • ***
  • Posts: 184
    • Homepage
Re: Towards Microcore on Allwinner A10
« Reply #41 on: August 24, 2012, 08:27:56 PM »

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.

Yes, there are some, especially among libraries.
Now that you have a good busybox, you can set back shebang in tce-load to
Code: [Select]
#!/bin/sh.
Furthermore, could you check if
Code: [Select]
mkswap /dev/zram0 works?
Cause for me it fails with something like `image too small', and I fear issues with kernel compilation.

Offline caminati

  • Full Member
  • ***
  • Posts: 184
    • Homepage
Re: Towards Microcore on Allwinner A10
« Reply #42 on: August 25, 2012, 01:20:05 AM »
Here I take public notes about another issue stemming from the problematic diversity among ARM hardware: hard-float (armhf) versus emulation (armel) EABI.

Since even RPi has hardfloat, and given the gain, it would be better to make sure everything is built as hardfloat right from the start.
I think this is already the case with the userspace binaries in my images (I have no idea about the kernel, but this should be a minor problem, see here: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=71&t=15221 and here: http://www.linuxsmiths.com/blog/?p=253).
To test that, I downloaded the same app from Debian armel and armhf repositories, and tried to run both: armel one couldn't start, armhf could.
Is there a better way?
Robert, do you know which species is the RPi image build with your picore-kit?

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: Towards Microcore on Allwinner A10
« Reply #43 on: August 25, 2012, 11:19:18 AM »
caminati, what is the code that you used to create the final  img  file.
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.
« Last Edit: August 25, 2012, 12:53:33 PM by roberts »
10+ Years Contributing to Linux Open Source Projects.

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7361
  • Founder Emeritus
Re: Towards Microcore on Allwinner A10
« Reply #44 on: August 25, 2012, 11:40:35 AM »
picore-kit is currently Debian arm soft float. Reason, it was easy to use Qemu to begin testing. The qemu-extra.tcz currently in the repository was used. This version of qemu does not support hard float. In fact, qemu-extra.tcz could use an update!

But the concept of the kit should be easy to extend with Raspbian with the caveat of those arm-linux-gnueabihf directories. Since I see no progress here, I will revisit as time permits.

I agree with observation of the current state of arm development. I was choosing the kit method so as to have a complete environment from which to start. Being kernel, modules, and libraries compatible with a released and supported system is nice for prototyping as Core only needs few binaries.

Then there is the decision going forward should extensions be made so as to be compatible between rpi and a10 systems, lowest common denominator? It is still early and I feel we are still prototyping both rpi and a10. We have a ways to go.
10+ Years Contributing to Linux Open Source Projects.