On 7/30/25 15:50, Ahmad Fatoum wrote:
> Hi,
>
> On 7/30/25 13:18, Ivaylo Ivanov wrote:
>> On 7/30/25 12:44, Ahmad Fatoum wrote:
>>> Hi,
>>>
>>> On 7/30/25 11:16, Ivaylo Ivanov wrote:
>>>> On 7/30/25 11:48, Ahmad Fatoum wrote:
>>>>> Hi Ivaylo,
>>>>>
>>>>> On 7/29/25 22:36, Ivaylo Ivanov wrote:
>>>>>> Add support for Samsung Galaxy S20 5G, based on exynos990, to the
>>>>>> current samsung board support. This platform, just like exynos8895,
>>>>>> needs a bit to be set in order to allow the framebuffer to refresh.
>>>>>>
>>>>> Oh, a shame that I sold the old S20 FE I had. :/
>>>>> I still have a rooted S10e though. I should give this a try when I have
>>>>> time.
>>>> Heh, I was thinking about getting an s10e to bring up mainline linux on it,
>>>> but I do have quite a lot of devices to work on right now. At the very
>>>> least,
>>>> I expect to throw in support for 7580 and 8890 in the future for both
>>>> mainline linux and barebox. The plan ideally will be to bring up support
>>>> for
>>>> exynos7580 in barebox to a decent state, with mmc and usb working at least.
>>>> S20 series are decently supported, but nothing exciting yet.
>>> Cool stuff. Looking forward to it. :-)
>>>
>>>> Another qustion: are there any plans to support booting fit images from an
>>>> address in ram instead of a file? I suspect porting over all the ufs stuff
>>>> from
>>>> linux will be a hassle
>>> It's something we will want sooner or later, but yes, it will likely be
>>> involved.
>>>
>>>> , so for S20 (which does not have an sd card slot, only ufs)
>>>> booting a fit image that s-boot has loaded into ram for us might be neat.
>>>> As far as I've seen, only "go" can do that, but not "bootm".
>>> $ addpart /dev/ram0 0x1000@0x1000(fit)
>>> $ bootm /dev/ram0.fit
>>>
>>> would've been the workaround so far.
>> Oh, nice. I'll give it a shot and if it works, I'll include it
>> in a config in the board dir as default boot behavior
>> (we really cannot interact with the console yet anyways).
> I think a convenient behavior, at least during development is to set
> autoboot=menu and set a menu timeout. Then add a config option that
> remaps volume up/down to up/down and some button as return and you
> should at least be able to navigate the menu.
>
> After timeout expires, system would boot normally.
Hm, I haven't thought of that. Mapping keys will need a pinctrl/gpio driver
though, so I think it will be best to just have default boot behavior as
bootm'ing a fit image from ram, while also having autoboot=menu
and a timeout set. That way we can expand it after adding keys in the
future. Does that sound good?
Best regards,
Ivaylo
>
>>> Since the fuzzing infrastructure has been merged, we also have
>>> ramdisk_init, which sets up a block device on top of a memory buffer
>>> without block layer caching. I think that's sufficient to implement
>>> losetup(8), which would go beyond addpart and even allow mounting file
>>> systems from the loop device.
>> I see. Looking forward to that.
>>
>> Best regards,
>> Ivaylo.
>>
>>> Cheers,
>>> Ahmad
>>>
>>>
>>>
>>>> Best regards,
>>>> Ivaylo
>>>>
>>>>>> diff --git a/arch/arm/dts/exynos990-x1s.dts
>>>>>> b/arch/arm/dts/exynos990-x1s.dts
>>>>>> new file mode 100644
>>>>>> index 00000000..19d59eaa
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/dts/exynos990-x1s.dts
>>>>>> @@ -0,0 +1,13 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>>>>>> +/*
>>>>>> + * Samsung Galaxy S20 5G (x1s/SM-G981B) barebox device tree source
>>>>>> + *
>>>>>> + * Copyright (c) 2025, Ivaylo Ivanov <ivo.ivanov.ivan...@gmail.com>
>>>>>> + */
>>>>>> +
>>>>>> +/dts-v1/;
>>>>>> +#include <arm64/exynos/exynos990-x1s.dts>
>>>>>> +
>>>>>> +/ {
>>>>>> + barebox,disable-deep-probe;
>>>>> Same comment: we want deep probe as default eventually. Did you run into
>>>>> problems without this?
>>>>>
>>>>> Cheers,
>>>>> Ahmad
>>>>>
>>>>>> +};
>>
