On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
> Hey There,
> I'm working on porting ChromiumOS to Exynos 4412.
Nice
> Basicly what I've achieved so far is to boot it.
> I'm running a modified overlay of daisy.
If you have a fully functional overlay feel free to submit CLs to gerrit if
you would like to add them into the tree.
> I'm booting of a sdcard that has the exynos proprietary stuff, uboot and a
> fat partition that the kernel is on.
> I've setted the root to /dev/sda3 (my usb drive)
> So far my ChromiumOS image builds and boot.
> But here's my problem:
> Uppon boot it will keep at "Your system is repairing itself. Please wait"
> and boot loop on that.
Maybe it is looking for your stateful partition in a particular location.
You could hack chromeos_startup to debug (or force the use of tmpfs)
> I've did a research around the web and I've found that its something on
> the state paritition, but the state partition is there and it isn't
> corrupted, If i put the sdcard on my laptop I can read it.
> I've uploaded my clobber.log to www.mdrjr.net/clobber.log
> Is there anything that I'm missing?
> The integrity of the usb drive looks to be ok.
> At first glance I've tought that it was somehow ChromiumOS getting lost
> and trying to access the sdcard that I use to boot instead of the USB key.
> I've even disabled the sdcard support on the kernel to try. Still the same
> issue.
I've already did the hack to echo the STATE_DEV and it shows /dev/sda1 that
is suppoused to be correct. Am I right here?
What are the problems or issues to move the stateful partition to tmpfs ?
Could you point me where to change that?
As far as uploading the overlay I'll, but as soon as my vendor provide me
the magical blobs to the MALI GPU. (aka. EGL).
My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead
of a15. And removing part of its gfx stuff.
More likely a arm-generic overlay (I've built that and it works as well).
Right now all I want is a image that will boot and log onto ChromiumOS.
Later after I achieve this goal I'll work on getting certain parts of my
hardware properly supported.
> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1
> that is suppoused to be correct. Am I right here?
> What are the problems or issues to move the stateful partition to tmpfs ?
> Could you point me where to change that?
> As far as uploading the overlay I'll, but as soon as my vendor provide me
> the magical blobs to the MALI GPU. (aka. EGL).
> My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead
> of a15. And removing part of its gfx stuff.
> More likely a arm-generic overlay (I've built that and it works as well).
> Right now all I want is a image that will boot and log onto ChromiumOS.
> Later after I achieve this goal I'll work on getting certain parts of my
> hardware properly supported.
>> On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
>>> Hey There,
>>> I'm working on porting ChromiumOS to Exynos 4412.
>> Nice
>>> Basicly what I've achieved so far is to boot it.
>>> I'm running a modified overlay of daisy.
>> If you have a fully functional overlay feel free to submit CLs to gerrit
>> if you would like to add them into the tree.
>>> I'm booting of a sdcard that has the exynos proprietary stuff, uboot and
>>> a fat partition that the kernel is on.
>>> I've setted the root to /dev/sda3 (my usb drive)
>>> So far my ChromiumOS image builds and boot.
>>> But here's my problem:
>>> Uppon boot it will keep at "Your system is repairing itself. Please
>>> wait"
>>> and boot loop on that.
>> Maybe it is looking for your stateful partition in a particular location.
>> You could hack chromeos_startup to debug (or force the use of tmpfs)
>>> I've did a research around the web and I've found that its something on
>>> the state paritition, but the state partition is there and it isn't
>>> corrupted, If i put the sdcard on my laptop I can read it.
>>> I've uploaded my clobber.log to www.mdrjr.net/clobber.log
>>> Is there anything that I'm missing?
>>> The integrity of the usb drive looks to be ok.
>>> At first glance I've tought that it was somehow ChromiumOS getting lost
>>> and trying to access the sdcard that I use to boot instead of the USB key.
>>> I've even disabled the sdcard support on the kernel to try. Still the
>>> same issue.
>>> Any directions or points will be very helpful.
> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1 that
> is suppoused to be correct. Am I right here?
> What are the problems or issues to move the stateful partition to tmpfs ?
> Could you point me where to change that?
> As far as uploading the overlay I'll, but as soon as my vendor provide me
> the magical blobs to the MALI GPU. (aka. EGL).
> My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead
> of a15. And removing part of its gfx stuff.
> More likely a arm-generic overlay (I've built that and it works as well).
> Right now all I want is a image that will boot and log onto ChromiumOS.
> Later after I achieve this goal I'll work on getting certain parts of my
> hardware properly supported.
>> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1
>> that is suppoused to be correct. Am I right here?
>> What are the problems or issues to move the stateful partition to tmpfs ?
>> Could you point me where to change that?
>> As far as uploading the overlay I'll, but as soon as my vendor provide me
>> the magical blobs to the MALI GPU. (aka. EGL).
>> My overlay rightnow is just a daisy overlay buiding with cortex-a9
>> instead of a15. And removing part of its gfx stuff.
>> More likely a arm-generic overlay (I've built that and it works as well).
>> Right now all I want is a image that will boot and log onto ChromiumOS.
>> Later after I achieve this goal I'll work on getting certain parts of my
>> hardware properly supported.
>>> On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
>>>> Hey There,
>>>> I'm working on porting ChromiumOS to Exynos 4412.
>>> Nice
>>>> Basicly what I've achieved so far is to boot it.
>>>> I'm running a modified overlay of daisy.
>>> If you have a fully functional overlay feel free to submit CLs to gerrit
>>> if you would like to add them into the tree.
>>>> I'm booting of a sdcard that has the exynos proprietary stuff, uboot
>>>> and a fat partition that the kernel is on.
>>>> I've setted the root to /dev/sda3 (my usb drive)
>>>> So far my ChromiumOS image builds and boot.
>>>> But here's my problem:
>>>> Uppon boot it will keep at "Your system is repairing itself. Please
>>>> wait"
>>>> and boot loop on that.
>>> Maybe it is looking for your stateful partition in a particular
>>> location. You could hack chromeos_startup to debug (or force the use of
>>> tmpfs)
>>>> I've did a research around the web and I've found that its something on
>>>> the state paritition, but the state partition is there and it isn't
>>>> corrupted, If i put the sdcard on my laptop I can read it.
>>>> I've uploaded my clobber.log to www.mdrjr.net/clobber.log
>>>> Is there anything that I'm missing?
>>>> The integrity of the usb drive looks to be ok.
>>>> At first glance I've tought that it was somehow ChromiumOS getting lost
>>>> and trying to access the sdcard that I use to boot instead of the USB key.
>>>> I've even disabled the sdcard support on the kernel to try. Still the
>>>> same issue.
>>>> Any directions or points will be very helpful.
Maybe caused by "encrypted stateful partition" / TPM issue, since you
probably don't have TPM in system?
Do it boot if you build factory test image (build_image factory_test)
instead?
>> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1
>> that
>> is suppoused to be correct. Am I right here?
>> What are the problems or issues to move the stateful partition to tmpfs ?
>> Could you point me where to change that?
>> As far as uploading the overlay I'll, but as soon as my vendor provide me
>> the magical blobs to the MALI GPU. (aka. EGL).
>> My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead
>> of a15. And removing part of its gfx stuff.
>> More likely a arm-generic overlay (I've built that and it works as well).
>> Right now all I want is a image that will boot and log onto ChromiumOS.
>> Later after I achieve this goal I'll work on getting certain parts of my
>> hardware properly supported.
>>> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1
>>> that is suppoused to be correct. Am I right here?
>>> What are the problems or issues to move the stateful partition to tmpfs ?
>>> Could you point me where to change that?
>>> As far as uploading the overlay I'll, but as soon as my vendor provide
>>> me the magical blobs to the MALI GPU. (aka. EGL).
>>> My overlay rightnow is just a daisy overlay buiding with cortex-a9
>>> instead of a15. And removing part of its gfx stuff.
>>> More likely a arm-generic overlay (I've built that and it works as well).
>>> Right now all I want is a image that will boot and log onto ChromiumOS.
>>> Later after I achieve this goal I'll work on getting certain parts of my
>>> hardware properly supported.
>>>> On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
>>>>> Hey There,
>>>>> I'm working on porting ChromiumOS to Exynos 4412.
>>>> Nice
>>>>> Basicly what I've achieved so far is to boot it.
>>>>> I'm running a modified overlay of daisy.
>>>> If you have a fully functional overlay feel free to submit CLs to
>>>> gerrit if you would like to add them into the tree.
>>>>> I'm booting of a sdcard that has the exynos proprietary stuff, uboot
>>>>> and a fat partition that the kernel is on.
>>>>> I've setted the root to /dev/sda3 (my usb drive)
>>>>> So far my ChromiumOS image builds and boot.
>>>>> But here's my problem:
>>>>> Uppon boot it will keep at "Your system is repairing itself. Please
>>>>> wait"
>>>>> and boot loop on that.
>>>> Maybe it is looking for your stateful partition in a particular
>>>> location. You could hack chromeos_startup to debug (or force the use of
>>>> tmpfs)
>>>>> I've did a research around the web and I've found that its something
>>>>> on the state paritition, but the state partition is there and it isn't
>>>>> corrupted, If i put the sdcard on my laptop I can read it.
>>>>> I've uploaded my clobber.log to www.mdrjr.net/clobber.log
>>>>> Is there anything that I'm missing?
>>>>> The integrity of the usb drive looks to be ok.
>>>>> At first glance I've tought that it was somehow ChromiumOS getting
>>>>> lost and trying to access the sdcard that I use to boot instead of the USB
>>>>> key.
>>>>> I've even disabled the sdcard support on the kernel to try. Still the
>>>>> same issue.
>>>>> Any directions or points will be very helpful.
> Maybe caused by "encrypted stateful partition" / TPM issue, since you
> probably don't have TPM in system?
> Do it boot if you build factory test image (build_image factory_test)
> instead?
> On Sun, Nov 4, 2012 at 12:03 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
>> Just to note:
>> Its getting that on:
>> cleanup_mounts()
>> Even that the STATEFUL partition is getting mounted correctly. (used a
>> mount >> /dev/ttySAC1 to see that)
>>> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1
>>> that
>>> is suppoused to be correct. Am I right here?
>>> What are the problems or issues to move the stateful partition to tmpfs ?
>>> Could you point me where to change that?
>>> As far as uploading the overlay I'll, but as soon as my vendor provide me
>>> the magical blobs to the MALI GPU. (aka. EGL).
>>> My overlay rightnow is just a daisy overlay buiding with cortex-a9
>>> instead
>>> of a15. And removing part of its gfx stuff.
>>> More likely a arm-generic overlay (I've built that and it works as well).
>>> Right now all I want is a image that will boot and log onto ChromiumOS.
>>> Later after I achieve this goal I'll work on getting certain parts of my
>>> hardware properly supported.
>>>> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1
>>>> that is suppoused to be correct. Am I right here?
>>>> What are the problems or issues to move the stateful partition to tmpfs
>>>> ?
>>>> Could you point me where to change that?
>>>> As far as uploading the overlay I'll, but as soon as my vendor provide
>>>> me the magical blobs to the MALI GPU. (aka. EGL).
>>>> My overlay rightnow is just a daisy overlay buiding with cortex-a9
>>>> instead of a15. And removing part of its gfx stuff.
>>>> More likely a arm-generic overlay (I've built that and it works as
>>>> well).
>>>> Right now all I want is a image that will boot and log onto ChromiumOS.
>>>> Later after I achieve this goal I'll work on getting certain parts of my
>>>> hardware properly supported.
>>>>> On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com>wrote:
>>>>>> Hey There,
>>>>>> I'm working on porting ChromiumOS to Exynos 4412.
>>>>> Nice
>>>>>> Basicly what I've achieved so far is to boot it.
>>>>>> I'm running a modified overlay of daisy.
>>>>> If you have a fully functional overlay feel free to submit CLs to
>>>>> gerrit if you would like to add them into the tree.
>>>>>> I'm booting of a sdcard that has the exynos proprietary stuff, uboot
>>>>>> and a fat partition that the kernel is on.
>>>>>> I've setted the root to /dev/sda3 (my usb drive)
>>>>>> So far my ChromiumOS image builds and boot.
>>>>>> But here's my problem:
>>>>>> Uppon boot it will keep at "Your system is repairing itself. Please
>>>>>> wait"
>>>>>> and boot loop on that.
>>>>> Maybe it is looking for your stateful partition in a particular
>>>>> location. You could hack chromeos_startup to debug (or force the use of
>>>>> tmpfs)
>>>>>> I've did a research around the web and I've found that its something
>>>>>> on the state paritition, but the state partition is there and it isn't
>>>>>> corrupted, If i put the sdcard on my laptop I can read it.
>>>>>> I've uploaded my clobber.log to www.mdrjr.net/clobber.log
>>>>>> Is there anything that I'm missing?
>>>>>> The integrity of the usb drive looks to be ok.
>>>>>> At first glance I've tought that it was somehow ChromiumOS getting
>>>>>> lost and trying to access the sdcard that I use to boot instead of the USB
>>>>>> key.
>>>>>> I've even disabled the sdcard support on the kernel to try. Still the
>>>>>> same issue.
>>>>>> Any directions or points will be very helpful.
>>>>>> Best Regards,
>>>>>> Mauro Ribeiro
>>>>>> --
>>>>>> Chromium OS discuss mailing list: chromium-os-disc...@chromium.org
>>>>>> View archives, change email options, or unsubscribe:
> Maybe caused by "encrypted stateful partition" / TPM issue, since you probably don't have TPM in system?
> Do it boot if you build factory test image (build_image factory_test) instead?
Trouble with encrypted stateful is a good suspect. AFAIK, a TPM
isn't required, but encrypted stateful *does* require some specific
kernel modules. The fix would be to add those modules, or skip
the encrypted stateful step.
I think specifying 'factory' on the 'mount-encrypted' command line
will skip the encryption; keescook@ or hungte@ will know more
about what that option does. The option is specified automatically
in factory test images, but you could also change chromeos_startup
to pass the argument unconditionally.
Somebody like keescook@ will have to comment on exactly
which kernel modules would be needed.
> On Sun, Nov 4, 2012 at 12:03 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
> Just to note:
> Its getting that on:
> cleanup_mounts()
> Even that the STATEFUL partition is getting mounted correctly. (used a mount >> /dev/ttySAC1 to see that)
> 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1 that
> is suppoused to be correct. Am I right here?
> What are the problems or issues to move the stateful partition to tmpfs ?
> Could you point me where to change that?
> As far as uploading the overlay I'll, but as soon as my vendor provide me
> the magical blobs to the MALI GPU. (aka. EGL).
> My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead
> of a15. And removing part of its gfx stuff.
> More likely a arm-generic overlay (I've built that and it works as well).
> Right now all I want is a image that will boot and log onto ChromiumOS.
> Later after I achieve this goal I'll work on getting certain parts of my
> hardware properly supported.
> Thank you for your help ;)
> 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
> I've already did the hack to echo the STATE_DEV and it shows /dev/sda1 that is suppoused to be correct. Am I right here?
> What are the problems or issues to move the stateful partition to tmpfs ?
> Could you point me where to change that?
> As far as uploading the overlay I'll, but as soon as my vendor provide me the magical blobs to the MALI GPU. (aka. EGL).
> My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead of a15. And removing part of its gfx stuff.
> More likely a arm-generic overlay (I've built that and it works as well).
> Right now all I want is a image that will boot and log onto ChromiumOS. Later after I achieve this goal I'll work on getting certain parts of my hardware properly supported.
> On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
> Hey There,
> I'm working on porting ChromiumOS to Exynos 4412.
> Nice
> Basicly what I've achieved so far is to boot it.
> I'm running a modified overlay of daisy.
> If you have a fully functional overlay feel free to submit CLs to gerrit if you would like to add them into the tree.
> I'm booting of a sdcard that has the exynos proprietary stuff, uboot and a fat partition that the kernel is on.
> I've setted the root to /dev/sda3 (my usb drive)
> So far my ChromiumOS image builds and boot.
> But here's my problem:
> Uppon boot it will keep at "Your system is repairing itself. Please wait" > and boot loop on that.
> Maybe it is looking for your stateful partition in a particular location. You could hack chromeos_startup to debug (or force the use of tmpfs)
> I've did a research around the web and I've found that its something on the state paritition, but the state partition is there and it isn't corrupted, If i put the sdcard on my laptop I can read it.
> I've uploaded my clobber.log to www.mdrjr.net/clobber.log
> Is there anything that I'm missing?
> The integrity of the usb drive looks to be ok.
> At first glance I've tought that it was somehow ChromiumOS getting lost and trying to access the sdcard that I use to boot instead of the USB key.
> I've even disabled the sdcard support on the kernel to try. Still the same issue.
> Since the kernel that ChromiumOS uses doesn't support my board I've went ahead to search on ChromiumOS kernel to see what I need.
> I've found some config's needed and added.
> Also I've found a device driver on drivers/platform I've also ported those to my vendor suplied kernel (We use 3.6 series for Linux and 3.0 series for Android). I've ported those to 3.6.
> Now the board boots and doesn't goes onto a random loop of repair.
> Now it will stop saying that init can't start certain process.
> mtp and thermal I've disabled (mtpd as far as I know is related to VPN stuff and thermal is daisy related, I've moved the .conf's files in /etc/init somewhere else)
> Now 3 process that can't be started:
> factory
> factorylog
> bootcache
To clarify, the three things named are upstart jobs, not processes
as such. The first two are specific to factory test images; once
you're back to the regular developer image, these won't exist.
I don't know why bootcache would fail to start; however, unless it
still won't start once you're booting a developer image, I don't think
it's an interesting problem.
> Any idea?
> Right now I'm switching from the factory_test image back to dev.
Yeah, retrying with a dev image is the right next step. If it doesn't
fail in a dev image, it doesn't matter (to you, at any rate).
> 2012/11/5 Richard Barnette <jrbarne...@chromium.org>
> On Nov 4, 2012, at 11:00 PM, Hung-Te Lin wrote:
> > Maybe caused by "encrypted stateful partition" / TPM issue, since you probably don't have TPM in system?
> > Do it boot if you build factory test image (build_image factory_test) instead?
> Trouble with encrypted stateful is a good suspect. AFAIK, a TPM
> isn't required, but encrypted stateful *does* require some specific
> kernel modules. The fix would be to add those modules, or skip
> the encrypted stateful step.
> I think specifying 'factory' on the 'mount-encrypted' command line
> will skip the encryption; keescook@ or hungte@ will know more
> about what that option does. The option is specified automatically
> in factory test images, but you could also change chromeos_startup
> to pass the argument unconditionally.
> Somebody like keescook@ will have to comment on exactly
> which kernel modules would be needed.
> > On Sun, Nov 4, 2012 at 12:03 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
> > Just to note:
> > Its getting that on:
> > cleanup_mounts()
> > Even that the STATEFUL partition is getting mounted correctly. (used a mount >> /dev/ttySAC1 to see that)
> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
> > I've already did the hack to echo the STATE_DEV and it shows /dev/sda1 that
> > is suppoused to be correct. Am I right here?
> > What are the problems or issues to move the stateful partition to tmpfs ?
> > Could you point me where to change that?
> > As far as uploading the overlay I'll, but as soon as my vendor provide me
> > the magical blobs to the MALI GPU. (aka. EGL).
> > My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead
> > of a15. And removing part of its gfx stuff.
> > More likely a arm-generic overlay (I've built that and it works as well).
> > Right now all I want is a image that will boot and log onto ChromiumOS.
> > Later after I achieve this goal I'll work on getting certain parts of my
> > hardware properly supported.
> > Thank you for your help ;)
> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
> > I've already did the hack to echo the STATE_DEV and it shows /dev/sda1 that is suppoused to be correct. Am I right here?
> > What are the problems or issues to move the stateful partition to tmpfs ?
> > Could you point me where to change that?
> > As far as uploading the overlay I'll, but as soon as my vendor provide me the magical blobs to the MALI GPU. (aka. EGL).
> > My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead of a15. And removing part of its gfx stuff.
> > More likely a arm-generic overlay (I've built that and it works as well).
> > Right now all I want is a image that will boot and log onto ChromiumOS. Later after I achieve this goal I'll work on getting certain parts of my hardware properly supported.
> > On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
> > Hey There,
> > I'm working on porting ChromiumOS to Exynos 4412.
> > Nice
> > Basicly what I've achieved so far is to boot it.
> > I'm running a modified overlay of daisy.
> > If you have a fully functional overlay feel free to submit CLs to gerrit if you would like to add them into the tree.
> > I'm booting of a sdcard that has the exynos proprietary stuff, uboot and a fat partition that the kernel is on.
> > I've setted the root to /dev/sda3 (my usb drive)
> > So far my ChromiumOS image builds and boot.
> > But here's my problem:
> > Uppon boot it will keep at "Your system is repairing itself. Please wait"
> > and boot loop on that.
> > Maybe it is looking for your stateful partition in a particular location. You could hack chromeos_startup to debug (or force the use of tmpfs)
> > I've did a research around the web and I've found that its something on the state paritition, but the state partition is there and it isn't corrupted, If i put the sdcard on my laptop I can read it.
> > I've uploaded my clobber.log to www.mdrjr.net/clobber.log
> > Is there anything that I'm missing?
> > The integrity of the usb drive looks to be ok.
> > At first glance I've tought that it was somehow ChromiumOS getting lost and trying to access the sdcard that I use to boot instead of the USB key.
> > I've even disabled the sdcard support on the kernel to try. Still the same issue.
> > Any directions or points will be very helpful.
> (moving the discussion back to the list, so everyone can benefit from
> what's learned).
> On Nov 5, 2012, at 4:09 PM, Mauro Ribeiro wrote:
>> Richard,
>> Thank you for your notes.
>> Since the kernel that ChromiumOS uses doesn't support my board I've went ahead to search on ChromiumOS kernel to see what I need.
>> I've found some config's needed and added.
>> Also I've found a device driver on drivers/platform I've also ported those to my vendor suplied kernel (We use 3.6 series for Linux and 3.0 series for Android). I've ported those to 3.6.
>> Now the board boots and doesn't goes onto a random loop of repair.
>> Now it will stop saying that init can't start certain process.
>> mtp and thermal I've disabled (mtpd as far as I know is related to VPN stuff and thermal is daisy related, I've moved the .conf's files in /etc/init somewhere else)
FWIW, mtpd is the daemon responsible for exposing MTP (Media Transfer
Protocol) devices to Chrome.
>> Now 3 process that can't be started:
>> factory
>> factorylog
>> bootcache
> To clarify, the three things named are upstart jobs, not processes
> as such. The first two are specific to factory test images; once
> you're back to the regular developer image, these won't exist.
> I don't know why bootcache would fail to start; however, unless it
> still won't start once you're booting a developer image, I don't think
> it's an interesting problem.
>> Any idea?
>> Right now I'm switching from the factory_test image back to dev.
> Yeah, retrying with a dev image is the right next step. If it doesn't
> fail in a dev image, it doesn't matter (to you, at any rate).
>> 2012/11/5 Richard Barnette <jrbarne...@chromium.org>
>> On Nov 4, 2012, at 11:00 PM, Hung-Te Lin wrote:
>> > Maybe caused by "encrypted stateful partition" / TPM issue, since you probably don't have TPM in system?
>> > Do it boot if you build factory test image (build_image factory_test) instead?
>> Trouble with encrypted stateful is a good suspect. AFAIK, a TPM
>> isn't required, but encrypted stateful *does* require some specific
>> kernel modules. The fix would be to add those modules, or skip
>> the encrypted stateful step.
>> I think specifying 'factory' on the 'mount-encrypted' command line
>> will skip the encryption; keescook@ or hungte@ will know more
>> about what that option does. The option is specified automatically
>> in factory test images, but you could also change chromeos_startup
>> to pass the argument unconditionally.
>> Somebody like keescook@ will have to comment on exactly
>> which kernel modules would be needed.
>> > On Sun, Nov 4, 2012 at 12:03 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
>> > Just to note:
>> > Its getting that on:
>> > cleanup_mounts()
>> > Even that the STATEFUL partition is getting mounted correctly. (used a mount >> /dev/ttySAC1 to see that)
>> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
>> > I've already did the hack to echo the STATE_DEV and it shows /dev/sda1 that
>> > is suppoused to be correct. Am I right here?
>> > What are the problems or issues to move the stateful partition to tmpfs ?
>> > Could you point me where to change that?
>> > As far as uploading the overlay I'll, but as soon as my vendor provide me
>> > the magical blobs to the MALI GPU. (aka. EGL).
>> > My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead
>> > of a15. And removing part of its gfx stuff.
>> > More likely a arm-generic overlay (I've built that and it works as well).
>> > Right now all I want is a image that will boot and log onto ChromiumOS.
>> > Later after I achieve this goal I'll work on getting certain parts of my
>> > hardware properly supported.
>> > Thank you for your help ;)
>> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
>> > I've already did the hack to echo the STATE_DEV and it shows /dev/sda1 that is suppoused to be correct. Am I right here?
>> > What are the problems or issues to move the stateful partition to tmpfs ?
>> > Could you point me where to change that?
>> > As far as uploading the overlay I'll, but as soon as my vendor provide me the magical blobs to the MALI GPU. (aka. EGL).
>> > My overlay rightnow is just a daisy overlay buiding with cortex-a9 instead of a15. And removing part of its gfx stuff.
>> > More likely a arm-generic overlay (I've built that and it works as well).
>> > Right now all I want is a image that will boot and log onto ChromiumOS. Later after I achieve this goal I'll work on getting certain parts of my hardware properly supported.
>> > On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com> wrote:
>> > Hey There,
>> > I'm working on porting ChromiumOS to Exynos 4412.
>> > Nice
>> > Basicly what I've achieved so far is to boot it.
>> > I'm running a modified overlay of daisy.
>> > If you have a fully functional overlay feel free to submit CLs to gerrit if you would like to add them into the tree.
>> > I'm booting of a sdcard that has the exynos proprietary stuff, uboot and a fat partition that the kernel is on.
>> > I've setted the root to /dev/sda3 (my usb drive)
>> > So far my ChromiumOS image builds and boot.
>> > But here's my problem:
>> > Uppon boot it will keep at "Your system is repairing itself. Please wait"
>> > and boot loop on that.
>> > Maybe it is looking for your stateful partition in a particular location. You could hack chromeos_startup to debug (or force the use of tmpfs)
>> > I've did a research around the web and I've found that its something on the state paritition, but the state partition is there and it isn't corrupted, If i put the sdcard on my laptop I can read it.
>> > I've uploaded my clobber.log to www.mdrjr.net/clobber.log
>> > Is there anything that I'm missing?
>> > The integrity of the usb drive looks to be ok.
>> > At first glance I've tought that it was somehow ChromiumOS getting lost and trying to access the sdcard that I use to boot instead of the USB key.
>> > I've even disabled the sdcard support on the kernel to try. Still the same issue.
>> > Any directions or points will be very helpful.
> On Mon, Nov 5, 2012 at 6:35 PM, Richard Barnette
> <jrbarne...@chromium.org> wrote:
> > +chromium-os-discuss
> > (moving the discussion back to the list, so everyone can benefit from
> > what's learned).
> > On Nov 5, 2012, at 4:09 PM, Mauro Ribeiro wrote:
> >> Richard,
> >> Thank you for your notes.
> >> Since the kernel that ChromiumOS uses doesn't support my board I've
> went ahead to search on ChromiumOS kernel to see what I need.
> >> I've found some config's needed and added.
> >> Also I've found a device driver on drivers/platform I've also ported
> those to my vendor suplied kernel (We use 3.6 series for Linux and 3.0
> series for Android). I've ported those to 3.6.
> >> Now the board boots and doesn't goes onto a random loop of repair.
> >> Now it will stop saying that init can't start certain process.
> >> mtp and thermal I've disabled (mtpd as far as I know is related to VPN
> stuff and thermal is daisy related, I've moved the .conf's files in
> /etc/init somewhere else)
> FWIW, mtpd is the daemon responsible for exposing MTP (Media Transfer
> Protocol) devices to Chrome.
> >> Now 3 process that can't be started:
> >> factory
> >> factorylog
> >> bootcache
> > To clarify, the three things named are upstart jobs, not processes
> > as such. The first two are specific to factory test images; once
> > you're back to the regular developer image, these won't exist.
> > I don't know why bootcache would fail to start; however, unless it
> > still won't start once you're booting a developer image, I don't think
> > it's an interesting problem.
> >> Any idea?
> >> Right now I'm switching from the factory_test image back to dev.
> > Yeah, retrying with a dev image is the right next step. If it doesn't
> > fail in a dev image, it doesn't matter (to you, at any rate).
> >> 2012/11/5 Richard Barnette <jrbarne...@chromium.org>
> >> On Nov 4, 2012, at 11:00 PM, Hung-Te Lin wrote:
> >> > Maybe caused by "encrypted stateful partition" / TPM issue, since you
> probably don't have TPM in system?
> >> > Do it boot if you build factory test image (build_image factory_test)
> instead?
> >> Trouble with encrypted stateful is a good suspect. AFAIK, a TPM
> >> isn't required, but encrypted stateful *does* require some specific
> >> kernel modules. The fix would be to add those modules, or skip
> >> the encrypted stateful step.
> >> I think specifying 'factory' on the 'mount-encrypted' command line
> >> will skip the encryption; keescook@ or hungte@ will know more
> >> about what that option does. The option is specified automatically
> >> in factory test images, but you could also change chromeos_startup
> >> to pass the argument unconditionally.
> >> Somebody like keescook@ will have to comment on exactly
> >> which kernel modules would be needed.
> >> > On Sun, Nov 4, 2012 at 12:03 PM, Mauro Ribeiro <mdr...@gmail.com>
> wrote:
> >> > Just to note:
> >> > Its getting that on:
> >> > cleanup_mounts()
> >> > Even that the STATEFUL partition is getting mounted correctly. (used
> a mount >> /dev/ttySAC1 to see that)
> >> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
> >> > I've already did the hack to echo the STATE_DEV and it shows
> /dev/sda1 that
> >> > is suppoused to be correct. Am I right here?
> >> > What are the problems or issues to move the stateful partition to
> tmpfs ?
> >> > Could you point me where to change that?
> >> > As far as uploading the overlay I'll, but as soon as my vendor
> provide me
> >> > the magical blobs to the MALI GPU. (aka. EGL).
> >> > My overlay rightnow is just a daisy overlay buiding with cortex-a9
> instead
> >> > of a15. And removing part of its gfx stuff.
> >> > More likely a arm-generic overlay (I've built that and it works as
> well).
> >> > Right now all I want is a image that will boot and log onto
> ChromiumOS.
> >> > Later after I achieve this goal I'll work on getting certain parts of
> my
> >> > hardware properly supported.
> >> > Thank you for your help ;)
> >> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
> >> > I've already did the hack to echo the STATE_DEV and it shows
> /dev/sda1 that is suppoused to be correct. Am I right here?
> >> > What are the problems or issues to move the stateful partition to
> tmpfs ?
> >> > Could you point me where to change that?
> >> > As far as uploading the overlay I'll, but as soon as my vendor
> provide me the magical blobs to the MALI GPU. (aka. EGL).
> >> > My overlay rightnow is just a daisy overlay buiding with cortex-a9
> instead of a15. And removing part of its gfx stuff.
> >> > More likely a arm-generic overlay (I've built that and it works as
> well).
> >> > Right now all I want is a image that will boot and log onto
> ChromiumOS. Later after I achieve this goal I'll work on getting certain
> parts of my hardware properly supported.
> >> > On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com>
> wrote:
> >> > Hey There,
> >> > I'm working on porting ChromiumOS to Exynos 4412.
> >> > Nice
> >> > Basicly what I've achieved so far is to boot it.
> >> > I'm running a modified overlay of daisy.
> >> > If you have a fully functional overlay feel free to submit CLs to
> gerrit if you would like to add them into the tree.
> >> > I'm booting of a sdcard that has the exynos proprietary stuff, uboot
> and a fat partition that the kernel is on.
> >> > I've setted the root to /dev/sda3 (my usb drive)
> >> > So far my ChromiumOS image builds and boot.
> >> > But here's my problem:
> >> > Uppon boot it will keep at "Your system is repairing itself. Please
> wait"
> >> > and boot loop on that.
> >> > Maybe it is looking for your stateful partition in a particular
> location. You could hack chromeos_startup to debug (or force the use of
> tmpfs)
> >> > I've did a research around the web and I've found that its something
> on the state paritition, but the state partition is there and it isn't
> corrupted, If i put the sdcard on my laptop I can read it.
> >> > I've uploaded my clobber.log to www.mdrjr.net/clobber.log
> >> > Is there anything that I'm missing?
> >> > The integrity of the usb drive looks to be ok.
> >> > At first glance I've tought that it was somehow ChromiumOS getting
> lost and trying to access the sdcard that I use to boot instead of the USB
> key.
> >> > I've even disabled the sdcard support on the kernel to try. Still the
> same issue.
> >> > Any directions or points will be very helpful.
>> On Mon, Nov 5, 2012 at 6:35 PM, Richard Barnette
>> <jrbarne...@chromium.org> wrote:
>> > +chromium-os-discuss
>> > (moving the discussion back to the list, so everyone can benefit from
>> > what's learned).
>> > On Nov 5, 2012, at 4:09 PM, Mauro Ribeiro wrote:
>> >> Richard,
>> >> Thank you for your notes.
>> >> Since the kernel that ChromiumOS uses doesn't support my board I've
>> went ahead to search on ChromiumOS kernel to see what I need.
>> >> I've found some config's needed and added.
>> >> Also I've found a device driver on drivers/platform I've also ported
>> those to my vendor suplied kernel (We use 3.6 series for Linux and 3.0
>> series for Android). I've ported those to 3.6.
>> >> Now the board boots and doesn't goes onto a random loop of repair.
>> >> Now it will stop saying that init can't start certain process.
>> >> mtp and thermal I've disabled (mtpd as far as I know is related to VPN
>> stuff and thermal is daisy related, I've moved the .conf's files in
>> /etc/init somewhere else)
>> FWIW, mtpd is the daemon responsible for exposing MTP (Media Transfer
>> Protocol) devices to Chrome.
>> >> Now 3 process that can't be started:
>> >> factory
>> >> factorylog
>> >> bootcache
>> > To clarify, the three things named are upstart jobs, not processes
>> > as such. The first two are specific to factory test images; once
>> > you're back to the regular developer image, these won't exist.
>> > I don't know why bootcache would fail to start; however, unless it
>> > still won't start once you're booting a developer image, I don't think
>> > it's an interesting problem.
>> >> Any idea?
>> >> Right now I'm switching from the factory_test image back to dev.
>> > Yeah, retrying with a dev image is the right next step. If it doesn't
>> > fail in a dev image, it doesn't matter (to you, at any rate).
>> >> 2012/11/5 Richard Barnette <jrbarne...@chromium.org>
>> >> On Nov 4, 2012, at 11:00 PM, Hung-Te Lin wrote:
>> >> > Maybe caused by "encrypted stateful partition" / TPM issue, since
>> you probably don't have TPM in system?
>> >> > Do it boot if you build factory test image (build_image
>> factory_test) instead?
>> >> Trouble with encrypted stateful is a good suspect. AFAIK, a TPM
>> >> isn't required, but encrypted stateful *does* require some specific
>> >> kernel modules. The fix would be to add those modules, or skip
>> >> the encrypted stateful step.
>> >> I think specifying 'factory' on the 'mount-encrypted' command line
>> >> will skip the encryption; keescook@ or hungte@ will know more
>> >> about what that option does. The option is specified automatically
>> >> in factory test images, but you could also change chromeos_startup
>> >> to pass the argument unconditionally.
>> >> Somebody like keescook@ will have to comment on exactly
>> >> which kernel modules would be needed.
>> >> > On Sun, Nov 4, 2012 at 12:03 PM, Mauro Ribeiro <mdr...@gmail.com>
>> wrote:
>> >> > Just to note:
>> >> > Its getting that on:
>> >> > cleanup_mounts()
>> >> > Even that the STATEFUL partition is getting mounted correctly. (used
>> a mount >> /dev/ttySAC1 to see that)
>> >> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
>> >> > I've already did the hack to echo the STATE_DEV and it shows
>> /dev/sda1 that
>> >> > is suppoused to be correct. Am I right here?
>> >> > What are the problems or issues to move the stateful partition to
>> tmpfs ?
>> >> > Could you point me where to change that?
>> >> > As far as uploading the overlay I'll, but as soon as my vendor
>> provide me
>> >> > the magical blobs to the MALI GPU. (aka. EGL).
>> >> > My overlay rightnow is just a daisy overlay buiding with cortex-a9
>> instead
>> >> > of a15. And removing part of its gfx stuff.
>> >> > More likely a arm-generic overlay (I've built that and it works as
>> well).
>> >> > Right now all I want is a image that will boot and log onto
>> ChromiumOS.
>> >> > Later after I achieve this goal I'll work on getting certain parts
>> of my
>> >> > hardware properly supported.
>> >> > Thank you for your help ;)
>> >> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
>> >> > I've already did the hack to echo the STATE_DEV and it shows
>> /dev/sda1 that is suppoused to be correct. Am I right here?
>> >> > What are the problems or issues to move the stateful partition to
>> tmpfs ?
>> >> > Could you point me where to change that?
>> >> > As far as uploading the overlay I'll, but as soon as my vendor
>> provide me the magical blobs to the MALI GPU. (aka. EGL).
>> >> > My overlay rightnow is just a daisy overlay buiding with cortex-a9
>> instead of a15. And removing part of its gfx stuff.
>> >> > More likely a arm-generic overlay (I've built that and it works as
>> well).
>> >> > Right now all I want is a image that will boot and log onto
>> ChromiumOS. Later after I achieve this goal I'll work on getting certain
>> parts of my hardware properly supported.
>> >> > On Sat, Nov 3, 2012 at 7:21 PM, Mauro Ribeiro <mdr...@gmail.com>
>> wrote:
>> >> > Hey There,
>> >> > I'm working on porting ChromiumOS to Exynos 4412.
>> >> > Nice
>> >> > Basicly what I've achieved so far is to boot it.
>> >> > I'm running a modified overlay of daisy.
>> >> > If you have a fully functional overlay feel free to submit CLs to
>> gerrit if you would like to add them into the tree.
>> >> > I'm booting of a sdcard that has the exynos proprietary stuff, uboot
>> and a fat partition that the kernel is on.
>> >> > I've setted the root to /dev/sda3 (my usb drive)
>> >> > So far my ChromiumOS image builds and boot.
>> >> > But here's my problem:
>> >> > Uppon boot it will keep at "Your system is repairing itself. Please
>> wait"
>> >> > and boot loop on that.
>> >> > Maybe it is looking for your stateful partition in a particular
>> location. You could hack chromeos_startup to debug (or force the use of
>> tmpfs)
>> >> > I've did a research around the web and I've found that its something
>> on the state paritition, but the state partition is there and it isn't
>> corrupted, If i put the sdcard on my laptop I can read it.
>> >> > I've uploaded my clobber.log to www.mdrjr.net/clobber.log
>> >> > Is there anything that I'm missing?
>> >> > The integrity of the usb drive looks to be ok.
>> >> > At first glance I've tought that it was somehow ChromiumOS getting
>> lost and trying to access the sdcard that I use to boot instead of the USB
>> key.
>> >> > I've even disabled the sdcard support on the kernel to try. Still
>> the same issue.
>> >> > Any directions or points will be very helpful.
>>> FWIW, mtpd is the daemon responsible for exposing MTP (Media Transfer
>>> Protocol) devices to Chrome.
>>> >> Now 3 process that can't be started:
>>> >> factory
>>> >> factorylog
>>> >> bootcache
>>> > To clarify, the three things named are upstart jobs, not processes
>>> > as such. The first two are specific to factory test images; once
>>> > you're back to the regular developer image, these won't exist.
>>> > I don't know why bootcache would fail to start; however, unless it
>>> > still won't start once you're booting a developer image, I don't think
>>> > it's an interesting problem.
>>> >> Any idea?
>>> >> Right now I'm switching from the factory_test image back to dev.
>>> > Yeah, retrying with a dev image is the right next step. If it doesn't
>>> > fail in a dev image, it doesn't matter (to you, at any rate).
>>> >> 2012/11/5 Richard Barnette <jrbarne...@chromium.org>
>>> >> On Nov 4, 2012, at 11:00 PM, Hung-Te Lin wrote:
>>> >> > Maybe caused by "encrypted stateful partition" / TPM issue, since
you probably don't have TPM in system?
>>> >> > Do it boot if you build factory test image (build_image
>>> >> Trouble with encrypted stateful is a good suspect. AFAIK, a TPM
>>> >> isn't required, but encrypted stateful *does* require some specific
>>> >> kernel modules. The fix would be to add those modules, or skip
>>> >> the encrypted stateful step.
>>> >> I think specifying 'factory' on the 'mount-encrypted' command line
>>> >> will skip the encryption; keescook@ or hungte@ will know more
>>> >> about what that option does. The option is specified automatically
>>> >> in factory test images, but you could also change chromeos_startup
>>> >> to pass the argument unconditionally.
>>> >> Somebody like keescook@ will have to comment on exactly
>>> >> which kernel modules would be needed.
>>> >> > On Sun, Nov 4, 2012 at 12:03 PM, Mauro Ribeiro <mdr...@gmail.com>
wrote:
>>> >> > Just to note:
>>> >> > Its getting that on:
>>> >> > cleanup_mounts()
>>> >> > Even that the STATEFUL partition is getting mounted correctly.
>>> >> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
>>> >> > I've already did the hack to echo the STATE_DEV and it shows
/dev/sda1 that
>>> >> > is suppoused to be correct. Am I right here?
>>> >> > What are the problems or issues to move the stateful partition to
tmpfs ?
>>> >> > Could you point me where to change that?
>>> >> > As far as uploading the overlay I'll, but as soon as my vendor
provide me
>>> >> > the magical blobs to the MALI GPU. (aka. EGL).
>>> >> > My overlay rightnow is just a daisy overlay buiding with cortex-a9
instead
>>> >> > of a15. And removing part of its gfx stuff.
>>> >> > More likely a arm-generic overlay (I've built that and it works as
well).
>>> >> > Right now all I want is a image that will boot and log onto
ChromiumOS.
>>> >> > Later after I achieve this goal I'll work on getting certain parts
of my
>>> >> > hardware properly supported.
>>> >> > Thank you for your help ;)
>>> >> > 2012/11/4 Mauro Ribeiro <mdr...@gmail.com>
>>> >> > I've already did the hack to echo the STATE_DEV and it shows
/dev/sda1 that is suppoused to be correct. Am I right here?
>>> >> > What are the problems or issues to move the stateful partition to
tmpfs ?
>>> >> > Could you point me where to change that?
>>> >> > As far as uploading the overlay I'll, but as soon as my vendor
provide me the magical blobs to the MALI GPU. (aka. EGL).
>>> >> > My overlay rightnow is just a daisy overlay buiding with cortex-a9
instead of a15. And removing part of its gfx stuff.
>>> >> > More likely a arm-generic overlay (I've built that and it works as
well).
>>> >> > Right now all I want is a image that will boot and log onto
ChromiumOS. Later after I achieve this goal I'll work on getting certain
parts of my hardware properly supported.
> Google Chromium the Browser requires GL to work right?
> My vendor doesn't provide OpenGL ES (Aka Mali Magical Blobs) for Linux.
I haven't verified for sure, but I think it's possible to get a hold of the
Mali 400 binaries through either Linaro, or ARM's Mali developer community
somewhere. I think it's the same drivers as for 4210, i.e. what's used on
the Origen board, etc.
(Sorry, I don't have any more detailed pointers than that for you, but
hopefully you can find something there without too much searching)
