Recent Posts
21
Hardware / Re: HiBy R1
« Last post by 7o9 on November 29, 2024, 05:32:21 AM »I have been playing with the firmware update file, trying to see if I could modify it a bit.
Unpacking the firmware and repacking it without making changes is not a problem. The update ISO file is not identical (though the contents are) but still valid and flashing the firmware worked fine.
I tried making changes to the rootfs.squashfs file (extracting it using unsquashfs, rebuilding it using mksquashfs) seemed to work fine. Creating an r1.upt ISO file from it worked like before and the player successfully flashed the modified file.
Unfortunately, the device no longer started after that. The changes to the rootfs.squashfs file or the way I rebuild it using mksquashfs must have broken it.
However, I learned that if you put a working (i.e. the official one from HiBy
) firmware file on the sd card and hold volume+ while powering it on, it will flash it back into life.
My HiBy R1 lives again and I learned that it is hard to really brick.
In between attempts to revive it, the USB boot mode of course still worked but I have no way to run anything using that yet.
Unpacking the firmware and repacking it without making changes is not a problem. The update ISO file is not identical (though the contents are) but still valid and flashing the firmware worked fine.
I tried making changes to the rootfs.squashfs file (extracting it using unsquashfs, rebuilding it using mksquashfs) seemed to work fine. Creating an r1.upt ISO file from it worked like before and the player successfully flashed the modified file.
Unfortunately, the device no longer started after that. The changes to the rootfs.squashfs file or the way I rebuild it using mksquashfs must have broken it.
However, I learned that if you put a working (i.e. the official one from HiBy
) firmware file on the sd card and hold volume+ while powering it on, it will flash it back into life. My HiBy R1 lives again and I learned that it is hard to really brick.
In between attempts to revive it, the USB boot mode of course still worked but I have no way to run anything using that yet.
22
Hardware / Re: HiBy R1
« Last post by emilyinspace on November 27, 2024, 04:38:48 PM »I am guessing that the biggest problem would be the touch driver, no? since most rockbox devices don't have a touch screen :'(
23
Hardware / Re: AIGO EROS Q / AIGO EROS K / IRULU Surfans F20 / AGPTek H3 / HIFI WALKER H2
« Last post by emilyinspace on November 27, 2024, 04:37:28 PM »Big thanks for these last couple of changes, my v1.8 device has the LCD inverted problem now fixed and device seems more stable (previously had some kernel? panics randomly when opening files...no more).
24
Rockbox General Discussion / Re: HIFI Walker H2 hw3 aux plug not working
« Last post by dconrad on November 27, 2024, 04:35:31 PM »Sounds like there's a couple things going on here.
First, please see this page: https://www.rockbox.org/wiki/ErosQNativeTroubleshooting. Due to the way the headphone port detection works, only a pair of headphones will work with the headphone port. An amplifier, aux cord, any device which is not headphones will not work with the headphones port.
Secondly, if wiggling it around makes it kind of work, it may be physically damaged. There's nothing we can do about that in software.
Third, if you reference section 6.1 of the manual, the maximum volume limit in the sound settings can be used to change the volume level of the line out port.
Hope that helps!
First, please see this page: https://www.rockbox.org/wiki/ErosQNativeTroubleshooting. Due to the way the headphone port detection works, only a pair of headphones will work with the headphone port. An amplifier, aux cord, any device which is not headphones will not work with the headphones port.
Secondly, if wiggling it around makes it kind of work, it may be physically damaged. There's nothing we can do about that in software.
Third, if you reference section 6.1 of the manual, the maximum volume limit in the sound settings can be used to change the volume level of the line out port.
Hope that helps!
25
Rockbox General Discussion / Re: Donation - just not via PayPal
« Last post by The Bagel Bird on November 27, 2024, 03:08:37 PM »First of all I would like to thank all developers and active forum participants for their commitment.
I would like to support the project with a donation, but not via PayPal.
Are there other options?
I think the only other mechanism we're in a position to use is Zelle, which requires the sender to have a US bank account.
Damn... really? I'm in Canada...
I want to donate at some point, when I'll have a little more money!
Could you guys use a patreon?
26
Rockbox General Discussion / HIFI Walker H2 hw3 aux plug not working
« Last post by The Bagel Bird on November 27, 2024, 03:05:04 PM »The headphone cable port specifically doesn't work, the line port works but I can't change the volume so it's not really handy.
I need to wiggle the cable around in order for it to work and if I move it again it stops working again.
My headphones are not the culprit because it does the same thing on my speaker.
And my aux cable isn't either because I bought a new one just to check that was it and the same issue comes up again.
So as a final check, I switched back to the original firmware and it didn't have that issue of wiggling the cable around to make it work/unwork.
So it's gotta be an issue with rockbox... right?
I reset my settings to see if that was it and it still does it...
I updated my rockbox version to the version that released yesterday but if I recall correctly the problem was already there.
Like the post title says, I am on the HIFI Walker H2 hw3 (version 1.8 if that matters)
I use the daily build of the 26th of november and yeah that's about it.
I can give you guys files if you need to, to help diagnose the problem.
I am new to rockbox and downloaded it about a month ago.
I made an account to report the issue so sorry if this might be on the wrong page.
I need to wiggle the cable around in order for it to work and if I move it again it stops working again.
My headphones are not the culprit because it does the same thing on my speaker.
And my aux cable isn't either because I bought a new one just to check that was it and the same issue comes up again.
So as a final check, I switched back to the original firmware and it didn't have that issue of wiggling the cable around to make it work/unwork.
So it's gotta be an issue with rockbox... right?
I reset my settings to see if that was it and it still does it...
I updated my rockbox version to the version that released yesterday but if I recall correctly the problem was already there.
Like the post title says, I am on the HIFI Walker H2 hw3 (version 1.8 if that matters)
I use the daily build of the 26th of november and yeah that's about it.
I can give you guys files if you need to, to help diagnose the problem.
I am new to rockbox and downloaded it about a month ago.
I made an account to report the issue so sorry if this might be on the wrong page.
27
Hardware / Re: HiBy R1
« Last post by dconrad on November 27, 2024, 02:07:47 PM »Certainly an interesting device. The more similar the X1600 is to the X1000 the easier it would be, if we wanted to do a native port. Probably still a fair amount of work to get it on the X1600 regardless.
28
The new HiBy R1 might be a candidate for running Rockbox.
It is running an Ingenic X1600 SoC using a Cirrus Logic CS43131 DAC with a 3" 800x480 on a Linux-4.4.94+ kernel.
Product information: https://store.hiby.com/products/hiby-r1
Like other Ingenic devices, it supports the USB boot mode. When holding down the 'next' button and plugging the USB cable, the device identifies as 'Ingenic USB BOOT DEVICE' with USB ID A108:EAEF.
A first firmware update is available here: https://store.hiby.com/apps/help-center
The firmware file is a renamed .iso file which can be extracted. It contains the Linux kernel (xImage) and a root filesystem in SquashFS format.
Drivers included (in directory 'module_driver') include axp2101, cw2015, lcd_lg35583, tcs1421, cst8xx_touch, codec_cs43131 and others. Most drivers include a script to load them which provides some helpful parameters (like gpio's).
For example:
lcd_lg35583.sh: insmod lcd_lg35583.ko gpio_lcd_power_en=-1 gpio_lcd_rst=PA31 gpio_spi_cs=PA30 gpio_spi_sck=PA00 gpio_spi_mosi=PA01 spi_bus_num=5 vcc_regulator_name=bldo1 vccio_regulator_name=bldo2
codec_cs43131.sh: insmod codec_cs43131.ko cs43131_i2c_bus_num=3 cs43131_pwr_gpio=PB02 cs43131_pwr_en_level=1 \
cs43131_rst_gpio=PB21 cs43131_rst_en_level=1 \
cs43131_mute_gpio=-1 cs43131_mute_en_level=-1 \
cs43131_po_sel_gpio=-1 cs43131_po_sel_en_level=-1
The attached picture is of the HiBy R1 next to a Sansa Clip+ for size reference.
It is running an Ingenic X1600 SoC using a Cirrus Logic CS43131 DAC with a 3" 800x480 on a Linux-4.4.94+ kernel.
Product information: https://store.hiby.com/products/hiby-r1
Like other Ingenic devices, it supports the USB boot mode. When holding down the 'next' button and plugging the USB cable, the device identifies as 'Ingenic USB BOOT DEVICE' with USB ID A108:EAEF.
A first firmware update is available here: https://store.hiby.com/apps/help-center
The firmware file is a renamed .iso file which can be extracted. It contains the Linux kernel (xImage) and a root filesystem in SquashFS format.
Drivers included (in directory 'module_driver') include axp2101, cw2015, lcd_lg35583, tcs1421, cst8xx_touch, codec_cs43131 and others. Most drivers include a script to load them which provides some helpful parameters (like gpio's).
For example:
lcd_lg35583.sh: insmod lcd_lg35583.ko gpio_lcd_power_en=-1 gpio_lcd_rst=PA31 gpio_spi_cs=PA30 gpio_spi_sck=PA00 gpio_spi_mosi=PA01 spi_bus_num=5 vcc_regulator_name=bldo1 vccio_regulator_name=bldo2
codec_cs43131.sh: insmod codec_cs43131.ko cs43131_i2c_bus_num=3 cs43131_pwr_gpio=PB02 cs43131_pwr_en_level=1 \
cs43131_rst_gpio=PB21 cs43131_rst_en_level=1 \
cs43131_mute_gpio=-1 cs43131_mute_en_level=-1 \
cs43131_po_sel_gpio=-1 cs43131_po_sel_en_level=-1
The attached picture is of the HiBy R1 next to a Sansa Clip+ for size reference.
29
User Interface and Voice / Re: Odd interface stuff in current/recent dev builds
« Last post by iPodVT on November 26, 2024, 10:14:57 AM »As for the reason for not keeping builds older than 2 weeks, that's quite simple -- each set of daily build artifacts takes up about 5.3GB, and storage gets expensive fast.
Meanwhile. Please try the latest dev buiild. It includes a change for a corner case that I'd missed when doing the ata/bigsector refactoring.
https://build.rockbox.org/data/rockbox-ipod6g.zip
EDIT: pressed send to soon, added description of the link.
Re the storage requirements of archiving older dev builds: Right - of course. I tend to forget that there are many different makes and models of Rockboxed DAPs other than the one that I am holding in my hand in any given moment.
I tried the exp build you posted above (before your edit to the build's description) and "Yes" remained "Yes" in the No/Yes menu. I didn't find a 'Dump log file' item in the Debug menu so I'm guessing you are not looking for a log file with this one.
30
User Interface and Voice / Re: Odd interface stuff in current/recent dev builds
« Last post by speachy on November 26, 2024, 09:53:12 AM »The reason I want access to those dev builds older than 14 days (or more specifically from Sept 9 through Oct 29) is that I have an ipod6g currently running f7db73097a-240909 that doesn't exhibit the problem with the No/Yes menus. And I first noticed and reported the No/Yes menu bug with an ipod6g that was running 914a56f34c-241029 [https://forums.rockbox.org/index.php/topic,55041.0.html]. So using a binary-search-type process of elimination with dev builds from the earlier to the later, it should only take me a handful or so of tries to find the dev build in which the bug first appeared. That could lead us to the change(s) that caused the bug.
Oh, I know exactly _what_ change introduced the problem; it was part of a long series of patches to make it possible to use more modern ATA drivers (and eventually, exFAT). The question was _why_ it broke; the symptoms don't make sense given the actual code.
As for the reason for not keeping builds older than 2 weeks, that's quite simple -- each set of daily build artifacts takes up about 5.3GB, and storage gets expensive fast.
There's a reasonable argument to be made to staggering things a litle (eg daily builds for a week, then weekly, then monthly) but that needs to be scripted robustly, and the retention timeframe is still going to be fairly short due to trying to keep the disk space in check. The "proper" solution is more frequent releases but bugs like this (iie regressions caused from trying to deal with ongoing joy of needing to deal with folks modding two-decade-old hardware) need to be solved first.
Meanwhile. Please try the latest dev buiild. It includes a change for a corner case that I'd missed when doing the ata/bigsector refactoring.
https://build.rockbox.org/data/rockbox-ipod6g.zip
EDIT: pressed send to soon, added description of the link.