Hi,
I know a lot has already been said and written about the transition to DTB and the trimslice. Still I must say I'm disappointed in our trimslice story for F-18.
I've had a trimslice sitting in its box for ages now, and as I wanted to work on bug 893157, it was time to finally unbox it and install Fedora on it.
So I downloaded the F-18 image, xzcat-ed it to a sata disk (I've the trimslice-h with internal 2.5" sata bay), updated boot.scr to the usb one and booted the trimslice.
And it failed, and now 2.5 hours later, I finally have things working with the original shipped 3.6 kernel, and I yet have to tree 3.7 or 3.8.
Let me repeat this, it took *me*, 2.5 hours, to get the basic images to boot! And I've build Allwinner A10 kernels + uboot from source, including writing my own .cmd files for them, etc. IOW I know this stuff!
So TL;DR. our F-18 trimslice images suck. And TBH for no good reasons, we could have done better and we should have done better. This is going to cost us users <full stop>.
So enough ranting on this, what happened in my case:
1) As said I followed the wiki instructions for installation to a usb-mass-storage device to the letter.
2) This did not boot, serial console showed that the problem was that dtbs/tegra20-trimslice.dtb was missing.
Sorry, have to rant again here, say what? our GOLD images have a .cmd file referring to a file which is not there? WTF, did we do QA, any QA at all on this, how can this have slipped through ??????? ????? ??????
3) As I know this stuff, the solution *seemed* easy, remove the command to load the dtb (not strictly necessary) and the 3th parameter from the cmd file, mkimage the scr file, done. After all the 3.6 kernel does not require a dtb, right ?
4) Hmm, now the boot hangs after the usb probing is done, weird. Lets try an sd-card
5) Same experience, ah it is hanging in waitroot, so why is it not finding root
6) Ah, root is specified by UUID, if I add root=/dev/mmcblk0p3 then it does work.
7) And with the usb boot it does not see the usb-disk at all -> no usb-storage driver -> no initrd (so no root by UUID).
8) But why no initrd? It is being loaded and the second parameter to bootm is correct ???
9) Try 3 different trimslice firmware versions -> no go.
10) Lets redo from start lets simply drop in the missing dtbs/tegra20-trimslice.dtb file, even though no dtb is needed for a 3.6 kernel, as the successfull boot without it in step 6 has proven. But lets try anyway combined with the original boot.cmd.usb file + dtb capable firmware
Heuh, now it does see the initrd, and everything works ... ????
So we need to pass-in a dtb for the initrd to work ????
###
So is this all a bit mysterious yes, still could we've done better? yes!
I had already updated to the dtb capable firmware before I begun, so if the dtbs/tegra20-trimslice.dtb file would have been in the image as it should have been, everything would have worked in one go.
That would have helped me, but not users who have not updated the firmware. The wiki-page says that the firmware update is needed when you do a kernel update, IOW it implies that the GA images will work with old firmware, which they don't, since the initrd seems to not get loaded, which breaks even mmc booting, because we specify root by UUID which requires an initrd.
###
So how to move forward with this. We should update the wiki with clear and precise step by step instructions on how to make things work, or maybe even just respin the images!
Assuming we're going with the wiki instructions, for sdcard users we've 2 options: 1) Treat them the same as usb-disk users, see below 2) Provide an updated boot.cmd.mmc0 and boot.scr.mmc0 for them, which removes the use of the dtb, and specifies root as root=/dev/mmcblk0p3. Idem with mmc1 for micro-sd users (needs to be tested).
For usb users we need the initrd, which for some reason is not working when not loading the dtb ??? And loading the dtb means new firmware. So we need to add instructions for usb-disk users to *first* upgrade the firmware, and also to add the missing dtb file to the image before trying to boot it.
Regards,
Hans
On 03/17/2013 02:59 PM, Hans de Goede wrote: [long story about trimslice support nightmware]
So is this all a bit mysterious yes, still could we've done better? yes!
Yes, please join the thread on how to handle dtbs and the transition. The situation in F18 isn't very good, but we can do much better in F19 if we act now.
I had already updated to the dtb capable firmware before I begun,
Which is your problem. The shipped image only works with the 2010 firmware. Once you move to a newer firmware you need to move to a newer kernel (new firmware plus old kernel prevents usb sata disks from being detected.
so if the dtbs/tegra20-trimslice.dtb file would have been in the image as it should have been, everything would have worked in one go.
Adding an appropriate dtbs symlink is documented on the wiki, in conjunction with updating the kernel.
That would have helped me, but not users who have not updated the firmware. The wiki-page says that the firmware update is needed when you do a kernel update, IOW it implies that the GA images will work with old firmware, which they don't, since the initrd seems to not get loaded, which breaks even mmc booting, because we specify root by UUID which requires an initrd.
The 2010 firmware works with the GA image. The 2012 firmware (512MB) works with the 3.7 and 3.8 kernels after creating the dtbs symlink. The boot.scr doesn't work with the 3.6 kernel on the 2012 firmware though- you have to use uboot 2010 + kernel 3.6 or uboot 2012 + kernel 3.7+dtb symlink.
Assuming we're going with the wiki instructions, for sdcard users we've 2 options:
- Treat them the same as usb-disk users, see below
- Provide an updated boot.cmd.mmc0 and boot.scr.mmc0 for them,
which removes the use of the dtb, and specifies root as root=/dev/mmcblk0p3. Idem with mmc1 for micro-sd users (needs to be tested).
For usb users we need the initrd, which for some reason is not working when not loading the dtb ??? And loading the dtb means new firmware. So we need to add instructions for usb-disk users to *first* upgrade the firmware, and also to add the missing dtb file to the image before trying to boot it.
The right solution for F19 is to make an auto-detecting boot.scr which loads the right combination of files. F18 is shipped and works as expected (Though it seems the old kernel + new uboot incompatibility is not well explained).
That would have helped me, but not users who have not updated the firmware. The wiki-page says that the firmware update is needed when you do a kernel update, IOW it implies that the GA images will work with old firmware, which they don't
The F18 GA image boots with no further action required when using the old firmware(v2010.09-1.03) on both SATA/USB and MMC.
So how to move forward with this. We should update the wiki
I added a note to the wiki about the firmware requirement, thanks for pointing it out.
Paul
Hi,
On 03/18/2013 05:43 PM, Paul Whalen wrote:
That would have helped me, but not users who have not updated the firmware. The wiki-page says that the firmware update is needed when you do a kernel update, IOW it implies that the GA images will work with old firmware, which they don't
The F18 GA image boots with no further action required when using the old firmware(v2010.09-1.03) on both SATA/USB and MMC.
Ah, I tried this and you're right. Weird because I tried before too, but with the 3th argument from bootm in boot.cmd removed (since the 3th argument is for the non existent dtb) and then it does not find the initrd, weird ...
Anyways you're right it works with the old firmware, thanks for looking into this and for updating the wiki.
Regards,
Hans
-
Brendan Conoboy -
Hans de Goede -
Paul Whalen