[Linux-exynos] Kernel for Snow XE303C12 board?
hramrach at gmail.com
Sun Mar 1 17:25:10 CET 2015
On 19 February 2015 at 13:31, Merlijn Wajer <merlijn at wizzup.org> wrote:
> On 19/02/15 13:07, Michal Suchanek wrote:
>> On 18 February 2015 at 17:10, Merlijn Wajer <merlijn at wizzup.org> wrote:
>> It does not work either. Or something that has next in the name and
>> can be found at kernel.org, anyway.
> This tree should work, at least boot and give display:
> It worked for me on snow last time I tried it (about a week ago)
>>> My recommendation would be to have a look at this guide:
>>> Note that it is for a slightly different model, but the instructions are
>>> mostly the same. You just need a different DTS. You can either use the
>>> dp-integ branch mentioned there, or linux-next from kernel.org.
>> With dp-integ branch I get display (and keyboard) and then the kernel
>> locks up waiting for mmc to get detected which never happens. I guess
>> I can try an USB stick or something.
> Weird, that worked for me. But linux-next should have most of this.
The inability to boot from mmc0 is not all that mysterious.
I tried pulling out and inserting the SD card in the slot and it
generated proper messages so mmc1 works flawlessly.
I changed the commandline to use mmc1 for root and examining the boot
messages I notice
1) I have /dev/mmc0boot0 /dev/mmc0boot1 and some other partition
2) /dev/mmc0 contains the GPT label but is not scanned during boot for
3) amending this with hdparm -z I get 7 partitions out of 15 or so
This means that my root on mmc0p13 is not going to work with dp-integ
for multiple reasons.
I also noticed I don't have macintosh mouse button emulation enabled
and mwifiex does not configure making the system unusable.
More importantly, it seems these boot0 and boot1 partitions which
contain some high quality zeroes are reserved for bootloader. Is there
some way to actually load the bootloader from one of these partitions
rather than the flash containing the ro loader?
>>> guide. For testing it's also recommended to use nv u-boot rather than
>>> the "provided" u-boot.
>> I know no way to rid myself of the "provided" u-boot. AFAIK the board
>> is set to boot from the onboard flash which is readonly. Supposedly
>> you can take apart the case and doing so you break the read-protect
>> connection. However, since there is no documented way of booting from
>> other media in the case you write a new u-boot to the flash memory and
>> it does not work it is probably not good idea to try it.
> nv u-boot can be chainloaded from the provided u-boot, requiring no
> changes to the 'provided' u-boot:
Yes, it requires changes to the nv u-boot so it does not get corrupted
by the provided u-boot and keeping around the chromeos partitions so
that you can switch usb booting back on in case you press space on the
horror boot screen.
More information about the Linux-exynos