Re: rk3399-gru-kevin: issues on bringup
Hi Simon, Marty,
I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload.
I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things.
Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?):
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.
Hi Marty,
On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi Simon, Marty,
I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload.
I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things.
Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?):
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.
I am just replying here as you asked for some details on IRC. What details do you need?
I was intending to try out a kevin if I have one. I will add that to my list.
Regards, Simon
On Tue, Feb 23, 2021 at 10:10:11AM -0500, Simon Glass wrote:
Hi Marty,
On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi Simon, Marty,
I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload.
I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things.
Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?):
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.
I am just replying here as you asked for some details on IRC. What details do you need?
Well, if its possible to actually do openocd/etc on the AP using a servo, I'd like to know how. All the documentation I could find is about using openocd to flash the EC, not debug the AP.
I was intending to try out a kevin if I have one. I will add that to my list.
Regards, Simon
Hi Marty,
On Tue, 23 Feb 2021 at 16:36, Marty E. Plummer hanetzer@startmail.com wrote:
On Tue, Feb 23, 2021 at 10:10:11AM -0500, Simon Glass wrote:
Hi Marty,
On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi Simon, Marty,
I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload.
I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things.
Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?):
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.
I am just replying here as you asked for some details on IRC. What details do you need?
Well, if its possible to actually do openocd/etc on the AP using a servo, I'd like to know how. All the documentation I could find is about using openocd to flash the EC, not debug the AP.
OK...in my case I attached a ARM DSTREAM JTAG unit to the 20-pin connector on the servo 2 board. I was then able to connect and debug U-Boot and linux. This was on a snow (Samsung exynos) so not the same SoC, but it might work. I can't recall the clock speed, but it certainly was slower than 200MHz.
This has some info:
https://elinux.org/images/7/7f/Manderson5.pdf
Here are the instructions I wrote, from the history as they have been removed from the page, being so out of date!
https://sites.google.com/a/google.com/chromeos/system/app/pages/admin/compar...
I was intending to try out a kevin if I have one. I will add that to my list.
Regards, Simon
On Wed, Feb 24, 2021 at 11:31:05AM -0500, Simon Glass wrote:
Hi Marty,
On Tue, 23 Feb 2021 at 16:36, Marty E. Plummer hanetzer@startmail.com wrote:
On Tue, Feb 23, 2021 at 10:10:11AM -0500, Simon Glass wrote:
Hi Marty,
On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi Simon, Marty,
I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload.
I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things.
Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?):
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.
I am just replying here as you asked for some details on IRC. What details do you need?
Well, if its possible to actually do openocd/etc on the AP using a servo, I'd like to know how. All the documentation I could find is about using openocd to flash the EC, not debug the AP.
OK...in my case I attached a ARM DSTREAM JTAG unit to the 20-pin connector on the servo 2 board. I was then able to connect and debug U-Boot and linux. This was on a snow (Samsung exynos) so not the same SoC, but it might work. I can't recall the clock speed, but it certainly was slower than 200MHz.
Ok, I thought it may be something like that. I have a flyswatter2 which should work.
This has some info:
https://elinux.org/images/7/7f/Manderson5.pdf
Here are the instructions I wrote, from the history as they have been removed from the page, being so out of date!
https://sites.google.com/a/google.com/chromeos/system/app/pages/admin/compar...
Beh. I can't view this page, 'You need permission\nSwitch to an account with permission."
I was intending to try out a kevin if I have one. I will add that to my list.
Regards, Simon
Hi,
On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi Simon, Marty,
I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload.
I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things.
Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?):
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.
I have the em100 working and have got to the same point as you, Marty.
em100 -s -c gd25lq64 -d /tmp/b/chromebook_kevin/u-boot.rom -r
So I suppose that means that SDRAM is running and we just need a SPI driver? I will see if I can figure out what is missing...
Update...it seems to just be missing the ID. I pushed a new patch to:
https://github.com/sjg20/u-boot/tree/kevin
Now I see:
Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride
U-Boot SPL 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700) Trying to boot from SPI
U-Boot 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)
Model: Google Kevin DRAM: 3.9 GiB Cannot find regulator pwm init_voltage MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
Got rc -1, expected 100 Failed to probe keyboard 'keyboard-controller' In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Google Kevin Net: No ethernet found. Hit any key to stop autoboot: 0 =>
No display and various errors on the way up, but at least it boots to a prompt.
Regards, Simon
On Wed, Mar 10, 2021 at 11:52:07PM -0500, Simon Glass wrote:
Hi,
On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi Simon, Marty,
I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload.
I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things.
Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?):
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.
I have the em100 working and have got to the same point as you, Marty.
em100 -s -c gd25lq64 -d /tmp/b/chromebook_kevin/u-boot.rom -r
So I suppose that means that SDRAM is running and we just need a SPI driver? I will see if I can figure out what is missing...
Update...it seems to just be missing the ID. I pushed a new patch to:
Christ, its always something small and stupid. Perhaps the failure message should be amended to indicate 'unknown jedec id: %x' or so to be a bit more informative.
This looks promising. Built it (away from the machine right now so can't test) and it seems that u-boot-rockchip.bin is just a bit too large to be flashed (8.8mb)? Or judging by your above em100 invocation this image is not to be used? If so, why is it produced at all?
Now I see:
Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride
U-Boot SPL 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700) Trying to boot from SPI
U-Boot 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)
Model: Google Kevin DRAM: 3.9 GiB Cannot find regulator pwm init_voltage MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
Got rc -1, expected 100 Failed to probe keyboard 'keyboard-controller' In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Google Kevin Net: No ethernet found. Hit any key to stop autoboot: 0 =>
No display and various errors on the way up, but at least it boots to a prompt.
A much better situation then before. I'll pull your changes into my tree and see what can be done with it.
Regards, Simon
Hi Marty,
On Sat, 13 Mar 2021 at 12:40, Marty E. Plummer hanetzer@startmail.com wrote:
On Wed, Mar 10, 2021 at 11:52:07PM -0500, Simon Glass wrote:
Hi,
On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi Simon, Marty,
I'm interested in getting U-Boot to work with Kevin as well, but don't have a Servo (or the willingness to open up the case yet), so I've been trying to boot from depthcharge as in README.chromium-chainload.
I don't have a way to see serial output and I see no other signs of life. Can you give me a tested configuration that immediately powers-off or reboots a Kevin so I can confirm what I'm doing works on the chainloading side? I mean I can boot Linux, but trying the same with U-Boot just gives me a blank screen even after accounting for a lot of things.
Meanwhile, I've wrote some code to automate making depthcharge partition images, and to enable the display on Kevin (and perhaps Bob). Since I don't know if chainloading works, I don't know if these are broken or not either. I'm unsure about sending untested patches to the list, so I put them up here if you want to take a look (and maybe test/fix them?):
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
They're not really things that'd make a non-booting Kevin boot, though. I hope at least some of it can be useful in some way.
I have the em100 working and have got to the same point as you, Marty.
em100 -s -c gd25lq64 -d /tmp/b/chromebook_kevin/u-boot.rom -r
So I suppose that means that SDRAM is running and we just need a SPI driver? I will see if I can figure out what is missing...
Update...it seems to just be missing the ID. I pushed a new patch to:
Christ, its always something small and stupid. Perhaps the failure message should be amended to indicate 'unknown jedec id: %x' or so to be a bit more informative.
It doesn't do that because it is the SPL 'tiny' version.
This looks promising. Built it (away from the machine right now so can't test) and it seems that u-boot-rockchip.bin is just a bit too large to be flashed (8.8mb)? Or judging by your above em100 invocation this image is not to be used? If so, why is it produced at all?
I think it is for booting from eMMC. But I am booting from SPI flash.
Now I see:
Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride
U-Boot SPL 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700) Trying to boot from SPI
U-Boot 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)
Model: Google Kevin DRAM: 3.9 GiB Cannot find regulator pwm init_voltage MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
Got rc -1, expected 100 Failed to probe keyboard 'keyboard-controller' In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Google Kevin Net: No ethernet found. Hit any key to stop autoboot: 0 =>
No display and various errors on the way up, but at least it boots to a prompt.
A much better situation then before. I'll pull your changes into my tree and see what can be done with it.
OK. I added a little patch to fix the EC as well
Regards, Simon
Hi,
I've had some recent success with my gru-kevin and wanted to update you on this. Long story short, I can boot from SPI flash and have the display, keyboard, eMMC, microSD card, USB disks all work (however with some hacks); but can't boot into Linux. Things seem to hang shortly after "Starting kernel..." but I don't know if something fails in U-Boot or if I get a kernel panic. (I still have no serial console).
There are three relevant branches on my GitHub repo now, please have a look. The first is for what I intend to send upstream soon enough. The other two include hacks and additional patches that build on top of the first, meant to improve things on a per-board basis:
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bob
I have no idea if the gru-bob versions work. I just thought things I did for gru-kevin are applicable to it as well and decided I should include them in case anyone wants to test.
I also want to ask you some things I'm indecisive about, before posting the rk3399-gru-chromebooks branch as patches.
Most of the patches are small config and dts changes that I've grouped by whatever effect they have. Should I squash them into one commit each for config/dts?
Simon, I've edited some of your patches and kept you as author & sign-off. Are you OK with the edited versions, am I doing things right? See:
https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f93...
https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc84...
https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18...
Marty, your (second) chromebook_kevin support patch didn't have your sign-off. Is it OK to add it? See:
https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc...
I also think I should squash my gru-kevin changes into that commit, add a commit message about board status, and keep Marty as author & sign-off while adding myself as Co-authored-by & sign-off. Any better ideas on how to structure the patches?
Do both of you want to be in /board/google/gru/MAINTAINERS? I have three of us listed there right now, but no idea if that's fine with you two.
Hope you can spare time on this.
On Mon, Nov 1, 2021 at 11:25 PM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi,
I've had some recent success with my gru-kevin and wanted to update you on this. Long story short, I can boot from SPI flash and have the display, keyboard, eMMC, microSD card, USB disks all work (however with some hacks); but can't boot into Linux. Things seem to hang shortly after "Starting kernel..." but I don't know if something fails in U-Boot or if I get a kernel panic. (I still have no serial console).
I suspect you need the following patch [1], we had the same hang in Fedora and even with a serial console and a whole bunch of kernel debug it was difficult to get to the bottom of. Sadly the fix, whether this patch or another one is still not upstream.
[1] http://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ice...
There are three relevant branches on my GitHub repo now, please have a look. The first is for what I intend to send upstream soon enough. The other two include hacks and additional patches that build on top of the first, meant to improve things on a per-board basis:
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bobI have no idea if the gru-bob versions work. I just thought things I did for gru-kevin are applicable to it as well and decided I should include them in case anyone wants to test.
I also want to ask you some things I'm indecisive about, before posting the rk3399-gru-chromebooks branch as patches.
Most of the patches are small config and dts changes that I've grouped by whatever effect they have. Should I squash them into one commit each for config/dts?
Simon, I've edited some of your patches and kept you as author & sign-off. Are you OK with the edited versions, am I doing things right? See:
https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f93...
https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc84...
https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18...
Marty, your (second) chromebook_kevin support patch didn't have your sign-off. Is it OK to add it? See:
https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc...
I also think I should squash my gru-kevin changes into that commit, add a commit message about board status, and keep Marty as author & sign-off while adding myself as Co-authored-by & sign-off. Any better ideas on how to structure the patches?
Do both of you want to be in /board/google/gru/MAINTAINERS? I have three of us listed there right now, but no idea if that's fine with you two.
Hope you can spare time on this.
On 02/11/2021 11:09, Peter Robinson wrote:
On Mon, Nov 1, 2021 at 11:25 PM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
some hacks); but can't boot into Linux. Things seem to hang shortly after "Starting kernel..." but I don't know if something fails in U-Boot or if I get a kernel panic. (I still have no serial console).
I suspect you need the following patch [1], we had the same hang in Fedora and even with a serial console and a whole bunch of kernel debug it was difficult to get to the bottom of. Sadly the fix, whether this patch or another one is still not upstream.
[1] http://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ice...
I already had this patch in the gru-kevin branch because it solves a hang in the coreboot -> depthcharge -> U-Boot -> Linux-on-USB chain, thanks for the pointer though :)
This problem I'm seeing now appears to be something else, but I have no idea as to what it could be. Since that chain works I assume I should look more into what coreboot/depthcharge does...
Hi Alpher,
On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi,
I've had some recent success with my gru-kevin and wanted to update you on this. Long story short, I can boot from SPI flash and have the display, keyboard, eMMC, microSD card, USB disks all work (however with some hacks); but can't boot into Linux. Things seem to hang shortly after "Starting kernel..." but I don't know if something fails in U-Boot or if I get a kernel panic. (I still have no serial console).
There are three relevant branches on my GitHub repo now, please have a look. The first is for what I intend to send upstream soon enough. The other two include hacks and additional patches that build on top of the first, meant to improve things on a per-board basis:
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bobI have no idea if the gru-bob versions work. I just thought things I did for gru-kevin are applicable to it as well and decided I should include them in case anyone wants to test.
I also want to ask you some things I'm indecisive about, before posting the rk3399-gru-chromebooks branch as patches.
Most of the patches are small config and dts changes that I've grouped by whatever effect they have. Should I squash them into one commit each for config/dts?
Probably best.
Simon, I've edited some of your patches and kept you as author & sign-off. Are you OK with the edited versions, am I doing things right? See:
https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f93...
https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc84...
https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18...
LGTM
Marty, your (second) chromebook_kevin support patch didn't have your sign-off. Is it OK to add it? See:
https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc...
I also think I should squash my gru-kevin changes into that commit, add a commit message about board status, and keep Marty as author & sign-off while adding myself as Co-authored-by & sign-off. Any better ideas on how to structure the patches?
Do both of you want to be in /board/google/gru/MAINTAINERS? I have three of us listed there right now, but no idea if that's fine with you two.
Hope you can spare time on this.
I actually have bob in my lab but I have not tried the Chrome OS boot script on it. I could probably add kevin.
$ do-try-int.sh bob Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob
Checking revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = '77680d8f85b94ffe690b8fe1f35767aef8b1415a' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─bob is on port 9904 and uses /dev/pts/39 │ ├─POWERON (bob) │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: bob │ │ │ └─Done. (1.038s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (9.073s) │ │ └─Done. (10.454s) │ ├─Calling uboot_flash ... │ │ └─Done. (0.677s) │ ├─POWEROFF (bob) │ └─Done. (11.868s) ├───────────────────────────────────────── └─SUCCESS (11.994s) tbot starting ... ├─Calling interactive_board ... │ ├─bob is on port 9904 and uses /dev/pts/39 │ ├─POWERON (bob) │ ├─Entering interactive shell (CTRL+D to exit) ... �Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride
U-Boot SPL 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600) Trying to boot from SPI rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
U-Boot 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600)
Model: Google Bob DRAM: 3.9 GiB Cannot find regulator pwm init_voltage MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
Got rc -1, expected 100 Failed to probe keyboard 'keyboard-controller' In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Google Bob Net: No ethernet found. Hit any key to stop autoboot: 0 =>
Regards, Simon
Hi Alper,
On Tue, 2 Nov 2021 at 17:05, Simon Glass sjg@chromium.org wrote:
Hi Alpher,
On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Hi,
I've had some recent success with my gru-kevin and wanted to update you on this. Long story short, I can boot from SPI flash and have the display, keyboard, eMMC, microSD card, USB disks all work (however with some hacks); but can't boot into Linux. Things seem to hang shortly after "Starting kernel..." but I don't know if something fails in U-Boot or if I get a kernel panic. (I still have no serial console).
There are three relevant branches on my GitHub repo now, please have a look. The first is for what I intend to send upstream soon enough. The other two include hacks and additional patches that build on top of the first, meant to improve things on a per-board basis:
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bobI have no idea if the gru-bob versions work. I just thought things I did for gru-kevin are applicable to it as well and decided I should include them in case anyone wants to test.
I also want to ask you some things I'm indecisive about, before posting the rk3399-gru-chromebooks branch as patches.
Most of the patches are small config and dts changes that I've grouped by whatever effect they have. Should I squash them into one commit each for config/dts?
Probably best.
Simon, I've edited some of your patches and kept you as author & sign-off. Are you OK with the edited versions, am I doing things right? See:
https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f93...
https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc84...
https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18...
LGTM
Marty, your (second) chromebook_kevin support patch didn't have your sign-off. Is it OK to add it? See:
https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc...
I also think I should squash my gru-kevin changes into that commit, add a commit message about board status, and keep Marty as author & sign-off while adding myself as Co-authored-by & sign-off. Any better ideas on how to structure the patches?
Do both of you want to be in /board/google/gru/MAINTAINERS? I have three of us listed there right now, but no idea if that's fine with you two.
Hope you can spare time on this.
I actually have bob in my lab but I have not tried the Chrome OS boot script on it. I could probably add kevin.
$ do-try-int.sh bob Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob
Checking revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = '77680d8f85b94ffe690b8fe1f35767aef8b1415a' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─bob is on port 9904 and uses /dev/pts/39 │ ├─POWERON (bob) │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: bob │ │ │ └─Done. (1.038s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (9.073s) │ │ └─Done. (10.454s) │ ├─Calling uboot_flash ... │ │ └─Done. (0.677s) │ ├─POWEROFF (bob) │ └─Done. (11.868s) ├───────────────────────────────────────── └─SUCCESS (11.994s) tbot starting ... ├─Calling interactive_board ... │ ├─bob is on port 9904 and uses /dev/pts/39 │ ├─POWERON (bob) │ ├─Entering interactive shell (CTRL+D to exit) ... �Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride
U-Boot SPL 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600) Trying to boot from SPI rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
U-Boot 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600)
Model: Google Bob DRAM: 3.9 GiB Cannot find regulator pwm init_voltage MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
Got rc -1, expected 100 Failed to probe keyboard 'keyboard-controller' In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Google Bob Net: No ethernet found. Hit any key to stop autoboot: 0 =>
Just to note that I have a kevin in my lab now and it boots into U-Boot with your
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
I also tried Bob and got this:
$ do-try-int.sh bob Revision 6a549d02fc43408cf4f000cc97688e7a64948572, board bob
Checking revision 6a549d02fc43408cf4f000cc97688e7a64948572 /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = '6a549d02fc43408cf4f000cc97688e7a64948572' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─POWERON (bob) │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: bob │ │ │ └─Done. (0.195s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (9.943s) │ │ └─Done. (10.329s) │ ├─Calling uboot_flash ... │ │ └─Done. (2.209s) │ ├─POWEROFF (bob) │ └─Done. (13.305s) ├───────────────────────────────────────── └─SUCCESS (13.438s) tbot starting ... ├─Calling interactive_board ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─POWERON (bob) │ ├─Entering interactive shell (CTRL+D to exit) ... Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride
U-Boot SPL 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600) Trying to boot from SPI rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
U-Boot 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
Model: Google Bob DRAM: 3.9 GiB MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: cros-ec-keyb Out: vidconsole Err: vidconsole Model: Google Bob Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:c... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@fe320000.blk... Disk mmc@fe320000.blk not ready Scanning disk mmc@fe330000.blk... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... Found 13 disks ** Unable to read file ubootefi.var ** Failed to load EFI variables BootOrder not defined EFI boot manager: Cannot load any image starting USB... Bus usb@fe380000: USB EHCI 1.00 Bus usb@fe3a0000: USB OHCI 1.0 Bus usb@fe3c0000: USB EHCI 1.00 Bus usb@fe3e0000: USB OHCI 1.0 Bus usb@fe800000: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fe900000: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe380000 for devices... 2 USB Device(s) found scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found scanning bus usb@fe3e0000 for devices... 1 USB Device(s) found scanning bus usb@fe800000 for devices... 1 USB Device(s) found scanning bus usb@fe900000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found
Device 0: unknown device No ethernet found. missing environment variable: pxeuuid missing environment variable: bootfile Retrieving file: pxelinux.cfg/00000000 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/0000000 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/000000 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/00000 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/0000 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/000 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/00 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/0 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-rk3399-gru No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-rk3399 No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm No ethernet found. missing environment variable: bootfile Retrieving file: pxelinux.cfg/default No ethernet found. Config file not found No ethernet found. No ethernet found. SF: Detected gd25lq32 with page size 256 Bytes, erase size 4 KiB, total 4 MiB Offset exceeds device limit sf - SPI flash sub-system
Usage: sf probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus and chip select sf read addr offset|partition len - read `len' bytes starting at `offset' or from start of mtd `partition'to memory at `addr' sf write addr offset|partition len - write `len' bytes from memory at `addr' to flash at `offset' or to start of mtd `partition' sf erase offset|partition [+]len - erase `len' bytes from `offset' or from start of mtd `partition' `+len' round up `len' to block size sf update addr offset|partition len - erase and write `len' bytes from memory at `addr' to flash at `offset' or to start of mtd `partition' sf protect lock/unlock sector len - protect/unprotect 'len' bytes starting at address 'sector'
sf test offset len - run a very basic destructive test ## Executing script at 00500000 Wrong image format for "source" command SCRIPT FAILED: continuing... =>
Having both in my lab will make it much easier to test.
Regards, Simon
On 06/11/2021 06:16, Simon Glass wrote:
On Tue, 2 Nov 2021 at 17:05, Simon Glass sjg@chromium.org wrote:
On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Most of the patches are small config and dts changes that I've grouped by whatever effect they have. Should I squash them into one commit each for config/dts?
Probably best.
I did so and updated the branches, now the series goes like this:
rockchip: gru: Set up SoC IO domain registers rockchip: gru: Add more devicetree settings rockchip: bob: Enable more configs rockchip: rk3399: Add support for chromebook_kevin
Marty, your (second) chromebook_kevin support patch didn't have your sign-off. Is it OK to add it? See:
I still didn't add a sign-off for this patch. There is an earlier version with one [1]. I'm not sure if I can add the sign-off citing that, or send the patches without a sign-off. I guess I'll wait a bit more for a reply?
[1] https://patchwork.ozlabs.org/patch/1053386/
I actually have bob in my lab but I have not tried the Chrome OS boot script on it. I could probably add kevin.
Booting the Chrome OS way would be an interesting experiment. I might eventually work on it, but not exactly a priority for me right now unless if it makes it easier for you to test things on these boards :D .
$ do-try-int.sh bob Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob
(I notice this was on a recent u-boot/master instead of my branch)
Just to note that I have a kevin in my lab now and it boots into U-Boot with your
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
I also tried Bob and got this:
$ do-try-int.sh bob Revision 6a549d02fc43408cf4f000cc97688e7a64948572, board bob
Checking revision 6a549d02fc43408cf4f000cc97688e7a64948572 /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = '6a549d02fc43408cf4f000cc97688e7a64948572' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─POWERON (bob) │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: bob │ │ │ └─Done. (0.195s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (9.943s) │ │ └─Done. (10.329s) │ ├─Calling uboot_flash ... │ │ └─Done. (2.209s) │ ├─POWEROFF (bob) │ └─Done. (13.305s) ├───────────────────────────────────────── └─SUCCESS (13.438s) tbot starting ... ├─Calling interactive_board ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─POWERON (bob) │ ├─Entering interactive shell (CTRL+D to exit) ... Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride
U-Boot SPL 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600) Trying to boot from SPI rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
I have a feeling that this is because the SPL devicetree filters out pinctrl subnodes while some other included nodes might be referring to those. That might be what's causing the same messages in sandbox as well...
U-Boot 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
Model: Google Bob DRAM: 3.9 GiB MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: cros-ec-keyb Out: vidconsole Err: vidconsole Model: Google Bob Net: No ethernet found.
Could you manually confirm that the display and keyboard works?
Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:c... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@fe320000.blk... Disk mmc@fe320000.blk not ready Scanning disk mmc@fe330000.blk... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... Found 13 disks [...] =>
This starts with mmc1 (microSD card) for me and gives an error for mmc0 (eMMC) which I have to prevent with a hack to skip its re-init. Nice to see that Bob doesn't need that. Other than that I see the same output with Chrome OS installed on eMMC.
I would greatly appreciate it if you could try booting into any Linux really, to have some logs of what goes wrong while doing so. Debian's installer images [2] should be somewhat working on Kevin/Bob. Booting after USB is initialized requires a patch [3] to fix a hang though.
[2] https://deb.debian.org/debian/dists/bullseye/main/installer-arm64/current/im...
[3] https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ic...
Having both in my lab will make it much easier to test.
Thanks for the tests so far!
Hi Alper,
On Sun, 7 Nov 2021 at 10:26, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
On 06/11/2021 06:16, Simon Glass wrote:
On Tue, 2 Nov 2021 at 17:05, Simon Glass sjg@chromium.org wrote:
On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Most of the patches are small config and dts changes that I've grouped by whatever effect they have. Should I squash them into one commit each for config/dts?
Probably best.
I did so and updated the branches, now the series goes like this:
rockchip: gru: Set up SoC IO domain registers rockchip: gru: Add more devicetree settings rockchip: bob: Enable more configs rockchip: rk3399: Add support for chromebook_kevin
Marty, your (second) chromebook_kevin support patch didn't have your sign-off. Is it OK to add it? See:
I still didn't add a sign-off for this patch. There is an earlier version with one [1]. I'm not sure if I can add the sign-off citing that, or send the patches without a sign-off. I guess I'll wait a bit more for a reply?
[1] https://patchwork.ozlabs.org/patch/1053386/
I actually have bob in my lab but I have not tried the Chrome OS boot script on it. I could probably add kevin.
Booting the Chrome OS way would be an interesting experiment. I might eventually work on it, but not exactly a priority for me right now unless if it makes it easier for you to test things on these boards :D .
$ do-try-int.sh bob Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob
(I notice this was on a recent u-boot/master instead of my branch)
Just to note that I have a kevin in my lab now and it boots into U-Boot with your
https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
I also tried Bob and got this:
$ do-try-int.sh bob Revision 6a549d02fc43408cf4f000cc97688e7a64948572, board bob
Checking revision 6a549d02fc43408cf4f000cc97688e7a64948572 /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = '6a549d02fc43408cf4f000cc97688e7a64948572' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─POWERON (bob) │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: bob │ │ │ └─Done. (0.195s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (9.943s) │ │ └─Done. (10.329s) │ ├─Calling uboot_flash ... │ │ └─Done. (2.209s) │ ├─POWEROFF (bob) │ └─Done. (13.305s) ├───────────────────────────────────────── └─SUCCESS (13.438s) tbot starting ... ├─Calling interactive_board ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─POWERON (bob) │ ├─Entering interactive shell (CTRL+D to exit) ... Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride
U-Boot SPL 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600) Trying to boot from SPI rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
I have a feeling that this is because the SPL devicetree filters out pinctrl subnodes while some other included nodes might be referring to those. That might be what's causing the same messages in sandbox as well...
U-Boot 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
Model: Google Bob DRAM: 3.9 GiB MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: cros-ec-keyb Out: vidconsole Err: vidconsole Model: Google Bob Net: No ethernet found.
Could you manually confirm that the display and keyboard works?
Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:c... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@fe320000.blk... Disk mmc@fe320000.blk not ready Scanning disk mmc@fe330000.blk... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... fs_devread read outside partition 2 Failed to mount ext2 filesystem... Found 13 disks [...] =>
This starts with mmc1 (microSD card) for me and gives an error for mmc0 (eMMC) which I have to prevent with a hack to skip its re-init. Nice to see that Bob doesn't need that. Other than that I see the same output with Chrome OS installed on eMMC.
I would greatly appreciate it if you could try booting into any Linux really, to have some logs of what goes wrong while doing so. Debian's installer images [2] should be somewhat working on Kevin/Bob. Booting after USB is initialized requires a patch [3] to fix a hang though.
[2] https://deb.debian.org/debian/dists/bullseye/main/installer-arm64/current/im...
[3] https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ic...
Having both in my lab will make it much easier to test.
Thanks for the tests so far!
Are you going to send your patches?
I haven't got as far as booting into Linux, nor trying some other kernel, but we should get these patches in...
Regards, Simon
On 25/11/2021 03:12, Simon Glass wrote:
On Sun, 7 Nov 2021 at 10:26, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I did so and updated the branches, now the series goes like this:
rockchip: gru: Set up SoC IO domain registers rockchip: gru: Add more devicetree settings rockchip: bob: Enable more configs rockchip: rk3399: Add support for chromebook_kevin
[...]
Are you going to send your patches?
I haven't got as far as booting into Linux, nor trying some other kernel, but we should get these patches in...
I got sidetracked while waiting for a reply from Marty... I'll send them now and hope for the best.
participants (4)
-
Alper Nebi Yasak -
Marty E. Plummer -
Peter Robinson -
Simon Glass