dCore Import Debian Packages to Mountable SCE extensions > Allwinner A10
Towards Microcore on Allwinner A10
roberts:
--- Quote from: caminati on August 24, 2012, 03:10:23 AM ---
--- Quote from: roberts on August 23, 2012, 11:37:18 PM ---Success! I have now scripted unpacking and repack of uCore and it still boots! ;D
--- End quote ---
You mean that you repacked it substituting your own-compiled busybox?
--- End quote ---
Yes!
Looking at other issues now. Finding many broken links.
caminati:
--- Quote from: roberts on August 24, 2012, 01:38:33 PM ---
--- Quote from: caminati on August 24, 2012, 03:10:23 AM ---
--- Quote from: roberts on August 23, 2012, 11:37:18 PM ---Success! I have now scripted unpacking and repack of uCore and it still boots! ;D
--- End quote ---
You mean that you repacked it substituting your own-compiled busybox?
--- End quote ---
Yes!
Looking at other issues now. Finding many broken links.
--- End quote ---
Yes, there are some, especially among libraries.
Now that you have a good busybox, you can set back shebang in tce-load to
--- Code: ---#!/bin/sh
--- End code ---
.
Furthermore, could you check if
--- Code: ---mkswap /dev/zram0
--- End code ---
works?
Cause for me it fails with something like `image too small', and I fear issues with kernel compilation.
caminati:
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?
roberts:
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.
roberts:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version