Hi guys, Did someone manage to get barebox working on Mini210/Tiny210 ? Alexey Galakhov started to port it, but I'm not sure he got a fully functionnal version. I'm not a good developper enough to help on this topic, but I'll try the github version : https://github.com/agalakhov/barebox/ If anybody is interested...
The issue with the mini210S at least will be the closed source nand driver, unless barebox has got that covered in some way?
Here is a post from him http://permalink.gmane.org/gmane.linux.drivers.mtd/40418 And I saw there was an uboot version on a S5PV210 based devboard, so it should be possible to find some source code somewhere. http://www.armkits.com/product/sbc2100.asp This was Alexey's status in september : What IS done: * command line works * kernel may boot from any accessible device (if any) * PLL and DRAM initialization works * bootloader may start from MMC using iROM code Work in progress (works for me but not released yet): * NAND read/write support What IS NOT done: * Booting from NAND * USB support (should be easy to do but does not work yet) * MMC support (ditto) * Ethernet support (untested)
I would really like to see this happen, I don't know what drivers barebox uses but there is a uboot version around that can at least boot from SD card. https://gitorious.org/opens4tiny210/u-boot But as it stands, there is no nand driver source code available for the mini210S 4GB.
I don't really understand this Nand driver problem. What is it used for? I thought it was just necessary for linux kernel. I don't understand the difference with mini2440 for example. Please, correct me where I'm wrong, but for me, nand is connected to the CPU through address & data lines. So the CPU access to it with hardware signals, driven by software values in its internal registers. What justifies the need of this driver, which is not the case with mini2440/6410 ? Thank you for your explanations
because the nand is different, it's a 4GB single chip on the mini210S, the driver is closed source, I believe it's using at least 16bit ecc, if you can find the ecc correction code for 16bit hardware ecc on this samsung SOC then we probably wouldn't need it. We also do not have the oob layout, this is where the ecc data is stored, it needs to be read back and compared, if you get the location wrong, your nand will look instantly bad even if there is nothing wrong with it. Lastly, we don't have a datasheet for the nand, there are pdf's floating around the net that are supposed to be for that chip, without anything solid to go on, it's ambiguous as to what the chips layout actually is, for instance, I dumped the oob from the 4GB chips, it comes back as 448 bytes, linux-mtd says it should be 436 bytes, datasheet says 640. Not entirely sure who's correct here, the nand clearly works, I can use my dumped settings to create new nand images using yaffs2utils and FA kernels boot. so, we need a nand driver of some description in the bootloader if we want to boot from nand.
I found this on chinese forum, would it help to handle NAND issues ? http://translate.google.com/translate?sl=zh-CN&tl=en&js=n&pr...
Not sure, if it's for the first tiny210 then probably not directly, as it uses SLC nand/8bit ecc I believe. Afaik, the mini210S nand driver is using 16bit ecc.
I hope this will help porting barebox to mini210/tiny210 : https://github.com/Reggi3/210-nand-patch
Me too screwface as it was me that posted it :D
I know, it was just to inform the whole forum readers, but maybe you did it before and I missed your post.
Thanks :)
Just for information, Cubieboard uses the same NAND chip. I have to dig a bit more if I find u-boot source. And maybe we can find some usefull help int the kernel
There are 2 or 3 different efforts going on on the arm9home.net forums, a barebox and uboot, however, they're for tiny210 slc. At the moment it doesn't really make much sense what's going on with them all, there are bits missing due to old versions of uboot and barebox and a couple of things in uboot I don't understand. I think I've even worked out why superboot can't write files > 2GB to nand too :-) Please do dig around for the u-boot source code, we probably can't use their nand driver at all (although it's not too much of an issue) but it would be nice to see what it's doing.
Hi! Jumping into this discussion as it seems really focused on a new project I might be involved in soon. The project's main goal will be having a fully working OE/Yocto [1] BSP layer for the mini210 board. This involves supporting the board in u-boot and porting the Linux patches by Friendlyarm to a more recent kernel and possibly upstreaming them. I have no experience with barebox, but it might a valid option too, I guess. At moment, I'm just reading code and googleing around to learn more about mini210 and related software. I don't even have the board with me yet to experiment with. Reading this post brought me a few questions I hope you can help me give an answer. Is, in your opinion, the NAND driver the only obstacle to a fully open source support of the board? I just started to compare the FriendlyArm kernel with a stock 3.0.8 tree, to figure out where they differ and to have a taste of the general quality of such a code. Can you confirm that the barebox patched tree previously mentioned in this thread and hosted in [2] is not of any help here? It only addresses tiny210 boards which come with different NAND chips (8bit ecc), correct? Apart from the aforementioned ones, do you know of any coordinated effort to bring mini210 support to recent kernels? I will also have a look at the Cubieboard related sources, and see if they can help. Hope this thing can grow up and we can make a better support for the board! Regards [1] https://www.yoctoproject.org/ [2] https://github.com/agalakhov/barebox
Hi Gizero, I've been thinking about working on getting a newer kernel for the mini210S boards. I think we might actually be able to get a higher kernel version than 3.0.8 but haven't looked too hard yet, I *think* there was jellybean support for the galaxy S (same chip as ours) and that came with a slightly newer kernel. However, moving to any other kernel shouldn't be too much of a hassle, I think we'd only really need the mach-mini210.c, some stuff for the LCDs and probably the wolfson micro audio codec driver, oh and the nand driver, then it's just the proprietary binary blobs to worry about. The nand driver isn't really so much of an obstacle, the only other things of real concern is the mfc/GLES etc. support, as far as I can tell these are from the samsung 'android' binaries that are supplied via AOSP. You are semi correct about [2] it's kind of helpful because anything is a start, however it doesn't completely work yet. There are a few bootloader efforts around, you'll find them mostly documented on www.arm9home.net It's chinese language so you'll need a translation tool of some kind. There's at least 1 other barebox project and at least 1 uboot project, however they seem to be serialising them as a set of tutorials, so I'm not even sure that I have the right version, however the version of uboot that I am running can boot the kernel from sd/tftp and the rootfs can be sd,nand or nfs. We made an effort to start getting the nand drivers into the chinese barebox code, however, we ran into some issues, namely barebox can't cope with >2GB nand chips (it can't address anything higher using 32bit unsigned int). At that point we decided to start again with the latest barebox source and add in what we needed, we have dm9000 code and sdhc read (write isn't working for some reason) and I'd made a start on the nand driver but took a break a week or so ago. Lastly, there are 3 different versions of mini210S, you mentioned mini210 in your post, so that really needs ironing out, underneath there's not too much difference between a tiny210 and a mini210 but the main one being the different nand on all of the boards. We currently have a 1GB SLC nand board, a 2GB MLC nand board and a 4GB MLC nand board. 2K/128K, 8K/1MB and 8K/1MB pages/block respectively. the 2GB/4GB boards are 'eol' in so much that they moved production over to the 1GB SLC nand on all new mini210S boards. Now that we have our own open source driver for the nand, it shouldn't be difficult to adjust it for whatever ecc bit depth is necessary and dumping the nand ecc layout for the respective nand chips is trivial, I've already posted that information on www.arm9home.net uboot forum. One other issue with the bootloader, it's not immediately apparent what ecc bit depth 'bl1' stage of the bootloader is burnt to nand with. The irom application notes have enough ambiguity that don't seem to make it clear what's happening there. For instance the tiny210 code that they put in appears to be using 8bit ecc at the bl1 stage and for loading the kernel but the nand driver in the kernel according to the information I dumped is only using 4bit ecc, that's going to make burning stuff a pain. Some useful links for you: https://github.com/Reggi3/210-nand-patch (open source 16bit nand drivers) https://github.com/Reggi3/mini210s-barebox (my barebox fork from jkent's which is a fork of original barebox/chinese barebox) http://arm9home.net/thread.php?fid-58.html (uboot forum on FA's forums) http://arm9home.net/read.php?tid-28941.html (my nand ecc layout post) http://arm9home.net/read.php?tid-28710.html (one of the many barebox tutorials) http://arm9home.net/read.php?tid-28161.html )one of the uboot posts/tutorials) https://code.google.com/p/x210ii/source/browse/uboot/#uboot%2Fcpu%2Fs5pc11x this last link is for an x210ii board but the nice thing about it is everything is there already, it should really just be a matter of shoehorning the 16bit ecc functions into and removing support for stuff that doesn't exist. The main issue that I found with the barebox/uboot projects was that the nand/mtd subsystems were generally old because the original source they'd started from was old (I'll refer back to the >2GB nand chips as an example, the issue is in the mtd/nand subsystem, fixed in newer version), however, most of the code seems to have been appropriated from samsung GPL'd source code somewhere along the line, so once it's in there it should be pretty robust. Regards, Reggie.
Why not forwarding your patches to Barebox to mainline? Your improvements are welcome. And: the current Barebox uses 64 bit to address file systems. So the 2 GiB limit should be gone.
Hi Juergen, they're not really ready for it as such I don't think, as you can see, I've done a bit of research on this to see exactly what's been done already with bootloaders and our barebox fork is from the pengutronix main repo, so when I get going on it again I will at some point post stuff. I am not really familiar with how barebox works either, so that's making some things a little difficult. I tried to reach out on the #barebox IRC channel but it seems to be very low traffic, however, I will probably get on with some coding over the weekend at some point.
Hi Reggie and others, Here is what I found on Cubieboard u-boot bootloader source https://github.com/cubieboard/u-boot-sunxi or https://github.com/linux-sunxi/u-boot-sunxi I leave the links without analysis, I have to dit in the code to understand how u-boot works. Nice work we all share our data to get a final working bootloader. I hope Alexey Galakhov will join us to prevent everybody work alone on same projects...
Hi Reggi, join us in the #ptxdist IRC. Or at the Barebix mailing list. Show us your work as an RFC and we will comment on it.
Hi Juergen, I'll join #ptxdist, and here's my latest git commit, https://github.com/Reggi3/mini210s-barebox/commit/54be23be59f7a8d36235c8... It'd be useful if you could look at the changes I've done for mtdoob.c and mtdraw.c, there are other relevant changes in the code but those 2 should give you an idea of the issue with > 2GB nand parts. It's pointless doing a pull/push of that code upstream right now though, as the code is basically untested in it's current state because of the missing 16bit ecc functions that are in my first attempt at getting barebox working for the 210S (I was working from code derived from the arm9home.net forums), I've just started speaking to the guy on the arm9home.net forum who's been working on his own barebox for the 210, I'd rather wait until we've got our code in line with each other then present something that might actually stand a chance of working. In the meantime, I'd really appreciate you taking a look at my latest commit and letting me know if my suspicions are correct. Regards, Reggie.
Hi Reggie, I will do, but it needs a few days to do so. Currently I'm busy with many other things (for example enjoying the warm sun...)
Hi, I'm now able to boot kernel from SD card on tiny210 using barebox. I use Juergen's SD driver from S3C6410 branch to do that. I use some dirty hacks however.
Hi Alexy, you should look at jian deng's repo (he's got loads of threads on the arm9home.net forums), he's got barebox in a mostly working state, I really need to do some testing for him but I haven't been well. It's essentially working for some 210 based boards, including 16bit nand ecc, so it probably just needs a couple of tweaks here and there if anything to get up to scratch.
Congrats, Alexey! Programming mini210s in such deep level must be apprecated well. I planned to port startos, gathered all components but now will freeze the work on non OS stage for my own projects (nobody interesting). For Linux and Android I use MTK based phone and Nexus 7. Devices may be connected via the USB shield or Android ADK. Congrats again, you've done a Great work!
Hi, I just wondered what was the current status on barebox for mini210. I would need a version which could be burnt on SD CARD and which would allow booting from an NFS server. It would be useful to work on the kernel without having to move the card to host PC, copy the kernel image, move again to the mini. SD slot is not made to support intensive manipulations. Do one of you have this working?
Nobody ?