search

xc-racer99 / u-boot-aries

U-boot port for first-gen Galaxy S devices. Flashed in place of kernel with stock IBL/PBL/SBL. Kernel read from OneNAND/MMC/SD/Serial.
9 stars 2 forks source link

SPL setup to replace IBL/PBL #31

Closed xc-racer99 closed 5 years ago

xc-racer99 commented 5 years ago

This is a simple SPL setup, lacking important things such as battery checking. With unchanged OM values (or the unbrickable mod), it will boot when the resulting aries-spl.bin is flashed to offset 0x0 of the onenand (ie from u-boot, run load mmc 0:1 0x30000000 aries-spl.bin; onenand erase 0x0 0x40000; onenand write 0x30000000 0x0 0x40000; - Note that heimdall doesn't appear to work - see https://github.com/xc-racer99/u-boot-aries/pull/31#issuecomment-508284445 for probable reason). If you don't have the unbrickable mod, you can just erase the IBL/PBL (onenand erase 0x0 0x4000;) then boot it from an SD card if you dd it to the SD card with a command such as dd if=spl/aries-spl.bin of=/dev/mmcblk0 seek=1 (it's offset 512 bytes from the start due to the MBR header - so GPT partitioning isn't possible). This doesn't work when you have the unbrickable mod applied.

Do note that it won't boot if the unbrickable mod has been incorrectly applied to your device, resulting in an OM value of 0x2b (normal unbrickable mod should be 0x29). This is the OM value for demux oneNAND and while the stock bootloader still works with this, this bootloader doesn't. I think this is due to the fact that the first stage bootloader is actually skipped in this case and this bootloader isn't signed while part 2 of the stock bootloader is. I think the real reason is that I was using heimdall, which doesn't flash the IBL as expected - see https://github.com/xc-racer99/u-boot-aries/pull/31#issuecomment-508284445

Compared to the stock bootloader, the SWRESET hook now works. It loads u-boot proper from the same offset on the oneNAND as the stock bootloader so the u-boot.bin can be the same regardless of using the stock IBL/PBL/SBL or this SPL.

Still TODO:

Closes #14

xc-racer99 commented 5 years ago

Ok, doing a bit more poking, it appears the reason that heimdall doesn't work is because there is some special handling of the IBL partition. The first 4k of boot.bin isn't written to the oneNAND, instead everything is shifted up 4k (ie starting at offset 0x1000) for 0x3000 (12kb) before an extra 0x1000 (4k) of blank space. Everything from offset 0x4000 and beyond matches up place for place as far as I can tell.

What's twigging something in my brain is that it might be like this to support EVT0, since the first-stage bootloader for EVT0 was slightly different and had a smaller max size (I could be wrong on this though, this is what I think is the case based on the O-Droid T bootloader and others)

PabloPL commented 5 years ago

Flashed new uboot (u-boot.bin) and spl (spl/aries-spl.bin) (needed to env default, otherwise spl_update was not defined):

Otherwise looks good (looking at code).

xc-racer99 commented 5 years ago

gpio keys (vol down/up) are not working for me in uboot (power key works)

Curious, it works fine when they're configured as input for me. I wonder if they need to be special func (0xF), this is what is set up in the vendor kernel. I'll check this on my device.

no logs/console over uart

No logs period, no logs from u-boot, or just no logs from loaded kernel?

PabloPL commented 5 years ago

No logs means no logs from bootloader :). Couldn't check kernel since i cannot select any option from bootmenu (only fastboot because it is first option in bootmenu). And i didn't yet booted any kernel after flashing new bootloader & spl so it didn't had last boot option stored (so it looks like normal user after first flash case).

Edit1: Strange that power Key works...

xc-racer99 commented 5 years ago

No logs means no logs from bootloader

Oh wait, what resistance value are you using? This will only work for some resistance values (523k and 619k but not 150k). 150k doesn't work as the fsa9480 requires the interrupt to be acked before it will switch while 523k and 619k are the "factory" modes that automatically switch.

Still no idea why the volume keys wouldn't be working...

PabloPL commented 5 years ago

@xc-racer99 Don't remeber now (and don't want to dissassembly cable to measure it), used 2 resistors so probably it's 150k. Will need to fix this (or finally use my https://wiki.tizen.org/MuxPi)

xc-racer99 commented 5 years ago

Don't remeber now (and don't want to dissassembly cable to measure it), used 2 resistors so probably it's 150k. Will need to fix this (or finally use my https://wiki.tizen.org/MuxPi)

Ah, ok. I still have my resistors in a breadboard so can easily check their values and test other values.

It's just a little awkward as we don't have interrupts so we need to manually check this info from the fsa9480. The only driver that can poll is the keyboard uclass, so I guess it'll have to be a connected/not connected on probe check for now.

PabloPL commented 5 years ago

Tried with 523k resistor and uart is working fine and i'm able to switch boot options (tested commits before and after adding fsa9480).

xc-racer99 commented 5 years ago

Tried with 523k resistor and uart is working fine and i'm able to switch boot options (tested commits before and after adding fsa9480).

Can you switch boot options without the resistor as well? With the latest patches to this branch, you should also be able to use a 150k resistor presuming it's plugged in at boot time.

PabloPL commented 5 years ago

Will try later. Offtopic: fourkbomb had some netconsole patches (over usb without Special cable i thing...). I Wonder if it would work on aries also...

xc-racer99 commented 5 years ago

Ok, things are moving along nicely now. I have suspend/resume working with the mainline kernel, but not with the Android kernel. With the Android kernel all I get is "wakeup wake lock: alarm" on the serial console and then nothing.

When running it from the SD card, suspend/resume doesn't work - presumably since the SD card backup is not meant to be used in the first place and the IROM doesn't try it after OneNAND fails.

xc-racer99 commented 5 years ago

My i9000M arrived today and I can confirm that the volume keys don't work. Will work on figuring out why...

xc-racer99 commented 5 years ago

Ok, volume key issue fixed - turns out GPH2(1) needs to be set as an output for the keys to work.

I think this is ready to merge as it's working on both a SGH-T959P and an i9000M, including suspend/resume on both Android and mainline linux.

Unless anyone has concerns, I'll go ahead and merge this in the next few days.